All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Migdol <michael-spam@migdol.net>, git@vger.kernel.org
Subject: Re: stash-p broken?
Date: Tue, 29 Jul 2014 13:43:57 -0400	[thread overview]
Message-ID: <20140729174357.GA20042@peff.net> (raw)
In-Reply-To: <xmqq61ig3xsp.fsf@gitster.dls.corp.google.com>

On Tue, Jul 29, 2014 at 10:00:22AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > So perhaps we could do something better on the viewing side, and
> > "simplify" combined merges for files with all-identical parents.
> 
> Or you can ask to show the difference with the first parent, no?

Yeah, though there is no way to do the other thing (--second-parent to
show only the index side). I doubt anybody wants that, though. Just
passing --first-parent would probably be fine (that would match "git
stash show", too, though like that "stash show" it is impossible to
override to see the index portion then).

But...

> I do not think giving a single-parent diff when --cc/-c is asked
> for, which is a clear indication that the caller is aware that the
> commit in question is a merge, is such a good idea.

I think that is my point, though. The user is _not_ aware that the
commit in question is a merge. They stashed some stuff, and now they
want to see the result. I'd like to show them a vanilla commit if the
index is irrelevant, and otherwise show them something more interesting.

I definitely don't think that should be the default behavior, but I
don't see a problem with it being part of stash. We pick apart the stash
already in git-stash.sh, so for "git stash show" we can do it ourselves.
But during a traversal, we need support from "git log", since the answer
is different for each stash (and even for each path).

-Peff

  reply	other threads:[~2014-07-29 17:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29  0:38 stash-p broken? Michael Migdol
2014-07-29  0:56 ` Michael Migdol
2014-07-29  2:59   ` brian m. carlson
2014-07-29  6:45     ` Øystein Walle
2014-07-29  9:23     ` Jeff King
2014-07-29 17:00       ` Junio C Hamano
2014-07-29 17:43         ` Jeff King [this message]
2014-07-29 18:23           ` Junio C Hamano
2014-07-31  0:23             ` Jeff King
2014-07-31 16:49               ` Junio C Hamano
2014-07-29 19:27           ` Junio C Hamano
2014-07-31  0:16             ` Jeff King

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=20140729174357.GA20042@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=michael-spam@migdol.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.