[Question] info/grafts file.

[Question] info/grafts file.

[Carl Baldwin]

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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: [Question] info/grafts file.

[Petr Baudis]

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

  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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [Question] info/grafts file.

[Junio C Hamano]

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.

Re: [Question] info/grafts file.

[Carl Baldwin]

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:
> 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.
> 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: [Question] info/grafts file.

[Alan Chandler]

On Tuesday 15 Nov 2005 00:03, Carl Baldwin wrote:
> 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.
>

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. 


-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.

Re: [Question] info/grafts file.

[Linus Torvalds]

On Tue, 15 Nov 2005, Alan Chandler wrote:

> On Tuesday 15 Nov 2005 00:03, Carl Baldwin wrote:
> > 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.
> >
> 
> 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 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

Re: [Question] info/grafts file.

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

Carl Baldwin wrote:
> 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.

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.)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Question] info/grafts file.

[Yann Dirson]

On Wed, Nov 16, 2005 at 07:57:14PM -0500, Ryan Anderson wrote:
> Carl Baldwin wrote:
> > 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.
> 
> 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.)

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,
-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>