Junio C Hamano <gitster@xxxxxxxxx> writes:
> In other words, can't the check you need in submodule be scripted around
> the specific plumbing responsible for the branch switching, which is:
>
> $ git read-tree -m HEAD $other_branch
>
>> @@ -397,7 +400,7 @@ static int merge_working_tree(struct checkout_opts *opts,
>>
>> /* 2-way merge to the new branch */
>> topts.initial_checkout = is_cache_unborn();
>> - topts.update = 1;
>> + topts.update = !opts->dry_run;
>> topts.merge = 1;
>> topts.gently = opts->merge && old->commit;
>> topts.verbose_update = !opts->quiet;
>
> What you are doing in this part of your patch is exactly that two-tree
> form of the "read-tree -m", no?
That is, this would succeed:
$ git reset --hard master
$ git read-tree --index-output=rubbish -m master next
and these would fail:
$ git reset --hard master
$ echo >>Makefile
$ git read-tree --index-output=rubbish -m master next
error: Entry 'Makefile' not uptodate. Cannot merge.
$ git reset --hard master
$ echo >>Makefile
$ git add Makefile
$ git read-tree --index-output=rubbish -m master next
error: Entry 'Makefile' would be overwritten by merge. Cannot merge.
Having said that, please do not discard your patch. After sleeping on
this, I started to think that "checkout -n" might be a better interface
than using the plumbing read-tree in the longer term, especially if you
can enhance it to handle "checkout -m -n" to check if the local change can
be merged without conflicts.
But if the only question you are interested in is "can I switch to that
branch from the current state of the index and the working tree?", I would
prefer to see if the script can use "read-tree -m" approach first.
We may also want to add "read-tree -n" so that you do not have to specify
a dummy index output only to prevent from writing the real index over,
though.
--
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