8 ms·

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

by bvrmn 4y ago

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

quietbritishjim 4y ago
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").
- troyvit 4y ago
  Yeah Mercurial seems like what git should have been but never will be.
- AvImd 4y ago
  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.
  - bvrmn 4y ago
    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/ https://stacked-git.github.io/
    - AvImd 4y ago
      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`.
      - bvrmn 4y ago
        For this case `git stash` is enough.
- lenkite 4y ago
  If only someone had launched hghub.com at the time of github.com.
  - bvrmn 4y ago
    I remember issues with windows/unix interop for mercurial repos when github started to gain traction.
  - WorldMaker 4y ago
    Bitbucket tried.
- bvrmn 4y ago
  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.
koonsolo 4y ago
> 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.
- morleyk 4y ago
  I would just delete the branch after merge to the main and then create a new branch from main.
- minitech 4y ago
  > 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.)
- maccam94 4y ago
  > 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
- bvrmn 4y ago
  > 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.

by bvrmn 4y ago

quietbritishjim 4y ago

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

troyvit 4y ago
Yeah Mercurial seems like what git should have been but never will be.
AvImd 4y ago
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.
- bvrmn 4y ago
  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/ https://stacked-git.github.io/
  - AvImd 4y ago
    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`.
    - bvrmn 4y ago
      For this case `git stash` is enough.
lenkite 4y ago
If only someone had launched hghub.com at the time of github.com.
- bvrmn 4y ago
  I remember issues with windows/unix interop for mercurial repos when github started to gain traction.
- WorldMaker 4y ago
  Bitbucket tried.
bvrmn 4y ago
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.

koonsolo 4y ago

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

morleyk 4y ago
I would just delete the branch after merge to the main and then create a new branch from main.
minitech 4y ago
> 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.)
maccam94 4y ago
> 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
bvrmn 4y ago
> 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.