a git plan, long term

[Russ Allbery]

Ian Young <ian at iay.org.uk> writes:

> I think there are various workflow advantages to Git, but they only
> benefit people who use Git in a Git-like way.  All you get before that
> is maybe a bit better performance, offline working and (probably) a bit
> of a brain ache.  So the time before we start to get value back from a
> move to Git is dependent on how long we take to learn what "Git-like"
> means.  People who have already had their brains gitified would probably
> see value more quickly.

Take this with a grain of salt, since I'm not an active Shibboleth
developer, but I like Git even for very Subversion-like workflows (I
actually intensely dislike the branch-frequently "recommended" Git
model).  I think there are some other advantages that are often not
noticed.

The thing I love the most about Git is that it gives me a lot more control
over the change sets that I construct.  This is due to a combination of
multiple features that Subversion doesn't have:

* Off-line commits that can be modified later before making them
  "official" by publishing them to the repository.  For me, this lowers
  the bar for a commit; I commit as soon as I think I have the right
  thing, instead of waiting until I'm sure it's perfect.  Then, if I find
  I need another change or fix, I git commit --amend.  Similarly, if I
  find that the original wording of the commit message isn't right, I
  amend.  Only when I'm sure of the commit do I push.

  This is, by far, the feature of Git that isn't in Subversion that I use
  the most.  It means that I can use commits as checkpoints to which I can
  revert when something doesn't work out, without publishing all of those
  commits as official and then having to add additional commits later to
  fix things that were wrong originally.  My internal messing-about is
  invisible; the official repository gets a single commit that fixes the
  issue and that I can point other people at, pull as a patch, etc.

* Partial commits.  I really like to have one commit for one fix, but
  while I'm working on a fix I often notice this other thing that has to
  be fixed, or that other thing I should change, so I end up with a
  working tree with several independent modifications.  Git and Subversion
  can both, of course, commit specific files.  What Git adds on top of
  that is the ability (via git add -p) to add specific changes in a file
  to a commit and leave other changes out.  This lets me "clean up" my
  working state into a much more understandable commit stream, while still
  letting me make whatever changes seem appropriate while I'm in the
  middle of code editing.

* Stashing.  This is where Git purists will say that I should be using
  branches, but I find stashes much more intuitive than branches.  The git
  stash command lets you take the current modified state of your tree and
  dump it into a holding area and restore your working tree to a pristine
  state.  Then, at any point later, you can pull back those changes and
  reapply them and start working on them again.  I use this frequently
  when I'm in the middle of fixing something, get interrupted, and have to
  deal with some other problem first.  You can do this with branches, of
  course, but stashes feel lighter-weight and better-suited to that
  particular problem.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>