4 ms·

> It was easier, because I could never figure out how to clean up properly if I made a mistake Made a mistake doing what? A mistake in your code or a mistake u

> It was easier, because I could never figure out how to clean up properly if I made a mistake Made a mistake doing what? A mistake in your code or a mistake using Mercurial? > If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup. Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc etc, but I'm just saying, it didn't work for me I've never understood this impulse to do "branch cleanup". Why are you adding unnecessary work? Is the source repository for tracking a history of changes or is it an art exhibition?

dreamcompiler 3y ago
I'be never understood this either--this idea of revising history to make the log look better. The proper solution is to build a better log display tool, not change the log itself.
- naasking 3y ago
  A better log display tool could help depending on why they want the log to look better. I often find that the reasons they want a better log is because they're not documenting/commenting their code sufficiently to figure out the code currently looks the way it does, so they want their source control to make up for poor coding practices.
- atq2119 3y ago
  I would certainly like to see this mythical tool that can support both: * Separating out different conceptual changes that are/were reviewed together and * Transparently cleanup a messy history that starts with a few base commits (corresponding to the conceptual changes) followed by a bunch of fixup commits for issues found by CI and review. That is the main problem solved by rebasing. I have yet to see even a coherent proposal for what the alternative would look like.
  - dreamcompiler 3y ago
    This could work with "meta-commit" messages added to groups of commits after the fact. Such messages could be parsed by the log display program. Git notes is the obvious tool for adding such metadata.
  - naasking 3y ago
    See this for a proper evisceration of rebase and what a proper tool would do: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
    - atq2119 3y ago
      This is yet another article that doesn't really seem to get it. For example: it argues that many small check-ins are better for bisecting -- but enabling a development process that encourages many small commits while still allowing bisect to work is one of the big reasons of rebase's existence! (Perhaps the author is biased/doesn't understand common use cases because SQLite has a famously thorough test suite that almost nobody else comes close to. SQLite's development flow is also comparatively simple: the Linux kernel, for example, has orders of magnitude more developers.) That said, it gets quite close to an interesting idea here: > Second, if Git remembered the source of cherry-picks in commits, Git users might have a better argument for avoiding rebase, because they’d have an alternative that didn’t lose history. I like the idea of properly remembering cherry-pick sources in commit metadata. It would be a cool thing to have, and potentially sometimes useful. But try to really imagine a world where this is how Git worked. How would you solve the two problems I stated in my GP comment? You'd just transform state A of a branch into state B by performing a sequence of cherry-picks. And that's pretty much exactly what git rebase is... So no, the author's proposal wouldn't eliminate the need for the rebase flow. It would subtly change the result of a rebase in a way that preserves more history. Which may or may not be useful, but I mostly wouldn't mind it. (Just for your consideration, losing history can be important when you're maintaining a mixture of open and closed source / trade secret branches. You may not care personally, but being pragmatic about such things has certainly helped git.)
      - naasking 3y ago
        > Perhaps the author is biased/doesn't understand common use cases because SQLite has a famously thorough test suite that almost nobody else comes close to I'm sure they understand the use cases quite well, and designed their Fossil VCS to address these faults. > And that's pretty much exactly what git rebase is... Except rebase disconnects it from the history where the author's solution does not. A view on a SQL table does not change the underlying data, it just presents it differently. That's the difference between what the author's proposal and yours.
jorams 3y ago
> I've never understood this impulse to do "branch cleanup". Why are you adding unnecessary work? Is the source repository for tracking a history of changes or is it an art exhibition? The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps. Often my first attempt at a change does something in an illogical order, or I make related changes that later end up in a separate merge. In the short term that change in thinking is somewhat interesting. In the long term it only confuses whoever is looking through the history to figure out why something is the way it is. The stronger version of this completely discards any history when merging a feature, but I often find that to get rid of useful information.
- naasking 3y ago
  > The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps. Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either. > In the long term it only confuses whoever is looking through the history to figure out why something is the way it is. Source control is the wrong tool for this job, that's what comments and tickets are for. Source control can help you retroactively figure out how and sometimes why something evolved in a certain way, like a good archaeological tool, but we don't use crude tools when there are better tools. I've taken to literally embedding ticket numbers along with comments directly in the code and in commit comments to document exactly why code does what it does. All functional changes are tied to tickets [1], and the tickets contain the full context, and the code comments contain a summary of that rationale. Use the right tool for the job. [1] where "functional changes" means changes that can affect behaviour, rather than stylistic changes on variable naming or revising comments that have no visible effects.
  - jorams 3y ago
    > Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either. It won't ever be perfect, but that doesn't mean we shouldn't strive to get as close as possible. > Source control is the wrong tool for this job, that's what comments and tickets are for. I agree that code comments play an important part in explaining why something is the way it is. Code comments and commit messages play a different role there, but they overlap and it can be tough to balance. Roughly: commits explain changes and the decisions made to arrive at that set of changes. Comments explain the end result and the decisions relevant to explain that end result. I disagree that tickets are a better way to convey this information. Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different, so all relevant information from such references should be in the comments or commit messages.

dreamcompiler 3y ago

I'be never understood this either--this idea of revising history to make the log look better. The proper solution is to build a better log display tool, not change the log itself.

naasking 3y ago
A better log display tool could help depending on why they want the log to look better. I often find that the reasons they want a better log is because they're not documenting/commenting their code sufficiently to figure out the code currently looks the way it does, so they want their source control to make up for poor coding practices.
atq2119 3y ago
I would certainly like to see this mythical tool that can support both: * Separating out different conceptual changes that are/were reviewed together and * Transparently cleanup a messy history that starts with a few base commits (corresponding to the conceptual changes) followed by a bunch of fixup commits for issues found by CI and review. That is the main problem solved by rebasing. I have yet to see even a coherent proposal for what the alternative would look like.
- dreamcompiler 3y ago
  This could work with "meta-commit" messages added to groups of commits after the fact. Such messages could be parsed by the log display program. Git notes is the obvious tool for adding such metadata.
- naasking 3y ago
  See this for a proper evisceration of rebase and what a proper tool would do: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
  - atq2119 3y ago
    This is yet another article that doesn't really seem to get it. For example: it argues that many small check-ins are better for bisecting -- but enabling a development process that encourages many small commits while still allowing bisect to work is one of the big reasons of rebase's existence! (Perhaps the author is biased/doesn't understand common use cases because SQLite has a famously thorough test suite that almost nobody else comes close to. SQLite's development flow is also comparatively simple: the Linux kernel, for example, has orders of magnitude more developers.) That said, it gets quite close to an interesting idea here: > Second, if Git remembered the source of cherry-picks in commits, Git users might have a better argument for avoiding rebase, because they’d have an alternative that didn’t lose history. I like the idea of properly remembering cherry-pick sources in commit metadata. It would be a cool thing to have, and potentially sometimes useful. But try to really imagine a world where this is how Git worked. How would you solve the two problems I stated in my GP comment? You'd just transform state A of a branch into state B by performing a sequence of cherry-picks. And that's pretty much exactly what git rebase is... So no, the author's proposal wouldn't eliminate the need for the rebase flow. It would subtly change the result of a rebase in a way that preserves more history. Which may or may not be useful, but I mostly wouldn't mind it. (Just for your consideration, losing history can be important when you're maintaining a mixture of open and closed source / trade secret branches. You may not care personally, but being pragmatic about such things has certainly helped git.)
    - naasking 3y ago
      > Perhaps the author is biased/doesn't understand common use cases because SQLite has a famously thorough test suite that almost nobody else comes close to I'm sure they understand the use cases quite well, and designed their Fossil VCS to address these faults. > And that's pretty much exactly what git rebase is... Except rebase disconnects it from the history where the author's solution does not. A view on a SQL table does not change the underlying data, it just presents it differently. That's the difference between what the author's proposal and yours.

jorams 3y ago

> I've never understood this impulse to do "branch cleanup". Why are you adding unnecessary work? Is the source repository for tracking a history of changes or is it an art exhibition? The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps. Often my first attempt at a change does something in an illogical order, or I make related changes that later end up in a separate merge. In the short term that change in thinking is somewhat interesting. In the long term it only confuses whoever is looking through the history to figure out why something is the way it is. The stronger version of this completely discards any history when merging a feature, but I often find that to get rid of useful information.

naasking 3y ago
> The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps. Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either. > In the long term it only confuses whoever is looking through the history to figure out why something is the way it is. Source control is the wrong tool for this job, that's what comments and tickets are for. Source control can help you retroactively figure out how and sometimes why something evolved in a certain way, like a good archaeological tool, but we don't use crude tools when there are better tools. I've taken to literally embedding ticket numbers along with comments directly in the code and in commit comments to document exactly why code does what it does. All functional changes are tied to tickets [1], and the tickets contain the full context, and the code comments contain a summary of that rationale. Use the right tool for the job. [1] where "functional changes" means changes that can affect behaviour, rather than stylistic changes on variable naming or revising comments that have no visible effects.
- jorams 3y ago
  > Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either. It won't ever be perfect, but that doesn't mean we shouldn't strive to get as close as possible. > Source control is the wrong tool for this job, that's what comments and tickets are for. I agree that code comments play an important part in explaining why something is the way it is. Code comments and commit messages play a different role there, but they overlap and it can be tough to balance. Roughly: commits explain changes and the decisions made to arrive at that set of changes. Comments explain the end result and the decisions relevant to explain that end result. I disagree that tickets are a better way to convey this information. Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different, so all relevant information from such references should be in the comments or commit messages.