Is it possible to mark a git commit as work-in-progress?

Question

I'm aware that there are various opinions and philosophies about whether or not all commits on the master branch should leave the project in a valid, working state. I'm not asking for these opinions.

For the sake of argument, let's assume that somewhere in the master branch history I identified a commit that is actually a work-in-progress commit, i.e. it doesn't build or it breaks other things. Since we are talking about history in the master branch, rebasing or amending (or anything that actually changes the commit) is not an option.

To warn other developers and to make it easy for an automated git bisect script to skip this commit, I want to somehow mark this commit as work-in-progress. How do I do this?

I have thought about using git tag, but since tags must be unique you would end up using tags like wip/<some_unique_id> which is an ugly hack in my opinion. Also, conceptually we do not want to treat this commit as a tagged commit, i.e. we probably never want to check it out, we may not want it to appear in the list of tagged commit points etc.

Solution 1

Use git notes to add notes to certain commits without touching their commit hash.

If you want to annotate HEAD~5 with a note, do

git notes add HEAD~5 -m "better don't use this commit. It breaks the build"

Publish your notes with

git push origin refs/notes/*

Have a read of ProGit for more details.

Solution 2

In other hand, just to bring good practices to the conversation, I would say the described situation where you cannot rebase or amend, being on master, should never happen. Every commit merged on a shared branch (master, develop, whatever) should always be stable. I don't see any reason explaining why a WIP commit could not be on a dedicated branch.

In a preferable approach, you would, for example:

git checkout -b hotfix-branch
git add .
git commit -m "[wip] Fixing index route access"
git push origin wip-branch

Then, after finishing the work:

git commit --amend  # Let's reword to "[hotfix] Fixed index route access"
git push origin hotfix-branch --force
git checkout master
git merge hotfix-branch  # Fast-forward or not, etc., whatever
git push origin master
git push --delete origin hotfix-branch
git branch -d hotfix-branch

In this example (which can surely be improved, that's not the point), amend can be replaced by some fixup/autosquash if needed, but you get the painting. The point is to work on a dedicated branch, use Git to save unstable state through a WIP commit, then rewrite history before merging to shared branch to keep the git log clean.

One should never, as you said, rewrite history on a shared branch. This is why you don't want to put yourself in a situation where such a thing could even come to your mind. Always work on dedicated branches where rewriting history doesn't matter, and merge clean and stable commits on shared branches. (:

Solution 3

I never heard about such feature, so I created it :

# Commit current work as wip so that I can switch branch
function gitwip {
    git add -A && git commit -m wip
}

# Reset last commit if it is a work in progress
function gitrwip {
   lastCommitMessage=`git log --oneline -n1 | awk '{$1= ""; print $0}'`
   lastCommitMessage=${lastCommitMessage:1:30}
   [ "$lastCommitMessage" = wip ] && git reset HEAD~1 || echo "#$lastCommitMessage#[...]" is not a wip commit
}

The gitwip function prevent me from doing a git reset HEAD~1 if the last commit is not a wip commit.

Comments

[Rudey]

Where do I place these lines? What's gitrwip?

[Moebius]

@RuudLenders This a bash function. You can put it in your terminals after your prompt. If you want this function to be here every time you log in with your terminal, you have to put it in your .bashrc (if you are using bash).

[mr_georg]

-1. This does not answer the question. The assumption of the OP's question was, that there is a wip-commit on master. It doesn't help to say, that it should not happen, even if you are absolutely right about that ...

[Scolopendre]

As I said in my first sentence, I was just talking about good practices, giving an alternative approach to a biased question. But you're right, that is not really a direct answer to the question, it could have been a comment. My bad. (: