Junio C Hamano <gitster@xxxxxxxxx> writes:
> These are not independent (you cannot be in bisect and am at the
> same time).
You should not, but it seems you can. At least, I just successfully
started a "git am" during a "git bisect".
Even if some checks may be added to actually prevent the situation, it
seems better to keep "git status" robust to this kind of situation. If
the user did something really wrong, nice advices in "git status" will
be particularly helpful.
>> + int conflict = 0;
>
> How is this different from "unmerged"?
[...]
>> + path = mkpath("%s/MERGE_HEAD", git_dir);
>> + if (!access(path, R_OK))
>> + unmerged_state = 1;
>
> Ahh, so "unmerged" is "conflicted during merge" (as opposed to
> rebase_state is "conflicted during rebase")? Doesn't the naming
> sound odd? If it were "merge_state", it might have made a bit more
> sense (but again, these are not independent conditions, so multiple
> variables do not make sense).
The variable naming is wrong (it could be s/conflicts/unmerged_present/
and s/unmerged_state/merge_in_progress/ for example). But these two
variables are indeed independant. You can have unmerged path without an
actual merge in progress (conflicts during "git am"), an you can have a
merge in progress without conflicts (if you've just "git add"-ed them).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html