3 ms·
I’m gonna be honest, this sounds horrible. If you do adopt this though, why even use Git? Why not use Perforce or something?
by weakfish 2y ago
I’m gonna be honest, this sounds horrible. If you do adopt this though, why even use Git? Why not use Perforce or something?
- kevmo314 2y agoAs someone who uses this model with git, the main reason is because git is ubiquitous but I cannot get used to git's incredibly user unfriendly API. I've tried the feature branch approach and it doesn't click for me. Merge conflicts, lost changes, and git reset everywhere. So in other words, I'm using this model because if I could use perforce I probably would, but git is everywhere. Also, every time I bring up git's user unfriendliness, I'm always told it's not that hard and I'm holding it wrong. I'm sure I am now too, I just don't care.
- mamcx 2y agoWith jujutsu I think is very close to allow this kind of stuff. I like branches because some of my work truly benefit from slow cooking, but with jj I'm more linear than before.
- weakfish 2y agoI’m curious how you’re encountering merge issues. I have gravitated towards aggressively rebasing onto main, which has almost entirely solved this for me.
- kevmo314 2y agoIf I'm only working on one feature at a time then actually it's largely ok, it's when I have to manipulate the commit graph that things start to really go wrong for me. But rebasing I still don't understand, even after using git for over 10 years. I mean, I understand conceptually what it's trying to do, but every time I run `git rebase` I end up in a crazy wild state. For example, suppose I'm working off main and I have a new branch right off HEAD with five commits on it. I realize that oh actually I want to port this onto a different branch that was HEAD~5 with three new commits that aren't on main. When I run this, git suddenly seems to merge conflict a whole bunch of stuff unrelated to my commits (and are related to the three commits not on main) and it gets worse the further from main the relevant branch is. What I really want to do is essentially take the last five commit diffs and apply them to the HEAD of some other branch instead, like how you might drag and drop the graph nodes. Currently to work around me not understanding why git doesn't align with my mental model, I un-commit my changes, git stash them, switch to the target branch, create a new branch, and then git stash pop. This seems to work much more reliably but it's so tedious to do every time that I kind of avoid doing this sort of change as a whole.
- hbogert 2y agoso `git rebase HEAD~5..HEAD --onto other-branch-with-3-new-commits` ? And now you have conflicts, how is that weird? I can't think of a magic tool which would guarantee you a conflict-free solution with your described scenario. What I don't understand is that, iiuc, you do not get conflicts with your stashing approach. Again, iiuc, this would result in the same conflicts as the rebase way, if not, you're not telling us something important in the way your are rebasing.
- kevmo314 2y ago> Again, iiuc, this would result in the same conflicts as the rebase way Yeah I mean I agree I would have expected too but it's not what happens to me. Like I said I'm sure I'm using it wrong but that's my gripe with git: I don't think it's very user friendly.