add -u / --auto-stage command-line parameter to toggle autostage

[Konfekt]

As vouched for by @teto, @ccoVeille and my humble self in the aftermath of #98

While, in theory, this is easily achieved by a temporary git config value as well. The thinking was that in practice, this to be rather an occasional opt-in rather than opt-out.

However, also in view of the upstream issue: libgit2/libgit2#385 , a cli flag might be more practical.

[kiprasmel]

The thinking was that in practice, this to be rather an occasional opt-in rather than opt-out.

I'm just wondering why turning it on always is not satisfactory already?
i.e., if always turned on with a config option, absorb will stage all changes if and only if there's nothing staged by you. otherwise, if you staged anything, absorb won't do any extra staging.

[Konfekt]

Usually there is some file that is not to be staged. In all other cases, it would be useful to stage all files. As discussed, this could be worked around by temporarily setting config options in an alias, but it seemed to me rather unwieldy instead of a switch like -u.

[kiprasmel]

Usually there is some file that is not to be staged.

I see, that makes sense. Myself however I commit the non-fixup files first, and only then run absorb, so I don't have this issue. But fair enough.

We could then also have a --no-autostage switch to disable temporarily if enabled by default..

[ccoVeille]

We could then also have a --no-autostage switch to disable temporarily if enabled by default..

I agree with you about the need of being able to disable a possible auto stage mode enabled by the conf.

[kiprasmel]

i could implement this.

@tummychow a UX question - if user specifies the --autostage flag, should we autostage everything, (A) even if something was already staged, or (B) only if nothing was staged (i.e. mimic the behavior of enabling the git config flag absorb.autoStageIfNothingStaged)?

to me I think (B) makes more sense. we could have an additional flag like --all to get the (A) behavior. and equivalent shorthands -u and -U, which matches how git does certain flags, e.g. checkout -b, checkout -B

[tummychow]

yeah i'm fine with having both personally. i prefer to stick to upstream ux where possible, but upstream doesn't set a great example here, eg git add has -A and -u, and git commit has -a which is like git add -u, etc. for now let's start with B (match the behavior of the git config flag). that way, we don't have to tackle questions of what to do with unabsorbed hunks (as we discussed back here)