4 ms·

> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate th

> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready Since you brought this up, I've noticed some people seem to work this way but I've never found anyone to ask why they do this. I get the idea behind clean, readable git logs with nice consistent messages, but isn't that what rebase/amend is for? To me, the status of my local git log is mostly irrelevant, the thing that really matters is the commit(s) I submit for merging. Also, probably for related reasons, I've never truly understood why git has this whole separate staging concept...

1718627440 1y ago
I also work this way. A commit is really about, well, committing that these are exactly the right lines of code I intended to write. I also read them in another program, so it gets easier to not think that I already know the code and skip over. I basically start from the clean state (no changes) again and approve the changes line-by-line according to whether they fit the domain model of the program, whether they are in the right places, are the right amount of complexity/abstraction, if they are readable/understandable. I typically also add/remove comments at that point, because I've now tried to read the code with a "second pair of eyes". I also use this to compare the changes to the commit messages. Ideally the changes follow from the message, not the other way around. While a VCS is also useful for adding a time-axis to code, for me the main selling point is, that it's adding causality to the code. You can ask 'Why is this code how it is?'. (Of course causality is a side-effect of time.) When you don't curate the commits you completely loose this feature. (You can still ask, but the answers will be confusing and need way more work, which for me amounts to manually comparing commits to grasp the big picture and intention.) > rebase/amend When you messed up, you can of course change commits, but this has a danger of creating a version that was never there or mixing history, for example combining a single physical change, that are multiple logical changes. In order to test that the code at least works I use ```git rebase --exec="make -C build distcheck"```, not sure if that is common. I also don't use MS GitHub -style merges, I find them inferior. (I also don't use MS GitHub, but that's for another reason.) I think they try to make merges the actual unit of change, which is stupid, because that is what a commit is for. To me merges are about semantic grouping of commits, i.e. maintaining a tree of commits representing the logical evolution of the code. Yes the staging area is exactly designed for this approach and I don't like people telling me I'm holding it wrong and don't need it. To use a metaphor, I think the staging area is like my desk were I'm producing stuff (I'm not producing code, I'm producing changes). Committing is about having produced a complete opus and then cleaning the desk. Cleaning isn't seen as annoying, it is important for the mind to process completing/validating and then starting afresh. Stashing is in this metaphor about switching to an alternate desk. This is different from putting the opus aside and having also a clean desk. (I think that is what Jujutsu wants you to do?) Having the staging-area/stash different from commits is a feature, the fact that the stash is the same storage-wise is an implementation detail.
- Filligree 1y ago
  By default, the top (current) commit acts like a staging area and in fact is implemented as a dirty working tree in git. Commits start live without a description, and can’t be pushed without adding one. jj commit names the current commit and creates a new empty, unnamed commit on top, which effectively is precisely git’s behaviour. I implore you to try it. In practice the distinction just doesn’t matter, except it’s one less concept to keep track of, and jj allows you to make up other workflows if you want.
  - 1718627440 1y ago
    Sure, sometimes I want to work with a WIP commit and then I'm just doing that in git. I think functionally of the stage is about the UI, so keeping it separate is kind of the point. I find that useful, as I can use both approaches, not sure how its better if jj can just use one? > to ask why they do this. This was what I was trying to explain. To me the feature is needing to manually mark every line to be committed. If I need to split the commit I'm already not paying that much attention.
    - riwsky 1y ago
      jj’s workflow isn’t about being careless with commits—it’s about time-shifting that care to when it’s most convenient. You’d split the commit later for the same reasons you wouldn’t want your text editor to force manually marking each line to save to disk.
- kps 1y ago
  >A commit is really about, well, committing that these are exactly the right lines of code I intended to write. That would be a ‘change’ in jj. A commit in jj is more like SQL than git; it's the end of a transaction, not a value judgement.
  - 1718627440 1y ago
    Thanks, I was writing about git, though.

1718627440 1y ago

I also work this way. A commit is really about, well, committing that these are exactly the right lines of code I intended to write. I also read them in another program, so it gets easier to not think that I already know the code and skip over. I basically start from the clean state (no changes) again and approve the changes line-by-line according to whether they fit the domain model of the program, whether they are in the right places, are the right amount of complexity/abstraction, if they are readable/understandable. I typically also add/remove comments at that point, because I've now tried to read the code with a "second pair of eyes". I also use this to compare the changes to the commit messages. Ideally the changes follow from the message, not the other way around. While a VCS is also useful for adding a time-axis to code, for me the main selling point is, that it's adding causality to the code. You can ask 'Why is this code how it is?'. (Of course causality is a side-effect of time.) When you don't curate the commits you completely loose this feature. (You can still ask, but the answers will be confusing and need way more work, which for me amounts to manually comparing commits to grasp the big picture and intention.) > rebase/amend When you messed up, you can of course change commits, but this has a danger of creating a version that was never there or mixing history, for example combining a single physical change, that are multiple logical changes. In order to test that the code at least works I use ```git rebase --exec="make -C build distcheck"```, not sure if that is common. I also don't use MS GitHub -style merges, I find them inferior. (I also don't use MS GitHub, but that's for another reason.) I think they try to make merges the actual unit of change, which is stupid, because that is what a commit is for. To me merges are about semantic grouping of commits, i.e. maintaining a tree of commits representing the logical evolution of the code. Yes the staging area is exactly designed for this approach and I don't like people telling me I'm holding it wrong and don't need it. To use a metaphor, I think the staging area is like my desk were I'm producing stuff (I'm not producing code, I'm producing changes). Committing is about having produced a complete opus and then cleaning the desk. Cleaning isn't seen as annoying, it is important for the mind to process completing/validating and then starting afresh. Stashing is in this metaphor about switching to an alternate desk. This is different from putting the opus aside and having also a clean desk. (I think that is what Jujutsu wants you to do?) Having the staging-area/stash different from commits is a feature, the fact that the stash is the same storage-wise is an implementation detail.

Filligree 1y ago
By default, the top (current) commit acts like a staging area and in fact is implemented as a dirty working tree in git. Commits start live without a description, and can’t be pushed without adding one. jj commit names the current commit and creates a new empty, unnamed commit on top, which effectively is precisely git’s behaviour. I implore you to try it. In practice the distinction just doesn’t matter, except it’s one less concept to keep track of, and jj allows you to make up other workflows if you want.
- 1718627440 1y ago
  Sure, sometimes I want to work with a WIP commit and then I'm just doing that in git. I think functionally of the stage is about the UI, so keeping it separate is kind of the point. I find that useful, as I can use both approaches, not sure how its better if jj can just use one? > to ask why they do this. This was what I was trying to explain. To me the feature is needing to manually mark every line to be committed. If I need to split the commit I'm already not paying that much attention.
  - riwsky 1y ago
    jj’s workflow isn’t about being careless with commits—it’s about time-shifting that care to when it’s most convenient. You’d split the commit later for the same reasons you wouldn’t want your text editor to force manually marking each line to save to disk.
kps 1y ago
>A commit is really about, well, committing that these are exactly the right lines of code I intended to write. That would be a ‘change’ in jj. A commit in jj is more like SQL than git; it's the end of a transaction, not a value judgement.
- 1718627440 1y ago
  Thanks, I was writing about git, though.