Merging and symmetry. Innocent question.

[Nathann Cohen]

Helloooooooooo everybody !

Given a very old commit and a more recent version of "master" (and knowing that I would like to avoid to checkout the old commit as I would need to recompile a lot of things), and given a new patch that I have to write which has this old patch as a dependency.

1) Is it safe to work on "master" only, create a new branch there, merge the old commit into it and write the patch ?

2) Or is it necessary to checkout the old commit, merge master in there, and write the patch then ?

Thank you for your help ! :-)

Nathann

[Volker Braun]

As far as source code is concerned, the only difference between

git checkout master

git merge old_branch

and 

git checkout old_branch

git merge master

is the order of the two parents on the merge commit. Depending on where you currently are, time stamps on different sets of files will be modified though.

[Nathann Cohen]

> is the order of the two parents on the merge commit. Depending on where you currently are, time stamps on different sets of files will be modified though.

And does that make any difference for the review of for Sage's final
source code ? Is any of the two ways preferred to the other, and for
which reason ?

Nathann

[Volker Braun]

The order of parents doesn't matter for Sage. Its only important for you if you want to use the HEAD^1 (or just HEAD^) and HEAD^2 syntax to refer to the first and second parent...

[Keshav Kini]

Volker Braun <vbrau...@gmail.com> writes:

> The order of parents doesn't matter for Sage. Its only important for
> you if you want to use the HEAD^1 (or just HEAD^) and HEAD^2 syntax
> to refer to the first and second parent...

IMHO this is actually very important at the release manager stage.
Walking up the tree from master following HEAD^1 at each step should
give you a concise history of merged tickets. In order to ensure this
is the case, the release manager should always do `git merge --no-ff`
when merging tickets. This is the discipline IPython enforced on their
repository and it has worked quite well for them.

What this means is that if you, as a ticket author, decide to merge your
ticket into master rather than master into your ticket, there's going to
be a sort of weird looking clump in the history graph when your ticket
is merged with --no-ff. You probably don't want to do this. Best
practice: ticket author merges master into their ticket branch,
maintainer merges ticket branches into master.

-Keshav

[Nathann Cohen]

Okay I see. Then this should probably be reported by the buldbot when not done as it should be, and it's going to be very painful after a while if we have to recompile every beta release for each patch waiting for a review when Sage is released :-P

Nathann

--
You received this message because you are subscribed to the Google Groups "sage-git" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-git+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Robert Bradshaw]

On Sun, Nov 17, 2013 at 9:29 AM, Keshav Kini <kesha...@gmail.com> wrote:
> Volker Braun <vbrau...@gmail.com> writes:
>
>> The order of parents doesn't matter for Sage. Its only important for
>> you if you want to use the HEAD^1 (or just HEAD^) and HEAD^2 syntax
>> to refer to the first and second parent...
>
> IMHO this is actually very important at the release manager stage.
> Walking up the tree from master following HEAD^1 at each step should
> give you a concise history of merged tickets. In order to ensure this
> is the case, the release manager should always do `git merge --no-ff`
> when merging tickets. This is the discipline IPython enforced on their
> repository and it has worked quite well for them.

Yes, the release manager (script) should take care of this.

> What this means is that if you, as a ticket author, decide to merge your
> ticket into master rather than master into your ticket, there's going to
> be a sort of weird looking clump in the history graph when your ticket
> is merged with --no-ff. You probably don't want to do this. Best
> practice: ticket author merges master into their ticket branch,
> maintainer merges ticket branches into master.

Could you clarify with an example? It'll all happen within the
ticket-specific branch.

- Robert

[Volker Braun]

On Sunday, November 17, 2013 12:29:20 PM UTC-5, Keshav Kini wrote:

IMHO this is actually very important at the release manager stage.

Agree, though that is nothing that Nathan has to worry about unless he wants to become the release manager ;-)

 

[Keshav Kini]

Robert Bradshaw <robe...@gmail.com> writes:
> On Sun, Nov 17, 2013 at 9:29 AM, Keshav Kini <kesha...@gmail.com> wrote:
>> Volker Braun <vbrau...@gmail.com> writes:
>>
>>> The order of parents doesn't matter for Sage. Its only important for
>>> you if you want to use the HEAD^1 (or just HEAD^) and HEAD^2 syntax
>>> to refer to the first and second parent...
>>
>> IMHO this is actually very important at the release manager stage.
>> Walking up the tree from master following HEAD^1 at each step should
>> give you a concise history of merged tickets. In order to ensure this
>> is the case, the release manager should always do `git merge --no-ff`
>> when merging tickets. This is the discipline IPython enforced on their
>> repository and it has worked quite well for them.
>
> Yes, the release manager (script) should take care of this.

OK, great!

>> What this means is that if you, as a ticket author, decide to merge your
>> ticket into master rather than master into your ticket, there's going to
>> be a sort of weird looking clump in the history graph when your ticket
>> is merged with --no-ff. You probably don't want to do this. Best
>> practice: ticket author merges master into their ticket branch,
>> maintainer merges ticket branches into master.
>
> Could you clarify with an example? It'll all happen within the
> ticket-specific branch.

You're right, sorry. I was imagining a slightly more convoluted release
management process (wrt to git) than was necessary. Indeed it will look
more or less the same on the first-parent spine of master.

Still, though, I think it's good practice to merge things into
the branch you've been working on, rather than merge the branch you've
been working on into other things and then move your branch pointer to
the result. When someone is browsing git history and sees a merge
commit, they would typically expect the first parent to point backwards
along the sort of "main line" of the branch that whoever made the commit
was working on. If that is not the case, navigation can be kind of
confusing.

This kind of assumption is also visible on github, for example, in the
Network view -- the first parent is typically shown as connected to the
merge commit by a solid line, whereas the second parent has an angled
arrow pointing at the merge commit (to show that it was sort of "merged
in" to an existing line of commits).

-Keshav

[Keshav Kini]

Keshav Kini <kesha...@gmail.com> writes:
> This kind of assumption is also visible on github, for example, in the
> Network view -- the first parent is typically shown as connected to the
> merge commit by a solid line, whereas the second parent has an angled
> arrow pointing at the merge commit (to show that it was sort of "merged
> in" to an existing line of commits).

Here's an example, btw: https://github.com/kini/merging-example/network

-Keshav

[Volker Braun]

On Sunday, November 17, 2013 3:08:51 PM UTC-5, Keshav Kini wrote:

the result.  When someone is browsing git history and sees a merge
commit, they would typically expect the first parent to point backwards
along the sort of "main line" of the branch that whoever made the commit
was working on.  If that is not the case, navigation can be kind of
confusing.

It is only confusing if you rely on hidden assumptions. Since we don't enforce any particular ordering, and can't change it, its imho best to just get used to the order being random.Realistically you are going to browse the log by looking for what kind of code was added in a particular ticket excluding the previous ticket. Then the order of the auxiliary merges commits inside the ticket branch doesn't matter.

[Keshav Kini]

Sure, I'm not suggesting you enforce that. I just think it's good
practice. It may be a "hidden" assumption but I think it's a pretty
common one among git users.

-Keshav