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

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

Junio> I do not use cvsimport but I wonder what Commit ID 985ca7
Junio> contains.  Can you try "git show 985ca7" and see if that is the
Junio> commit you want?

To bring the tree clean, I issued "git commit -a -m 'cvs sync'", and
"git-whatchanged -p" shows the most recent commit with the diff actually
*backed out* the most recent change in CVS, and the next change down was
actually the good one.  Weird.  Do I need to start all over again?

So the commit ID reported before the command says Done. was
actually what you wanted, but that latest tree was not checked
out cvsimport, so "git status" reported "you have these changes"
(it should have said "you have these backed-out", but there is
no way for it to know), and obviously your commit on top of that
is to back it out.

I just tried it on a copy of my day-job CVS repository.  Indeed
what it does seem quite strange.

    ...
    skip patchset 1019: 1142562992 before 1142562992
    skip patchset 1020: 1142563093 before 1142563093
    Fetching Makefile   v 1.10
    Update Makefile: 871 bytes
    Tree ID 4c51717e01fb08b6d15bc6e35d48142d2d5b94e7
    Parent ID 98d49aa57b93552cea82ce20c880bad4bcc5ebfc
    Committed patch 1021 (master 2006-03-17 03:04:31)
    Commit ID ad6c4fb908df7057d5564bf22cf9e0f9f3e743f2
    DONE


It updated the 'master' branch head, it reported the tip commit
ID before saying DONE, and that commit ID is stored in
refs/heads/master.  However, it does not seem to touch index nor
working tree files (I did not get "you may need to do merge"
message, by the way).

Since I know I was just trying things out, I do not care what is
in my index nor in the working tree files, so I could at this
point say:

	$ git reset --hard

to sync the master tree, but in general you may be running
cvsimport into a dirty tree, in which case you are screwed.

I think reverting this commit would help, but I do not remember
offhand what the breakage this patch was trying to fix.

    commit a541211ef4136eb7464c4466d20b60b8580efc44
    Author: Matthias Urlichs [off-list ref]
    Date:   Tue Mar 7 10:08:34 2006 +0100

        cvsimport: Remove master-updating code

        The code which tried to update the master branch was somewhat broken.
        => People should do that manually, with "git merge".

        Signed-off-by: Matthias Urlichs [off-list ref]
        Signed-off-by: Junio C Hamano [off-list ref]

... Ugh, and after I wrote all of the above, the version of git
I have at work predates that commit X-<.  So maybe this was
fixed with that commit, and you are expected to say:

	$ git pull . origin

assuming that you are on "master" branch and cvsimoprt tracks
CVS head with "origin" branch, that is.

Smurf, help?

quoted

quoted

quoted

quoted

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

Junio> Since I know I was just trying things out, I do not care what is
Junio> in my index nor in the working tree files, so I could at this
Junio> point say:

Junio> 	$ git reset --hard

Junio> to sync the master tree, but in general you may be running
Junio> cvsimport into a dirty tree, in which case you are screwed.

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.

Junio> ... Ugh, and after I wrote all of the above, the version of git
Junio> I have at work predates that commit X-<.  So maybe this was
Junio> fixed with that commit, and you are expected to say:

Junio> 	$ git pull . origin

Junio> assuming that you are on "master" branch and cvsimoprt tracks
Junio> CVS head with "origin" branch, that is.

Again, if that's the case, the manpage should say what's really
happening, so as not to confuse dumb people like me. :)

-- 
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!

Hi,

Junio C Hamano:

... Ugh, and after I wrote all of the above, the version of git
I have at work predates that commit X-<.  So maybe this was
fixed with that commit, and you are expected to say:

	$ git pull . origin

Exactly.

assuming that you are on "master" branch and cvsimoprt tracks
CVS head with "origin" branch, that is.

Smurf, help?

What for? You got it, after all. *g*

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Sally sued for support; she was claimin'
Phil had fathered her baby (named Damon).
    She said, "I ought to know,"
    As she pointed below.
"'Cause this is the box that he came in."

Hi,

Randal L. Schwartz:

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.

The real workaround is not to import into live branches,
which is not a git-cvs-specific problem, so I didn't add that
to its manpage.

I'm not opposed to an appropriate patch if you think its necessary.
If you do, keep in mind that there are other git-*import scripts out
there which presumably have the same problem. ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
That which is good to be done, cannot be done too soon; and if it is
neglected to be done early, it will frequently happen that it will not be done
at all.
					-- Bishop Mant