Junio C Hamano <gitster@xxxxxxxxx> writes:
> In other words, I would prefer to see something like:
>
> $ git merge --index-only [-s <strategy>] <other_branch>
>
> which
>
> (0) does work without any file checked out in the working tree;
>
> (1) does not update a path in the working tree even if the merge
> result for the path is different from the original index entry for
> the path;
>
> (2) updates the index only when everything cleanly merges (depending
> on the definition of "cleanly merges", e.g. "union" may be a lot
> more lenient than the usual "text" merge) and aborts without
> touching anything if there is a conflict (because --index-only
> does not allow us to touch working tree to ask the user to resolve
> the conflict).
>
> "git merge" is designed to work without any file checked out in the
> working tree, by considering a _missing_ file in the working tree as if
> there is _no change_ to the path during a merge. IOW, we do not say "you
> have an uncommitted local removal of a path, which other side tried to
> modify, hence we stop the merge to protect your local change".
>
> This is so that you can do something like this:
> ...
> In other words, we are already half-way there, I think.
Addendum.
People have wished on this list who have two or more branches, e.g. "work"
and "play", based on the same upstream branch to be able to do:
$ git fetch origin
$ git checkout work
$ git merge @{u}
$ git checkout play
$ git merge @{u}
$ git checkout work
i.e. integrate upstream changes without having to check out "play" branch
first, if there is no conflict. The standard answer has been "You cannot,
because you may not know if there will be a conflict until you try".
But the existing "merge in a temporary working tree that is empty to start
with" support is a good way to implement it. You would do something like
this after you are on your "work" branch and finished merging from its
upstream (package this up in a "git simplemerge" script):
rm -fr .t && mkdir .t && cd .t &&
GIT_DIR=$(git rev-parse --git-dir) &&
GIT_INDEX_FILE=$GIT_DIR/temp-index &&
GIT_WORK_TREE=$(pwd) &&
export GIT_DIR GIT_INDEX_FILE GIT_WORK_TREE &&
save_head &&
git symbolic-ref refs/heads/play HEAD
git read-tree play &&
(
git merge --no-commit play@{upstream}
)
restore_head
If the merge goes well without conflict, you write the temporary index out
to a tree, create a commit and update the "play" branch (save_head should
save away the current branch and restore_head should restore it).
If the merge conflicts, you _could_ ask the user to resolve it in .t/
directory (with these updated GIT_DIR/GIT_INDEX_FILE/GIT_WORK_TREE), write
the result out to a tree, create a commit and update the "play"
branch. This is entirely optional, as the common request is to do this
only when the merge is trivial and there is no conflict.
And if we are allowed to punt when there is a conflict, we do not need the
temporary working tree at all if we had --index-only option. We only need
to save and restore the HEAD pointer and the index file so that we can
continue working on the "work" branch after we are done.
This incidentally is the reason why I said "update the index" and not
"create a commit" when I specified the behaviour of "--index-only" in the
previous message.
--
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