[Question] info/grafts file.

Greetings,

A simple question to clarify something in the repository.

What level of support is to be expected for the .git/info/grafts file? I added a grafts file to a repository imported from SVN. However, when I cloned the repository using git clone -l -s I did not end up with a grafts file in the cloned repository.

Cheers, Carl

  Hello,

Dear diary, on Mon, Nov 14, 2005 at 07:20:19PM CET, I got a letter where Carl Baldwin <cnb@fc.hp.com> said that...

  grafts are meant to be a purely local thing, private to your current
repository so that you can extend it in certain way. If you want
something public and official, that's what the "parent" lines in the
commit objects are - so you are really better off just rewriting the
history.

Grafts are considered local preference, and not copied when cloned. I am unsure this was a right decision, but that is how things are right now.

This is fine, I just needed to know.

How hard is it to, in a generic way, take a grafts file and reconstruct commits to include the parents in the graft file in the actual tree? I am wondering because I couldn't, after much work, get git-svnimport to find my merges correctly. So, I am needing to hand-graft some merges in to make things right. Any suggestions? I could try to figure something out if I can find some time. I'm good with graph traversals and such.

Carl

On Mon, Nov 14, 2005 at 12:56:37PM -0800, Junio C Hamano wrote:

On Tuesday 15 Nov 2005 00:03, Carl Baldwin wrote:

I am interested in that question as well. If you recall I was asking on this list about a week ago how to lose history (because it was irrelevent).

I at first attemtped to use a graft to bypass all the changes I wanted to loose, but as many of the tools ignored it I gave up. When I looked at whether I could change the history by making a commit that looked like the graft, I came to the conclusion that I would have to do a number of things

a) Recreate the commits all the way to the head - because the commits where all stored in a content addressable file store, as soon as the parent link changes it becomes a new commit with a new sha1, so changing a commit in the middle of a stream of branches effectively required you to walk up to the head (difficult because the linkages are the other way) re-creating new commits.

b) Understand the topology of all the interlinking commits, and make sure that the two commits I were trying to squash together didn't have any intermediate commits that effectively pointed outside of this space (and when I say "pointed" I mean either via a parent link, OR via a reverse virtual link when some other commits parent link pointed at the commit in question).

Because of all of this complexity I gave up and used cg-merge -squash to create the first stage squashed branch and then manually used git-cherry-pick to pick one by one the commits from on top of the old branch and move it to the new one (not so hard there were only about 20 commits in all to move that way).

So I am interested to see if my logic for why the complexity was high was correct.

On Tue, 15 Nov 2005, Alan Chandler wrote:

I think you should be able to use "git-convert-objects" to do both history pruning and history adding.

It would need a bit of work: right now "convert_commit()" parses the commit 100% by hand, and doesn't care about the grafts file. But that is where such a conversion would be done.

Right now "convert_commit()" actually does the first conversion in-place (because the size of the head of the commit never changes), and then calls "convert_date()" which will allocate a new buffer and do the conversion there - that's for totally stupid hysterical raisins, and it should really have allocated the new buffer in convert_commit() - something you'd need to do if you end up editing the "parent" information at that point.

So it would take some work, but the infrastructure for doing these kinds of conversions is all there.

		Linus

Carl Baldwin wrote:

It's actually pretty easy. I wrote a rough (and not quite safe) tool to do this a week or so ago.

http://marc.theaimsgroup.com/?l=git&m=113131673606637&w=2

I will try and clean it up a bit and submit it for inclusion in contrib/ sometime this coming weekend, but you should be able to use it to solve this problem.

It's pretty straightforward, honestly. (And I'm pretty sure it could be faster if I did things slightly differently.)

On Wed, Nov 16, 2005 at 07:57:14PM -0500, Ryan Anderson wrote:

Hey, this exactly looks like the kind of script I intended to write in the following days ! I'll have a close look at it. Do you have a git repo from where I could pull the latest version ?

My goal is to write an "AcheoloGIT" toolkit, to be able to reconstruct an history incrementally, from patches, identifying in the way patches which build upon other patches. To make it more clear, there are in the embedded world a number of vendor shipping "jumbo patches", which include parts or all of official arch-specific trees, with more stuff added.

And well, since it is not an easy task, the process has to be incremental, grafting here and there between various parts of the tree to gradually refine my view of its history.

There is some preliminary work, but for now only focussed on making the import of series of patches more comforable. Grafting was supposed to be the next step :)

http://ydirson.free.fr/soft/git/argit.git/

Best regards,