# Re: [RFH] An early draft of v1.5.0 release notes 10 messages from 2006-11-21 to 2007-01-04. Participants: Horst H. von Brand, Junio C Hamano, Nicolas Pitre, David Kågedal, Andreas Ericsson. Thread: https://gitlist.dev/t/6125 ## Horst H. von Brand, 2006-11-21 18:14 Subject: Re: git-show --stat on first commit Message-ID: <200611211814.kALIE4EQ009257@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200611211814.kALIE4EQ009257%40laptop13.inf.utfsm.cl In-Reply-To: ``` Jakub Narebski wrote: > Peter Baumann wrote: > > On 2006-11-21, Santi Béjar wrote: > >> On 11/21/06, Andy Parkins wrote: [...] > >> In general the initial commit diff (or stat) is hidden, but perhaps it > >> make sense to show it in "git show", you asked fo this specifically. > > Why not make --root the default? I also stumbled over this behaviour and > > even asked on this list. > > In my opinion this will help new users which are supprised that they > > can't get the diff of the inital commit (which is totaly non-intuitiv > > behavior). > > And one less "wart" to clean, which another thread is all about. :-) 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. > Because for projects imported into git first commit diff is huge, > and not very interesting. 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. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 ``` ## Horst H. von Brand, 2006-12-15 15:19 Subject: Re: svn versus git Message-ID: <200612151519.kBFFJSYn012227@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612151519.kBFFJSYn012227%40laptop13.inf.utfsm.cl In-Reply-To: ``` Jakub Narebski wrote: > Andy Parkins wrote: > > > On Wednesday 2006 December 13 22:56, Shawn Pearce wrote: > > > >> git cat-file -p $REV:$file > >> > >> not sure how much easier it gets than that. Load in the bash > >> completion from contrib/completion and you can even tab complete > >> the $file part. > > > > Yes. I was a little unfair on that one; I forgot about the REV:file syntax. > > However, it's still not simple for a new user; I think I'd say "draw" if > > the "-p" weren't a requirement. > > $ git repo-config alias.less "-p cat-file -p" > $ git repo-config alias.cat "cat-file -p" > > remedies that. > > [...] > >> How is it unfriendly? What specifically would you change to make > >> it more friendly? > > > > $ git-ls-tree v1.0.0 > > 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile > > I'm a newbie: what's that number at the front? What's a blob? What's > > that great big number - I've only seen commit hashes that look like > > that, and that isn't one. Definitely not friendly. > The number in front is octal mode of a file or directory. "blob" > is a file (or symbolic link), "tree" is a directory, all of this > can be found in git(7). 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 :-). [...] > Perhaps we should add git-ls which would be porcelain frontend > to git-ls-files and git-ls-tree, just like git-diff is frontend > to git-diff-files, git-diff-index and git-diff-tree (and also does > pure blob diff). That is a more newbie-friendly answer. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 ``` ## Andreas Ericsson, 2006-12-15 15:41 Subject: Re: svn versus git Message-ID: <4582C233.1000706@op5.se> URL: https://gitlist.dev/e/4582C233.1000706%40op5.se In-Reply-To: <200612151519.kBFFJSYn012227@laptop13.inf.utfsm.cl> ``` Horst H. von Brand wrote: > Jakub Narebski wrote: >> Andy Parkins wrote: >> >>> On Wednesday 2006 December 13 22:56, Shawn Pearce wrote: >>> >>>> git cat-file -p $REV:$file >>>> >>>> not sure how much easier it gets than that. Load in the bash >>>> completion from contrib/completion and you can even tab complete >>>> the $file part. >>> Yes. I was a little unfair on that one; I forgot about the REV:file syntax. >>> However, it's still not simple for a new user; I think I'd say "draw" if >>> the "-p" weren't a requirement. >> $ git repo-config alias.less "-p cat-file -p" >> $ git repo-config alias.cat "cat-file -p" >> >> remedies that. >> >> [...] >>>> How is it unfriendly? What specifically would you change to make >>>> it more friendly? >>> $ git-ls-tree v1.0.0 >>> 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile > >>> I'm a newbie: what's that number at the front? What's a blob? What's >>> that great big number - I've only seen commit hashes that look like >>> that, and that isn't one. Definitely not friendly. > >> The number in front is octal mode of a file or directory. "blob" >> is a file (or symbolic link), "tree" is a directory, all of this >> can be found in git(7). > > 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. 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 andreas.ericsson@op5.se OP5 AB www.op5.se ``` ## Junio C Hamano, 2006-12-15 18:14 Subject: Re: svn versus git Message-ID: <7v3b7hxc05.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3b7hxc05.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <4582C233.1000706@op5.se> ``` Andreas Ericsson writes: >>> The number in front is octal mode of a file or directory. "blob" >>> is a file (or symbolic link), "tree" is a directory, all of this >>> can be found in git(7). >> >> 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. > > 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. '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 ``` ## Horst H. von Brand, 2006-12-27 13:00 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <200612271300.kBRD082j007703@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612271300.kBRD082j007703%40laptop13.inf.utfsm.cl In-Reply-To: ``` Jakub Narebski wrote: [...] > Perhaps that is the idea, but that idea is not described in above > new feature announcement. "... to reencode the message to UTF-8 > when displaying, if needed." would cover it, but perhaps better > would be to cover this in more detail: "reencode message to UTF-8 > if i18n.commitencoding is not set to something other than UTF-8", > or "reencode ... to i18n.commitencoding ... if needed". 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). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Junio C Hamano, 2006-12-27 19:42 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <7vtzzh5dnv.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vtzzh5dnv.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200612271300.kBRD082j007703@laptop13.inf.utfsm.cl> ``` "Horst H. von Brand" writes: > Jakub Narebski wrote: > > [...] > >> Perhaps that is the idea, but that idea is not described in above >> new feature announcement. "... to reencode the message to UTF-8 >> when displaying, if needed." would cover it, but perhaps better >> would be to cover this in more detail: "reencode message to UTF-8 >> if i18n.commitencoding is not set to something other than UTF-8", >> or "reencode ... to i18n.commitencoding ... if needed". > > 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). 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, 2006-12-28 00:49 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <7vbqlo4zg8.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbqlo4zg8.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vtzzh5dnv.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > "Horst H. von Brand" writes: > ... >> 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). > ... > Maybe i18n.displayencoding set to latin1 is what you are after? > I think it might make sense... I've done this and will be pushing the result out in 'next' shortly, with a new test. I find the result mostly sensible. ``` ## Nicolas Pitre, 2006-12-28 01:44 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0612272041421.18171%40xanadu.home In-Reply-To: <7vbqlo4zg8.fsf@assigned-by-dhcp.cox.net> ``` On Wed, 27 Dec 2006, Junio C Hamano wrote: > Junio C Hamano writes: > > > "Horst H. von Brand" writes: > > ... > >> 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). > > ... > > Maybe i18n.displayencoding set to latin1 is what you are after? > > I think it might make sense... > > I've done this and will be pushing the result out in 'next' > shortly, with a new test. I find the result mostly sensible. Shouldn't the LANG environment variable be used for this purpose instead? Nicolas ``` ## David Kågedal, 2006-12-29 11:56 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <87k60alxv3.fsf@morpheus.local> URL: https://gitlist.dev/e/87k60alxv3.fsf%40morpheus.local In-Reply-To: ``` Nicolas Pitre writes: > On Wed, 27 Dec 2006, Junio C Hamano wrote: > >> Junio C Hamano writes: >> >> > "Horst H. von Brand" writes: >> > ... >> >> 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). >> > ... >> > Maybe i18n.displayencoding set to latin1 is what you are after? >> > I think it might make sense... >> >> I've done this and will be pushing the result out in 'next' >> shortly, with a new test. I find the result mostly sensible. > > Shouldn't the LANG environment variable be used for this purpose > instead? You mean LC_CTYPE, no? -- David Kågedal ``` ## Horst H. von Brand, 2007-01-04 00:09 Subject: Re: [PATCH] Documentation/tutorial: misc updates Message-ID: <200701040009.l0409hQV008867@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200701040009.l0409hQV008867%40laptop13.inf.utfsm.cl In-Reply-To: ``` Jakub Narebski wrote: > Horst H. von Brand wrote: > > >> +------------------------------------------------ > >> +$ git branch -d experimental > >> +------------------------------------------------ > >> + > >> +This command ensures that the changes in the experimental branch are > >> +already in the current branch. > >> + > > Huh? This deletes the branch, it doesn't ensure changes have been saved. > It ensures that the branch we want to delete is in lineage of > current branch (otherwise we would have to use -D). 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. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ```