little conundrum

little conundrum

[Alan Chandler]

I have a little problem I am trying to solve.  Tried a few things and got 
nowhere, so I thought I would ask here.

I have two directories one of which contains a tree of source code that was an 
original software package that I downloaded.  The other contains the result 
of some unfinished - but quite substancial changes that I had made to that 
source code.  Since this was some time ago, I don't have any records, but it 
is quite possible that I added and removed quite a few files.

I would like to make myself a git repository that contains at the start, an 
initial commit of the original downloaded source code, and a second commit on 
the top of that that contains the the current state of play after the changes 
I have made.

Since I don't actually have a list of the files, I thought I would establish 
these automatically by going into each directory and doing a cg-init.  So I 
now have two disjoint repositories each with their source tree in it.

My next thought was to add a branch to one of them and then pull the resultant 
code over and merge it using cg-branch-add followed by a cg-update.  But when 
I do that it complains that there is no common base.  

I tried creating an empty directory and separately merging the two versions 
with it, so that I have a common parent, but whatever I do, I can't get one 
of those nice little gitk diagrams that has any linkage between the two 
versions of the source code.

Is there an approach I could take to achieve what I want?
-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.

Re: little conundrum

[Johannes Schindelin]

Hi,

On Thu, 3 Nov 2005, Alan Chandler wrote:

> I would like to make myself a git repository that contains at the start, 
> an initial commit of the original downloaded source code, and a second 
> commit on the top of that that contains the the current state of play 
> after the changes I have made.

How about this:

	cd orig/
	git-init-db
	git-add $(find * -type f)
	git-commit -m "initial"
	cd ../modified
	mv ../orig/.git ./
	git-add $(find * -type f)
	git-commit -a -m "my modifications"

Of course -- in the great tradition of this list -- totally untested.

Hth,
Dscho

Re: little conundrum

[Peter Eriksen]

On Thu, Nov 03, 2005 at 06:47:56PM +0100, Johannes Schindelin wrote:
...
> How about this:
> 
> 	cd orig/
> 	git-init-db
> 	git-add $(find * -type f)
> 	git-commit -m "initial"
> 	cd ../modified
> 	mv ../orig/.git ./
> 	git-add $(find * -type f)
> 	git-commit -a -m "my modifications"

As I stated in another message be careful with links because
they are not of "-type f".  In addition do

find * -type l

or at least keep in mind what is really going on.

Peter 

Re: little conundrum

[Alan Chandler]

On Thursday 03 Nov 2005 17:47, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 3 Nov 2005, Alan Chandler wrote:
> > I would like to make myself a git repository that contains at the start,
> > an initial commit of the original downloaded source code, and a second
> > commit on the top of that that contains the the current state of play
> > after the changes I have made.
>
> How about this:
>
> 	cd orig/
> 	git-init-db
> 	git-add $(find * -type f)
> 	git-commit -m "initial"
> 	cd ../modified
> 	mv ../orig/.git ./
> 	git-add $(find * -type f)
> 	git-commit -a -m "my modifications"
>
> Of course -- in the great tradition of this list -- totally untested.

Also untested, but what about removing the files from the index that aren't in 
the working directory?

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

Re: little conundrum

[Johannes Schindelin]

Hi,

On Thu, 3 Nov 2005, Alan Chandler wrote:

> Also untested, but what about removing the files from the index that 
> aren't in the working directory?

IIRC "git-commit -a" includes "git-update-index --remove".

Hth,
Dscho

Re: little conundrum

[Peter Eriksen]

On Thu, Nov 03, 2005 at 05:41:20PM +0000, Alan Chandler wrote:
> I have a little problem I am trying to solve.  Tried a few things and got 
> nowhere, so I thought I would ask here.
> 
> I have two directories one of which contains a tree of source code that was an 
> original software package that I downloaded.  The other contains the result 
> of some unfinished - but quite substancial changes that I had made to that 
> source code.  Since this was some time ago, I don't have any records, but it 
> is quite possible that I added and removed quite a few files.
> 
> I would like to make myself a git repository that contains at the start, an 
> initial commit of the original downloaded source code, and a second commit on 
> the top of that that contains the the current state of play after the changes 
> I have made.

What I read from this, is that you could do something like (with Git,
but I suppose Cogito is very similar):

]cd original
]git-init-db
]git-add all-the-files
]git-commit -m "Initial import"
]cp -rf ../modified/* .
]git-status
...fix things up adding and deleting files
]git-commit -m "First big change

The point is, I think git-status will tell you about any
modifications you have made by just overwriting the original
tree with the modified one.

Peter

Re: little conundrum

[Alan Chandler]

On Thursday 03 Nov 2005 18:10, Peter Eriksen wrote:
> On Thu, Nov 03, 2005 at 05:41:20PM +0000, Alan Chandler wrote:
> > I have a little problem I am trying to solve.  Tried a few things and got
> > nowhere, so I thought I would ask here.
> >
> > I have two directories one of which contains a tree of source code that
> > was an original software package that I downloaded.  The other contains
> > the result of some unfinished - but quite substancial changes that I had
> > made to that source code.  Since this was some time ago, I don't have any
> > records, but it is quite possible that I added and removed quite a few
> > files.

> What I read from this, is that you could do something like (with Git,
> but I suppose Cogito is very similar):
>
> ]cd original
> ]git-init-db
> ]git-add all-the-files
> ]git-commit -m "Initial import"
> ]cp -rf ../modified/* .
> ]git-status
> ...fix things up adding and deleting files
> ]git-commit -m "First big change
>
> The point is, I think git-status will tell you about any
> modifications you have made by just overwriting the original
> tree with the modified one.


The advantage of cg-init (as opposed git-init-db) is that it finds all the 
files to add.

I just did a quick trial of this, and it appears that git-status does not 
notice deleted or added files.

That is one of the major issues that was worrying me - that I didn't miss any 
of those.  

There is a manual workaround - I have just run up kdiff3 (from kde) on the two 
directories and it is showing 59 file differences (as opposed to the 21 
reported by git-status).  So I could go down them one by one and deal with 
them.

But I was hoping there was an automated method:-(



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

Re: little conundrum

[Peter Eriksen]

On Thu, Nov 03, 2005 at 06:48:57PM +0000, Alan Chandler wrote:
> On Thursday 03 Nov 2005 18:10, Peter Eriksen wrote:
[snip]
> > ]cd original
> > ]git-init-db
> > ]git-add all-the-files
> > ]git-commit -m "Initial import"
> > ]cp -rf ../modified/* .
> > ]git-status
> > ...fix things up adding and deleting files
> > ]git-commit -m "First big change

Perhaps something like this is better (now I actually tried it out):

]rm -rf linux-2.6/.git
]cp -r linux-2.6 peter-2.6
...Initialize a repo in linux-2.6 with cg-init or similar and commit.
...Remove, add and change files in peter-2.6.
]mv linux-2.6/.git peter-2.6/.git
]cd peter-2.6/
]git-status

How does this work for you?

Peter

Re: little conundrum

[Alan Chandler]

On Thursday 03 Nov 2005 19:16, Peter Eriksen wrote:

>
> Perhaps something like this is better (now I actually tried it out):
>
> ]rm -rf linux-2.6/.git
> ]cp -r linux-2.6 peter-2.6
> ...Initialize a repo in linux-2.6 with cg-init or similar and commit.
> ...Remove, add and change files in peter-2.6.
> ]mv linux-2.6/.git peter-2.6/.git
> ]cd peter-2.6/
> ]git-status
>
> How does this work for you?

This is the same as before.  It lists the modified files, but it doesn't tell 
you about any added or deleted files.

[I have done this manually now - originally I thought that there were quite a 
few files - but once I had stripped out things like "tags" and some spurious 
directories that were empty it ended up being only three files:-).  So its 
only an intellectual exercise now:-)]

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

Re: little conundrum

[Peter Eriksen]

On Thu, Nov 03, 2005 at 07:30:28PM +0000, Alan Chandler wrote:
...
> This is the same as before.  It lists the modified files, but it doesn't tell 
> you about any added or deleted files.

That's odd, because I get this (shortened) output with Git current:

~/peter-2.6]git-status
#
# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#       deleted:  README
#       deleted:  REPORTING-BUGS
#       deleted:  arch/mips/mips-boards/atlas/Makefile
#       deleted:  arch/mips/mips-boards/sead/sead_setup.c
#       modified: fs/fs-writeback.c
#       deleted:  init/Kconfig
#       deleted:  init/Makefile
#       deleted:  init/calibrate.c
#
#
# Untracked files:
#   (use "git add" to add to commit)
#
#       drivers/media/MAINTAINERS
#       drivers/parport/mips-boards/atlas/Makefile
#       drivers/parport/mips-boards/atlas/atlas_gdb.c
#       drivers/parport/mips-boards/sead/sead_setup.c
#       fs/fs-writeback.c~
nothing to commit


> [I have done this manually now - originally I thought that there were quite a 
> few files - but once I had stripped out things like "tags" and some spurious 
> directories that were empty it ended up being only three files:-).  So its 
> only an intellectual exercise now:-)]

Be careful to remember to add any links.  At least with Git when
I last tried importing directories containing them.

Peter

Re: little conundrum

[Petr Baudis]

Dear diary, on Thu, Nov 03, 2005 at 06:41:20PM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> told me that...
> Since I don't actually have a list of the files, I thought I would establish 
> these automatically by going into each directory and doing a cg-init.  So I 
> now have two disjoint repositories each with their source tree in it.
> 
> My next thought was to add a branch to one of them and then pull the resultant 
> code over and merge it using cg-branch-add followed by a cg-update.  But when 
> I do that it complains that there is no common base.  
> 
> I tried creating an empty directory and separately merging the two versions 
> with it, so that I have a common parent, but whatever I do, I can't get one 
> of those nice little gitk diagrams that has any linkage between the two 
> versions of the source code.

The empty directory is the good approach to do the merge, but you are
going to get a huge number of conflicts. Anyway, this is probably the
most sensible behaviour for cg-merge, so I added cg-merge -j which does
exactly that - use empty tree as a base for three-way merge.

But you actually do not want to do a merge, but:

	$ cd original-version
	$ cg-init
	$ cd ../modified-version
	$ cg-init
	$ cg-branch-add orig ../original-version
	$ cg-fetch orig
	$ echo `cg-object-id` `cg-object-id orig` >.git/info/grafts

Voila, now your commit in 'modified' has the commit in 'original' as its
parent.

PS: And to be able to even commit the cg-merge -j, I had to back out the
git-read-tree -u usage in cg-Xlib's tree_timewarp, which made it racy as
hell - basically, it could be argued that it working _properly_ would be
a race now. Besides, keeping local changes wouldn't work, and stuff.
cg-admin-uncommit was painfully broken.

-- 
				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: little conundrum

[Alan Chandler]

On Thursday 03 Nov 2005 20:06, Petr Baudis wrote:
...
> But you actually do not want to do a merge, but:
>
> 	$ cd original-version
> 	$ cg-init
> 	$ cd ../modified-version
> 	$ cg-init
> 	$ cg-branch-add orig ../original-version
> 	$ cg-fetch orig
> 	$ echo `cg-object-id` `cg-object-id orig` >.git/info/grafts


very nice

I didn't know about the grafts stuff, but I can see what its doing.
-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.