Re: rev-list pretty format behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Oliver Runge <oliver.runge@xxxxxxxxx> writes:

> I'm using git version 2.4.0-rc1. The same behavior exists in 2.1.0.
>
> Trying the same with rev-list results in:
>> git rev-list --pretty=format:"%h ..." HEAD~3...HEAD
> commit 826aed50cbb072d8f159e4c8ba0f9bd3df21a234
> 826aed5 ...
> commit 915e44c6357f3bd9d5fa498a201872c4367302d3
> 915e44c ...
> commit 067178ed8a7822e6bc88ad606b707fc33658e6fc
> 067178e ...

This is very much the designed behaviour, I would think.  IIRC, the
user-format support of "rev-list" was designed so that the scripts
can customize the output from "rev-list -v", which was how scripts
were expected to read various pieces of information for each commit
originally.  And the 40-hex commit object name and/or a line that
begins with "commit ..." when a user format is used are meant to
serve as stable record separator (in that sense, having %H or %h in
the userformat given to rev-list is redundant) when these scripts
are reading output from "rev-list".

A new option to tell "rev-list" that "I am designing an output that
is a-line-per-commit with the userformat and do not need the default
record separator" or "I will arrange record separator myself" would
be an acceptable thing to add, provided if many scripts yet to be
written would benefit from such a feature, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]