Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On branching

b-list.org

Post reply on HN
Print view View original

31–40 of 43 posts

Re: On branching

#31

Post by hyperbolist »

ubernostrum wrote: post #27
hyperbolist wrote: post #16

Earlier quoted context omitted.

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. Whi…

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.

Re: On branching

#32

Post by hyperbolist »

apotheon wrote: post #21
hyperbolist wrote: post #10

Earlier quoted context omitted.

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?"

Re: On branching

#33

Post by fexl »

youngian wrote: post #23
eru wrote: post #11

Earlier quoted context omitted.

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

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.

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.

Re: On branching

#34

Post by fr0sty »

apotheon wrote: post #21
hyperbolist wrote: post #10

Earlier quoted context omitted.

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.

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...

Re: On branching

#35

Post by gsakkis »

ellyagg wrote: post #15

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 li…

Funny, I could have posted the same comment after s/git/mercurial/g and s/Github/BitBucket/g. But then again, it would be equally stupid and trollish.

Re: On branching

#36

Post by unbracketed »

ubernostrum wrote: post #26
unbracketed wrote: post #24

Earlier quoted context omitted.

"Git standard workflow"? Where'd you get that notion from? Supposing there is one, care to share?

Where'd you get that notion from? From the documentation and from the fact that pretty much every git user who's responded has told me the same things. Or am I supposed to take that as a massive coincidence?

You didn't specify your sample size and I won't vouch for what people I don't know tell you. You can take it as whatever you'd like. Next you'll be saying the Django tutorial is the standard way to lay out projects. It's in the documentation, right?

Re: On branching

#37

Post by eru »

fexl wrote: post #33
youngian wrote: post #23

Earlier quoted context omitted.

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.

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.

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.

Re: On branching

#38

Post by ubernostrum »

unbracketed wrote: post #36
ubernostrum wrote: post #26

Earlier quoted context omitted.

Where'd you get that notion from? From the documentation and from the fact that pretty much every git user who's responded has told me the same things. Or am I supposed to take that as a massive coincidence?

You didn't specify your sample size and I won't vouch for what people I don't know tell you. You can take it as whatever you'd like. Next you'll be saying the Django tutorial is the standard way to lay out projects. It's in the documentation, right?

Well, of the people who decided to provide answers on HN or reddit, the consensus was: merge the branch, delete it, then add a tag on the merge commit. And then on IRC the author of this book told me to do the same thing:

http://pragprog.com/titles/tsgit/pragmatic-version-control-u...

The only person who suggested anything else, out of fifty-seven comments so far, was one who suggested merging the branch and then keeping it around rather than deleting and tagging it.

Since that's all I have to go on, and since it seems to be a pretty clear consensus, I'm taking their advice as being a generally-accepted convention amongst git users. Granted, such conventions in git seem to be as ephemeral as branches (e.g., fads such as "rebase everything! rebase after every commit! No, wait, never rebase! Rebasing is evil! Nobody should rebase!"), but if you're trying to suggest that as a result there are no conventions, I'm just going to write you off.

Re: On branching

#39

Post by llimllib »

_delirium wrote: post #18
ellyagg wrote: post #15

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 li…

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.

> 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...

Re: On branching

#40

Post by nsm »

ellyagg wrote: post #15

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 li…

I use mercurial, because it supports HTTPS pushing. Git has had a request for http(s) push for years and hasn't implemented it. My university blocks outgoing SSH access and none of the standard prescribed solutions work. Its quite easy for someone with a job to say - "Get a VPS and tunnel through it", but I can't afford a VPS, so git has barriers to entry, and until that is reduced I will stick to my LiveJournal.

You should switch to Windows again, you'll receive the enormous benefit that everyone you know uses the same OS.

Post reply on HN