tig

tig copied to clipboard

While editing a commit in tig, it is not apparent what the end commit will be if we are to append the edits. So it's better to have an append mode in the status view.

Once the append mode is activated, tig should show the diff with HEAD's parent. Activating the commit keybinding will activate commit -a commit --amend instead of commit.

Is this the append mode you mentioned in the comment on Google+?https://plus.google.com/114916345471115163934/posts/1BiTKKjiaVJ)

[U]pon entering append mode, the diff is taken from the parent commit of the HEAD (effectively making the parent of current HEAD as HEAD). The diff will show up as if you are going to do a commit -a command. This is greatly useful to check what exactly will be the commit after you edit a commit in the history.

The trick is also in that you may unstage the changes made in the editing commit, and that should work seamless with the interactive mode of tig too.

The interactive + append mode is a nifty combination as they let you not worry about the previous commit and lets you worry about what the commit should've been.

With TL;DR being: interactive git commit ---amend

Regarding the status view, this should be a matter of using HEAD^ instead of HEAD when showing staged and unstaged changes.

Regarding using commit -a instead of commit. Do you meangit commit --amend, because-a` commits everything and I am not sure this is what you want. Dynamically changing the keybinding I think will end up overcomplicating things in the code, at least in its current state. The main reason being that keybindings and execution of external commands are handled globally and not in the status view itself. So to support this you would have to be able to bind multiple commands to one key, e.g.:

# Enter append mode
bind generic 'A' :set status-append-mode = yes \
                 :bind generic 'C' !git commit --amend

Where the ending '' tells tig to read the next line and append this.

Personally, I have to keybindings for committing. '.' which "ends" a current status/staging session, and '+' which "amends^Wappends" to the previous session.

bind generic . !git commit
bind generic + !git commit --amend

@jonas yes this is the same functionality I mentioned on that G+ post

Sorry for the confusion, I should've been using commit --amend instead of commit -a.

I understand that changing the key-bindings dynamically is overcomplicated, But how about adding a new key-binding by default for amending?

Let the user to choose the correct key for committing/amending, even in the amend mode.

Can you give an example of how this would be configured? Because as I said keybindings are not handled by the status view itself.

@jonas like you said before, you can put the key-binding in the base configuration of tigrc

so

bind status + !git commit --amend

will work in this case.

Why --amend at all? Just git reset HEAD^ before you start working. I mean, what disadvantage would there be?

@cody,

Resetting will make you lose the commit message for one. In amend mode you can do selective reset. To make this more clear, try using the amend mode in git-cola.

On Thu, Jan 15, 2015, 7:33 AM Cody A. Taylor [email protected] wrote:

Why --amend at all? Just git reset HEAD^ before you start working. I mean, what disadvantage would there be?

— Reply to this email directly or view it on GitHub https://github.com/jonas/tig/issues/211#issuecomment-70028832.

Commit messages are intended to be be short and easy to remember. More often than not your commit message changes anyway. If your commits are really large enough to justify a selective reset as reason to use --amend I propose that tig doesn't fit your workflow in the first place.

You could also bind git diff --staged for this purpose.

Yes they are also intended to be explaining the changes. The first line of the commit should be short, however there can be subsequent lines explaining why things are done in the commit. This kind of commit messages are seen in Linux kernel tree and others.

Yes there might be workarounds for this. But this may not be apparent for everyone.

I think this is a really cool feature to have with tig.

@cody, consider the following scenario: You made a commit that should've been two commits. How to go about splitting this?

With tig amend mode, you could do this without resetting the tree. (This is possible in cola)

I do git rebase -i HEAD~2 on the command line. While tig is great, it's workflow is simple. If you want a direct feature of git, use git.

For the original problem I still suggest binding something to git diff --staged %(commit). This will cover all use cases for --staged:

1. See only staged changes - select the HEAD commit in main view.
2. See all the changes if you were to commit --amend - select the HEAD^ commit in the main view.
3. See if it's reasonable to squash the index into two or more previous commits - select the HEAD~(N) commit you don't want to include.

@Avinash-Bhat I've stumbled across another option. After doing git reset --soft you will have an ORIG_HEAD pointer that keeps the commits you just reset. You can use that like git commit -c ORIG_HEAD to keep the same commit information.

Seeing as how @jonas wrote tig mostly for his own use, he will usually writes features he will use himself (correct if I'm wrong here @jonas). This seems like an edge case with more than one work around, so creating a specialized mode for appending to a commit seems to be not very likely.

I think amend is a common workflow for many (e.g. Android AOSP development using Gerrit). I believe this is partially evidenced by the fact that git team added the --amend feature in the first place.

I agree this is a missing feature. I just switched from git-cola to tig for commiting and this is the only feature I'm missing so far.