Very nice program. Comments and usage questions...

[Mark Williamson]

>      MS> Does this preclude symlinking .git?  I'd like to keep one .git
> which MS> is mirrored from the net and allow for more than one working MS>
> directory.
>
>      I think people typically do this by symlinking .git/objects, not
>      .git/ itself.
>
<snip>
>      One major downside of this, which I was burned once myself
>      (which is the reason for me to stop doing it), is that
>      git-fsck-cache and git-prune-script would not know anything
>      about the objects in the shared .git/objects reachable from
>      other work trees, and can happily garbage collect objects
>      necessary for other work trees.
>
> He sounds like he knowns what he's talking about.

Ah, that's quite interesting.  Yes, I'm sure what he's saying is correct.  
However, you can still achieve what you wanted by cloning the complete 
repository several times (using the "cogito" scripts for git, I'd use 
something like "cg-clone src-repo/.git destination".

The fsck problem looks like it only applies if you're sharing the same object 
database.  A clone won't do that in git (AFAIK) but will therefore take up a 
fair bit of space (but disk space is cheap ;-)).

> > And then "hg update" to check out files for editing / building, "hg pull"
> > to get latest changes, etc.
>
> Perhaps you can explain this, then.  How is that pulling updates is
> reconcilled with local modifications?  If I patch a file in version
> 2.6.11 and there are mainline changes made to that driver in 2.6.12,
> the pull will induce conflicts.  What I've been doing is saving my
> changesets as patches, updating the tree to 2.6.12 (in this case) and
> then reapplying the changesets, fixing conflicts and then publishing
> the new patches.  I find it hard to believe that this is how other
> people handle upgrades.

Doesn't sound very fun!

I do the following:
hg pull # gets the latest changes and squirrels them away in .hg/
hg update -m # gets the changes into my working dir, does the merges

At this point it mentions a load of "merges" that are often files I've not 
touched - it handles these on its own, I only get conflicts on files I've 
actually changed.  I've been assuming that a "merge" occurs every time I've 
made a checkin and therefore "branched" the history, so these messages 
nothing to worry about.

> Similarly, I tried something like this with the current repo.  I
> updated to 2.6.11, applied my patch, updated to 2.6.12 with merging
> and was greeted with a mess of changed files that had nothing to do
> with my patch.

Does it actually require you to resolve anything, or does it just work?

Cheers,
Mark