Cogito Tutorial If It Helps

I reworked the previous tutorial to take in the changes in the scripts. Will make this a series of tutorials to cover all aspects. Any suggestions or hints or spelling corrections would be most welcome.

http://ksit.dynalias.com/articles.php?s_id=46&art_id=41

Dear diary, on Tue, Apr 26, 2005 at 10:52:27PM CEST, I got a letter where James Purser <purserj@ksit.dynalias.com> told me that...

Thanks for writing that! :-)

I'd vote for describing the cg-update right near cg-pull, or perhaps even before cg-update, as the primary method; I think it's commonly what people really want to do when they do cg-pull anyway.

cg-merge is _not_ like doing cg-diff | cg-patch - that's a dangerous thought, and not true at all. cg-diff | cg-patch will just apply the given diff to your working directory, but it won't record any merging metadata, will often get it very wrong, and you will get to all sorts of other troubles. Just always use cg-merge. And probably pass it -b only when you know what are you doing.

Thanks,

On Wed, 2005-04-27 at 07:18, Petr Baudis wrote:

Thanks for that, I've changed it a little to point out that cg-patch should really only be used for small single file patches.

Dear diary, on Tue, Apr 26, 2005 at 11:36:43PM CEST, I got a letter where James Purser <purserj@ksit.dynalias.com> told me that...

No, you've missed the point. It isn't the size of the change what matters - cg-patch should handle even huge patches (mostly) fine. What matters is that you just did was not merge. It was applying some patch to your working tree, but not merging branches.

So after doing cg-diff | cg-patch several times, you have your working tree full of huge local changes (making it impossible to sensibly cg-merge) and your last commit happenned long ago. Or you commit the cg-patch results, but your commits are wrong, since they don't carry the appropriate merge information.

On Tuesday 26 April 2005 21:52, James Purser wrote:

Although I have been reading this mailing list since almost the beginning, I have not had a chance to download and try anything. Using this message as an incentive to start, I started to follow this.

However I have run into problems.  

Let me try and explain.

The first part of the tutorial of loading the tarball and building things is fine (should be, its a well trodden mental model) - and actually for me I did not have libcurl3-dev installed the first time - but because I already had the mental model in my mind on this stage it was easy to fit.

I then issued the cg-clone command to get a fresh copy of cogito. This is where I think it would be useful to take time-out from the tutorial and explain what I have here. For me at least, if I don't have a mental model of what is happening, I am totally confused.

I "think" I understand the git repository with the various content addressable objects. Reading the README file describes that quite well. I assume that is what is stored in the .git subdirectory (although I have yet to find any text that formally says that).

Where I am confused is the relationship between what is in the .git subdirectory and the project tree of cogito that sits around it. Obviously I understand that its the latest version of the project as represented by the objects in the repository, but what I don't really understand (and neither your tutorial nor all the explanations of each of the commands in the README really explain it either) is how the various commands adjust the relationship.

For instance cg-branch-add seems to add a branch to the repository from a url (I assume it downloads any "blobs" etc that are not already in my local repository and creates a tag that identifies the head of a tree object), but a don't understand how I am supposed see that particular branch as expanded code. (I suspect it might be cg-seek, but I am not really sure - and if it is how do you find out what branch this expanded code is now pointed to?). But what do cg-update and cg-pull do in terms of the uncompressed code sitting in the surrounding directory round the repository, particularly when you perform them on a branch that is not the one that the code refers to.

The reason I raise all this, is when I follow through on your tutorial and get to the cg-diff stage I get this

xargs: cg-Xdiffdo: No such file or directory

And I have absolutely no idea whats wrong or where to start looking.

Dear diary, on Wed, Apr 27, 2005 at 08:22:07PM CEST, I got a letter where Alan Chandler <alan@chandlerfamily.org.uk> told me that...

Those commands affect your working tree:

	cg-cancel
		Cancels out any modifications in the working tree w.r.t.
		the last commit
	cg-merge
		Merges changes done in another branch to your current
		branch
	cg-patch
		Applies a patch, with regard to special git-specific
		info generated by cg-diff
	cg-rm
		Removed the file from your working tree if it's still
		around
	cg-seek
		Changes your working tree to match some other commit in
		the database
	cg-update
		Potentially brings in changes from a remote branch, and
		updates your working tree to the latest commit + those
		changes

Those commands affect the objects database:

	cg-commit
	cg-pull
		cg-pull just gets the data from remote objects database
		to the local objects database; it is the "first part"
		of what cg-update does
	cg-update

This affects both:

	cg-merge
		Not directly, but it can call cg-commit automatically.
	cg-update

You didn't do make install and you don't have the cogito tree in your $PATH.

On Wednesday 27 April 2005 20:32, Petr Baudis wrote:

Thanks - that makes things a lot clearer

I DID do a make install - which put everything in ~/bin (including cg-Xdiffdo) and ~/bin is the first item in my $PATH.

On Wednesday 27 April 2005 23:15, Alan Chandler wrote:

Thanks to James Purser its fixed.

I needed the full path to ~/bin rather than just using the ~ in $PATH.

On Wed, 2005-04-27 at 06:52 +1000, James Purser wrote:

Hrm... this tutorial is exactly like cogito's own readme as far as I'm concerned : it just makes things even more confusing to me. I must be really stupid, I should stick to hacking the kernel and not try to use userland tools :)

Anyway, can you explain what it is all about this branch thing ?

I don't understand why in hell you would want linux-2.6 to be a branch of cogito itself ...

Ben.

On Thu, 2005-04-28 at 10:48 +1000, Benjamin Herrenschmidt wrote:

Forget it, I must be lacking caffeine this morning, you are adding linus git, not linux-2.6 as a branch which makes a lot more sense... sorry for the noise.

Ben.