Hacker News Reader

Comment by wredcoll | Hacker News Reader

> 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...

View on HN

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.

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.

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.

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.

>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.

Thanks, I was writing about git, though.

> 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.

Thank you for going into details, you helped me understand a few more details.

Let me describe how I think about it and why it might possibly conflict with your ideas.

I think the best way to describe it is as a series of approvals, each one being more important than the previous one.

The absolute lowest level of approval, writing the file to disk. You've made some changes and you're happy enough with them to at least save them in case you have a power outage or something.

The next level of approval is committing to your local git repo. This is code you're fairly confident you want later, even if it might not be perfect yet.

The next level is pushing your branch to the origin repo. Now you're saying that this is code you're willing to let other people look at.

The last level is merging this code into main/trunk/whatever. This is the final level of approval, this code passes all of our checks, it shouldn't need any more improvement.

Given this system, adding another level in there, for staging commits, feels pretty unnecessary.

I agree that merge commits tend to make for ugly git history, but I don't think that's particularly inherent to any of these systems of code integration, it's more a function of how much the developers care about the git log.

> change commits, but this has a danger of creating a version that was never there or mixing history,

I'm not sure what the benefit here is. I think I've basically ended up in a situation where I treat 'git commit' the same way I treated "save file" 20 years ago. My local commits/saves/edits aren't important, what's meaningful is the final unit of change I'm sending to the remote, and that unit needs to be deliberately constructed somehow. Whether that involves rebasing or amending or careful usage of git stage, it's an artificial unit you're creating just as much as the actual code changes.

Reply on news.ycombinator.com