threads / discuss / 62689

git-log --format missing trailing newline character

Subject: git-log --format missing trailing newline character

## tl;dr

7 messages between Dec 23, 2024 and Dec 26, 2024.

replies: 6people: 4as markdown or json

Alejandro Colomar· Dec 23, 2024, 20:28 UTC · lore
Hi!

I'm having trouble scripting around git-log(1), due to a missing newline character at the end of the file.

	$ git -v
	git version 2.45.2
	$ git log --format=format:'%H' HEAD^^^..HEAD | wc -l
	2
	$ git log --format=format:'%H' HEAD^^^..HEAD
	2ff431ab1b46a25088fe40baf1faf35ea9fac722
	e75e6c4504022ae52d877926e63c908d9572088a
	178442837d39560a789a8044a8eb90fde3ad7cd7

Would you mind fixing this bug? POSIX requires that text files end in a newline character, precisely for being able to use UNIX tools to process output from arbitrary commands.

Have a lovely night! Alex

-- 
<https://www.alejandro-colomar.es/>
Kristoffer Haugsbakk· Dec 23, 2024, 20:36 UTC · re: Alejandro Colomar · lore

Re: git-log --format missing trailing newline character

On Mon, Dec 23, 2024, at 21:28, Alejandro Colomar wrote:
Show 17 quoted lines
> Hi!
>
> I'm having trouble scripting around git-log(1), due to a missing newline
> character at the end of the file.
>
> 	$ git -v
> 	git version 2.45.2
> 	$ git log --format=format:'%H' HEAD^^^..HEAD | wc -l
> 	2
> 	$ git log --format=format:'%H' HEAD^^^..HEAD
> 	2ff431ab1b46a25088fe40baf1faf35ea9fac722
> 	e75e6c4504022ae52d877926e63c908d9572088a
> 	178442837d39560a789a8044a8eb90fde3ad7cd7
>
> Would you mind fixing this bug?  POSIX requires that text files end in a
> newline character, precisely for being able to use UNIX tools to process
> output from arbitrary commands.

Is the format here simplified relative to your use case? Or do you just want to process commits as one-hash-per-line? I would use git-rev-list(1) instead in that case.

-- 
Kristoffer Haugsbakk
Alejandro Colomar· Dec 23, 2024, 20:49 UTC · re: Kristoffer Haugsbakk · lore

Re: git-log --format missing trailing newline character

Hi Kristoffer,
On Mon, Dec 23, 2024 at 09:36:48PM GMT, Kristoffer Haugsbakk wrote:
Show 21 quoted lines
> On Mon, Dec 23, 2024, at 21:28, Alejandro Colomar wrote:
> > Hi!
> >
> > I'm having trouble scripting around git-log(1), due to a missing newline
> > character at the end of the file.
> >
> > 	$ git -v
> > 	git version 2.45.2
> > 	$ git log --format=format:'%H' HEAD^^^..HEAD | wc -l
> > 	2
> > 	$ git log --format=format:'%H' HEAD^^^..HEAD
> > 	2ff431ab1b46a25088fe40baf1faf35ea9fac722
> > 	e75e6c4504022ae52d877926e63c908d9572088a
> > 	178442837d39560a789a8044a8eb90fde3ad7cd7
> >
> > Would you mind fixing this bug?  POSIX requires that text files end in a
> > newline character, precisely for being able to use UNIX tools to process
> > output from arbitrary commands.
> 
> Is the format here simplified relative to your use case?  Or do you just
> want to process commits as one-hash-per-line?
I want to process commits as one-hash-per-line, yes.
The entire pipeline I have is this:
	git rev-list "$old..HEAD" \
	| sed 's,.*,https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib\&id=&,';

which I run in <hooks/post-update> in my server for printing URIs to all of the newly pushed commits. I use that for easily pasting them to the confirmation email I write to contributors when I apply and push one of their patches.

>  I would use
> git-rev-list(1) instead in that case.

Hmmm, thanks! I knew there had to be some git-rev-something for this, but couldn't find it! :)

I had workarounded it by doing
	git log --oneline --abbrev=40 | cut -f1 -d' '
However, git-rev-list(1) is better, of course, so I'll use it.

Anyway, it feels awkward that git-log(1) skips the last newline whith --format=format. Should that be fixed?

Have a lovely night! Alex

> 
> -- 
> Kristoffer Haugsbakk
> 
-- 
<https://www.alejandro-colomar.es/>
Andreas Schwab· Dec 23, 2024, 21:09 UTC · re: Alejandro Colomar · lore

Re: git-log --format missing trailing newline character

On Dez 23 2024, Alejandro Colomar wrote:
> Anyway, it feels awkward that git-log(1) skips the last newline whith
> --format=format.  Should that be fixed?
If you want terminator semantics, use tformat: instead of format:.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Alejandro Colomar· Dec 23, 2024, 21:23 UTC · re: Andreas Schwab · lore

Re: git-log --format missing trailing newline character

Hi Andreas,
On Mon, Dec 23, 2024 at 10:09:14PM GMT, Andreas Schwab wrote:
Show 6 quoted lines
> On Dez 23 2024, Alejandro Colomar wrote:
> 
> > Anyway, it feels awkward that git-log(1) skips the last newline whith
> > --format=format.  Should that be fixed?
> 
> If you want terminator semantics, use tformat: instead of format:.
Thanks!

Have a lovely night! Alex

-- 
<https://www.alejandro-colomar.es/>
Junio C Hamano· Dec 26, 2024, 16:00 UTC · re: Alejandro Colomar · lore

Re: git-log --format missing trailing newline character

Alejandro Colomar <alx@kernel.org> writes:
Show 9 quoted lines
> Hi Andreas,
>
> On Mon, Dec 23, 2024 at 10:09:14PM GMT, Andreas Schwab wrote:
>> On Dez 23 2024, Alejandro Colomar wrote:
>> 
>> > Anyway, it feels awkward that git-log(1) skips the last newline whith
>> > --format=format.  Should that be fixed?
>> 
>> If you want terminator semantics, use tformat: instead of format:.

Or, "--format=%H" should do the right thing, as that is a mere short-hand for "--pretty=tformat:%H".

Alejandro Colomar· Dec 26, 2024, 17:06 UTC · re: Junio C Hamano · lore

Re: git-log --format missing trailing newline character

Hi Junio,
On Thu, Dec 26, 2024 at 08:00:42AM -0800, Junio C Hamano wrote:
Show 14 quoted lines
> Alejandro Colomar <alx@kernel.org> writes:
> 
> > Hi Andreas,
> >
> > On Mon, Dec 23, 2024 at 10:09:14PM GMT, Andreas Schwab wrote:
> >> On Dez 23 2024, Alejandro Colomar wrote:
> >> 
> >> > Anyway, it feels awkward that git-log(1) skips the last newline whith
> >> > --format=format.  Should that be fixed?
> >> 
> >> If you want terminator semantics, use tformat: instead of format:.
> 
> Or, "--format=%H" should do the right thing, as that is a mere
> short-hand for "--pretty=tformat:%H".

Hmmm. So many times having read that part of the manual, and I had never noticed that. I had never seen that tformat existed, and even less that the default was it (when there's %placeholder string). I had always read 'format' instead of 'tformat'. :)

Thanks!
-- 
<https://www.alejandro-colomar.es/>

← back to recent threads