Re: [PATCH v4] libc: Extend __libc_freeres framework (Bug 23329).

[Florian Weimer <fweimer at redhat dot com>]

On 06/28/2018 04:23 PM, Andreas Schwab wrote:
> On Jun 28 2018, Carlos O'Donell <carlos@redhat.com> wrote:
>
> > On 06/28/2018 09:44 AM, Florian Weimer wrote:
> > > On 06/28/2018 03:35 PM, Carlos O'Donell wrote:
> > > > This is the only commit I have on top of master.
> > > >
> > > > Where are the conflicts?
> > >
> > > git am cannot construct a common ancestor because it doesn't have a copy of the original file:
> > >
> > > diff --git a/ChangeLog b/ChangeLog
> > > index 1f35f29d77..5f34833c2c 100644
> > >
> > > Locally, I do not have a blob starting with 1f35f29d77, with master at commit 0b11b6491cc01b5ce5fea1302f8591f25e8c4d80.
> >
> > I don't have it either, but git format-patch HEAD~2 still generates it.
>
> It's a blob, not a commit.  Try git show 1f35f29d77.

I used git cat-file blob.  I'm surprised that git show handles blob 
hashes because doing so increases the chances of collisions

I didn't have it locally at first, but then I fetched, and grepped 
whatchanged output, but rooted that not in the fetched master branch 
(master instead of origin/master).

So I guess a git am-based workflow would have to always git fetch first.

*However*, Carlos' messages are not actually git am-ready.  The commit 
message that git am produces is totally bogus and does not match what's 
intended to be committed at all.  We should probably continue that 
discussion on the other thread, though.

Thanks,
Florian