Mecanism for excluding branches from the octopus
Usecases :
- 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 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 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 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:none -
current:current -
upstream:upstream -
simple: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, probablynone
-
We 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
@benba @geofberard It's a bit dense, sorry for that. Tell me if there's anything not clear or missing. It's an opened discussion of course.
Seems great to me , it's much more elaborated than what I had in mind :-)
For the syntax to exclude I would suggest something like -e pattern instead of !branch-to-exclude because branch can be created with a leading !
ex: git octopus -e octopus-* -e master features/*
A very straight forward implementation would be to git ls-remote the matching pattern as today
then git ls-remote with all exclude patterns
and then retain only branches that are not in the intersection of both lists.
The advantage is than the pattern syntax would be exactly the same between the include part and the exclude part.
How do we deal with the config then ? It seems that we'll have to introduce a new config key like octopus.excludePattern
@benba @apflieger I've a modification which does exactly that. With -e option and octopus.excludePattern config key. I'll try to clean up the code and make a PR.
And @apflieger +1 for detecting automatically the branch to exclude
Hi @ozangunalp, we haven't met yet! This would be welcome.
Update : the first part is in the master branch and will be part of the next release (1.4)