git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: git diff woes
Date: Mon, 12 Nov 2007 12:19:08 +0100	[thread overview]
Message-ID: <473836AC.6090802@op5.se> (raw)
In-Reply-To: <Pine.LNX.4.64.0711121047590.4362@racer.site>

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 12 Nov 2007, Andreas Ericsson wrote:
> 
>> Johannes Schindelin wrote:
>>
>>>  And sure you can trust the hunk header.  Like most of the things, the 
>>> relate to the _original_ version, since the diff is meant to be 
>>> applied as a forward patch.
>>>
>>> So for all practical matters, the diff shows the correct thing: "in 
>>> this hunk, which (still) belongs to that function, change this and 
>>> this."
>>>
>>> Of course, that is only the case if you accept that the diff should be 
>>> applied _in total_, not piecewise.  IOW if you are a fan of GNU patch 
>>> which happily clobbers your file until it fails with the last hunk, 
>>> you will not be happy.
>>>
>> You're right. GNU patch will apply one hunk and then happily churn on 
>> even if it fails. git-apply will apply all hunks or none, so all hunks 
>> can assume that all previous hunks were successfully applied. So what 
>> was your point again?
> 
> My point was that this diff is not to be read as if the previous hunks had 
> been applied.  Just look at the context: it is also the original file.
> 

The context is ambiguous, as it must be present in both the new and the
old file for it to actually *be* context. Otherwise it would be part of
the +- diff text.

> It seems I am singularly unable to explain plain concepts as this: a diff 
> assumes that the file is yet unchanged.
> 

Sure, but the useraid with writing the apparent function declaration in
the hunk header *will* be confusing if the function declaration changes
in the same patch as other things in the function.

> So I'll stop.
> 

Give me something valuable instead, such as your opinion on whether it
would be better to not print the function declaration at all if it will
be changed by applying the same patch, or if one should pick one of the
declarations from old or new and, if so, which one to pick.

I simply refuse to believe that you wouldn't immediately think the hunk
below holds an obvious bug. I thought so because of the helpful function
context git diff prints (which is a helper for human reviewers, and not
something git-apply or GNU patch needs to work), and now I want to do
something about it so others won't have to suffer the same confusion.

@@ -583,75 +346,100 @@ double jitter_request(const char *host, int *status){
       if(verbose) printf("%d candiate peers available\n", num_candidates);
       if(verbose && syncsource_found) printf("synchronization source found\n")
       if(! syncsource_found){
-               *status = STATE_UNKNOWN;
+               status = STATE_WARNING;
               if(verbose) printf("warning: no synchronization source found\n")
       }

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

  reply	other threads:[~2007-11-12 11:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-12  9:44 git diff woes Andreas Ericsson
2007-11-12 10:01 ` Johannes Schindelin
2007-11-12 10:35   ` Andreas Ericsson
2007-11-12 10:50     ` Johannes Schindelin
2007-11-12 11:19       ` Andreas Ericsson [this message]
2007-11-12 21:30     ` Junio C Hamano
2007-11-13  0:03       ` Andreas Ericsson
2007-11-13  0:59         ` Johannes Schindelin
2007-11-13  2:53         ` Miles Bader
2007-11-13  7:40           ` Andreas Ericsson
2007-11-13  9:15             ` [PATCH] diffcore: Allow users to decide what funcname to use Andreas Ericsson
2007-11-13 10:03               ` Jakub Narebski
2007-11-13 10:07                 ` Andreas Ericsson

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=473836AC.6090802@op5.se \
    --to=ae@op5.se \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.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).