git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Caleb Cushing <xenoterracide@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
	Daniel Barkalow <barkalow@iabervon.org>
Subject: Re: mergetool feature request - select remote or local
Date: Wed, 14 May 2008 21:25:33 -0400	[thread overview]
Message-ID: <200805142125.40027.xenoterracide@gmail.com> (raw)
In-Reply-To: <7vzlqsok0y.fsf@gitster.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

On Wednesday 14 May 2008 01:47:09 pm you wrote:
> I never understood why people are using git and not ftp when they say the
> other side is always right, but I see this comes up every once in a while,
> so it would probably be a good thing to support.

well in my case I'm not particularly sure why fast forward didn't just merge 
them. Seems like I had resolved these changes in master previously. this 
problem is most annoying when I am resolving the same issues across multiple 
branches.

> The above "(l)local" and "(m)anual" look inconsistent, and the wording
> should be more like "local, remote or merge".

local,remote, merge is fine and I used the (m) for example because of how it 
asked me to handle a file existing locally (with mods?) but had been deleted 
in MERGE_HEAD?

> > also in the event of having 20 files with this issue it would be nice to
> > have an option after first starting mergetool for remote all or local
> > all.
>
> This makes me wonder if you are better off not using mergetool in such a
> situation.  Instead, perhaps
>
>         $ git ls-files -u --no-stage | xargs git checkout MERGE_HEAD

perhaps... I'm not this familiar with git yet.

> might be a better option?  The attached is a completely untested
> weather-baloon patch.
>
> If this turns out to be a better approach, perhaps we would further want
> to tweak things to make:
>
>         $ git checkout --unmerged MERGE_HEAD [--] [<pathspec>...]
>
> to work (if you want "local", you would use "HEAD" instead of
> "MERGE_HEAD").

> Looks easy enough.  Caleb, does this approach fit the situation you
> described better?

um.. is that just a resolution for an merge all (local or remote).

I'm gonna be honest when I say I'm an amateur developer (although I've 
considered myself a pretty good admin for a few years) and relatively new to 
git. So I'm getting a bit lost, but it sounds reasonable. It wouldn't affect 
any files that had been successfully fast forwarded right?

unfortunately I'm not sure how easy testing will be, as this problem doesn't 
arise with every merge, but has arisen often enough to be a pita.
-- 
Caleb Cushing

my blog http://xenoterracide.blogspot.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

      parent reply	other threads:[~2008-05-15  1:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14 11:21 mergetool feature request - select remote or local Caleb Cushing
2008-05-14 17:47 ` Junio C Hamano
2008-05-14 18:40   ` Daniel Barkalow
2008-05-14 19:19     ` Junio C Hamano
2008-05-15  1:25   ` Caleb Cushing [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200805142125.40027.xenoterracide@gmail.com \
    --to=xenoterracide@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).