git merges

[Andy Seaborne <an...@apache.org>]

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

Re: git merges

[Kristian Rosenvold <kr...@apache.org>]

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 <rv...@dotnetrdf.org>:
> 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" <an...@apache.org> 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
>
>
>
>

Re: git merges

[Rob Vesse <rv...@dotnetrdf.org>]

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" <an...@apache.org> 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