Using Git

Andrew Benton b3nton at gmail.com
Mon Sep 12 17:40:30 PDT 2011


On Mon, 12 Sep 2011 23:12:49 +0100
Matthew Burgess <matthew at linuxfromscratch.org> wrote:

> Hi all,
> 
> This was prompted by a discussion on lfs-dev about a new server for LFS.
> 
> There are plenty of git tutorials out there, but none that seem to 
> describe the following workflow I use:

I'm not a git expert, but I do use it. There is probably a correct way to do this, however, this is what I'd do...

> 1) Checkout sources (svn co)

For the initial checkout:
git clone git://url/of/repo
to update thereafter:
git pull

> 2) Make a change and commit it locally (quilt new, quilt add, edit 
> files, quilt refresh)

git commit -a -m "1st commit message"

> 3) Make a 2nd change and commit it locally (quilt new, quilt add, edit 
> files, quilt refresh)

git commit -a -m "2nd commit message"

> 4) 'Rewind' to the 1st change, as I need to make a change to the first 
> commit (quilt pop, edit files, quilt refresh)

To rewind I would use:
git reset --hard really-long-index-number
However, doing that would reset everything and forget all the changes
you've made so first you should save the last commit to a patch:
git show > ~/name-of-last-change.diff
You can dump any change you commit to a patch:
git show really-long-index-number > ~/suitable-name-for-patch.diff

> 5) 'Fast forward' to the 2nd change, to ensure it still applies on top 
> of the first (quilt push)

I would just apply the patch then commit the change
patch -p1 < ~/name-of-last-change.diff
git commit -a -m "2nd commit message"

> 6) Rewind both changes, update from upstream so that I have all the 
> latest changes, then do a final 'fast forward' of both changes to ensure 
> they both apply cleanly on top of the latest upstream changes

git reset --hard really-long-index-number
git pull
patch -p1 < ~/name-of-first-change.diff
git commit -a -m "1st commit message"
patch -p1 < ~/name-of-last-change.diff
git commit -a -m "2nd commit message"

If the patches don't apply after your git pull then you'll need to edit
the files and apply the changes by hand. I'm sure we've all fixed
broken patches.

> 7) Rewind both changes again, 'fast forward' each change in turn and 
> commit them upstream (quilt pop -a, quilt push, svn ci, quilt push, svn ci)

I think git push works the same as git pull but in the other direction
(assuming you have commit privileges). I don't think I've ever used it,
I normally just walk or ssh to the other machine and then pull.
I like git. It seems to me that everything is just a patch and a commit
message to git. The patches are just normal unified diffs. It's like
the way Linus was getting an endless stream of kernel patches in his
inbox and this is just a tool for managing the flow of patches. There's
probably a more sophisticated way of doing the rewinds that you've
described (there are 151 files in /usr/libexec/git-core) but I'm a
simple sort of person and patches are something familiar I can easily
work with without getting lost.

Andy



More information about the lfs-chat mailing list