Olaf Hering <olaf@xxxxxxxxx> writes: > Is there a way to detect (from a script) if the current working tree is in state 'merge'? The first step is to define what "state 'merge'" is, I think. Are you trying to go into a repository with an unknown state, see if there is anything to commit, and then commit whatever is in the working tree and/or in the index? Perhaps you are doing so with some condition to avoid recording random mess (e.g. avoid doing a commit if the index is still unmerged, i.e. "git ls-files -u" gives something, as "git commit -a" from such a state may record working tree files in an unusable contents with conflict markers)? The way "git commit" that is forbidden to create an empty commit (i.e. a single-parent commit whose tree is identical to the tree of its sole parent) is to see if the index to be made into a tree to be committed is different from the tree of HEAD (i.e. "diff-index HEAD" must not be empty) but still allow an otherwise empty commit to be made if MERGE_HEAD exists (i.e. the resulting commit will be a no-op relative to the previous tip of the branch, marking everything done on the side-branch to now have been integrated---this happens when a side branch gets merged to 'master' but a better solution is already there). > Right now I had the case that a conflict resolution resulted in > 'no pending changes'. As a result my "git --no-pager status > --porcelain --untracked-files=no | tee $t" showed nothing, which > skipped the required 'git commit' in my script. Why are you scripting around "git commit"? Doesn't "git commit" refrain from creating an empty commit when there is nothing to commit anyway, unless it is recording a merge whose result happens to be a no-op?
