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@xxxxxxxxxxx> www.herland.net
Attachment:
signature.asc
Description: This is a digitally signed message part.