[Numpy-discussion] Remove current 1.7 branch?

Hänel Nikolaus Valentin valentin.haenel@epfl...
Thu Jul 12 07:45:30 CDT 2012


Hi,

* Charles R Harris <charlesr.harris@gmail.com> [2012-07-12]:
> Travis and I agree that it would be appropriate to remove the current 1.7.x
> branch and branch again after a code freeze. That way we can avoid the pain
> and potential errors of backports. It is considered bad form to mess with
> public repositories that way, so another option would be to rename the
> branch, although I'm not sure how well that would work. Suggestions?

I am a silent listener on this list, but in this case I may have some
valuable insights to share, on the two proposed options:

1) delete the branch

You can delete the branch in the remote repository. Anyone using the --prune
option for fetch, pull or remote update will have their corresponding
remote-tracking-branch deleted (pruned) automatically.

The problem arises, if people have created a local branch from the
remote-tracking-branch, they need to explicitly delete it. If they don't, they
risk pushing that branch again after it has been recreated in the remote
repository (depends on the setting of 'push.default').

In fact, what I have seen in the past is people not deleting their local branch
and when the branch is recreated, they receive a message from git when they
push, that the branch could not be updated. This is because their setting for
'push.default' is set to 'matching' (which is the default) and suddenly the
branch has appeared again in the remote repo, so git tries to push the local
branch to remote branch (since they have the same name).

But their local version of this branch is still at the old position and because
the new remote branch does not contain the old branch's commits, a fast-forward
is not possible and they end up merging the old commits into the new branch in
a feeble attempt to somehow get rid of the annoying error message.  In the end,
you have a really bad mess including random merge commits that make no sense
and suddenly re-appearing commits that were supposed to have been long
forgotten.

Do you trust everyone to a) read the mail the explains the need to delete their
local branch and b) actually go and delete it? ;)

Incidentally, if you wish the commits on the branch to be included in master,
you must cherry-pick them, but from what I gather that has already been done.

2) merge the branch to master

You can merge the branch to master and leave it at that. In this case, when you
wish to make use of the branch again at a later stage, you fast-forward the
branch to the commit from where it should be used again (which is most probably
the commit that master points to) and then commit on that branch to actually
create the bifurcation.

With this option, nobody needs to take any explicit action. Anyone who has
created a local branch to track that branch can simply merge the new
remote-tracking-branch by fast-forward as and when it is used again.

Of course, you must include all commits that are on that branch. If
there are any commits who's changes you would not like to see in master,
first merge, and the use 'git revert' on those commits to undo the
changes.

So, as you can see it depends on the git skill-level of the developers, how
much risk you are willing to take, and how clean and pure you would like to
have your history. Personally, I would favour option 1) since it is the
cleaner solution, but in the light of the probable number of forks of the
numpy repo, option 2) sounds like a safer bet IMHO.

Hope that helps.

V-


More information about the NumPy-Discussion mailing list