Re: trouble with debugging binary

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Sun, Nov 23, 2014 at 7:42 PM, Ray Andrews <rayandrews@xxxxxxxxxxx> wrote:
> On 11/23/2014 10:12 AM, Mikael Magnusson wrote:
>>
>>
>> If you think "git pull" downloads patches and applies them locally,
>> you are completely mistaken :).
>
>
> I'm thinking that git does everything with 'patches', although
> they might not be called that. Nevermind tho, I'm reading the
> doc, and will understand it all in time. Anyway, what I meant
> was that if I patch something here by hand, and then 'pull' ,
> *and* that same patch has been applied upstream,
> will git recognize the local patch as kosher, or will it complain that
> the file has been locally changed.
>
> Trying it, I see that git does *not* see the patch as kosher and
> demands that I 'stash' it. git is very fussy, just as it should be.

Ah, that makes sense :). Yes, if you have anything *uncommitted*, git
will never touch it unless you specify an option that sounds like
--force or --hard or so. Note though that pull will create merge
commits for you if you have committed stuff locally, which will make
you end up with a fork of zsh.

What you may want to do if you have a few local patches is to use git
pull --rebase and it'll move your commits on top of upstream each time
(by generating patches, updating the tree, and then applying them
again). I would recommend doing this rather than carrying uncommitted
changes around in a stash forever. You can set the pull.rebase git
option in your zsh repo to true to make it the default too.

What I usually do is just 'git fetch', inspect the history with 'git
log ..@{u}' (or paste the range output from fetch), and if there's
anything I care about, I manually run 'git rebase'.

>> I'm actually a bit confused about what you consider the 'normal' diff
>> format, almost nobody uses anything other than the unified format.
>
> ... just 'diff' with no switches.  Now that I try 'diff -u' I see what you
> mean--that's what I normally see, I just didn't know how to produce
> that format, now I do. It sure is easier to read.

It's also a bit safer in that the extra context lets 'patch' detect in
more cases whether the patch has already been applied, and prevents
you from applying it twice (eg, if it only contains additions, the <>
format will happily add them in at the specified line number forever).

-- 
Mikael Magnusson