Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)

[Johan Herland <johan@herland.net>]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

On Saturday 05 May 2007, Alex Riesen wrote:
> Johan Herland, Fri, May 04, 2007 13:53:10 +0200:
> > As for "Reverts", the commit pointed to should already be in your
> > history, since you cannot revert something that hasn't already been
> > applied at an earlier point in your history. In other words, the
> > reverted commit will automatically be included in your "git gc
> > --prune" or "git clone" regardless of the "Reverts" fields, since
> > "Reverts" can only point to an ancestor.
>
> So it becomes useless after rebase

Only if rebase also rebases the commit pointed to by "Reverts" (the 
reverted commit). And even in that case, it should be possible for 
rebase to detect the "Reverts" relationship and rewrite it properly, 
or - if people want to - skip both the reverted and the reverting 
commit in the rebase process.

> > As for "Cherry-Pick", it's a fairly weak relationship that
> > shouldn't affect anything except to give a hint to merge, blame,
> > and similar tools.
>
> In which case, just put it in the message part of commit (in fact, it
> was there for some time. And was mostly useless, and got dropped).

Ok. If merging branches which have had cherry-picks between them is such 
a rare occurrence that there is no point in adding hints for merge (to 
do better conflict resolution), blame (to see who _really_ wrote the 
piece of code that was cherry-picked by someone else), etc. then there 
is indeed no justification for the "Cherry-Pick" header field.

> And how exactly do you think the tools _can_ use this hint?
> Especially merge, which should be absolutely certain about what
> inputs and hints gets.

When merging two branches where one branch has a commit that is later 
reverted, and the other branch has cherry-picked the first/reverted 
commit, but not the second/reverting: With these hints, git can now ask 
the user a more intelligent question like "The following commit was 
reverted in one of the branches. Do you want to keep it or revert it?". 
The current alternative seems to be to auto-choose one or the other (in 
my testing, the reverting commit was dropped in the merge). Will git 
always make the correct decision? If git is always correct, then what I 
suggest is obviously useless.

> And what use is it for blame? How do you prioritze the hint? Is it
> more important than the history (which describes each and every
> line), or less? If the hint is more important, than how (and how
> often) do you tell the user that the hint was not found (because the
> commit is long pruned) and the tool switched back to looking into
> history.

Consider the following scenario:

----
$ mkdir test
$ cd test
$ git init
Initialized empty Git repository in .git/
$ git config user.name "User A"
$ cat >f <<\EOF
foo
bar
baz
EOF
$ git add f && git commit -m "User A: foo, bar, baz"
Created initial commit bb0203aabb4936d95dca30f946cb1d849df59f24
 1 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 f
$ git config user.name "User B"
$ cat >f <<\EOF
foo
barf
baz
EOF
$ git commit -a -m "User B: bar -> barf"
Created commit 5ced0ccaba0bf4a982dc2cdd792a1a0e7b1883eb
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git config user.name "User C"
$ git revert HEAD
Created commit 38da1083ae4677000f8bb70729f474f358c71a3e
 1 files changed, 1 insertions(+), 1 deletions(-)
----

At this point, what output do we _really_ want from "git blame f"?

Currently we get:
----
^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo
38da1083 (User C 2007-05-05 12:28:00 +0200 2) bar
^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz
----

Can you categorically say that there is no use for the following output? 
(even if you need to pass an option to "git blame" to get it):
----
^bb0203a (User A 2007-05-05 12:25:44 +0200 1) foo
^bb0203a (User A 2007-05-05 12:25:44 +0200 1) bar
^bb0203a (User A 2007-05-05 12:25:44 +0200 3) baz
----

> It's useless.

Maybe. At least some of the fields I proposed are probably useless. But 
I don't think we should throw away the core idea unless we can show 
that _all_ fields are useless.


Have fun!

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]