Looking at your source tree I assume you're talking about the hadoop branch :)
Generally speaking there's two modes of operations with git: A) Public mode You're pushing the code to a public repo like apache and you cannot rewrite the code (at least /should/ not) A lot of people would recommend that you simply do /not/ merge from master into your branch unless there is something on master you actually require. With reasonably mature code bases this quite often works. If there is lots of concurrent/overlapping activity things get worse. It's quite educational some times to actually try not merging from master :) B) Private mode Not all your changes need to be pushed to the public repo. If your collaborators are known you can do a lot more stuff that'll keep your changeset clean (like rebasing). I almost exclusively rebase the branches on my "private" github clones (not very private actually...). It is quite common to request that people fix up their "private" history before submitting to the public repo. But then again, it is usually not considered good form to *require* this. If you intend to be a number of people collaborating over a repo that gets rewritten you need a little more git-skills for everyone involved. Kristian 2015-01-14 12:52 GMT+01:00 Rob Vesse <[email protected]>: > For branches that haven't diverged too much you can do a git rebase > instead but that is more error prone and personally I dislike it because > it essentially changes history and certainly you can't safely do it for > branches that have been pushed remotely which is almost inevitable for > longer lived feature branches. Given that one of the core ASF principles > around IP is that the provenance of code should be maintained I prefer (at > least for the ASF) not to do anything that changes the history. > > (NB - Before git experts shoot me down technically you can do it for > pushed branches but it likely requires deleting the remote branch and > pushing the rebased branch. This is also very brittle if multiple people > are trying to work on the same feature branch) > > Probably the best thing to do from a workflow perspective is to ask people > to push new code separately from merges. So if I have a branch with > changes that I want to bring up to date I would do the following: > > 1 - Push the new code for the feature branch > 2 - Merge master into the feature branch > 3 - Push the merged changes for the feature branch > > That way you'd get a separate set of emails for the merges and the actual > new code > > Rob > > On 14/01/2015 11:09, "Andy Seaborne" <[email protected]> wrote: > >>Fine tuning our processes ... >> >>Rob is now ahead with "[??/93]" :-) OK - he's sub-contracted the work >>of the actually commit to others. >> >>Is there anyway we can stop this? >> >>Is there a better way to merge two branches in git? >> >> Andy > > > >
