Re: [PATCH] Force new line at end of commit message

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

 



"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:

> I'd like to hear Junio's or Linus' two cents on the matter, but
> if we really want to say that all commits must end with an LF then
> maybe git-commit-tree, git-hash-object and git-fast-import should be
> performing that sort of validation before creating such an object in
> the ODB.

I've so far tried to keep the lowest-level plumbing commit-tree
(and even lower hash-object) without such an artificial limit.
At the lowest level, commit objects should be able to hold any
byte sequence (this includes NUL bytes) as the user wishes.
People who want to use git to implement/experiment a data
structure that may not have anything to do with the usual SCM
should be able to do so using such low-level.

It is a different story about what conventions should Porcelains
enforce.  For example, I'd be perfectly happy if git-commit (at
least under its default mode of operation) does not allow NULs
nor incomplete lines in the message, and if git-format-patch and
git-am do not to pass something you cannot e-mail sanely (but
that is only true once we rewrite rebase not to rely on the
pipeline between them).  Porcelain level should really make it
easy and safe for the users to work with git as an SCM.

-
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]

  Powered by Linux