4 ms·

> You should not just be interested in how the tip of your feature branch compares to the latest main, but also into the logical sequence of steps your feat bra

• exceptione 2y ago
  When you rebase your feat branch on top of latest main, all commits in your feat branch are YOUR commits. Each of those commits change something relative to main. Unless your are committing against yourself. So if you are confusing yourself (which should be rare because --I repeat-- all commits in your feat branch are your own commits) you have a good opportunity to clean up your own mess with git rebase -i.
• MrJohz 2y ago
  > But those events do go wrong, and having the context to understand what happened matters. Have you never had a mismerge or a merge conflict? Interestingly, despite being designed for a very rebase-heavy workflow, this is one of the things that Jujutsu does really well. You work with mutable changes rather than immutable commits, and each change references one or more commits that represent (roughly) the history of that change. So locally, you can see how a particular change has evolved, and you can easily undo some action or reference an older state while working on that change itself. Then when you push to a remote, the other people will only see the end-result of the change. Which is typically what I want: I want to retain a good sense of the history of the changes I'm working on at the moment, so I can go back and forth, try out different things, and not worry about losing any data or handling conflicts badly or whatever. But, when I've finished with my change, and it's been pushed, reviewed, etc, that history is now superfluous. I don't need to know that, while I was developing a feature, I accidentally committed a typo and then needed to make another commit to remove that typo. (And if there is information I do think is important, then I can create additional changes, or add the information to the commit message or the code itself as a comment.)
  • Nullabillity 2y ago
    > Interestingly, despite being designed for a very rebase-heavy workflow, this is one of the things that Jujutsu does really well. [snip] Then when you push to a remote, the other people will only see the end-result of the change. Yes, jujutsu is designed to hide (some of) the problems with rebase from yourself, while still inflicting them on everyone else . History for me, but not for thee! While also complicating the interaction model because you now have two sorts of history to contend with. Which actually sucks, because jj could have had been a much better alternative to Quilt for maintaining patch series over third-party software (á la Linux distributions) if it supported collaboration over the metahistory/oplog. > But, when I've finished with my change, and it's been pushed, reviewed, etc, that history is now superfluous. I don't need to know that, while I was developing a feature, I accidentally committed a typo and then needed to make another commit to remove that typo. This assumes that you'll actually find all the issues during the review. Do you also erase your history after every release?
    • MrJohz 2y ago
      Do you have a case where seeing all the small changes I made during development is helpful for fixing bugs and issues in the future? I would have thought it is rarely useful, and often actively unhelpful. Let's say I make a change in three steps: I rename all uses of X in the codebase, I remove the Y component, and I fix bug Z. To me, this should be three commits: X, Y, and Z, one for each of the changes. But to get to the final point, I probably haven't done that in only three steps. What I've probably done is I've tried out change W, but that didn't help at all so I abandoned it, then I started doing Y, realised that I needed to do X first for Y to make sense, so I switched and did X, then I finished Y, then I could do Z. Then I realised that while doing X I'd forgotten some stuff so I finished that off, then I realised that the tests weren't passing because part of Y wasn't finished. Then I pushed everything and the reviewer pointed out that while fixing Z, I'd left some code commented out and I needed to remove it properly. Long-term, which of these sets of changes would be most useful? Surely the first one: it shows my aim while making changes, it is clearly bisectable, and it is divided into clean units of work without overlap or having those units intermingled. As a future developer, I can run `git blame` or equivalent and clearly see why each line of code was changed, and for what reason. Whereas with the latter case, bisecting the codebase will stumble on all the intermediate situations where a test failed or the code didn't compile or whatever, because bad states during the development process are now part of the permanent history. And it'll produce spurious results when I try to annotate a file: the last time this file was changed was because I temporarily commented out this line and then immediately commented it back in again, how do I see only the changes that made a meaningful impact to this line? In my experience, recording these sorts of "fixup" changes permanently in the history has never been useful. Having clear, precise commits that each do one thing: definitely, yes, this is a fantastic tool. But being able to go back in time with such granularity as to see when you broke a test and then fixed it in review? Or when you started out doing one change and then did something else instead in a different order? I have never found that level of detail useful, and it is often makes things harder when I'm trying to focus on the significant commits and changes and just want to filter all of those out.