git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, Yann Dirson <ydirson@altern.org>,
	Petr Baudis <pasky@suse.cz>
Subject: Re: [PATCH] gitweb: Fix and simplify "split patch" detection
Date: Sun, 02 Sep 2007 17:15:44 -0700	[thread overview]
Message-ID: <7vmyw4ob7z.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <200709022218.43042.jnareb@gmail.com> (Jakub Narebski's message of "Sun, 2 Sep 2007 22:18:42 +0200")

Jakub Narebski <jnareb@gmail.com> writes:

> Alternate solution, which we did chose, is to check when git splits
> patches, and do not check if parsed info from current patch corresponds
> to current or next raw diff format output line.  Git splits patches
> only for 'T' (typechange) status filepair, and there always two patches
> corresponding to one raw diff line.

Not that I can think of a better way offhand than what you
already mentioned, but I have to say that I am not entirely
happy with this implementation.  A really old git showed two
patches (one creation and one deletion) for "complete rewrite",
which was corrected long time ago.  I do not think we will
change the typechange output in a similar way in the future, but
relying on that level of detail feels somewhat ugly.

As you are reading from --patch-with-raw, you already know the
order of patches that will be given to you when you finished
reading the "raw" part.  The patches will come in the same
order.  So it might be possible to keep track of patches to what
path you are expecting and decide if it is part of what you are
processing at the point you process "diff --git" line.

  reply	other threads:[~2007-09-03  0:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-02 20:18 [PATCH] gitweb: Fix and simplify "split patch" detection Jakub Narebski
2007-09-03  0:15 ` Junio C Hamano [this message]
2007-09-03  9:47   ` Jakub Narebski
2007-09-03 11:00     ` Junio C Hamano

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=7vmyw4ob7z.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=pasky@suse.cz \
    --cc=ydirson@altern.org \
    /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).