Hacker News Reader

Comment by btym | Hacker News Reader

For example, correctly merging a finished feature branch requires up to 15 individual Git commands!

Am I missing something? Does `git merge` imply fourteen other commands?

Maybe they include things like stashing/popping current uncomitted changes, switching to target branch, pulling source and target branches first, rebasing feature branch onto latest target branch, resolving conflicts, ... ? All of these are things I has to do at one point or another to 'just' merge some feature branch from somebody else into master while I was working on another branch myself. So if they combine all of that in one command including taking care of everything which can go wrong I can imagine getting 15 commands.

> So if they combine all of that in one command including taking care of everything which can go wrong I can imagine getting 15 commands.

My concern would be: what happens when the automation encounters and edge case; what kind of unholy mess would you end up with?

And to be fair, with GitHub and GitLab, doing local feature branch merges has become a very rare event for me in the last 5 years.

Git Town covers a ton of edge cases. Just look at their "features" folder. If something goes wrong, Git Town allows to cleanly abort and undo what it did so far and go back to where it started.

That's a lot safer than the unholy mess that ensues when most people try to run "git reset --hard" or "git push --force" manually.

Edge cases handled properly may be the killer feature of this project, at least for me. With git, as long as I'm in familiar territory it's fine, but when somethings goes off rails my head's working set explodes with options.

The "15" is a link to a test case which shows the 15 commands. It's a contrived scenario in my opinion: it assumes that you want to merge a feature branch into the main branch while you're in the middle of working on some other, unrelated feature and have uncommited changes in your working directory.

Hardly a contrived scenario; I run into situations exactly like that at least once a week...

You could just make a new clean checkout in a different directory?

This is what I often do, however with larger repositories (where people have a bad habit of committing files that they probably shouldn't be, blowing out the size of the repo significantly), this can also be slow! But of course, this all comes down to your specific circumstances.

Mine were exacerbated by the fact that the bulk of the team didn't really understand git very well, and bouncing between features at a super rapid pace meant I could get into some slightly odd situations. Nothing a bit of git-fu can't fix normally, but can take a little bit of wrangling or forethought.

You could. I work with Firefox and that code base is huge so it's not a good idea to download 15+ gigs every time you don't know how to do something. Learning the tools is a more sustainable way to go.

Make an external worktree. No need to re-clone the whole repo, nor stashing/commiting your work, switching branch, doing the merge, etc (which you may know how to do, but is a pain if you often need to do so)

https://git-scm.com/docs/git-worktree

That's a neat command... it's also relatively new to git. I hadn't heard about it before... thanks!

Not sure what they're referring to, maybe resolving conficts (`git merge --continue` and such). But at least you may want to delete the topic branch afterwards, locally and on remote.

Reply on news.ycombinator.com