git branch help?

[Peter Hutterer]

On Tue, Aug 03, 2010 at 08:16:23AM +0200, Kevin Kofler wrote:
> Matt McCutchen wrote:
> > The only potentially confusing behavior was that git defaulted to
> > pushing all branches.  Given that, the push failed due to a concurrent
> > change to a different branch on the destination, and it was necessary to
> > switch to that branch in order to perform the merge (well, rebase, but
> > the difference isn't important here).  I see nothing arcane, exotic,
> > bizarre, or broken about that.  And I don't think I would change the
> > default push behavior: I can envision forgetting to push a change to a
> > non-current branch until someone complains about it.
> 
> The whole idea of having more than one branch in a checkout is confusing. I 
> really don't see why I'd want to have a complete clone of the repository on 
> my HDD rather than a working copy which contains all I actually work on (the 
> current revision of one branch; if I work on multiple branches, that's what 
> directories on my file system are for). (And this is another reason why I 
> consider DVCSes to be broken by design.)

it's likely that one you get used to git you'll be using branches heavily.
And once you start using several branches interchangably, directories don't
cut it anymore compared to git.

one example: updating to a new version of the wacom driver was a matter of
fedpkg clone xorg-x11-drv-wacom
<update master branch>
fedpkg commit && fedpkg push && fedpkg build

fedpkg switch-branch f14
git cherry-pick master
fedpkg commit && fedpkg push && fedpkg build

fedpkg switch-branch f13
git cherry-pick master
fedpkg commit && fedpkg push && fedpkg build

this is imo superior to re-editing spec files, possibly forgetting to update
sources/cvsignore in other branches (which has happened in the past). I know
what the original commit did, so cherry-picking it to other branches will do
the same.

Cheers,
  Peter