4 ms·

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

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

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.