On Tue, Aug 20, 2013 at 10:18:08AM -0700, Junio C Hamano wrote:
> As you mentioned, merge gives readable merge log messages, but it
> deliberately uses the real URL, not your personal nickname for the
> remote when writing the title line of a merge, i.e.
>
> Merge [branch of ]
>
> so it w
Jeff King writes:
> It _only_ impacts git-shortlog, not git-log or other traversals. Making
> it an even more dubious feature, IMHO.
I think this was done by an explicit end user request for shortlog.
As you mentioned, merge gives readable merge log messages, but it
deliberately uses the real U
On Tue, Aug 20, 2013 at 04:38:17PM +0200, Stefan Beller wrote:
> As proposed I checked recent kernel history and saw:
>
> $ git log --min-parents=2 --oneline
> d6a5e06 Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes
> 7067552 Merge branch 'x86-urgent-for-linus' of
>
On 08/20/2013 04:23 PM, Thomas Rast wrote:
> Stefan Beller writes:
>
>> As I am resending the patch, could somebody please explain me
>> the mechanism of the "# repo-abbrev:" line? Even git itself doesn't
>> use it in the .mailmap file, but a quick google search shows up only
>> kernel repositori
On Tue, Aug 20, 2013 at 04:17:07PM +0200, Stefan Beller wrote:
> Stepping two steps back, I am trying to figure out, what this repo_abrev
> thing is doing, as I could find no documentation.
It's meant to abbreviate long pathnames in subject lines. As you noted,
the kernel .mailmap has:
# repo-
Stefan Beller writes:
> As I am resending the patch, could somebody please explain me
> the mechanism of the "# repo-abbrev:" line? Even git itself doesn't
> use it in the .mailmap file, but a quick google search shows up only
> kernel repositories.
I had no idea (we really lack documentation on
On 08/20/2013 03:40 PM, Thomas Rast wrote:
> Stefan Beller writes:
>
>> The condition as it is written in that line was most likely intended to
>> check for the pointer passed to free(), rather than checking for the
>> 'repo_abbrev', which is already checked against being non null at the
>> begin
On Tue, Aug 20, 2013 at 03:40:02PM +0200, Thomas Rast wrote:
> Stefan Beller writes:
>
> > The condition as it is written in that line was most likely intended to
> > check for the pointer passed to free(), rather than checking for the
> > 'repo_abbrev', which is already checked against being no
Stefan Beller writes:
> The condition as it is written in that line was most likely intended to
> check for the pointer passed to free(), rather than checking for the
> 'repo_abbrev', which is already checked against being non null at the
> beginning of the function.
[...]
> -
9 matches
Mail list logo
