little conundrum

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?

Hi,

On Thu, 3 Nov 2005, Alan Chandler 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"

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

Hth, Dscho

On Thu, Nov 03, 2005 at 06:47:56PM +0100, Johannes Schindelin wrote: ...

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 

On Thursday 03 Nov 2005 17:47, Johannes Schindelin wrote:

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

Hi,

On Thu, 3 Nov 2005, Alan Chandler wrote:

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

Hth, Dscho

On Thu, Nov 03, 2005 at 05:41:20PM +0000, Alan Chandler wrote:

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

On Thursday 03 Nov 2005 18:10, Peter Eriksen wrote:

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

On Thu, Nov 03, 2005 at 06:48:57PM +0000, Alan Chandler wrote:

[snip]

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

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

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:-)]

On Thu, Nov 03, 2005 at 07:30:28PM +0000, Alan Chandler wrote: ...

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

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

Peter

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

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.

On Thursday 03 Nov 2005 20:06, Petr Baudis wrote: ...

very nice

I didn't know about the grafts stuff, but I can see what its doing.