4 ms·

In Git you don’t have to actually commit, you can use the staging area. It’s something I do rather often. I’m going to make a non-trivial change and I’m not sur

In Git you don’t have to actually commit, you can use the staging area. It’s something I do rather often. I’m going to make a non-trivial change and I’m not sure if it’s the right approach, so I `git add -A` first, make my change, and then `git diff —-cached` to review it. This is especially useful when doing things like running formatting tools, so I can see what the tool just did. And it doesn’t require making any commits. Having said that, this approach only works if I know up front that I’m going to want to compare the code. Far more often is making a change and then realizing I want to see the old version. A history timeline would be extremely useful here.

nilsbunger 6y ago
Even commits are malleable until you push them somewhere. I do this a lot - create commits of any meaningful checkpoint, then rearrange/squash/remove commits later that I don’t want , to create a well-formed commit that I push. Git stash can handle your use cases too, but commits are more powerful as they let you compose multiple pieces together
- gorgoiler 6y ago
  If you work on a branch you can push them to your remote repo anyway. Good for backups or if you move between hosts for any reason (I do this all the time as I prefer static workstations for focus and work/life balance.) Branches rightly became a bit of a dirty word over the last decade. In a fast moving collaborative codebase the pattern you really want to avoid is using a long running feature branch — one that remains uncommitted to trunk for ever more uncomfortable periods of time. Branches themselves — the VCS technology part — are incredibly useful when used fluently.
- sixstringtheory 6y ago
  You can also use git commit --fixup, or, to fix up a commit with message “wip something”, you can make comments with messages like “fixup! wip something” or “squash! wip something” and git rebase --autosquash --interactive will reorder them all (squash! allowing you to stack commit messages by writing in the commit bodies)
  - xyzzy_plugh 6y ago
    Yes. I usually maintain a hefty stack of commits where the top ~5 are experimental WIP nonsense for me to either clean up to or discard, the next ~10 might be code out for review. But in between pushes to remotes, every session of changes turns into a slew of fixups and I'm often rebasing a stack of 30+ commits, massaged into 2-3 change sets.
    - sixstringtheory 6y ago
      I have the same, but now at work we use the GitHub squash function in PRs. I still make fixup commits but don’t have to rebase to manually squash them any more.
- CGamesPlay 6y ago
  Trivia for you: git stash is actually storing the changes as a set of stacked commits on a hidden branch. You can even do a git log or amend on your stash, although the stash abstraction is pretty complicated under the hood.
WalterBright 6y ago
Eh, I use the dumb approach of: cp code.d code.old if I'm going to make some trial changes :-/
- cpach 6y ago
  Nothing wrong with that :)
vincentmarle 6y ago
Are you suggesting that people make commits before reviewing the changes? I never thought of that...
- throwaway744678 6y ago
  No commit is involved at this point, only the staging area.

nilsbunger 6y ago

Even commits are malleable until you push them somewhere. I do this a lot - create commits of any meaningful checkpoint, then rearrange/squash/remove commits later that I don’t want , to create a well-formed commit that I push. Git stash can handle your use cases too, but commits are more powerful as they let you compose multiple pieces together

gorgoiler 6y ago
If you work on a branch you can push them to your remote repo anyway. Good for backups or if you move between hosts for any reason (I do this all the time as I prefer static workstations for focus and work/life balance.) Branches rightly became a bit of a dirty word over the last decade. In a fast moving collaborative codebase the pattern you really want to avoid is using a long running feature branch — one that remains uncommitted to trunk for ever more uncomfortable periods of time. Branches themselves — the VCS technology part — are incredibly useful when used fluently.
sixstringtheory 6y ago
You can also use git commit --fixup, or, to fix up a commit with message “wip something”, you can make comments with messages like “fixup! wip something” or “squash! wip something” and git rebase --autosquash --interactive will reorder them all (squash! allowing you to stack commit messages by writing in the commit bodies)
- xyzzy_plugh 6y ago
  Yes. I usually maintain a hefty stack of commits where the top ~5 are experimental WIP nonsense for me to either clean up to or discard, the next ~10 might be code out for review. But in between pushes to remotes, every session of changes turns into a slew of fixups and I'm often rebasing a stack of 30+ commits, massaged into 2-3 change sets.
  - sixstringtheory 6y ago
    I have the same, but now at work we use the GitHub squash function in PRs. I still make fixup commits but don’t have to rebase to manually squash them any more.
CGamesPlay 6y ago
Trivia for you: git stash is actually storing the changes as a set of stacked commits on a hidden branch. You can even do a git log or amend on your stash, although the stash abstraction is pretty complicated under the hood.

WalterBright 6y ago

Eh, I use the dumb approach of: cp code.d code.old if I'm going to make some trial changes :-/

cpach 6y ago
Nothing wrong with that :)

vincentmarle 6y ago

Are you suggesting that people make commits before reviewing the changes? I never thought of that...

throwaway744678 6y ago
No commit is involved at this point, only the staging area.