{"thread":{"id":"6125","subject":"Re: [RFH] An early draft of v1.5.0 release notes","startedAt":"2006-11-21T18:14:04Z","lastAt":"2007-01-04T00:09:43Z","messageCount":10,"participants":["Horst H. von Brand","Junio C Hamano","Nicolas Pitre","David Kågedal","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295240","messageId":"200611211814.kALIE4EQ009257@laptop13.inf.utfsm.cl","threadId":"6125","inReplyTo":"jnareb@gmail.com","subject":"Re: git-show --stat on first commit","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-11-21T18:14:04Z","receivedAt":"2006-11-21T18:14:04Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Jakub Narebski wrote:\n> Peter Baumann wrote:\n> > On 2006-11-21, Santi Béjar wrote:\n> >> On 11/21/06, Andy Parkins wrote:\n\n[...]\n\n> >> In general the initial commit diff (or stat) is hidden, but perhaps it\n> >> make sense to show it in \"git show\", you asked fo this specifically.\n\n> > Why not make --root the default? I also stumbled over this behaviour and\n> > even asked on this list.\n\n> > In my opinion this will help new users which are supprised that they\n> > can't get the diff of the inital commit (which is totaly non-intuitiv\n> > behavior).\n\n> > And one less \"wart\" to clean, which another thread is all about. :-)\n\nCount me in! A freshly created repo should be just empty, not some strange\nconstruction that isn't a real repo. The empty set /is/ real useful, you\nknow. Even if it is just for symmetry.\n\n> Because for projects imported into git first commit diff is huge,\n> and not very interesting.\n\nThat isn't your call to make. Sure, if I just untarred something large and\ngitified it, I /know/ the diff to \"before\" is huge, and not really\ninformative, and I'll abstain from asking for it. But if I just started a\nproject with a half dozen files, I'd like to see what came before, or look\nat the difference to \"5 commits back\" (which just happens to be every\nchange, as there are 4 commits in all).\n\nThe main focus here is on large(ish) projects with a lot of history, but if\nyou want to be able to get some mindshare you will have to look at the\nother end, projects just getting off the ground.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"294774","messageId":"200612151519.kBFFJSYn012227@laptop13.inf.utfsm.cl","threadId":"6125","inReplyTo":"jnareb@gmail.com","subject":"Re: svn versus git","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-15T15:19:28Z","receivedAt":"2006-12-15T15:19:28Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Jakub Narebski wrote:\n> Andy Parkins wrote:\n> \n> > On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:\n> > \n> >> git cat-file -p $REV:$file\n> >>\n> >> not sure how much easier it gets than that. Load in the bash\n> >> completion from contrib/completion and you can even tab complete\n> >> the $file part.\n> > \n> > Yes. I was a little unfair on that one; I forgot about the REV:file syntax. \n> > However, it's still not simple for a new user; I think I'd say \"draw\" if \n> > the \"-p\" weren't a requirement.\n> \n> $ git repo-config alias.less \"-p cat-file -p\"\n> $ git repo-config alias.cat \"cat-file -p\"\n> \n> remedies that.\n> \n> [...]\n> >> How is it unfriendly? What specifically would you change to make\n> >> it more friendly?\n> > \n> > $ git-ls-tree v1.0.0\n> > 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile\n\n> > I'm a newbie: what's that number at the front? What's a blob? What's\n> > that great big number - I've only seen commit hashes that look like\n> > that, and that isn't one. Definitely not friendly.\n\n> The number in front is octal mode of a file or directory. \"blob\"\n> is a file (or symbolic link), \"tree\" is a directory, all of this\n> can be found in git(7).\n\nI don't want to come through as rude, but that you can find the explanation\nsomewhere (and as an old(ish) Unix/git hand you know (or should be able to\nguess easily) what it means) doesn't help the _newbie_ confronted with this\ngibberish one iota. Explaining it it the git list also doesn't help. Either\nmake it self-explanatory, relegate this command to git-plumbing or axe its\noutput (perhaps show this only with --verbose or such, with Unix you get\nfast to the point where you know --verbose is probably totally mistifying\nexcept for /real/ experts :-).\n\n[...]\n\n> Perhaps we should add git-ls which would be porcelain frontend\n> to git-ls-files and git-ls-tree, just like git-diff is frontend\n> to git-diff-files, git-diff-index and git-diff-tree (and also does\n> pure blob diff).\n\nThat is a more newbie-friendly answer.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"297932","messageId":"4582C233.1000706@op5.se","threadId":"6125","inReplyTo":"200612151519.kBFFJSYn012227@laptop13.inf.utfsm.cl","subject":"Re: svn versus git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-15T15:41:39Z","receivedAt":"2006-12-15T15:41:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Horst H. von Brand wrote:\n> Jakub Narebski wrote:\n>> Andy Parkins wrote:\n>>\n>>> On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:\n>>>\n>>>> git cat-file -p $REV:$file\n>>>>\n>>>> not sure how much easier it gets than that. Load in the bash\n>>>> completion from contrib/completion and you can even tab complete\n>>>> the $file part.\n>>> Yes. I was a little unfair on that one; I forgot about the REV:file syntax. \n>>> However, it's still not simple for a new user; I think I'd say \"draw\" if \n>>> the \"-p\" weren't a requirement.\n>> $ git repo-config alias.less \"-p cat-file -p\"\n>> $ git repo-config alias.cat \"cat-file -p\"\n>>\n>> remedies that.\n>>\n>> [...]\n>>>> How is it unfriendly? What specifically would you change to make\n>>>> it more friendly?\n>>> $ git-ls-tree v1.0.0\n>>> 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8 Makefile\n> \n>>> I'm a newbie: what's that number at the front? What's a blob? What's\n>>> that great big number - I've only seen commit hashes that look like\n>>> that, and that isn't one. Definitely not friendly.\n> \n>> The number in front is octal mode of a file or directory. \"blob\"\n>> is a file (or symbolic link), \"tree\" is a directory, all of this\n>> can be found in git(7).\n> \n> I don't want to come through as rude, but that you can find the explanation\n> somewhere (and as an old(ish) Unix/git hand you know (or should be able to\n> guess easily) what it means) doesn't help the _newbie_ confronted with this\n> gibberish one iota.\n\n\nI think it would help if we could write out things ls-style though and \nI'm all for axing the SHA1 (I don't even think the SHA1 of specific \nfiles of a tree can be *used* for anything), so the above would be\n\n-rw-r--r-- Makefile\n\nwhich most newbies should grok fairly quickly. Not least because it's \nfamiliar, and we can even toss in the size in that string without taking \nup too much screen real estate. If we try really hard to cater to people \nwho have never seen ls output we're gonna end up annoying the other side \nof the camp so much that they'll walk away in disgust.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"297914","messageId":"7v3b7hxc05.fsf@assigned-by-dhcp.cox.net","threadId":"6125","inReplyTo":"4582C233.1000706@op5.se","subject":"Re: svn versus git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T18:14:18Z","receivedAt":"2006-12-15T18:14:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n>>> The number in front is octal mode of a file or directory. \"blob\"\n>>> is a file (or symbolic link), \"tree\" is a directory, all of this\n>>> can be found in git(7).\n>>\n>> I don't want to come through as rude, but that you can find the explanation\n>> somewhere (and as an old(ish) Unix/git hand you know (or should be able to\n>> guess easily) what it means) doesn't help the _newbie_ confronted with this\n>> gibberish one iota.\n>\n> I think it would help if we could write out things ls-style though and\n> I'm all for axing the SHA1 (I don't even think the SHA1 of specific\n> files of a tree can be *used* for anything), so the above would be\n>\n> -rw-r--r-- Makefile\n>\n> which most newbies should grok fairly quickly.\n\n'ls-tree' is a plumbing and existing scripts (not limited to\nwhat are in git.git) use it to extract object names from\narbitrary trees. It's output format will NOT change.\n\nThe honest position to take on \"svn list\" question is \"we do not\nhave a counterpart for that command\".\n\nNow, I happen to think \"getting list of all paths in one\nparticular revision\" is not a very useful operation from the end\nuser's point of view. One possible use is to get such a list\nfrom multiple revisions and compare them with \"comm -3\", but\nthat is obviously useless in the context of git. You can do\nthat with \"diff --name-status --diff-filter=AD\" without doing\nls-tree yourself.\n\nBut if \"ls $commit\" is still interesting at end-user level,\nprobably we would need a Porcelain to let users do so.\n\nJohannes recently made\n\n\t$ git show $commit^{tree}\n\nto do the name-only variant.\n\nIf people actually do \"ls-tree --name-only\" (or ls-tree\n--like-ls-l) often, we might want to be even easier:\n\n\t$ git show --ls $commit\n\nor even:\n\n\t$ git ls $commit\n\nor even:\n\n\t[alias] ls = ls-tree --name-only\n\n"},{"id":"30350","messageId":"200612271300.kBRD082j007703@laptop13.inf.utfsm.cl","threadId":"6125","inReplyTo":"jnareb@gmail.com","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-27T13:00:08Z","receivedAt":"2006-12-27T13:00:08Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Jakub Narebski wrote:\n\n[...]\n\n> Perhaps that is the idea, but that idea is not described in above\n> new feature announcement. \"... to reencode the message to UTF-8 \n> when displaying, if needed.\" would cover it, but perhaps better\n> would be to cover this in more detail: \"reencode message to UTF-8\n> if i18n.commitencoding is not set to something other than UTF-8\",\n> or \"reencode ... to i18n.commitencoding ... if needed\".\n\nAnd what happens to the people who can't/won't display UTF-8? This is a\nboth a project wide configuration (how does stuff get saved) + a user/local\nconfiguration (how to display stuff).\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"30357","messageId":"7vtzzh5dnv.fsf@assigned-by-dhcp.cox.net","threadId":"6125","inReplyTo":"200612271300.kBRD082j007703@laptop13.inf.utfsm.cl","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-27T19:42:12Z","receivedAt":"2006-12-27T19:42:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n> Jakub Narebski wrote:\n>\n> [...]\n>\n>> Perhaps that is the idea, but that idea is not described in above\n>> new feature announcement. \"... to reencode the message to UTF-8 \n>> when displaying, if needed.\" would cover it, but perhaps better\n>> would be to cover this in more detail: \"reencode message to UTF-8\n>> if i18n.commitencoding is not set to something other than UTF-8\",\n>> or \"reencode ... to i18n.commitencoding ... if needed\".\n>\n> And what happens to the people who can't/won't display UTF-8? This is a\n> both a project wide configuration (how does stuff get saved) + a user/local\n> configuration (how to display stuff).\n\nPresumably you would do something like:\n\n\tgit log | tcs -f utf -t latin1 | less\n\nThe point being that the input to tcs will be uniformly UTF-8\neven the committers used Latin-1 and UTF-8, either carelessly or\ndeliberately [*1*].\n\nMaybe i18n.displayencoding set to latin1 is what you are after?\nI think it might make sense...\n\nIn any case, as Jakub and others pointed out, the description\nwas not nice nor clear. How about this as an update?\n\n* I18n\n\n - We have always encouraged the commit message to be encoded in\n UTF-8, but the users are allowed to use legacy encoding as\n appropriate for their projects. This will continue to be the\n case. However, a non UTF-8 commit encoding _must_ be\n explicitly set with i18n.commitencoding in the repository\n where a commit is made; otherwise git-commit-tree will\n complain if the log message does not look like a valid UTF-8\n string.\n\n[Side note: in v1.5.0 preview, it only warns about this\n situation; I have a feeling that it might be better to promote\n this to an error and refuse to commit until the user sets\n i18n.commitencoding to the name of the legacy encoding used for\n the project -- this will be a one-time inconvenience but will\n be much better in the long run.]\n\n - The value of i18n.commitencoding in the originating\n repository is recorded in the commit object on the \"encoding\"\n header, if it is not UTF-8. git-log and friends notice this,\n and reencodes the message to the encoding specified with\n i18n.commitencoding when displaying, if they are different.\n\n\n[Footnote]\n\n*1* For encoding as simple as Latin I do not think it is an\nissue, but we do not want to encode everything to UTF-8 at\ncommit time, because non-reversible conversion can lose\ninformation. I do not want to rule out a situation where a\nparticular commit log entry needs to be in an encoding different\nfrom the project norm, which hopefully is UTF-8, because it\nneeds to describe something in a character that cannot be\nreversibly converted to UTF-8 (maybe the project is about iconv\nenhancement, the commit fixes something related to irreversible\nconversion and the log message wants to give an example).\n"},{"id":"30377","messageId":"7vbqlo4zg8.fsf@assigned-by-dhcp.cox.net","threadId":"6125","inReplyTo":"7vtzzh5dnv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T00:49:11Z","receivedAt":"2006-12-28T00:49:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> \"Horst H. von Brand\" writes:\n> ...\n>> And what happens to the people who can't/won't display UTF-8? This is a\n>> both a project wide configuration (how does stuff get saved) + a user/local\n>> configuration (how to display stuff).\n> ...\n> Maybe i18n.displayencoding set to latin1 is what you are after?\n> I think it might make sense...\n\nI've done this and will be pushing the result out in 'next'\nshortly, with a new test. I find the result mostly sensible.\n"},{"id":"30386","messageId":"Pine.LNX.4.64.0612272041421.18171@xanadu.home","threadId":"6125","inReplyTo":"7vbqlo4zg8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-28T01:44:19Z","receivedAt":"2006-12-28T01:44:19Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 27 Dec 2006, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > \"Horst H. von Brand\" writes:\n> > ...\n> >> And what happens to the people who can't/won't display UTF-8? This is a\n> >> both a project wide configuration (how does stuff get saved) + a user/local\n> >> configuration (how to display stuff).\n> > ...\n> > Maybe i18n.displayencoding set to latin1 is what you are after?\n> > I think it might make sense...\n> \n> I've done this and will be pushing the result out in 'next'\n> shortly, with a new test. I find the result mostly sensible.\n\nShouldn't the LANG environment variable be used for this purpose \ninstead?\n\n\nNicolas\n"},{"id":"30471","messageId":"87k60alxv3.fsf@morpheus.local","threadId":"6125","inReplyTo":"Pine.LNX.4.64.0612272041421.18171@xanadu.home","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2006-12-29T11:56:00Z","receivedAt":"2006-12-29T11:56:00Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 27 Dec 2006, Junio C Hamano wrote:\n>\n>> Junio C Hamano writes:\n>> \n>> > \"Horst H. von Brand\" writes:\n>> > ...\n>> >> And what happens to the people who can't/won't display UTF-8? This is a\n>> >> both a project wide configuration (how does stuff get saved) + a user/local\n>> >> configuration (how to display stuff).\n>> > ...\n>> > Maybe i18n.displayencoding set to latin1 is what you are after?\n>> > I think it might make sense...\n>> \n>> I've done this and will be pushing the result out in 'next'\n>> shortly, with a new test. I find the result mostly sensible.\n>\n> Shouldn't the LANG environment variable be used for this purpose \n> instead?\n\nYou mean LC_CTYPE, no?\n\n-- \nDavid Kågedal\n"},{"id":"30782","messageId":"200701040009.l0409hQV008867@laptop13.inf.utfsm.cl","threadId":"6125","inReplyTo":"jnareb@gmail.com","subject":"Re: [PATCH] Documentation/tutorial: misc updates","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-04T00:09:43Z","receivedAt":"2007-01-04T00:09:43Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Jakub Narebski wrote:\n> Horst H. von Brand wrote:\n> \n> >> +------------------------------------------------\n> >> +$ git branch -d experimental\n> >> +------------------------------------------------\n> >> +\n> >> +This command ensures that the changes in the experimental branch are\n> >> +already in the current branch.\n> >> +\n\n> > Huh? This deletes the branch, it doesn't ensure changes have been saved.\n\n> It ensures that the branch we want to delete is in lineage of\n> current branch (otherwise we would have to use -D).\n\nI know. But it doesn't \"ensure\" anything, the /user/ has to ensure\nbeforehand that there are no outstanding changes for it to succeed. Fine\ndistinction, I know. But better be extra clear.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"}]}