Re: [PATCH] checkout: error out when index is unmerged even with -m
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Feb 24, 2008, 06:29 UTC
- Message-ID
- <alpine.LNX.1.00.0802240121170.19024@iabervon.org>
- In-Reply-To
- <7voda7xmnk.fsf_-_@gitster.siamese.dyndns.org>
On Sat, 23 Feb 2008, Junio C Hamano wrote:
> Even when -m is given to allow fallilng back to 3-way merge > while switching branches, we should refuse if the original index > is unmerged.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Show 5 quoted lines
> Signed-off-by: Junio C Hamano <gitster@pobox.com> > --- > > * I think this bug was inherited from the scripted version. > Fixing it is much easier here.
I'm pretty sure it was. I wasn't clear on all the motivations for checkout -m behavior, so I tried to make it exactly the same.
Show 18 quoted lines
> builtin-checkout.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index 283831e..e028270 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -226,8 +226,8 @@ static int merge_working_tree(struct checkout_opts *opts,
> refresh_cache(REFRESH_QUIET);
>
> if (unmerged_cache()) {
> - ret = opts->merge ? -1 :
> - error("you need to resolve your current index first");
> + error("you need to resolve your current index first");
> + return 1;
> } else {
> topts.update = 1;
> topts.merge = 1;Ditch the "else" now that it's not needed? And, actually, I think you can ditch most of the use of "ret" when there's only one case for getting to needing a real merge.
-Daniel *This .sig left intentionally blank*