Hacker News Reader

Comment by bvrmn | Hacker News Reader

Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform.

Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git)

I know you have no time to know your tool. But I don't see any hurdles to allocate one evening and read https://jwiegley.github.io/git-from-the-bottom-up/. It gives a model that you can apply to other distributed VCS and may be make you a better engineer.

View on HN

Mercurial is also great for rebasing (that's cherry picking in Git terminology - not the same as git rebase!). If I had experimental changes, I would often just commit things and mark them as private (so they wouldn't get pushed) rather than shelve (the Hg equivalent of git stash). Then, when I actually wanted them, I would rebase them on to the most recent revision (using --keep so the originals were still there if something went wrong - then I could strip the originals when the dust settled). Hg is so easy to use that you can feel really confident manipulating the commit graph, in a way you normally wouldn't risk in git.

It helps that Mercurial has a really nice cross platform GUI: TortoiseHg. Version control is one of those things that really benefits from a GUI because you're manipulating small elements complex object - the commit graph. Using the command line is bit like using ed to edit a text file (i.e. with commands like "insert xyz between lines 12 and 13").

Yeah Mercurial seems like what git should have been but never will be.

Is there any option to have this "private commits" feature in git? I just realized it's exactly what I wanted so many times. I've tried the assume-unchanged hack but it's too brittle.

I successfully use [stgit][1] (for 10 years) for private commits and pretty much for the rest of near-git workflows.

[1]: https://stacked-git.github.io/

Does stgit help with the following scenario:

1. I want some changes in my repo to be persistent whenever I switch to a new branch, pull, or merge a remote.

2. They should not be shown in git status.

3. They should not be pushed.

From skimming the front page I haven't found whether something like this is supported.

I see that with stgit I can `stg pop` my "persistent changes" before pushing to the remote and then apply it again with `stg push` but that requires that I use stg commands to create patches instead of `git commit`.

For this case `git stash` is enough.

If only someone had launched hghub.com at the time of github.com.

I remember issues with windows/unix interop for mercurial repos when github started to gain traction.

Bitbucket tried.

I heavily used mq extension and it was pretty inferior in UX terms to StGit at those times. With StGit there are no any nice features in Mercurial for me.

> Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with.

I did, plus MS SourceSafe, Team Foundation Source Control and Bazaar.

I don't see the problem with SVN and Mercurial. If you have merge conflicts, no tool is going to solve that.

If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merge again. Have fun solving all the merge conflicts that actually shouldn't be there.

Like I said, SVN and Mercurial are fine too. I don't see any reason why git would magically solve some merge conflict that SVN or Mercurial is not able to.

> do a squash merge to the main

If you want Git to continue keeping track of your commits, don’t squash-merge them.

Squash merging loses valuable history in general and use of it is a sign that commits on source branches are being made carelessly.

(That said, if I had to do this, I’d rebase off of the squash before merging again and have no problems.)

> try to do a squash merge to the main, then do some other changes in your branch, and try to merge again

For this situation, at the end just do:

git rebase -i main

And delete all of the commits that you included in your squashed commit. If you want to preserve your detailed history you can create a new branch for the rebase like so:

git checkout -b mybranch-rebase && git rebase -i main

> If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merge again. Have fun solving all the merge conflicts that actually shouldn't be there.

Why I should want to do it? It feels unnatural. What problem you are trying to solve by this workflow?

I'm very curious how your favorite VCS handle this case.

I would just delete the branch after merge to the main and then create a new branch from main.

Reply on news.ycombinator.com