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

Junio C Hamano [off-list ref] 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

quoted

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