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

Am 07.05.2011 21:24, schrieb Junio C Hamano:

Junio C Hamano [off-list ref] writes:

quoted

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.

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.