Re: Using Git to manage your Emacs changes

[Ken Raeburn]

On Apr 7, 2010, at 15:23, John Wiegley wrote:
> If anyone here is like me and can't stand Bzr's interface/lack-of-speed due 
> to comfort with Git, there is a *somewhat* more palatable solution:

Thanks!

> 1. Install git-bzr (http://github.com/pieter/git-bzr).  Make sure it works by
>    testing on some very small project from someplace.

Is this currently the best version to use?  There are other versions at github, 
perhaps some are better maintained.

> 2. Do a bzr checkout of Emacs.  DO NOT use git-bzr to directly checkout the
>    Emacs tree.  It will take days and days and download over 20G of data.
> 
> 3. Using git-bzr, point it at your local bzr checkout so it can do a fully 
> local
>    translation of the Bzr commits to Git commits.  This will take several 
> hours,
>    but not hog network bandwidth.

> 5. Now here's the tricky part.  Move your .git directory from your git-bzr 
> checkout
>    over into your Bzr working tree.  Yes, we want Bzr and Git to manage the 
> same
>    tree.  You should be wearing your Depends; this is not for the faint of 
> heart.

These (#2,#3,#5) sound like things that git-bzr could simply be updated to do 
this way.  Well, maybe not the last step, exactly, but can you move the bzr 
info into a git checkout instead?  Or, to keep it looking more like a clean git 
tree, at the cost of more disk space, bury the bzr info under .git/ and apply 
the patches in a separate copy there.  (That would also avoid the need for a 
clean tree at the start, since you wouldn't clobber your git working copy.)

> 7. Sadly, git-bzr is sufficiently broken that you will not be able to push 
> your
>    changes with "git bzr push upstream", as the docs indicate.  Instead, we 
> have
>    to use "git format-patch" and then turn each patch into a Bzr commit 
> manually,
>    which get pushed with "bzr push".  Once pushed, "git bzr pull upstream" 
> reflects
>    that new commit back in Git:

Again, it looks like a straightforward enough, programmatic change that git-bzr 
could be fixed to just do it.  Kind of a shame about the rebasing requirement, 
if someone's got local branches; why is it needed?  Is this process unable to 
push content or commit info into bzr in a way that matches the git version?

What happens at this point if there's a conflict with newer upstream changes?  
(I.e., which command fails?  Will your script recover or blindly charge ahead?  
Do you need any special commands to keep things in sync in that case?)

Ken