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
pgpHC43D2M7sF.pgp
Description: Digitale Signatur von OpenPGP
