Hacker News Reader

Comment by hyperbolist | Hacker News Reader

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.

View on HN

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.

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

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.

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.

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.

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.

GIT_EXTERNAL_DIFF lets you use emacs as your diff tool.

http://stackoverflow.com/questions/255202/how-do-i-view-git-...

Further:

To say "I'm done with this branch", merge it to master. This is natural; you already do this.

  git branch --merged master # list branches that are "done"
  git branch --no-merged master # list branches that are "not done"

Now you never need to delete any branches if you don't want to and you can eyeball their status without introducing any misbehaviors or gymnastics.

Okay, now . . . tell me how this provides any benefit over Mercurial's options.

I'm not making that claim, and freely admit that I am utterly ignorant about mercurial. I'm merely demonstrating that, contrary to the author's assertion, it's possible to use git without deleting branches and still have a meaningful way to measure whether a branch is "done", and it's the common-sense measure of "has it merged?"

You can change your mind and turn a 'bookmark' into a 'branch' and back again. you can also fold your branch into another one and pretend it never happened. Or you can pick your branch up and place it somewhere else in the tree, or...

I very much like what you say about "newfound willingness." But I, Triceratops, am perfectly willing to experiment:

  cd project/loom
  cp -pr code ~/version/loom/95.before_zany_idea
  # hack away; restore if irredeemably stupid
  diff -r code ~/version/loom/93.released
  # you get the idea

I'm not trying to denigrate git. I still use it to publish code, e.g. http://github.com/chkoreff/Loom. But my dirty little secret is, I still shamefully use "cp -pr" and "diff -r" anyway, and only git-commit right before pushing to github.

Reply on news.ycombinator.com