3 ms·

In my experience, if you ever use more than clone, fetch, pull, push, checkout, merge(tool), reset, add, and commit then somebody messed up.

CameronNemo 7y ago
I rebase all the time FWIW.
- sixstringtheory 7y ago
  I constantly use git commit --fixup 6138D3A git rebase --autosquash --interactive origin/master to keep a clean history of cohesive commits. Rarely do I change _everything_ required for an objective in one go, I still like to commit as I work, I just like the finished product to _seem_ like I did it in one go, for future maintainers' sake. And I rebase to catch up with upstream, I can't stand having intermediate merge commits in my history and rebasing lets you resolve conflicts as they're introduced, instead of an all-at-once at the end.
  - rane 7y ago
    You might find this git alias useful. Wrote it a few years ago and find it useful daily. [alias] fix = "!_() { c=$(git rev-parse $1) && git commit --fixup $c && if grep -qv \"No local changes\" <<<$(git stash); then s=1; fi; git -c core.editor=cat rebase -i --autosquash $c~; if [[ -n "$s" ]]; then git stash pop; fi; }; _" The workflow becomes: $ git add ... # stage the changes you want to apply to 6138d3a $ git fix 6138d3a
    - sixstringtheory 7y ago
      Wow, I always love when a git/shell elder comes along and shows me something like this. I didn't know about `git -c` before, I'm assuming it's setting per-command config values? I've also not used/seen `!_()` before... I'm assuming it's introducing something like an anonymous function and calling it at the end... but why not just break out the body of the function and execute it directly in the alias? Does it help with error propagation? Thank you!
      - raimue 7y ago
        git will append all remaining command line arguments to the end of the aliased command. Therefore `!f() { ... }; f` is the usual style for this kind of git alias to get access to the arguments as needed with $1, $2, etc. in the shell function.

CameronNemo 7y ago

I rebase all the time FWIW.

sixstringtheory 7y ago
I constantly use git commit --fixup 6138D3A git rebase --autosquash --interactive origin/master to keep a clean history of cohesive commits. Rarely do I change _everything_ required for an objective in one go, I still like to commit as I work, I just like the finished product to _seem_ like I did it in one go, for future maintainers' sake. And I rebase to catch up with upstream, I can't stand having intermediate merge commits in my history and rebasing lets you resolve conflicts as they're introduced, instead of an all-at-once at the end.
- rane 7y ago
  You might find this git alias useful. Wrote it a few years ago and find it useful daily. [alias] fix = "!_() { c=$(git rev-parse $1) && git commit --fixup $c && if grep -qv \"No local changes\" <<<$(git stash); then s=1; fi; git -c core.editor=cat rebase -i --autosquash $c~; if [[ -n "$s" ]]; then git stash pop; fi; }; _" The workflow becomes: $ git add ... # stage the changes you want to apply to 6138d3a $ git fix 6138d3a
  - sixstringtheory 7y ago
    Wow, I always love when a git/shell elder comes along and shows me something like this. I didn't know about `git -c` before, I'm assuming it's setting per-command config values? I've also not used/seen `!_()` before... I'm assuming it's introducing something like an anonymous function and calling it at the end... but why not just break out the body of the function and execute it directly in the alias? Does it help with error propagation? Thank you!
    - raimue 7y ago
      git will append all remaining command line arguments to the end of the aliased command. Therefore `!f() { ... }; f` is the usual style for this kind of git alias to get access to the arguments as needed with $1, $2, etc. in the shell function.