[ANNOUNCE] Cogito-0.8 (former git-pasky, big changes!)

  Hello,

  here goes Cogito-0.8, my SCMish layer over Linus Torvald's git tree
history tracker. This package was formerly called git-pasky, however
this release brings big changes. The usage is significantly different,
as well as some basic concepts; the history changed again (hopefully the
last time?) because of fixing dates of some old commits. The .git/
directory layout changed too.

  Upgrading through pull is possible, but rather difficult and requires
some intimacy with both git, git-pasky and Cogito. So probably the best
way to go is to just get cogito-0.8 tarball at

	http://www.kernel.org/pub/software/scm/cogito/

or

	ftp://ftp.kernel.org/pub/software/scm/cogito/

build and install it, and do

	cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git

  Yes, this is a huge change. No, I don't expect any further changes of
similar scale. I think the new interface is significantly simpler _and_
cleaner than the old one.

  First for the concept changes. There is no concept of tracking
anymore; you just do either cg-pull to just fetch the changes, or
cg-update to fetch them as well as merge them to your working tree.
Even more significant change is that Cogito does not directly support
local branches anymore - git fork is gone, you just go to new directory
and do

	cg-init ~/path/to/your/original/repository

(or cg-clone, which will try to create a new subdirectory for itself). This now acts as a separate repository, except that it is hardlinked with the original one; therefore you get no additional disk usage. To get new changes to it from the original repository, you have to cg-update origin. If you decide you want to merge back, go to the original repository, add your new one as a branch and pull/update from it.

  As for the interface changes, you will probably find out on your own;
cg-help should be of some help. All the scripts now start with 'cg-',
and you should ignore the 'cg-X*' ones. The non-trivial mapping is:

	git addremote -> cg-branch-add
	git lsremote -> cg-branch-ls
	git patch -> cg-mkpatch
	git apply -> cg-patch
	git lsobj -> cg-admin-lsobj

  Commands that are gone:

	git fork
	git track

  New commands:

	cg-clone
	cg-update

  Of course other changes include various bugfixes, and latest Linus'
stuff (although we do not make use of Linus' tags yet).

  Note that I don't know how many time will I have for hacking Cogito
until the next Sunday/Monday. I hope I will get some time to at least
apply bugfixes etc, but I don't know how much more will I be able to do.
You would make me a happy man if you could please port your pending
patches from git-pasky to Cogito; I promise to apply them and I hope
there isn't going to be another so big change in the foreseeable future,
which would cause major conflicts for your patches etc.

  Note that I cc'd LKML since it is going to break stuff for anyone
using git-pasky now (apologies for that; it won't happen another time).
Please try not to keep it in the cc' list unless it is really relevant.

  Have fun,

Dear diary, on Tue, Apr 26, 2005 at 05:24:22AM CEST, I got a letter where Petr Baudis <pasky@ucw.cz> told me that...

I forgot to mention that you should really only upgrade if you feel brave and are willing to do some testing; it is likely there are some new bugs introduced by the renaming, some leftovers of the original git-pasky stuff in some not-so-frequently called scripts, etc. I will see how many bug reports will we get and how fast will the bugcount drop; if things won't stabilize very quickly, I might release git-pasky-0.7.1 with few obvious bugfixes.

(And don't write announcements at 4am.)

Heh. Another huge change would be moving the top level directories around a bit.

bindings COPYING git.spec Makefile programs README.reference tests contrib doc include po README src VERSION

Leaving fixing the makefiles aside as an exercise for the interested reader... that's:

#!/bin/sh

# completely rearrange the file structure of cogito/git # just to make pasky and other scm users insane once again # FIXME - fix the makefiles, git.spec

CFILES=`ls *.c` DFILES=`ls ppc/* mozilla-sha1/*` HFILES=`ls *.h` SRCDIR=src # or libgit? INCDIR=include/git-guts # or keep in SRCDIR or include/git or whatever COGDIR=programs/cogito # or just cogito. is git-web likely to be inc?

mkdir -p $SRCDIR $INCDIR $COGDIR \ bindings/perl bindings/python bindings/ruby po tests doc # just ideas, # no files (yet)

mv $CFILES ppc mozilla-sha1 $SRCDIR mv $HFILES $INCDIR COGFILES=`file * | grep "script text executable" | cut -f1 -d:` mv $COGFILES $COGDIR

cg-rm $CFILES $HFILES $COGFILES
for i in $CFILES $DFILES
do
         cg-add $SRCDIR/$i
done
for i in $HFILES
do
         cg-add $INCDIR/$i
done

cg-commit

Dear diary, on Tue, Apr 26, 2005 at 06:12:04AM CEST, I got a letter where Mike Taht <mike.taht@timesys.com> told me that...

Actually, I've been thinking about this, but I think we just don't need it *yet*.

And by the time we will need to make things more hierarchical, we will hopefully have some way to deal with renames sensibly. We need something for that too - either something ultra-smart as Linus describes, or explicit renames, but merging not working across renames makes them total nightmare.

For a Linux kernel merge tool that I did inside SGI, I come to the conclusion the following heuristics identified renames fairly accurately, coming up with the same renames as a careful manual examination.

The key heuristic was to consider one file A to be a rename of another B if the size (number of lines) of the diff of A and B (diff -auw A B | wc -l) is less than 50% of the combined size of A and B (cat A B | wc -l).

Only pathname pairs with the same basename were considered - I was focused here on renames due to directory restructuring. I'm not sure now if this is a good assumption - but it sure saved some computation.

Any file with the string "Makefile" in its name had to be excluded from consideration.

In case of multiple potential renames (say one file is copied to two places, removing the original and modifying each copy a little), the 'best' rename was selected, where 'best' meant the lowest ratio of diff 'diff -auw' size to combined 'cat' size.

The end result of the above was a fairly natural identification of renames. If say I moved kernel/cpuset.c to mm/cpuset.c and changed it a little bit, the above heuristics would show a rename, plus a few changes.

On Tuesday 26 April 2005 07:12, Mike Taht wrote:

<snip> something like:

--- cogito-0.8.orig/Makefile 2005-04-26 06:02:01.000000000 +0300 +++ cogito-0.8/Makefile 2005-04-26 18:10:52.558786968 +0300

On Tue, 2005-04-26 at 05:24 +0200, Petr Baudis wrote:

Unless you already did this in the latest release, it would be nice to have something like havign all the low level tools be by default in some ~/lib/git or whatever, and only the cg-* scripts in ~/bin on install, unless maybe you pass some kind of I_AM_A_REAL_GIT=1 on the make line ...

I don't really plan to use the low level tools, and I don't like the way they clobber my bin namespace :)

Ben.

Petr Baudis wrote:

tar xvfj $x cd x make ... gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o rpull rpull.c libgit.a rsh.c -lz -lssl gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o rev-list rev-list.c libgit.a -lz -lssl gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-mktag git-mktag.c libgit.a -lz -lssl gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o diff-tree-helper diff-tree-helper.c libgit.a -lz -lssl make: commit-id: Command not found Generating cg-version...

So, it still complains about commit-id

	Jeff

On Tue, 26 Apr 2005, Jeff Garzik wrote:

In this case, it would complain about .git/HEAD even if it found commit-id. The right solution is probably to suppress that part if there's no .git/HEAD.

	-Daniel
*This .sig left intentionally blank*

The right thing is to stop assuming that everyone has . in their $PATH, to start with...

On Tue, 26 Apr 2005, Al Viro wrote:

Does anyone have . in their $PATH? I've only used the commit-id that I installed previously. Since the tarball doesn't have a .git directory, the only way you end up building cogito from a directory with a repository is by using an earlier cogito or something of the sort, in which case, you probably have the program.

In any case, commit-id isn't actually necessary for this operation.

- We don't necessarily have commit-id available when building. Furthermore, we don't necessarily have a repository. Just put in .git/HEAD if it exists; otherwise, it's a base distribution.

Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>

Petr Baudis wrote:

Looks like the git-pasky-0.7 tags (and friends) are now dead links. For example:

[philip@xray cogito]$ cg-mkpatch git-pasky-0.7:HEAD .git/objects/c8/3b95297c2a6336c2007548f909769e0862b509: No such file or directory fatal: cat-file c83b95297c2a6336c2007548f909769e0862b509: bad file Invalid id: c83b95297c2a6336c2007548f909769e0862b509

Is there any way to recover that, or has the timeline been irrevocably altered, and we're all now doomed to meet bastard daughters of long dead crew members? [grin]...

:v)

Actually, I really liked that Enterprise-C episode...

Dear diary, on Tue, Apr 26, 2005 at 09:02:34AM CEST, I got a letter where Philip Pokorny <ppokorny@mindspring.com> told me that...

Oops. Good catch, fixed. I actually just iterated cg-log. ;-)

It assumes the presense of .git/HEAD but doesn't actually fail when missing.

... gcc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o diff-tree-helper diff-tree-helper.c libgit.a -lz -lssl cat: .git/HEAD: No such file or directory Invalid id: Generating cg-version...

Morten

Hi!

It seems to need libcurl-dev... installed.

Error handling could certainly be improved:

pavel@amd:/data/l/cogito$ cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git ./cg-clone: line 22: cg-init: command not found pavel@amd:/data/l/cogito$ PATH=/data/l/cogito:$PATH pavel@amd:/data/l/cogito$ cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git cg-clone: cogito/ already exists

										Pavel