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

21–30 of 43 posts

Re: On branching

#21

Post by apotheon »

hyperbolist wrote: post #10
ubernostrum wrote: post #5

Earlier quoted context omitted.

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.

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.

Re: On branching

#22

Post by tene »

ubernostrum wrote: post #17
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 had a two-word reply to your opinions, but then I realized HN would vote me down into oblivion for expressing it in those terms. So I'll pose it in different terms: why haven't you given into the network effects of, say, Visual Basic?

Can you elaborate on what the network effects of using Visual Basic would be, actually? What domains does Visual Basic have significant network effects? How does this compare against the network effects of Perl's CPAN, which is a significant factor in my choice of programming language?

Re: On branching

#23

Post by youngian »

eru wrote: post #11
fexl wrote: post #2

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.

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

Re: On branching

#24

Post by unbracketed »

ubernostrum wrote: post #8
traviscline wrote: post #6

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

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

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

Re: On branching

#25

Post by ubernostrum »

tene wrote: post #22
ubernostrum wrote: post #17

Earlier quoted context omitted.

I had a two-word reply to your opinions, but then I realized HN would vote me down into oblivion for expressing it in those terms. So I'll pose it in different terms: why haven't you given into the network effects of, say, Visual Basic?

Can you elaborate on what the network effects of using Visual Basic would be, actually? What domains does Visual Basic have significant network effects? How does this compare against the network effects of Perl's CPAN, which is a significant factor in my choice of programming language?

Offhand, I'd bet VB will open up a larger raw number of job opportunities than Perl. So why doesn't everybody jump on that bandwagon? After all, every major language is Turing-complete, so obviously people are just nitpicking when they could be choosing a clear winner.

Re: On branching

#26

Post by ubernostrum »

unbracketed wrote: post #24
ubernostrum wrote: post #8

Earlier quoted context omitted.

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

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

Re: On branching

#27

Post by ubernostrum »

hyperbolist wrote: post #16
ubernostrum wrote: post #14

Earlier quoted context omitted.

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

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.

Re: On branching

#28

Post by ubernostrum »

traviscline wrote: post #19
ubernostrum wrote: post #8

Earlier quoted context omitted.

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

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.

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

Re: On branching

#29

Post by traviscline »

ubernostrum wrote: post #28
traviscline wrote: post #19

Earlier quoted context omitted.

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.

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

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

Re: On branching

#30

Post by fexl »

_delirium wrote: post #7
fexl wrote: post #2

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.

I do this too, partly because when I have branches and revisions as actual directories and files, I can use the usual Unix tools on them, instead of having to use a parallel set of tools provided by the version control system.

I have another reason for the old-fashioned approach. I do hedge fund accounting for a living. With my software tools I can reproduce every result ever created for a fund from original input, even going back several years. I have translators for various brokerage feeds that I've had to maintain and adapt for years -- and this is no small feat considering that information technology people in the financial industry can't do a complete, consistent, or stable data feed to save their lives.

Whenever I make a change, either to a translator or even the core accounting code, I make a copy of the library. I then have to go back and run all funds, including my test funds, as a regression test using the new modified library. I have to do that one fund at a time, testing to make sure no catastrophic differences have arisen. So during this interim period, I have some funds running on the new code and some funds running on the old code. BOTH versions have to be "live" at the same time.

I also have to keep backups of the data as well, both inputs and outputs, so I can "diff" those easily. I'm sure as heck not gonna put that into git.

So I'm not just stick in the mud trying to be contrary -- I have work to do, and it needs to be as reliable as a Swiss watch.

Post reply on HN