How do you deal with incomplete commits?

[Thomas Friedrichsmeier]

Hi all,

may I pick your brains for this question that keeps coming up for me?

Say I'm working on a feature in branch A. I have some changes in my
working copy that are so half-baked that I don't want them to end up in
the commit history as such, but I don't want to throw them away, either.

Now I want to switch to branch B for something unrelated. What do I do
with my changes? How do you folks deal with this?

1) Stash my changes, then switch. Works, but the stash is something
that I tend to forget about, when going back, and this method get
messy, quickly, when dealing with several branches at once.

2) Commit the changes, anyway, but marked as "WIP" or similar, and use
commit --amend, when coming back. However, it wouldn't be the first
time that I forgot to amend, after all, and pushed my WIP-commits.

2a) I could use a "work/" branch, which would at least give me a chance
to correct this after pushing. I'd still have to remember to do so,
before merging my work into a regular branch, though.

2b) What I'd really like to see is a commit keyword that would make git
throw an error, if I try to commit something on top of it, thus forcing
me to use commit --amend.

2c) Alternatively, do we have a keyword that would prevent a commit
from being pushed (or from being merged to something that is not a
"work/" branch)? That would not be as nice as 2b, IMO, but it would
still catch my usual mistakes.

Any other solution that I am missing? Do we have something along the
lines of 2c (not according to our docs, AFAICS)?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20201031/0027865a/attachment.sig>