From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:13
Jay Soffian [off-list ref] writes:
So then, why does "git merge FETCH_HEAD" bother to strip out a
not-for-merge marker that wouldn't be there?
In general, FETCH_HEAD is usable as an extended SHA-1, in that any file
that is in .git/ and begins with [0-9a-f]{40} names that object. That is
how "git log -p ..FETCH_HEAD" in my example worked.
The reason stripping of not-for-merge is done is to support a usage that
is not so sane as well.
You can do a wildcard fetch that leaves full of not-for-merge entries in
FETCH_HEAD, and then use FETCH_HEAD as an extended SHA-1 to merge the one
that happens to be on the first line. "git merge" *could* in such a case
produce:
Merge commit $ugly_40_hexadecimal_name
to say that it merged that commit named by a random extended SHA-1, but it
knows that FETCH_HEAD has better information than that. The line tells
where you got that commit from. And that is recorded past not-for-merge
marker (if exists, otherwise it is an empty string) that is enclosed by a
HT on each side. This is a direct translation from the scripted version
that did:
sed -e 's/ not-for-merge / /' -e 1q
It is being overly nice to produce a sensible merge message, even when you
asked it to do something not very sensible.
Now to something totally useless.
After reading the builtin-merge.c and original git-merge.sh (now in
contrib/examples) script, I think it could have done something entirely
different.
It could have done this instead.
sed -e '/ not-for-merge /d'
to learn the commits and their human-readable origins, and it could have
tried to reproduce what "git pull" did when it invoked git-merge using
that information. Then you could use this workflow:
$ git pull <possibly with arguments>
... oops, conflicted and is very messy.
... I tried to resolve, but failed and made the mess even worse.
... Let's start over.
$ git reset --hard
... FETCH_HEAD knows which refs are for merging
$ git merge FETCH_HEAD
That is, no matter what the arguments were for the initial "git pull",
what should be merged is recorded in FETCH_HEAD, and that is how you can
retry the merge without refetching over the network.
But such a change makes FETCH_HEAD different from what it traditionally
meant, and does that only to "git merge", making the result very
inconsistent. For example, "git log ..FETCH_HEAD" will still use the
object name on the first line, and it won't be a way to convince yourself
that the changes are sensible and it is Ok to run "git merge FETCH_HEAD"
anymore. So I do not think such a change will be an improvement.
From: Jay Soffian <hidden> Date: 2016-06-15 22:46:13
On Tue, Feb 17, 2009 at 3:35 AM, Junio C Hamano [off-list ref] wrote:
Now to something totally useless.
After reading the builtin-merge.c and original git-merge.sh (now in
contrib/examples) script, I think it could have done something entirely
different.
It could have done this instead.
sed -e '/ not-for-merge /d'
to learn the commits and their human-readable origins, and it could have
tried to reproduce what "git pull" did when it invoked git-merge using
that information. Then you could use this workflow:
$ git pull <possibly with arguments>
... oops, conflicted and is very messy.
... I tried to resolve, but failed and made the mess even worse.
... Let's start over.
$ git reset --hard
... FETCH_HEAD knows which refs are for merging
$ git merge FETCH_HEAD
That is, no matter what the arguments were for the initial "git pull",
what should be merged is recorded in FETCH_HEAD, and that is how you can
retry the merge without refetching over the network.
But such a change makes FETCH_HEAD different from what it traditionally
meant, and does that only to "git merge", making the result very
inconsistent. For example, "git log ..FETCH_HEAD" will still use the
object name on the first line, and it won't be a way to convince yourself
that the changes are sensible and it is Ok to run "git merge FETCH_HEAD"
anymore. So I do not think such a change will be an improvement.
Unless dwim_ref() is updated to handle FETCH_HEAD specially, and
return not the first SHA1, but the one not marked "not-for-merge".
Then the UI would at least be consistent, but this would not be
backward compatible.
j.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:13
Hi,
On Tue, 17 Feb 2009, Jay Soffian wrote:
On Tue, Feb 17, 2009 at 3:35 AM, Junio C Hamano [off-list ref] wrote:
quoted
Now to something totally useless.
After reading the builtin-merge.c and original git-merge.sh (now in
contrib/examples) script, I think it could have done something entirely
different.
It could have done this instead.
sed -e '/ not-for-merge /d'
to learn the commits and their human-readable origins, and it could have
tried to reproduce what "git pull" did when it invoked git-merge using
that information. Then you could use this workflow:
$ git pull <possibly with arguments>
... oops, conflicted and is very messy.
... I tried to resolve, but failed and made the mess even worse.
... Let's start over.
$ git reset --hard
... FETCH_HEAD knows which refs are for merging
$ git merge FETCH_HEAD
That is, no matter what the arguments were for the initial "git pull",
what should be merged is recorded in FETCH_HEAD, and that is how you can
retry the merge without refetching over the network.
But such a change makes FETCH_HEAD different from what it traditionally
meant, and does that only to "git merge", making the result very
inconsistent. For example, "git log ..FETCH_HEAD" will still use the
object name on the first line, and it won't be a way to convince yourself
that the changes are sensible and it is Ok to run "git merge FETCH_HEAD"
anymore. So I do not think such a change will be an improvement.
Unless dwim_ref() is updated to handle FETCH_HEAD specially, and
return not the first SHA1, but the one not marked "not-for-merge".
Then the UI would at least be consistent, but this would not be
backward compatible.
You cannot fix parsing FETCH_HEAD as a ref (and neither will you be able
to do with PUSH_HEAD), as it can contain _more_ than one SHA-1s. This
still holds true when ignoring the not-for-merge lines, as an octopus is
a quite real possibility.
Ciao,
Dscho
From: Jay Soffian <hidden> Date: 2016-06-15 22:46:13
On Tue, Feb 17, 2009 at 12:22 PM, Johannes Schindelin
[off-list ref] wrote:
quoted
Unless dwim_ref() is updated to handle FETCH_HEAD specially, and
return not the first SHA1, but the one not marked "not-for-merge".
Then the UI would at least be consistent, but this would not be
backward compatible.
You cannot fix parsing FETCH_HEAD as a ref (and neither will you be able
to do with PUSH_HEAD), as it can contain _more_ than one SHA-1s. This
still holds true when ignoring the not-for-merge lines, as an octopus is
a quite real possibility.
An even better argument against than it not being backward compatible. :-)
And there is no PUSH_HEAD.
j.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:13
Hi,
On Tue, 17 Feb 2009, Jay Soffian wrote:
On Tue, Feb 17, 2009 at 12:22 PM, Johannes Schindelin
[off-list ref] wrote:
quoted
quoted
Unless dwim_ref() is updated to handle FETCH_HEAD specially, and
return not the first SHA1, but the one not marked "not-for-merge".
Then the UI would at least be consistent, but this would not be
backward compatible.
You cannot fix parsing FETCH_HEAD as a ref (and neither will you be able
to do with PUSH_HEAD), as it can contain _more_ than one SHA-1s. This
still holds true when ignoring the not-for-merge lines, as an octopus is
a quite real possibility.
An even better argument against than it not being backward compatible. :-)
And there is no PUSH_HEAD.
Heh, that's why I used the future tense :-)
Ciao,
Dscho