
On branching - stakent
http://www.b-list.org/weblog/2010/feb/02/branching/
======
hyperbolist
Coming from svn, I too felt initial discomfort about git's promiscuous
branching, but then I learned to stop worrying and love the index. Working in
svn repositories evokes "I wish this was a git repository" every time.

I wouldn't have initially trusted git if it weren't for Linus's Google Talk.
And I'm glad I gave it the time it requires to change workflows.

The most unexpected side-effect of using git is a newfound willingness to
follow experimental ideas in my projects as fast as I can think/type. I'll
guess it comes from confidence in git's ability to safely partition branches
in-situ; the relative speed and ease with which branches are created, merged
and destroyed; and the existence of the index and stash. Git removes the
version control inertia I didn't even know was there.

~~~
ubernostrum
You seem to be under the impression that I'm afraid of short-lived branches
for minor work. I'm not sure how you could have gotten that impression unless
you didn't actually read the article.

~~~
hyperbolist
I read the article, I enjoyed it. It reminded me of why I like git so much.

git-diff doesn't require you to do gymnastics to compare files from different
branches in the same working directory: "git diff branch1 [branch2] path"
where omitting branch2 compares the working path instead of branch2's.

And I think your second problem with git, that big hairy branches should
somehow be distinct from small simple branches, is also a non-issue.
Especially since you already recognized the solution: let big hairy branches
live, and small simple branches die.

Since you can reconstruct deleted branches, I don't see the problem with
deleting them. Bugfix branches for specific releases can be created as needed
by choosing the release commit in master as the starting point for the branch.
If you really want to keep dormant branches around you can rename them to keep
them distinct from "working" branches.

Sorry for not having specifically addressed these in the original comment,
which was actually supposed to be a reply to fexl
<http://news.ycombinator.com/item?id=1095116>

~~~
ubernostrum
_git-diff doesn't require you to do gymnastics to compare files from different
branches_

It requires me to use git-diff. How do I do it without involving the VCS tool?
How do I get both files side-by-side in Emacs so I can go through them
thoroughly (some of us prefer that to reading diffs, you know)?

 _Since you can reconstruct deleted branches, I don't see the problem with
deleting them._

I want the history of my codebase to be easy to get a feel for; that means
major work (e.g., a long-lived branch which made significant changes) should
be easily accessible. Telling people to hunt down the right merge commit and
work back through its ancestry doesn't do that. Inventing ad-hoc schemes of
tags or renamed branches to try to make up for the inability to keep a branch
but say you're done with it doesn't do that.

 _It reminded me of why I like git so much._

Meanwhile, it's (one reason) why I _don't_ like git so much.

~~~
hyperbolist
_How do I get both files side-by-side in Emacs so I can go through them
thoroughly (some of us prefer that to reading diffs, you know)?_

    
    
      git show branch:path/to/file > /tmp/file
    

_I want the history of my codebase to be easy to get a feel for_

So never delete branches. You'll know if they're "done" if they've been merged
into your master branch.

~~~
ubernostrum
_git show_

Did you miss the part where I said I'd like to _not involve the VCS tool_?
Without using git, how do I see two different branches' versions of files?

 _So never delete branches. You'll know if they're "done" if they've been
merged into your master branch._

But nobody else will. What everybody and their brother has told me to do is
delete the branch and invent an ad-hoc naming scheme to tag the merge commits.
Which is... um, no, that's not the same as being able to close a branch.

~~~
hyperbolist
_how do I see two different branches' versions of files?_

You could clone the branches to different paths, I guess.

 _But nobody else will [know that a branch is "done".]_

If you've instructed the team to care about merged status, they will. And
there's nothing semantically strange about it either.

I get it, git isn't for you. I concede.

------
ellyagg
It actually annoys me when people don't use git now. Git has clearly won among
current dvcs. If something comes along later that's head and shoulders above
dvcs, then I'll be happy to switch. But for now, random folks' views on why
their tool is marginally technically better doesn't outweigh the enormous
benefits of everyone you know using the same dvcs.

And it annoys me when people use BitBucket over Github. It's like your one
friend who insists on not having a Facebook account and sticking to his
Livejournal because Livejournal is supposedly better at some random thing, but
in reality, you strongly suspect he just wants to prove he's not a follower,
an independent breed cut from a better cloth than the rest of us.

These days, whenever I need a new little tool, its official repo is usually on
Github. This lets me pull it into my project as a submodule and still
contribute back in a very efficient way. As soon as it's mercurial, I can't,
simply because I don't know mercurial and I certainly have zero intention of
attaining the same mastery of it that I have of git. And, frankly, I don't
want to attain any mastery of it.

Moreover, of course, you can't just mix repos willy nilly. Maybe there's a way
to use mercurial as a submodule of git repos. But it's gonna be a dastardly
hack.

So, please. Just use git. Competition is good, but so is standardization. I
get that you have highly nuanced opinions about the various merits of dvcs,
and I'm sure you're right and I'm wrong. But it just doesn't matter, because
the benefits of mercurial don't outweigh the beneficial network effects of
using git, and that's never going to change.

~~~
_delirium
Maybe it's the circles I travel in, but I don't see the same git dominance you
do vs. mercurial; I see them both really frequently. Among major projects I
can think of off the top of my head, Python, Adium, OpenOffice, and Mozilla
are all on mercurial.

~~~
llimllib
> Python... [is] on mercurial

Welllll... no. Python has made the decision to move to hg, but the conversion
has hit some stumbling blocks and is not yet complete:

[http://sayspy.blogspot.com/2010/01/where-hg-transition-
stand...](http://sayspy.blogspot.com/2010/01/where-hg-transition-stands.html)

------
traviscline
I don't really see much value in keeping a branch around after development is
complete (or defunct).

If the work is complete then merge it (with no-ff if you want to show the
merge explicitly). If it's defunct then delete it. If you want to keep it
around but discourage further development then tag it or come up with a naming
convention.

That you have the ability to mark branches as closed in mercurial is mainly
paper over their odd decision to not allow deletion of branches.

~~~
ubernostrum
_I don't really see much value in keeping a branch around after development is
complete (or defunct)._

If you have both branches and a way to close them, then you have a much
simpler way to get a feel for the history of the code. You know at a quick
glance what sort of major work has gone on and what's still ongoing.

If you don't have that you'll end up inventing more complex ad-hoc schemes to
get it (merging a branch, deleting it and tagging the merge commit is an
example of one such scheme, and it doesn't do the same thing).

And the ability to mark branches as closed in Mercurial is, to me, an
indication that the developers put some thought into the different use cases
for branching and wanted to cover more of them than git's standard workflow
does ;)

~~~
traviscline
Actually, git supports more workflows, you could simply implement read-only
branches with a naming scheme and a hook.

In lots of ways git is a superset, branch workflow included.

~~~
ubernostrum
_git is a superset_

A superset which doesn't include everything that's in the alleged subset? That
must be a new definition of "superset" that I haven't heard of yet...

~~~
traviscline
The possible workflows with git encompass hg workflows. You're obviously not
interested in gaining anything but self-fulfillment throughout this thread.

------
fexl
I've used svn and git, but something still doesn't feel right. I still like
"cp -pr" and "diff -r" for version control. I waste disk space with whole
directory copies, but I eventually "rm -rf" the really old ones. I don't trust
automatic merges so I do them manually, yanking and pasting between vim edit
panels. I am a paleolithic relic.

~~~
eru
"rm -rf" is dangerous. A versioning system should allow you to get by without
doing dangerous stuff.

~~~
youngian
<http://code.google.com/p/trash-cli/>

I don't know, maybe if you're old-fashioned you won't like the trash metaphor,
but I love it. And every so often I just do trash-empty 30 to clean out
anything older than a month.

~~~
fexl
I like the trash metaphor. I haven't formalized it yet, but often I will
simply "mv" things to ~/old or ~/tmp and let it rot there for a few months.
Thanks for the tip, I'll check it out.

~~~
eru
I quite like the way Gmail handles this issue. Stuff just goes stale and drops
of the first page of your inbox. But it's still there --- and I now feel that
it's barbaric to delete emails.

