From: ori@eigenstate.org
To: 9front@9front.org
Subject: Re: [9front] [PATCH] patch: fix consecutive deletions
Date: Fri, 07 Oct 2022 14:09:44 -0400 [thread overview]
Message-ID: <0F5FA97017BDFEF80BBBAE2985BBA4EB@eigenstate.org> (raw)
In-Reply-To: <08EFF1FAF1422A02191E5789046BEA99@mforney.org>
Quoth Michael Forney <mforney@mforney.org>:
>
> Consecutive delete hunks will both have newpath of /dev/null, but we
> need to slurp oldpath between these hunks.
> ---
> Proposed fix for the issue I reported on the mailing list a few days
> ago. This retains the current patch file selection behavior, though I
> still think we should adopt the standard behavior for compatibility
> with external patches and tools.
Looks good to me.
Changing our current behavior should be painless -- nothing currently
should depend on it; git/patch is the heaviest user, and it hasn't been
around long enough for a long tail of external scripts to care.
> diff 8f1867a19f7ca881a32878dcee08ddce11b5db36 185bd356498369a987e364293f3942e047b99f48
> --- a/sys/src/cmd/patch.c
> +++ b/sys/src/cmd/patch.c
> @@ -556,9 +556,9 @@
> int
> apply(Patch *p, char *fname)
> {
> - char *o, *s, *e, *curfile;
> + char *o, *s, *e, *curfile, *nextfile;
> int i, osz;
> - Hunk *h;
> + Hunk *h, *prevh;
> Fbuf f;
>
> e = nil;
> @@ -565,14 +565,26 @@
> o = nil;
> osz = 0;
> curfile = nil;
> + h = nil;
> + prevh = nil;
> for(i = 0; i < p->nhunk; i++){
> h = &p->hunk[i];
> - if(curfile == nil || strcmp(curfile, h->newpath) != 0){
> + if(strcmp(h->newpath, "/dev/null") == 0)
> + nextfile = h->oldpath;
> + else
> + nextfile = h->newpath;
> + if(curfile == nil || strcmp(curfile, nextfile) != 0){
> + if(curfile != nil){
> + if(!dryrun)
> + o = append(o, &osz, e, f.buf + f.len);
> + blat(prevh->oldpath, prevh->newpath, o, osz);
> + osz = 0;
> + }
> if(!dryrun){
> slurp(&f, h->oldpath);
> e = f.buf;
> }
> - curfile = h->newpath;
> + curfile = nextfile;
> }
> if(!dryrun){
> s = e;
> @@ -581,12 +593,12 @@
> o = append(o, &osz, h->new, h->new + h->newlen);
> e += h->oldlen;
> }
> - if(i+1 == p->nhunk || strcmp(curfile, p->hunk[i+1].newpath) != 0){
> - if(!dryrun)
> - o = append(o, &osz, e, f.buf + f.len);
> - blat(h->oldpath, h->newpath, o, osz);
> - osz = 0;
> - }
> + prevh = h;
> + }
> + if(curfile != nil){
> + if(!dryrun)
> + o = append(o, &osz, e, f.buf + f.len);
> + blat(h->oldpath, h->newpath, o, osz);
> }
> free(o);
> return 0;
prev parent reply other threads:[~2022-10-07 18:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-03 19:32 Michael Forney
2022-10-07 18:09 ` ori [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=0F5FA97017BDFEF80BBBAE2985BBA4EB@eigenstate.org \
--to=ori@eigenstate.org \
--cc=9front@9front.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).