Re: [RFH] An early draft of v1.5.0 release notes

Jakub Narebski <jnareb@gmail.com> wrote:

[...]

Count me in! A freshly created repo should be just empty, not some strange construction that isn't a real repo. The empty set /is/ real useful, you know. Even if it is just for symmetry.

That isn't your call to make. Sure, if I just untarred something large and gitified it, I /know/ the diff to "before" is huge, and not really informative, and I'll abstain from asking for it. But if I just started a project with a half dozen files, I'd like to see what came before, or look at the difference to "5 commits back" (which just happens to be every change, as there are 4 commits in all).

The main focus here is on large(ish) projects with a lot of history, but if you want to be able to get some mindshare you will have to look at the other end, projects just getting off the ground.

Jakub Narebski <jnareb@gmail.com> wrote:

I don't want to come through as rude, but that you can find the explanation somewhere (and as an old(ish) Unix/git hand you know (or should be able to guess easily) what it means) doesn't help the _newbie_ confronted with this gibberish one iota. Explaining it it the git list also doesn't help. Either make it self-explanatory, relegate this command to git-plumbing or axe its output (perhaps show this only with --verbose or such, with Unix you get fast to the point where you know --verbose is probably totally mistifying except for /real/ experts :-).

[...]

That is a more newbie-friendly answer.

Horst H. von Brand wrote:

I think it would help if we could write out things ls-style though and I'm all for axing the SHA1 (I don't even think the SHA1 of specific files of a tree can be *used* for anything), so the above would be

-rw-r--r-- Makefile

which most newbies should grok fairly quickly. Not least because it's familiar, and we can even toss in the size in that string without taking up too much screen real estate. If we try really hard to cater to people who have never seen ls output we're gonna end up annoying the other side of the camp so much that they'll walk away in disgust.

Andreas Ericsson <ae@op5.se> writes:

'ls-tree' is a plumbing and existing scripts (not limited to what are in git.git) use it to extract object names from arbitrary trees. It's output format will NOT change.

The honest position to take on "svn list" question is "we do not have a counterpart for that command".

Now, I happen to think "getting list of all paths in one particular revision" is not a very useful operation from the end user's point of view. One possible use is to get such a list from multiple revisions and compare them with "comm -3", but that is obviously useless in the context of git. You can do that with "diff --name-status --diff-filter=AD" without doing ls-tree yourself.

But if "ls $commit" is still interesting at end-user level, probably we would need a Porcelain to let users do so.

Johannes recently made

	$ git show $commit^{tree}

to do the name-only variant.

If people actually do "ls-tree --name-only" (or ls-tree --like-ls-l) often, we might want to be even easier:

	$ git show --ls $commit

or even:

	$ git ls $commit

or even:

	[alias] ls = ls-tree --name-only

Jakub Narebski <jnareb@gmail.com> wrote:

[...]

And what happens to the people who can't/won't display UTF-8? This is a both a project wide configuration (how does stuff get saved) + a user/local configuration (how to display stuff).

"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:

Presumably you would do something like:

	git log | tcs -f utf -t latin1 | less

The point being that the input to tcs will be uniformly UTF-8 even the committers used Latin-1 and UTF-8, either carelessly or deliberately [*1*].

Maybe i18n.displayencoding set to latin1 is what you are after? I think it might make sense...

In any case, as Jakub and others pointed out, the description was not nice nor clear. How about this as an update?

* I18n

 - We have always encouraged the commit message to be encoded in
   UTF-8, but the users are allowed to use legacy encoding as
   appropriate for their projects.  This will continue to be the
   case.  However, a non UTF-8 commit encoding _must_ be
   explicitly set with i18n.commitencoding in the repository
   where a commit is made; otherwise git-commit-tree will
   complain if the log message does not look like a valid UTF-8
   string.

[Side note: in v1.5.0 preview, it only warns about this
 situation; I have a feeling that it might be better to promote
 this to an error and refuse to commit until the user sets
 i18n.commitencoding to the name of the legacy encoding used for
 the project -- this will be a one-time inconvenience but will
 be much better in the long run.]

 - The value of i18n.commitencoding in the originating
   repository is recorded in the commit object on the "encoding"
   header, if it is not UTF-8.  git-log and friends notice this,
   and reencodes the message to the encoding specified with
   i18n.commitencoding when displaying, if they are different.

[Footnote]

*1* For encoding as simple as Latin I do not think it is an issue, but we do not want to encode everything to UTF-8 at commit time, because non-reversible conversion can lose information. I do not want to rule out a situation where a particular commit log entry needs to be in an encoding different from the project norm, which hopefully is UTF-8, because it needs to describe something in a character that cannot be reversibly converted to UTF-8 (maybe the project is about iconv enhancement, the commit fixes something related to irreversible conversion and the log message wants to give an example).

Junio C Hamano <junkio@cox.net> writes:

I've done this and will be pushing the result out in 'next' shortly, with a new test. I find the result mostly sensible.

On Wed, 27 Dec 2006, Junio C Hamano wrote:

Shouldn't the LANG environment variable be used for this purpose instead?

Nicolas

Nicolas Pitre <nico@cam.org> writes:

You mean LC_CTYPE, no?

Jakub Narebski <jnareb@gmail.com> wrote:

I know. But it doesn't "ensure" anything, the /user/ has to ensure beforehand that there are no outstanding changes for it to succeed. Fine distinction, I know. But better be extra clear.