On Sun, Sep 09, 2007 at 07:34:15PM +0200, Joakim Tjernlund wrote: > > > > -----Original Message----- > > From: Joakim Tjernlund [mailto:joakim.tjernlund@xxxxxxxxxxxx] > > Sent: den 9 september 2007 12:14 > > To: 'Eric Wong'; 'Junio C Hamano' > > Cc: 'git@xxxxxxxxxxxxxxx' > > Subject: RE: [PATCH] git-svn: understand grafts when doing dcommit > > > > > -----Original Message----- > > > From: Eric Wong [mailto:normalperson@xxxxxxxx] > > > Sent: den 9 september 2007 01:33 > > > To: Junio C Hamano > > > Cc: Joakim Tjernlund; git@xxxxxxxxxxxxxxx > > > Subject: [PATCH] git-svn: understand grafts when doing dcommit > > > > > > Use the rev-list --parents functionality to read the parents > > > of the commit. cat-file only shows the raw object with the > > > original parents and doesn't take into account grafts; so > > > we'll rely on rev-list machinery for the smarts here. > > > > > > Signed-off-by: Eric Wong <normalperson@xxxxxxxx> > > > --- > > > Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > "Joakim Tjernlund" <joakim.tjernlund@xxxxxxxxxxxx> writes: > > > > > > > > > hmm, I think git-cat-file is to blame. > > > > > git-cat-file commit > > > da783cce390ce013b19f1d308ea6813269c6a6b5 does > > > > > not list list any parent... > > > > > > > > The plumbing cat-file does not deal with grafts and this is > > > > deliberate. Otherwise you would not be able to find the true > > > > set of parents when you'd want to. > > > > > > > > So do not blame cat-file, but blame the Porcelain that uses > > > > cat-file to read a commit object, without annotating what it > > > > read with what is in grafts, in this case your command line > > > > experiment ;-). > > > > > > > > The log family of commands and rev-list plumbing while > > > > traversing commit ancestry chain do take grafts into account. > > > > > > > > One caveat is pretty=raw output format shows true parents > > > > without grafts on "parent " header line, while the "commit " > > > > fake header prepended in the output for each commit shows the > > > > parents that takes into account. > > > > > > > > To illustrate, if you forge the history and say the parent of > > > > 1ddea77 is 5da1606 (when the true parent is 820eca68) with > > > > grafts mechanism, here is what happens: > > > > > > > > $ echo '1ddea77e449ef28d8a7c74521af21121ab01abc0 > > > 5da1606d0bf5b970fadfa0ca91618a1e871f6755' >.git/info/grafts > > > > $ git show -s --pretty=raw --parents 1ddea77 > > > > commit 1ddea77e449ef28d8a7c74521af21121ab01abc0 > > > 5da1606d0bf5b970fadfa0ca91618a1e871f6755 > > > > tree e9e61bc801438062978ff47b0963c536ed1e51a9 > > > > parent 820eca68c2577d7499d203d7f4f7ae479b577683 > > > > author Nick Hengeveld <nickh@xxxxxxxxxxxx> 1127757131 -0700 > > > > committer Junio C Hamano <junkio@xxxxxxx> 1127805558 -0700 > > > > > > > > [PATCH] Return CURL error message when object > > > transfer fails > > > > > > > > Return CURL error message when object transfer fails > > > > ... > > > > > > Interesting. I didn't know about the --parents option before. > > > > > > git-svn.perl | 11 +++-------- > > > 1 files changed, 3 insertions(+), 8 deletions(-) > > > > > > diff --git a/git-svn.perl b/git-svn.perl > > > index fbd4691..f818160 100755 > > > --- a/git-svn.perl > > > +++ b/git-svn.perl > > > @@ -841,14 +841,9 @@ sub working_head_info { > > > > > > sub read_commit_parents { > > > my ($parents, $c) = @_; > > > - my ($fh, $ctx) = command_output_pipe(qw/cat-file commit/, $c); > > > - while (<$fh>) { > > > - chomp; > > > - last if ''; > > > - /^parent ($sha1)/ or next; > > > - push @{$parents->{$c}}, $1; > > > - } > > > - close $fh; # break the pipe > > > + chomp(my $p = command_oneline(qw/rev-list --parents -1/, $c)); > > > + $p =~ s/^($c)\s*// or die "rev-list --parents -1 $c failed!\n"; > > > + @{$parents->{$c}} = split(/ /, $p); > > > } > > > > > > sub linearize_history { > > > -- > > > Eric Wong > > > > Tested the patch and now it works, but I get the same > > complaints as I got > > when using filter-branch, lots of: > > r3 = 55a489bd4f66dd1f641a4676359d7b8911dc7d83 (git-svn) > > W: HEAD and refs/remotes/git-svn differ, using rebase: > > :100644 100644 f85ae11af7715a224015582724cb2bab87ec914a > > > > Tried to remove the .rev_db* file and rebuild it after I > > added the graft, but > > that didn't help. > > > > Just noticed I get > W: HEAD and refs/remotes/git-svn differ, using rebase: > :100644 100644 f85ae11af7715a224015582724cb2bab87ec914a > messages as soon as there is more than one commit in my master and then > doing a dcommit. This is something new with 1.5.3 It's a bit verbose, but this is correct behavior. It's the result of fixing a bug caused by dcommit not detecting conflicts caused by later commits when the commits were not fully rebased. Also, I believe you will only see it when later commits touch files that were touched by earlier commits in during the dcommit. For more details see: commit 751eb39590a1325e761a84bedd5ca2660d2d3497 Author: Eric Wong <normalperson@xxxxxxxx> Date: Fri Aug 31 18:16:12 2007 -0700 git-svn: fix dcommit clobbering upstream when committing multiple changes -chris - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
