Re: [PATCH] Teach checkout the -n|--dry-run option

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 07.05.2011 21:24, schrieb Junio C Hamano:
> Junio C Hamano <gitster@pobox.com> 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.

Thanks for pointing me to "git read-tree -m". When I saw that a "git
checkout -n" would do exactly what I needed, I stopped looking for
alternatives (especially as I saw that adding -n there would help
other non-submodule use cases as well).

> 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.

I'll see if I can come up with a solution for the "-m -n" case (I stopped
after implementing the checkout branch case I needed to get some feedback
if this thing went into the right direction). And I assume the "git
checkout <pathspec>" case should learn -n too?

> 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.

Yup, I will try that.

> 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.

Hmm, wouldn't using "read-tree --index-output=/dev/null" be equivalent to
"read-tree -n"? But nonetheless it might make sense to add the -n option.