Re: git-cvsimport "you may need to merge manually"

merlyn@stonehenge.com (Randal L. Schwartz) writes:

Yeah, this doesn't make sense.  It used to "Just Work".  I can
certainly add "git reset --hard" to my workflow, if that's the real
work around.  And if so, the manpage should document that.

That should _not_ be the solution.

I think the behaviour we are seeing does not make much sense.
I'll take a deeper look at it tonight (or tomorrow if I am
unlucky), if nobody beats me to it.

Sorry about the breakage.

quoted

quoted

quoted

quoted

"Junio" == Junio C Hamano [off-list ref] writes:

Junio> I think the behaviour we are seeing does not make much sense.
Junio> I'll take a deeper look at it tonight (or tomorrow if I am
Junio> unlucky), if nobody beats me to it.

Junio> Sorry about the breakage.

No, *thanks* for looking at it.  Your tireless contributions
are well appreciated.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

I tested the version in today's "next" branch, and it fixes the
problem for me in my tests that use my day-job CVS repository as
a guinea pig.

In case you are not brave enough to switch to "next" wholesale,
but are kind enough to try out the relevant cvsimport change for
us, here is a patch that applies on top of "master".  It is a
roll-up of two commits on my jc/cvsimport branch.

-- >8 --
cvsimport: honor -i and non -i upon subsequent imports

Documentation says -i is "import only", so without it,
subsequent import should update the current branch and working
tree files in a sensible way.

"A sensible way" defined by this commit is "act as if it is a
git pull from foreign repository which happens to be CVS not
git".  So:

 - If importing into the current branch (note that cvsimport
   requires the tracking branch is pristine -- you checked out
   the tracking branch but it is your responsibility not to make
   your own commits there), fast forward the branch head and
   match the index and working tree using two-way merge, just
   like "git pull" does.

 - If importing into a separate tracking branch, update that
   branch head, and merge it into your current branch, again,
   just like "git pull" does.

Initial round of the updated code read the tip of the current
branch before and after the import runs, but forgot to chomp
what we read from the command.  The read-tree command did not
them with the trailing LF.  This has been fixed.

---

diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 02d1928..3728294 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl

@@ -453,6 +453,7 @@ chdir($git_tree);
 my $last_branch = "";
 my $orig_branch = "";
 my %branch_date;
+my $tip_at_start = undef;
 
 my $git_dir = $ENV{"GIT_DIR"} || ".git";
 $git_dir = getwd()."/".$git_dir unless $git_dir =~ m#^/#;

@@ -487,6 +488,7 @@ unless(-d $git_dir) {
 		$last_branch = "master";
 	}
 	$orig_branch = $last_branch;
+	$tip_at_start = `git-rev-parse --verify HEAD`;
 
 	# populate index
 	system('git-read-tree', $last_branch);

@@ -873,7 +875,22 @@ if (defined $orig_git_index) {
 
 # Now switch back to the branch we were in before all of this happened
 if($orig_branch) {
-	print "DONE; you may need to merge manually.\n" if $opt_v;
+	print "DONE.\n" if $opt_v;
+	if ($opt_i) {
+		exit 0;
+	}
+	my $tip_at_end = `git-rev-parse --verify HEAD`;
+	if ($tip_at_start ne $tip_at_end) {
+		for ($tip_at_start, $tip_at_end) { chomp; }
+		print "Fetched into the current branch.\n" if $opt_v;
+		system(qw(git-read-tree -u -m),
+		       $tip_at_start, $tip_at_end);
+		die "Fast-forward update failed: $?\n" if $?;
+	}
+	else {
+		system(qw(git-merge cvsimport HEAD), "refs/heads/$opt_o");
+		die "Could not merge $opt_o into the current branch.\n" if $?;
+	}
 } else {
 	$orig_branch = "master";
 	print "DONE; creating $orig_branch branch\n" if $opt_v;