git fast-import : How to change parent during import?

Hi everyone,

Is it possible to change the parent of a commit during fast import? I've tried using "reset" command and making a new commit pointing to a new parent, but in both cases I get a "new tip ... does not contain ..." error message.

Providing a bit of context. I'm trying to improve git-p4 to detect the parent commit of a new branch. Unfortunately, in Perforce a branch is nothing more than a copy of a bunch of files into a new location. Because the origin of the copy can be any past commit and there is no information about which commit was used it is very difficult to identify a parent of a new branch. But if we assume that in this copy process no file is modified then it should be possible to identify the parent commit simply by comparing their SHA-1. To achieve this I used the checkpoint command to flush the list of imported commits to disk and then used standard rev-list and diff-tree commands to make find the parent commit. I am now at a point where I am able to correctly identify the parent commit, but when trying to update the from information I get the above message.

Thanks in advance for your help,

Hi,

Vitor Antunes wrote:

Have you tried "git fast-import --force"?

[...]

The advice in the section "Use Tag Fixup Branches" of git-fast-import(1) might be useful.

Thanks for an interesting example, and hope that helps. Jonathan

Hi Jonathan,

On Tue, Mar 8, 2011 at 2:44 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Oh... I completely overlooked the command line argument list in the man page... Thanks for the tip, worked like a charm!

I'm still trying to understand it. Do you know of any practical example that I can look into?

Thanks for your help,

Hi,

Vitor Antunes wrote:

It's likely I misunderstood what you're trying to do. If you have some work in progress, I'd be glad to look at it.

Anyway, concerning tag fixup branches: git://repo.or.cz/cvs2svn.git has an example in cvs2svn_lib/git_output_option.py::process_tag_commit. The idea is to make commits that don't belong to any branch on a separate TAG_FIXUP ref, using the "reset" command where appropriate; then the resulting commits can be inspected, merged, reset to, or used in some other way later.

The "tag fixup" idea is that in VCSes like CVS, tags do not necessarily match the content on any branch. So the history looks somewhat like so (time flowing left to right):

                     TAG
                    /
 o --- o --- o --- o --- o --- o ...

instead of the perhaps more sensible

 o --- o --- o --- TAG --- o --- o ...

The side branch leading up to a tag does not correspond to any branch name; after it is in the correct state one can use the "tag" command to get it remembered in permanent history. The same technique might be useful whenever you are creating history that is not meant to stay permanently on any branch.

Jonathan

Hi Jonathan,

On Tue, Mar 8, 2011 at 10:23 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

I think I understood the idea behind TAG_FIXUP and I think it can be a better solution for my problem. I could make the commit into TAG_FIXUP, search for a better parent in the source branch and then reset it to that parent or rebase it over any other commit. I'll try to do this in the following days, so I will most likely come back with more doubts :)

Thanks,

Hi Jonathan,

On Tue, 8 Mar 2011 16:23:28 -0600 Jonathan Nieder <jrnieder@gmail.com> wrote:

I don't think the TAG_FIXUP trick is what I need in this case. Assume the following:

A --- B --- C --- D ...    (branch1)
      \
       E --- F --- G ...   (branch2)

Now assume that we are at commit D when we detect a commit to branch2. At this point there is no way of knowing the origin commit in branch1. What is currently being done is to use commit D as the parent of branch2, which is incorrect. But if we assume that all branches are created through a "cp" like command, then we know that B=E. So my idea is to go over A, B, C, etc and commit E "from:" each one and see which results in a zero differences diff-tree.

Unfortunately, the current implementation I am using doesn't feel simple enough. Because I'm using commands external to fast-import, I need to be constantly making use of "checkpoint". And this seems to not be good enough, because I need to sleep during 0.1s (didn't try other values) after each "checkpoint" before being able to use diff-tree and similar commands. I am also forced to use the "--force" command due to all the orphan commits I leave behind.

I would really prefer to have a simpler solution. Do you, or anyone else, see another option?

Thanks in advance,

On Mon, 7 Mar 2011 20:44:27 -0600 Jonathan Nieder <jrnieder@gmail.com> wrote:

I know this is an old topic, but I'm looking into this again now. What I'm now trying to do is to stop using "--force".

Is there a way to manually force fast-import to drop an old commit that the frontend script decided it was no longer necessary?

Thanks,

Vitor Antunes wrote:

Sure --- patch fast-import (I'd be happy to review such a patch). :)

Heya,

On Mon, Aug 29, 2011 at 01:39, Jonathan Nieder <jrnieder@gmail.com> wrote:

That's actually a feature that we need for remote-helpers as well (to be able to drop refs). Would be nice to have a 'drop ref' command in fast export :).