Tommi Virtanen <tv@xxxxxxx> writes:
> My best idea so far is to add a "git commit -A" option, that
> essentially does the "update-index --refresh". Whenever index
> has a file state != HEAD, update-index it. The modified unrelated
> files will have index state == HEAD. Or altering "git commit -a"
> to do that.
I am not sure what you are trying to achieve by --refresh. It
does not update the object names in the index. Maybe you are
thinking about --again, but that is when you did something to
the index yourself, so it would not buy you much in the "novice
faced with merge" case.
Anyway, I think the time to commit is too late to save somebody
who does not understand the index. How would you explain why
you sometimes need to use -A and sometimes -a? That is why I
suggested to make "git pull" and "git merge" refuse to work if
there are local changes for novice users, where the definition
of novice is "git commit -a" is the only way to make a commit.
We can have [core] novice = yes in .git/config for that.
If somebody does not understand the index, if the merge is
prevented because the local change does conflict with it, how
would you explain why sometimes you can merge and sometimes you
cannot?
But if you insist going that route, I would say we could make
"git commit -a" on a merge commit to do a bit more magic.
For example, we could make -a do something special for a merge
by looking at the presense of .git/MERGE_HEAD.
- if "commit -a", and without .git/MERGE_HEAD, just grab
all the local modifications that are not in index yet,
and commit it.
- upon "commit -a", and when .git/MERGE_HEAD exists,
grab the paths that ls-files -u reports, update-index
them. Other automerged paths are already registered
in the index.
> Except, trying to solve usability problems by _adding_ options
> is just insane.
I am not sure if it is "usability" but additional option to
simplify things does not sound right, I'd agree.
> For example, we had a case where we absolutely _had_ to keep
> an ugly workaround in the tree, in a file not otherwise
> edited, but we definitely did not want to commit the kludge,
> at least not to the branch that was really being worked on. So
> such restricted mode would just have meant either people could
> not merge, or they had to use index anyway.
Your example is a very ill-thought out one.
If you are leaving the uncommitable kludge around, you cannot be
using "commit -a" with the normal non-merge workflow. Why
would you worry about not being able to do "commit -a" on a
merge then?
For the beginning user without index, I would rewrite your
scenario like this.
- Jack is a beginning user of git and does not (want to) understand
the index (right now).
- Jack works on branch X, say his HEAD points to X1. He has an edited,
uncommitted files with the names A, B and C.
- Jack wants to pull new changes made by others to his branch.
But "git merge" invoked from "git pull" says he needs to stash
away the local changes to do the merge.
- Jack stashes away what he has been working on and cleans up
his mess.
git diff >P.diff
git checkout HEAD A B C
- Jack then pulls. There are merge conflicts in files D, E, ..., Z.
- Jack resolves the merge conflicts and is ready to commit the resulting
merge. Note files A, B and C do not have his unfinished work.
There is no "if Jack does this or that" problem; he says "git
commit -a" because that is the only "commit" command he knows
about.
- Jack then reapplies what he stashed away with "git apply P.diff"
and keeps working.
Maybe "git stash" command that does "git diff --full-index" with
some frills, and "git unstash" command which does an equivalent
of "git am -3" would help this workflow (bare "git apply" does
not do the three-way merge like am does).
-
: 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