4 ms·

> history does not matter if the change was parented in some temporary context It does if it means a big ball o' hackage lands on the public working branch, si

> history does not matter if the change was parented in some temporary context It does if it means a big ball o' hackage lands on the public working branch, since it complicates merges, backouts, cherrypicks, and bisects. Git users can also hide individual commit messages behind one big combined message, losing part of the project's development history and logical progression. When I pull your repo and build it, and I find that it doesn't build on my system, I don't want to dig through a 500-line merge commit to figure out why you changed this one line from the one that used to build last week, I want the 14-line diff it was part of so I can begin to understand what you were thinking when you committed it. If I later find out that that 14-line change was wrong but the rest of your 500-line merge was fine, I want to be able to back it out with a single command. (In Fossil, it's `fossil merge --backout abcd1234`.) > confuse other people with irrelevant information when they try to navigate the history. How much time do you spend navigating the project's history vs looking at the tip of the current branch? I'd wager that the times you dig back into the history, it's because you are in fact trying to figure out why you got here, which means a trail of detailed breadcrumbs will be more likely helpful than "...and between one week and the next, something changed in commit abcd1234, but we've lost all of its internal context, so we'll be spending next week reconstructing it because Angie's on vacation now."

tangent128 7y ago
Squashing changes isn't the only use of rebasing. It's reasonably common for me to start exploring a problem space, stub out a concept, and have a long drawn-out conversation with the compiler that touches many files, before finally reaching a point that is working enough to be interesting. At that point, I can take a step back and note that actually, not all of those changes have to be made all at once, and I can break that patch up into a bunch of simpler pieces. In Git, I have two essentially-equivalent choices: 1. stage the commit in small chunks, adding a separate descriptive comment for each. 2. commit everything as a WIP commit so this working state is in the reflog, then break it up into smaller commits with interactive rebase. In either process, I'm able to get a better comprehension of my own thoughts along the way. Fossil, refusing both staging would force me to commit the proverbial 500-line blob all at once, which is less helpful to the reviewer trying to discern my thought process. If rebasing isn't important to your workflow, Fossil probably is a better choice for you than Git. It has a lot of comforts that I really appreciated even eight years ago when I did frequently use Fossil (distributed wiki and tickets are really nice, the web interface serving raw artifacts from any point in time is great for HTML5 game jams, SQLite is a very portable repository format, etc. etc. etc.), and I'm sure it's only improved in that regard. The only reason I use Git for personal projects is because rebase is that helpful to my process.
- wyoung2 7y ago
  > Fossil...would force me to commit the proverbial 500-line blob all at once Nope. If it were me doing such a thing as you describe, I'd start the work on a feature branch. If I'm working on that repo with other active developers, this lets them see what I'm up to and possibly help; and if not help, then at least be aware about where my head's at, so they can better predict what's likely to land on the shared working branch later. If I got to a point where only part of the branch needed to be applied, I could cherrypick those individual changes, either down to the parent branch or up to a higher-level feature branch. All of this happens in public, with the work fully recorded, so someone doesn't have to reconstruct the development history after the fact later. This mode of development helps keep your project's bus factor above 1.
  - tangent128 7y ago
    You can commit code that doesn't compile onto a feature branch so people can see what you're up to, I guess, but I don't see that helping with bisecting later, and I wouldn't expect the commit messages to be useful. To be clear, my typical approach is certainly to commit every time I return to a working state. But in more experimental modes, I often reach that the long-way-around and have ended up with multiple semantic changes I wish to break apart for study. Unless I'm missing something and Fossil has gained the ability to cherry-pick selective lines from a commit.
- kazinator 7y ago
  Squashing isn't rebasing, period. The connection between the two is that git has a script called git rebase, which has an interactive mode, and that can squash commits. git merge has squash functionality also (git merge --squash).
dahart 7y ago
> It does if it means a big ball o' hackage lands on the public working branch, since it complicates merges, backouts, cherrypicks, and bisects. Rebase on a local working copy is normally used for cleaning up a string of commits that is messy and/or separating commits that mixed multiple logical changes together. Local commit history before push is arbitrary. There’s nothing sacred that needs to be preserved about the exact order I typed things into each file, that’s not what I want from a version control system. Personally, I haven’t really seen use of rebase complicating merges, reverts, cherry picks, or bisects. I can imagine ways it can happen, but I haven’t seen it be a problem in practice. However, I have seen cases where failing to rebase caused problems. Allowing build breakage between two commits is an example where bisect is affected, and squashing the fix into the first commit before push is much preferred. So, anyway, your example feels totally contrived. > How much time do you spend navigating the project’s history vs looking at the tip of the current branch? This is a false dichotomy. I need both. I happen to navigate project history quite a lot, like multiple times per day. In addition to how I got here I usually need to know who changed it, so I can talk to them.

tangent128 7y ago

Squashing changes isn't the only use of rebasing. It's reasonably common for me to start exploring a problem space, stub out a concept, and have a long drawn-out conversation with the compiler that touches many files, before finally reaching a point that is working enough to be interesting. At that point, I can take a step back and note that actually, not all of those changes have to be made all at once, and I can break that patch up into a bunch of simpler pieces. In Git, I have two essentially-equivalent choices: 1. stage the commit in small chunks, adding a separate descriptive comment for each. 2. commit everything as a WIP commit so this working state is in the reflog, then break it up into smaller commits with interactive rebase. In either process, I'm able to get a better comprehension of my own thoughts along the way. Fossil, refusing both staging would force me to commit the proverbial 500-line blob all at once, which is less helpful to the reviewer trying to discern my thought process. If rebasing isn't important to your workflow, Fossil probably is a better choice for you than Git. It has a lot of comforts that I really appreciated even eight years ago when I did frequently use Fossil (distributed wiki and tickets are really nice, the web interface serving raw artifacts from any point in time is great for HTML5 game jams, SQLite is a very portable repository format, etc. etc. etc.), and I'm sure it's only improved in that regard. The only reason I use Git for personal projects is because rebase is that helpful to my process.

wyoung2 7y ago
> Fossil...would force me to commit the proverbial 500-line blob all at once Nope. If it were me doing such a thing as you describe, I'd start the work on a feature branch. If I'm working on that repo with other active developers, this lets them see what I'm up to and possibly help; and if not help, then at least be aware about where my head's at, so they can better predict what's likely to land on the shared working branch later. If I got to a point where only part of the branch needed to be applied, I could cherrypick those individual changes, either down to the parent branch or up to a higher-level feature branch. All of this happens in public, with the work fully recorded, so someone doesn't have to reconstruct the development history after the fact later. This mode of development helps keep your project's bus factor above 1.
- tangent128 7y ago
  You can commit code that doesn't compile onto a feature branch so people can see what you're up to, I guess, but I don't see that helping with bisecting later, and I wouldn't expect the commit messages to be useful. To be clear, my typical approach is certainly to commit every time I return to a working state. But in more experimental modes, I often reach that the long-way-around and have ended up with multiple semantic changes I wish to break apart for study. Unless I'm missing something and Fossil has gained the ability to cherry-pick selective lines from a commit.
kazinator 7y ago
Squashing isn't rebasing, period. The connection between the two is that git has a script called git rebase, which has an interactive mode, and that can squash commits. git merge has squash functionality also (git merge --squash).

dahart 7y ago

> It does if it means a big ball o' hackage lands on the public working branch, since it complicates merges, backouts, cherrypicks, and bisects. Rebase on a local working copy is normally used for cleaning up a string of commits that is messy and/or separating commits that mixed multiple logical changes together. Local commit history before push is arbitrary. There’s nothing sacred that needs to be preserved about the exact order I typed things into each file, that’s not what I want from a version control system. Personally, I haven’t really seen use of rebase complicating merges, reverts, cherry picks, or bisects. I can imagine ways it can happen, but I haven’t seen it be a problem in practice. However, I have seen cases where failing to rebase caused problems. Allowing build breakage between two commits is an example where bisect is affected, and squashing the fix into the first commit before push is much preferred. So, anyway, your example feels totally contrived. > How much time do you spend navigating the project’s history vs looking at the tip of the current branch? This is a false dichotomy. I need both. I happen to navigate project history quite a lot, like multiple times per day. In addition to how I got here I usually need to know who changed it, so I can talk to them.