3 ms·
I think I found it extra confusing because this action (check out previous commit, do some work, merge with main) was completely supported in my previous dvcs o
by kibibu 3y ago
I think I found it extra confusing because this action (check out previous commit, do some work, merge with main) was completely supported in my previous dvcs of choice, Mercurial.
- deleted 3y ago[deleted]
- nerdponx 3y agoThe Git idiom in general is to make a branch for any work you intend to keep. But I'm also curious what you mean by doing work on a previous commit and then merging with main. Maybe it's a way to solve a problem I hadn't considered before.
- kibibu 3y agoBeen a long time since I used Hg, and I've mostly trained myself out of these ideas, but I'll try to recall the use cases. 1. Consider doing a bisect to find when a bug was introduced (which may now be in multiple branches) and being able to fix it immediately then merge and/or rebase over the current versions. 2. Working on a branch, you realize that you'd like to try an alternative approach to a problem. You check out a previous commit, leaving the branch in its non-working state, and try your alternative approach. If it works, you keep going on this version, otherwise you can just switch back. The temporary unnamed branch continues to exist until you choose to delete it (ideally before pushing!) . This unlocks a much lower inertia way to do small experimental work without having to formally label new branches, which carries enough weight to make me hesitate. I would do this all the time in Hg and almost never in git. In git I would probably reach for stash to achieve something similar.