You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 30, 2025. It is now read-only.
In some configuration, all branches of a repo are merged in a octopus. For instance, having multiple repos, one of them called 'features', is a good practice. The resulting merge of the 'features' repo can't be pushed on the repo itself because it would be taken itself in a subsequent octopus merge. The workaround is to push the merge on a separate repo (this is what LesFuets.com does).
A developper pushed his branch and broke the octopus merge. He tries to fix it on his local repo. To do so, he commits changes on his local branch and run git octopus locally to test if it fixes the merge. The problem is that this local octopus will include the remote branch as well as the local one, which causes conflicts in most cases. The only workaround we have currently is to delete the remote branch locally with git update-ref -d refs/remotes/origin/branch_name before running the local octopus.
In both cases, we just need to exclude a given branch from the merge. We need to consider both usecases for finding an elegant solution.
I came up with some ideas. First thing is that in both cases, we would expect the exclusion to be done everytime the command is run. So it should be declarable in configuration.
Proposal:
Allow a new syntax that negate branch pattern : !branche-to-exclude or even !branch-*. This would work as both command argument and configuration entry.
Allow git octopus to detect and exclude automatically the remote branch that correspond to the local branch you are on. This behavior itself should be configurable (conf key octopus.exclude) with the following values :
none (default): don't detect the remote branch
current: exclude branches that have the same name that the current local branch
upstream: read the upstream configuration of the current local branch. I'm not sure if this value is needed but maybe just for consistency/transparency on how it works internally.
pushDefault: automatically choose between none, current and upstream depending on the value of the push.default config (see git-config push.default section). This could be the default value on the next major release of git-octopus. Here's the mapping between push.default values and the resulting remote detection:
nothing : none
current : current
upstream : upstream
simple : current or upstream. The latter is the safest because it will match the remote part of the ref which is not possible in the current mode. See bellow.
matching : I'm not sure, probably none
We need to choose the behavior of the current value regarding remotes. git push uses the notion of 'remote' whereas git octopus doesn't. This means that in the current mode, we are not able to determine the remote part of the ref (of the remote branch we are looking for) in the context of a git octopus run. I don't think it is a big deal, let's just trip off refs/heads/ of the current branch ref, grep it on the list of branches beeing merged and exclude the result.
Note that 1. and 2. could be implemented seperately
Usecases :
git octopuslocally to test if it fixes the merge. The problem is that this local octopus will include the remote branch as well as the local one, which causes conflicts in most cases. The only workaround we have currently is to delete the remote branch locally withgit update-ref -d refs/remotes/origin/branch_namebefore running the local octopus.In both cases, we just need to exclude a given branch from the merge. We need to consider both usecases for finding an elegant solution.
I came up with some ideas. First thing is that in both cases, we would expect the exclusion to be done everytime the command is run. So it should be declarable in configuration.
Proposal:
Allow a new syntax that negate branch pattern :
!branche-to-excludeor even!branch-*. This would work as both command argument and configuration entry.Allow
git octopusto detect and exclude automatically the remote branch that correspond to the local branch you are on. This behavior itself should be configurable (conf key octopus.exclude) with the following values :none(default): don't detect the remote branchcurrent: exclude branches that have the same name that the current local branchupstream: read the upstream configuration of the current local branch. I'm not sure if this value is needed but maybe just for consistency/transparency on how it works internally.pushDefault: automatically choose betweennone,currentandupstreamdepending on the value of the push.default config (see git-config push.default section). This could be the default value on the next major release of git-octopus. Here's the mapping between push.default values and the resulting remote detection:nothing:nonecurrent:currentupstream:upstreamsimple:currentorupstream. The latter is the safest because it will match the remote part of the ref which is not possible in thecurrentmode. See bellow.matching: I'm not sure, probablynoneWe need to choose the behavior of the
currentvalue regarding remotes.git pushuses the notion of 'remote' whereasgit octopusdoesn't. This means that in thecurrentmode, we are not able to determine the remote part of the ref (of the remote branch we are looking for) in the context of agit octopusrun. I don't think it is a big deal, let's just trip offrefs/heads/of the current branch ref, grep it on the list of branches beeing merged and exclude the result.Note that 1. and 2. could be implemented seperately