3 ms·

Mercurial was not better. Features like rebase /squash are not native to mercurial (even though they since added extensions for this) and the tool had a very

by zzzeek 9mo ago

Mercurial was not better. Features like rebase /squash are not native to mercurial (even though they since added extensions for this) and the tool had a very rigid view of the commit history. I had all my projects on Mercurial for several years after using SVN, because it felt more similar to SVN and I had no mental concept of why you'd ever want something so crazy as "rebase" - commit histories looked the way I always remembered them looking with SVN, with tons of tiny commits like "fix comma", "fix syntax", and no steady concept of a commit hash linked to a complete, working change, because that was something I had never seen before. Basically I just didn't get it. Today my workflow is based on git + gerrit code review (which is heavily based around git), or in other areas github pull requests, and there is no such thing as a series of little commits that all hodge-podge together to form a particular change to the code, we tailor changes to be perfect, we push -f to keep each commit in the series to be a full and CI-tested story of a change, then we squash-merge them. My use with git is 100% all day things that were impossible with Mercurial back when I used it, if there are extensions for these things now, they are afterthoughts, git understood these concepts from the beginning.

jamwil 9mo ago
As a native son of git, I’m curious what the idiomatic way to maintain a patched fork was without rebase? Would you simply have your “patched” branch and merge in upstream changes as they arrive?
- zzzeek 9mo ago
  as I recall, you didn't! you just had branches full of dozens of commits for every little bit of the change. yes you'd have to merge continuously to stay up to date.
btreecat 9mo ago
hg sees history as useful metadata, and therefore you shouldn't dress it up artificially. git allows for folks to be Pinky's out with their commit history for warm an fuzzies. If you think editing history is a grand idea that should be used regularly (like with rebase) then I already know you likely haven't been responsible for large mature code base. Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.
- zzzeek 9mo ago
  you might want to check on what you "know" then....
  - btreecat 9mo ago
    [flagged]
    - throw-the-towel 9mo ago
      Nice technical argument you've got here.
      - btreecat 9mo ago
        What's your excuse then?
    - zzzeek 9mo ago
      just so you know, this line > Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone. see that's a common story from a legacy way of working, back when everyone wrote perl / php scripts and shoved it all into a repo. The way that people years from now understand what someone else did is that when that someone else does the thing, it's presented for code review. That is, your patch does not go in at all if nobody else knows how it works. You present each change as a logical series of commits, without lots of noise like "fixed typo" or "oops forgot this test", just the way people present patches on the LKML (this is why Linus "got it" before anyone else did), and then other people review it, which is where it's established, "this change makes sense, I understand why and how you did it, and it has good tests". When you work on a project that is truly long term, you yourself need these records to understand what you did 10 or 15 years ago. So there's no issue that short term history was modified, this is actually essential, because what you're doing is editing the story of how a change came about and presenting it for review. Having it be a long series of small commits that sometimes reverse each other is not going to help anyone understand a particular feature or change, it's noise.

by zzzeek 9mo ago

jamwil 9mo ago

As a native son of git, I’m curious what the idiomatic way to maintain a patched fork was without rebase? Would you simply have your “patched” branch and merge in upstream changes as they arrive?

zzzeek 9mo ago
as I recall, you didn't! you just had branches full of dozens of commits for every little bit of the change. yes you'd have to merge continuously to stay up to date.

btreecat 9mo ago

hg sees history as useful metadata, and therefore you shouldn't dress it up artificially. git allows for folks to be Pinky's out with their commit history for warm an fuzzies. If you think editing history is a grand idea that should be used regularly (like with rebase) then I already know you likely haven't been responsible for large mature code base. Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.

zzzeek 9mo ago
you might want to check on what you "know" then....
- btreecat 9mo ago
  [flagged]
  - throw-the-towel 9mo ago
    Nice technical argument you've got here.
    - btreecat 9mo ago
      What's your excuse then?
  - zzzeek 9mo ago
    just so you know, this line > Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone. see that's a common story from a legacy way of working, back when everyone wrote perl / php scripts and shoved it all into a repo. The way that people years from now understand what someone else did is that when that someone else does the thing, it's presented for code review. That is, your patch does not go in at all if nobody else knows how it works. You present each change as a logical series of commits, without lots of noise like "fixed typo" or "oops forgot this test", just the way people present patches on the LKML (this is why Linus "got it" before anyone else did), and then other people review it, which is where it's established, "this change makes sense, I understand why and how you did it, and it has good tests". When you work on a project that is truly long term, you yourself need these records to understand what you did 10 or 15 years ago. So there's no issue that short term history was modified, this is actually essential, because what you're doing is editing the story of how a change came about and presenting it for review. Having it be a long series of small commits that sometimes reverse each other is not going to help anyone understand a particular feature or change, it's noise.