git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Junio C Hamano'" <gitster@pobox.com>
Cc: "'git mailing list'" <git@vger.kernel.org>
Subject: RE: [RFE/RFC] format-patch/diff via path
Date: Sat, 20 Jan 2018 02:41:25 -0500	[thread overview]
Message-ID: <018c01d391c2$164eeaf0$42ecc0d0$@nexbridge.com> (raw)
In-Reply-To: <xmqqinbxngra.fsf@gitster.mtv.corp.google.com>

On January 20, 2018 2:15 AM, Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> > I’m still a bit perplexed by some behaviour seen today, and am looking
> > for a clean way to deal with it that the documentation does not make
> > clear. So, I’m asking in a different way. Suppose a graph of
> >
> > A---B---C---D---E
> > \      \               /
> >   \----F—G----/
> >
> 
> An ASCII art that is not drawn for fixed-width font is by definition
> understandable only by the person who drew it X-<.  I am guessing that F is a
> child of both A and B (but I am not sure, as I do not see a reason why it
> should even be a merge to begin with, so my guess is likely to be wrong), and
> E is a merge between D and G.

My bad... outlook... and user. 
> 
> IOW, I am guessing that the below is the equivalent of what you drew for
> those who look at the picture in fixed-width font:
> 
>     A---B---C---D---E
>      \   \         /
>       .---F-------G

As unintelligible, X-<, but you are probably correct.

> > When trying to perform a format-patch from B to E, I was seeing
> > commits B-A-F-G-E rather than what I wanted B-C-D-E.
> 
> Assuming that E is a merge, format-patch output should not show E anyway
> (i.e. think in terms of "git log --no-merges --reverse", instead of fearing that
> format-patch is somehow more magical---it is not).  So if you want to show
> the comit B, C and D (meaning three patches, i.e. "diff A B", "diff B C", and
> "diff C D"), then you would do "format-patch A..D", not "format-patch A..E".
> If you meant that you are not interested in the change between A and B,
> then the range would be "B..D" instead of "A..D".  Ending the range at "E"
> means you want to see what is reachable from E, and unless you say you are
> not interested in G, you would get G, if you only say you are not interested in
> A (or B), as G is not reachable from A (or B).

While the end point, E was the same regardless of which path, I was interested in submitting the patches along B..E. A is the parent of B and F and was included in the format-patch, which then forward through F and G then E.

> It is unclear how you told format-patch when "trying to perform a format-
> patch from B to E" from your description, but if you said "format-patch
> A^..E", it is likely that you would have seen all commits in the depicted part
> of the graph except for merge commits.

That seems to be the case. I used format-patch B..E with no other args. A was not specified but got drawn in. D-E was a merge so is that why that path wasn't selected? I'd still like to be able to include merges - is that a dream?


      reply	other threads:[~2018-01-20  7:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-20  6:26 [RFE/RFC] format-patch/diff via path Randall S. Becker
2018-01-20  7:14 ` Junio C Hamano
2018-01-20  7:41   ` Randall S. Becker [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='018c01d391c2$164eeaf0$42ecc0d0$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).