From: Daniel Barkalow Date: Sun, 24 Feb 2008 06:29:26 GMT Subject: Re: [PATCH] checkout: error out when index is unmerged even with -m Message-ID: 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 > Signed-off-by: Junio C Hamano > --- > > * 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. > 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*