{"thread":{"id":"10064","subject":"A tour of git: the basics (and notes on some unfriendly messages)","startedAt":"2007-09-28T23:07:25Z","lastAt":"2007-09-30T14:31:50Z","messageCount":26,"participants":["Carl Worth","Shawn O. Pearce","Junio C Hamano","Johannes Schindelin","Nguyen Thai Ngoc Duy","Steffen Prohaska","Pierre Habouzit","Wincent Colaiuta"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"54300","messageId":"87ir5us82a.wl%cworth@cworth.org","threadId":"10064","inReplyTo":null,"subject":"A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-09-28T23:07:25Z","receivedAt":"2007-09-28T23:07:25Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"I recently \"ported\" the introductory chapter of Bryan O’Sullivan's\nDistributed revision control with Mercurial[1] from mercurial to\ngit. The result is here:\n\n\tA tour of git: the basics\n\thttp://cworth.org/hgbook-git/tour/\n\nI did this as an attempt to demonstrate that git and mercurial are\nfundamentally equally \"easy to learn\", and definitely not as an effort\nto try to leech Bryan's hard work, (nor would I even want to encourage\nthat kind of thing). More of my rationale is available here:\n\n\tGit is easy to learn\n\thttp://cworth.org/hgbook-git/\n\nI have two reasons for sharing this with the list. First, I'd\nappreciate any feedback that the knowledgable readers on this list\nmight have. If anything could be made more clear, or if I have factual\nmistakes in the text, I'd definitely like to fix those. Please let me\nknow.\n\nSecond, the process of porting the document highlighted a few issues\nin git that I think would be nice to fix. I only noticed fairly\ncosmetic issues, but I included them as XXX comments in the text. I'll\nshare them here as well: (all of these are with git 1.5.3.2).\n\n * Is \"git help\" actually a builtin thing or just a way to call out to\n \"man\"? Does it work at all in Windows ports of git, for example?\n (OK, so that one's just a question, not an issue it git)\n\n * Would it make sense to put much smaller amounts of text into \"git\n help\" than the entire man page? For example, maybe just the\n description and the most common options or maybe an example? Maybe\n do something like \"git -v help\" for more details? See my text for\n more on this, or compare \"git help init\" to \"hg help init\" and \"hg\n -v help init\".\n\n * The output from a git-clone operating locally is really confusing:\n\n\t$ git clone hello hello-clone\n\tInitialized empty Git repository in /tmp/hello-clone/.git/\n\t0 blocks\n\n Empty? Didn't I just clone it? What does \"0 blocks\" mean?\n\n * git-log by default displays \"Date\" that is the author date, but\n also only uses committer date for options such as --since. This is\n confusing.\n\n * It would be nice if all short-format options, (like \"git log -p\"), were\n also available in a long-format option, (like \"git log --patch\").\n\n * There's a ton of extraneous output from git-fetch. I would love to\n see it reduced to a single-line progress bar, (even if a\n multiple-staged progress bar). I'm imagining a final line\n something like:\n\n\tComputing (100%) Transferring (100%)\n\n But you can imagine more accurate words than those, (I'm not even\n sure what all of the things mean that git-fetch is currently\n reporting progress on).\n\nObviously some of these would be pretty easy, and I should jump into\nthe git implementation to try them out, but I've just been typing this\nstuff as fast as I could, and I'm about to go campout in the rain and\nhail now, (fun, fun!), so I wanted to get this out before I forgot\nanything.\n\nThanks in advance for any of your time, attention, or feedback, (and\nespecially any patches!).\n\n-Carl\n\n[1] http://hgbook.red-bean.com/\n\t"},{"id":"54303","messageId":"20070929000056.GZ3099@spearce.org","threadId":"10064","inReplyTo":"87ir5us82a.wl%cworth@cworth.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-29T00:00:56Z","receivedAt":"2007-09-29T00:00:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Carl Worth wrote:\n> I recently \"ported\" the introductory chapter of Bryan O’Sullivan's\n> Distributed revision control with Mercurial[1] from mercurial to\n> git. The result is here:\n> \n> \tA tour of git: the basics\n> \thttp://cworth.org/hgbook-git/tour/\n\nInteresting.\n \n> * Is \"git help\" actually a builtin thing or just a way to call out to\n> \"man\"? Does it work at all in Windows ports of git, for example?\n> (OK, so that one's just a question, not an issue it git)\n\n`git help` with no arguments displays a message compiled into git.\n`git help init` runs `man git-init`. If you don't have any manual\npages installed, or if they aren't available to your man installation\nthen it fails with \"No manual entry for git-init\" or whatever your\nlocal man implementation dumps.\n\nBrett Schwartz started an asciidoc viewer for Tcl/Tk that I am still\nplaying around with and trying to get working right in git-gui.\nIn theory one could use that to display the manual right from the\nasciidoc files, thus bypassing the need for asciidoc and xmlto.\n\nOn Cygwin we have man, so `git help init` (or `git init --help`) work\njust fine to display the manual entry. No idea about the MSYS port.\n \n> * The output from a git-clone operating locally is really confusing:\n> \n> \t$ git clone hello hello-clone\n> \tInitialized empty Git repository in /tmp/hello-clone/.git/\n> \t0 blocks\n> \n> Empty? Didn't I just clone it? What does \"0 blocks\" mean?\n\nYea. That's because we realized its on the local disk and used\n`cpio` with hardlinks to copy the files. So cpio says it copied\n0 blocks as it actually just hardlinked everything for you. No\ndata was actually copied.\n\ngit-gui's new clone UI uses fancy progress meters here and tries\nto shield the user from \"plumbing and UNIX tools\" spitting out\nseemingly nonsense messages. We probably should try harder in\ngit-clone to do the same here.\n \n> * git-log by default displays \"Date\" that is the author date, but\n> also only uses committer date for options such as --since. This is\n> confusing.\n\nI've never thought about that. But when you say it I think its very\nobvious that it could be confusing to a new user. Maybe we should\nshow the committer line and its date if it doesn't match the author\nname/date. Usually I don't care who committed a change in git.git\n(its a very small handful of people that Junio pulls from directly)\nbut at day-job committer name is usually just as interesting as\nthe author name *when they aren't the same*.\n\n> * There's a ton of extraneous output from git-fetch. I would love to\n> see it reduced to a single-line progress bar, (even if a\n> multiple-staged progress bar). I'm imagining a final line\n> something like:\n> \n> \tComputing (100%) Transferring (100%)\n> \n> But you can imagine more accurate words than those, (I'm not even\n> sure what all of the things mean that git-fetch is currently\n> reporting progress on).\n\nYea. About half of that output is from pack-objects and either\nunpack-objects or index-pack. The other part is from git-fetch\nitself as it updates the local tracking branches (if any are to be\nupdated). Now that git-fetch is in C and reasonably stable maybe\nI can look into making this prettier. Few people really grok the\npack-objects/index-pack output, nor do they care. They just want\nto know two things:\n\n - Is git working or frozen in limbo?\n - Is git frozen because my network sucks, or git sucks?\n - When will this be done? Please $DIETY, I want to go home!\n Make the fetch finish!\n\nThe C based git-fetch made the http protocol almost totally silent.\n(No more got/walk messages.) But that's actually also bad as it\nnow doesn't even let you know its transferring anything at all.\n\nThere are serious issues here about getting the user the progress\nthey really want. The last item (\"When will this be done?\") is\nactually not possible to determine under either the native git\nprotocol or HTTP/FTP. We have no idea up front how much data must\nbe transferred. In the native git case we do know how many objects,\nbut we don't know how many bytes that will be. It could be under\na kilobyte in one project. That same object count for a different\nset of objects fetch could be 500M. Radically different transfer\ntimes would be required.\n \n-- \nShawn.\n"},{"id":"54305","messageId":"7v1wcinvth.fsf@gitster.siamese.dyndns.org","threadId":"10064","inReplyTo":"87ir5us82a.wl%cworth@cworth.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-29T00:45:30Z","receivedAt":"2007-09-29T00:45:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks for starting this. It was an interesting read.\n\n----------------------------------------------------------------\n\n#2.2.1\n\n\"git help init\" would give man page. The time when the short\nhelp is given is when you mistype options, as in:\n\n\t$ git init --huh?\n\n#2.4\n\n\tBy default this command prints a brief paragraph of output...\n\nNot really. The default is to give you the entire log message,\nunless you somehow made --pretty=short the default with your\ncopy of git.\n\n\tThe \"git log\" tool doesn't display the Committer...\n\nYou can ask it to, so \"by default\" is missing.\n\n#2.7.1\n\n\tBut some poepl, (notably Linus...\n\ntypo.\n\n#2.7.6\n\n\tfor which \"git commit --amend\" was\n\nwas what? \"invented\" perhaps?\n\n\n#2.8.3\n\n\tUsing \"git remote\" to pull changes other repositories\n\n\"changes from other repositories\".\n\n----------------------------------------------------------------\n"},{"id":"54306","messageId":"Pine.LNX.4.64.0709290144310.28395@racer.site","threadId":"10064","inReplyTo":"20070929000056.GZ3099@spearce.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-29T00:49:55Z","receivedAt":"2007-09-29T00:49:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 28 Sep 2007, Shawn O. Pearce wrote:\n\n> On Cygwin we have man, so `git help init` (or `git init --help`) work \n> just fine to display the manual entry. No idea about the MSYS port.\n\nWe open the html pages. That is, we don't yet, since we do not generate \nthe html pages just yet; asciidoc is a Python program, and Python is not \navailable as an MSys program as far as I know (and asciidoc insists on \nfinding files in a Unix-like file structure, so we _do_ need an MSys \nPython).\n\n... but all this would be easier if we succeeded in having a minimal \nasciidoc lookalike in git.git...\n\n> > * The output from a git-clone operating locally is really confusing:\n> > \n> > \t$ git clone hello hello-clone\n> > \tInitialized empty Git repository in /tmp/hello-clone/.git/\n> > \t0 blocks\n> > \n> > Empty? Didn't I just clone it? What does \"0 blocks\" mean?\n> \n> Yea. That's because we realized its on the local disk and used\n> `cpio` with hardlinks to copy the files. So cpio says it copied\n> 0 blocks as it actually just hardlinked everything for you. No\n> data was actually copied.\n> \n> git-gui's new clone UI uses fancy progress meters here and tries\n> to shield the user from \"plumbing and UNIX tools\" spitting out\n> seemingly nonsense messages. We probably should try harder in\n> git-clone to do the same here.\n\nAFAICT git-clone is a prime candidate for builtinification, after which \nissues like this should be easy to address.\n\n> > * git-log by default displays \"Date\" that is the author date, but\n> > also only uses committer date for options such as --since. This is\n> > confusing.\n> \n> I've never thought about that. But when you say it I think its very \n> obvious that it could be confusing to a new user. Maybe we should show \n> the committer line and its date if it doesn't match the author \n> name/date. Usually I don't care who committed a change in git.git (its \n> a very small handful of people that Junio pulls from directly) but at \n> day-job committer name is usually just as interesting as the author name \n> *when they aren't the same*.\n\n--pretty=fuller\n\nCiao,\nDscho\n"},{"id":"54311","messageId":"fcaeb9bf0709282232v376d2bccoc7ffcc5ae184b59e@mail.gmail.com","threadId":"10064","inReplyTo":"87ir5us82a.wl%cworth@cworth.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-09-29T05:32:27Z","receivedAt":"2007-09-29T05:32:27Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 9/29/07, Carl Worth wrote:\n> I recently \"ported\" the introductory chapter of Bryan O'Sullivan's\n> Distributed revision control with Mercurial[1] from mercurial to\n> git. The result is here:\n>\n> A tour of git: the basics\n> http://cworth.org/hgbook-git/tour/\n\nMinor thing. On Gentoo you should do \"emerge dev-util/git\" instead of\n\"emerge git\" because there is another program with the same name.\n-- \nDuy\n"},{"id":"54315","messageId":"4D958F04-D531-416A-9FB4-E4119BEC6905@zib.de","threadId":"10064","inReplyTo":"Pine.LNX.4.64.0709290144310.28395@racer.site","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-29T07:44:56Z","receivedAt":"2007-09-29T07:44:56Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 29, 2007, at 2:49 AM, Johannes Schindelin wrote:\n\n>\n> On Fri, 28 Sep 2007, Shawn O. Pearce wrote:\n>\n>> On Cygwin we have man, so `git help init` (or `git init --help`) work\n>> just fine to display the manual entry. No idea about the MSYS port.\n>\n> We open the html pages. That is, we don't yet, since we do not \n> generate\n> the html pages just yet; asciidoc is a Python program, and Python \n> is not\n> available as an MSys program as far as I know (and asciidoc insists on\n> finding files in a Unix-like file structure, so we _do_ need an MSys\n> Python).\n>\n\nI propose to clone the html pages from git.git's html branch and\ninclude them in the installer. I continue to believe that this is\nthe simplest and fastest solution for providing html pages.\n\nI'll provide a patch (hopefully next week).\n\n\tSteffen\n"},{"id":"54318","messageId":"20070929090121.GA4216@artemis.corp","threadId":"10064","inReplyTo":"20070929000056.GZ3099@spearce.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-09-29T09:01:21Z","receivedAt":"2007-09-29T09:01:21Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sat, Sep 29, 2007 at 12:00:56AM +0000, Shawn O. Pearce wrote:\n> The C based git-fetch made the http protocol almost totally silent.\n> (No more got/walk messages.) But that's actually also bad as it\n> now doesn't even let you know its transferring anything at all.\n> \n> There are serious issues here about getting the user the progress\n> they really want. The last item (\"When will this be done?\") is\n> actually not possible to determine under either the native git\n> protocol or HTTP/FTP. We have no idea up front how much data must\n> be transferred. In the native git case we do know how many objects,\n> but we don't know how many bytes that will be. It could be under\n> a kilobyte in one project. That same object count for a different\n> set of objects fetch could be 500M. Radically different transfer\n> times would be required.\n\n I'm not sure you need the ETA thing. I've used bzr only a couple of\ntime, I don't think it shows any kind of ETA, but I think I remember sth\nlike:\n\nStage 3/4\n[==========================> ] [43%]\n\n And that's all is needed. It's sober, and informative enough I think.\n\n\n Many git commands output are still messy and indeed, having them in C\nshould help in that regard. The usual culprit are I think:\n\n * git fetch/clone/pull/.. ;\n * git push ;\n * git repack/gc/... ;\n * git merge (even with the merge.verbosity set to the minimum it's\n still not very readable and confusing).\n\n\n I do believe that the quite verbose output git commands sometimes have\nis quite confusing, and let the user think it's messy. I believe that\nporcelains should be more silent, it's OK for the plumbing to spit\nprogress messages and so on, because people using the plumbing are able\nto understand those, but porcelains should not.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54342","messageId":"Pine.LNX.4.64.0709291606010.28395@racer.site","threadId":"10064","inReplyTo":"4D958F04-D531-416A-9FB4-E4119BEC6905@zib.de","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-29T15:06:59Z","receivedAt":"2007-09-29T15:06:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 29 Sep 2007, Steffen Prohaska wrote:\n\n> On Sep 29, 2007, at 2:49 AM, Johannes Schindelin wrote:\n> \n> > \n> > On Fri, 28 Sep 2007, Shawn O. Pearce wrote:\n> > \n> > > On Cygwin we have man, so `git help init` (or `git init --help`) \n> > > work just fine to display the manual entry. No idea about the MSYS \n> > > port.\n> > \n> > We open the html pages. That is, we don't yet, since we do not \n> > generate the html pages just yet; asciidoc is a Python program, and \n> > Python is not available as an MSys program as far as I know (and \n> > asciidoc insists on finding files in a Unix-like file structure, so we \n> > _do_ need an MSys Python).\n> \n> I propose to clone the html pages from git.git's html branch and include \n> them in the installer. I continue to believe that this is the simplest \n> and fastest solution for providing html pages.\n\nI'm hesitant... The html branch is synced with the master branch. And we \ndeviate from the master branch quite a lot ATM.\n\n> I'll provide a patch (hopefully next week).\n\nThis will be a good temporary workaround.\n\nCiao,\nDscho\n"},{"id":"54344","messageId":"11910819531200-git-send-email-prohaska@zib.de","threadId":"10064","inReplyTo":"A835C8E8-8EC5-43B7-9252-8709214DE7AD@zib.de","subject":"[PATCH] WinGit: included /bin/start in the installer","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-29T16:05:52Z","receivedAt":"2007-09-29T16:05:52Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"/bin/start is needed to tell Windows to open html pages.\n\nSigned-off-by: Steffen Prohaska \n---\n share/WinGit/release.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/share/WinGit/release.sh b/share/WinGit/release.sh\nindex 67d0725..5ab876a 100644\n--- a/share/WinGit/release.sh\n+++ b/share/WinGit/release.sh\n@@ -29,7 +29,7 @@ ls.exe,md5sum.exe,mkdir.exe,msys-1.0.dll,msysltdl-3.dll,mv.exe,patch.exe,\\\n patch.exe.manifest,perl.exe,printf,ps.exe,pwd,rm.exe,rmdir.exe,rxvt.exe,\\\n scp.exe,sed.exe,sh.exe,sleep.exe,sort.exe,split.exe,ssh-agent.exe,ssh.exe,\\\n tail.exe,tar.exe,tee.exe,touch.exe,tr.exe,true.exe,uname.exe,uniq.exe,vi,\\\n-vim.exe,wc.exe,which,xargs.exe,ssh-add.exe} lib/perl5/ share/git* share/vim) |\n+vim.exe,wc.exe,which,xargs.exe,ssh-add.exe,start} lib/perl5/ share/git* share/vim) |\n tar xvf - &&\n mkdir lib/perl5/site_perl &&\n cp /lib/{Error.pm,Git.pm} lib/perl5/site_perl/ &&\n-- \n1.5.3.mingw.1.3.g195850\n"},{"id":"54345","messageId":"11910819542185-git-send-email-prohaska@zib.de","threadId":"10064","inReplyTo":"11910819531200-git-send-email-prohaska@zib.de","subject":"[PATCH] WinGit: include html pages from official git.git's html branch","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-29T16:05:53Z","receivedAt":"2007-09-29T16:05:53Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"It is assumed that a matching version of the html documentation\nis available as the HEAD of /doc/git/html/.git. If not an error\nwill be reported.\n\nThis patch doesn't include a mechanism to fetch the html pages\nto /doc/git/html/.git. You should manually clone them. Maybe\nthis could handled as a submodule of msysgit?\n\nSigned-off-by: Steffen Prohaska \n---\n share/WinGit/release.sh | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/share/WinGit/release.sh b/share/WinGit/release.sh\nindex 5ab876a..8a3c197 100644\n--- a/share/WinGit/release.sh\n+++ b/share/WinGit/release.sh\n@@ -5,6 +5,8 @@ test -z \"$1\" && {\n \texit 1\n }\n \n+test -d /doc/git/html/.git || { echo \"Error: html pages in /doc/git/html/.git missing\"; exit 1; }\n+\n TARGET=\"$HOME\"/WinGit-$1.exe\n OPTS7=\"-m0=lzma -mx=9 -md=64M\"\n TARGET7=tmp.7z\n@@ -21,6 +23,9 @@ mkdir \"$TMPDIR\" &&\n cp uninstaller.exe \"$TMPDIR\"/bin) &&\n cd \"$TMPDIR\" &&\n echo \"Copying files\" &&\n+(git --git-dir=/doc/git/html/.git log --pretty=format:%s -1 HEAD &&\n+ mkdir -p doc/git/html && cd doc/git/html &&\n+ git --git-dir=/doc/git/html/.git archive HEAD | tar xf -) &&\n (cd / && tar cf - bin/{git*,awk,basename.exe,bash.exe,bunzip2,bzip2.exe,\\\n cat.exe,chmod.exe,clear,cmp.exe,cp.exe,cpio,cut.exe,cvs.exe,date.exe,diff.exe,\\\n du.exe,echo,egrep,env.exe,expr.exe,false.exe,find.exe,gawk.exe,grep.exe,\\\n-- \n1.5.3.mingw.1.3.g195850\n"},{"id":"54343","messageId":"A835C8E8-8EC5-43B7-9252-8709214DE7AD@zib.de","threadId":"10064","inReplyTo":"Pine.LNX.4.64.0709291606010.28395@racer.site","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-29T16:06:21Z","receivedAt":"2007-09-29T16:06:21Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 29, 2007, at 5:06 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Sat, 29 Sep 2007, Steffen Prohaska wrote:\n>\n>> On Sep 29, 2007, at 2:49 AM, Johannes Schindelin wrote:\n>>\n>>>\n>>> On Fri, 28 Sep 2007, Shawn O. Pearce wrote:\n>>>\n>>>> On Cygwin we have man, so `git help init` (or `git init --help`)\n>>>> work just fine to display the manual entry. No idea about the MSYS\n>>>> port.\n>>>\n>>> We open the html pages. That is, we don't yet, since we do not\n>>> generate the html pages just yet; asciidoc is a Python program, and\n>>> Python is not available as an MSys program as far as I know (and\n>>> asciidoc insists on finding files in a Unix-like file structure, \n>>> so we\n>>> _do_ need an MSys Python).\n>>\n>> I propose to clone the html pages from git.git's html branch and \n>> include\n>> them in the installer. I continue to believe that this is the \n>> simplest\n>> and fastest solution for providing html pages.\n>\n> I'm hesitant... The html branch is synced with the master branch. \n> And we\n> deviate from the master branch quite a lot ATM.\n\nWe could choose a specific commit from the html branch for the WinGit\nrelease. I don't think we'll need modifications to the documentation\nin msysgit. Selecting an older version that matches the state of msysgit\nshould be sufficient.\n\nFixes to the documentation could be committed directly to git.git.\n\n\n>> I'll provide a patch (hopefully next week).\n>\n> This will be a good temporary workaround.\n\nThe patch following soon will assume that html is available. Maybe\nwe could add it as a submodule of msysgit?\n\nI haven't looked into the submodule mechanisms and therefore will\nnot include it in the patch. I just manually cloned the html branch.\nFor now, this may be sufficient to create a WinGit installer.\n\n\tSteffen\n"},{"id":"54358","messageId":"Pine.LNX.4.64.0709292149280.28395@racer.site","threadId":"10064","inReplyTo":"11910819542185-git-send-email-prohaska@zib.de","subject":"Re: [PATCH] WinGit: include html pages from official git.git's html branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-29T20:50:58Z","receivedAt":"2007-09-29T20:50:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 29 Sep 2007, Steffen Prohaska wrote:\n\n> It is assumed that a matching version of the html documentation\n> is available as the HEAD of /doc/git/html/.git. If not an error\n> will be reported.\n> \n> This patch doesn't include a mechanism to fetch the html pages\n> to /doc/git/html/.git. You should manually clone them. Maybe\n> this could handled as a submodule of msysgit?\n\nI'd rather handle it as in git.git, as another branch, and not check it \nout in /git/html/, but rather use \"git read-tree \n--prefix=/tmp/WinGit/share/git/html origin/html\", or some such.\n\nCiao,\nDscho\n"},{"id":"54363","messageId":"E5C688F2-4A8D-402A-9757-5007BE4A8B25@zib.de","threadId":"10064","inReplyTo":"20070929000056.GZ3099@spearce.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-29T21:48:25Z","receivedAt":"2007-09-29T21:48:25Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 29, 2007, at 2:00 AM, Shawn O. Pearce wrote:\n\n>> * There's a ton of extraneous output from git-fetch. I would \n>> love to\n>> see it reduced to a single-line progress bar, (even if a\n>> multiple-staged progress bar). I'm imagining a final line\n>> something like:\n>>\n>> \tComputing (100%) Transferring (100%)\n>>\n>> But you can imagine more accurate words than those, (I'm not even\n>> sure what all of the things mean that git-fetch is currently\n>> reporting progress on).\n>\n> Yea. About half of that output is from pack-objects and either\n> unpack-objects or index-pack. The other part is from git-fetch\n> itself as it updates the local tracking branches (if any are to be\n> updated). Now that git-fetch is in C and reasonably stable maybe\n> I can look into making this prettier. Few people really grok the\n> pack-objects/index-pack output, nor do they care. They just want\n> to know two things:\n>\n> - Is git working or frozen in limbo?\n> - Is git frozen because my network sucks, or git sucks?\n> - When will this be done? Please $DIETY, I want to go home!\n> Make the fetch finish!\n>\n> The C based git-fetch made the http protocol almost totally silent.\n> (No more got/walk messages.) But that's actually also bad as it\n> now doesn't even let you know its transferring anything at all.\n>\n> There are serious issues here about getting the user the progress\n> they really want. The last item (\"When will this be done?\") is\n> actually not possible to determine under either the native git\n> protocol or HTTP/FTP. We have no idea up front how much data must\n> be transferred. In the native git case we do know how many objects,\n> but we don't know how many bytes that will be. It could be under\n> a kilobyte in one project. That same object count for a different\n> set of objects fetch could be 500M. Radically different transfer\n> times would be required.\n\nOften you know that you have a good connection and you are not\ninterested in any progress reporting at all. _No_ output would be\nperfect. A return code of 0 would already tell you all you need\nto know. If you'd like to know more you could pass something like\n'--verbose' or '--progress'.\n\nQuite often git prints a lot of very technical information that\nis not very interesting as long as things succeed without error.\nSome examples are\n- git fetch (see above)\n- git rebase: prints a lot of details that I'm not interested in\n unless the rebase fails.\n- git push: prints updates of remote heads. A message about\n failing to update a remote head may get lost.\n- git merge: the fact that a merge is a fast forward merge gets\n printed at the very top, followed by (often a lot of) diffstat.\n I know diffstat can help to judge if the merge did what you\n expected. But even more important is the fact that the merge\n was just a fast forward, which may get buried under lots of output.\n\nMaybe git should become more quiet, as other unix tools are, and\nper default only report problems. Technical details and progress\ncould be requested explicitly by '--verbose' or similar. We could\npipe all the technical output to a per-repository logfile, which\ncan be consulted in case of errors. The log could be cropped\nduring 'git gc'.\n\n\n\tSteffen\n"},{"id":"54370","messageId":"7vr6khjf22.fsf@gitster.siamese.dyndns.org","threadId":"10064","inReplyTo":"Pine.LNX.4.64.0709292149280.28395@racer.site","subject":"Re: [PATCH] WinGit: include html pages from official git.git's html branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-29T22:13:25Z","receivedAt":"2007-09-29T22:13:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Sat, 29 Sep 2007, Steffen Prohaska wrote:\n>\n>> It is assumed that a matching version of the html documentation\n>> is available as the HEAD of /doc/git/html/.git. If not an error\n>> will be reported.\n>> \n>> This patch doesn't include a mechanism to fetch the html pages\n>> to /doc/git/html/.git. You should manually clone them. Maybe\n>> this could handled as a submodule of msysgit?\n>\n> I'd rather handle it as in git.git, as another branch, and not check it \n> out in /git/html/, but rather use \"git read-tree \n> --prefix=/tmp/WinGit/share/git/html origin/html\", or some such.\n\nThis is starting to smell like an opportunity to use the gitlink\nstuff, isn't it?\n"},{"id":"54373","messageId":"7vlkapjeir.fsf@gitster.siamese.dyndns.org","threadId":"10064","inReplyTo":"E5C688F2-4A8D-402A-9757-5007BE4A8B25@zib.de","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-29T22:25:00Z","receivedAt":"2007-09-29T22:25:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> Quite often git prints a lot of very technical information that\n> is not very interesting as long as things succeed without error.\n> Some examples are\n> - git fetch (see above)\n\nProbably.\n\n> - git rebase: prints a lot of details that I'm not interested in\n> unless the rebase fails.\n\nYes. Most of the clutter is coming from \"am\" which also should\nbe squelched.\n\nSaying\n\n\tSwitched to branch \n\nis good when the branch to rebase is specified.\n\n\t\"HEAD is now at ...\"\nis not useful -- it is a side effect of rewinding the head to\nthe --onto commit.\n\n\t\n Applying \n\t\n Wrote tree \n Committed: \n\nare coming from \"am\" for each patch. We could squelch these\ninto just one \"Applying \" and nothing else, which\nwould also help making \"am\" quieter.\n\n> - git push: prints updates of remote heads. A message about\n> failing to update a remote head may get lost.\n\nPlease do not remove the report of successful update, as people\noften say \"git push\" or \"git push $there\" without explicitly\nsaying which refs to push. When pushing out to publish, I say\n\"git push ko\" (to mean k.org) and I _want_ my positive feedback.\n\n> - git merge: the fact that a merge is a fast forward merge gets\n> printed at the very top, followed by (often a lot of) diffstat.\n> I know diffstat can help to judge if the merge did what you\n> expected. But even more important is the fact that the merge\n> was just a fast forward, which may get buried under lots of output.\n\nI do not think fast-forwardness is particularly interesting. If\nyou find fast-forwardness interesting, I suspect you would even\nwant to know what _your_ change that were not in the other side\nof the merge, which is something that we do not even report\nright now.\n\n> Maybe git should become more quiet, as other unix tools are, and\n> per default only report problems. Technical details and progress\n> could be requested explicitly by '--verbose' or similar.\n\nI'd agree with this sentiment in principle, and many of the\nthings you propose to remove above fall into the \"unnecessary\nclutter\" category. But some of the existing output fall into\nthe \"necessary info\" category --- diffstart after merge and\nreport of successful remote ref updates are such things, so we\nshould be careful not to go overboard.\n"},{"id":"54379","messageId":"Pine.LNX.4.64.0709300022080.28395@racer.site","threadId":"10064","inReplyTo":"7vr6khjf22.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] WinGit: include html pages from official git.git's html branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-29T23:23:59Z","receivedAt":"2007-09-29T23:23:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 29 Sep 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Sat, 29 Sep 2007, Steffen Prohaska wrote:\n> >\n> >> It is assumed that a matching version of the html documentation is \n> >> available as the HEAD of /doc/git/html/.git. If not an error will be \n> >> reported.\n> >> \n> >> This patch doesn't include a mechanism to fetch the html pages to \n> >> /doc/git/html/.git. You should manually clone them. Maybe this could \n> >> handled as a submodule of msysgit?\n> >\n> > I'd rather handle it as in git.git, as another branch, and not check \n> > it out in /git/html/, but rather use \"git read-tree \n> > --prefix=/tmp/WinGit/share/git/html origin/html\", or some such.\n> \n> This is starting to smell like an opportunity to use the gitlink stuff, \n> isn't it?\n\nI'd agree that we could have a submodule in /doc/git/html/. This way, \neven users of msysGit and GitMe would benefit.\n\nCiao,\nDscho\n"},{"id":"54387","messageId":"87d4w0styy.wl%cworth@cworth.org","threadId":"10064","inReplyTo":"7v1wcinvth.fsf@gitster.siamese.dyndns.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-09-30T03:38:45Z","receivedAt":"2007-09-30T03:38:45Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 28 Sep 2007 17:45:30 -0700, Junio C Hamano wrote:\n> Thanks for starting this. It was an interesting read.\n\nYou're welcome. I hope it's useful for people.\n\nThe original goal was to demonstrate that git is no harder to learn\nthan mercurial. So that attempt is done, now, (whether successful or\nnot, I can't really judge).\n\nNow, after getting some initial feedback, it's clear that the document\ncould further be improved by focusing on the \"git way\" of doing things\nthat aren't as natural in hg, (like multiple branches in a single\nrepository).\n\nRather than extending the current document, though, I think I'll just\ndraw up on outline based on what I think would be a good order to\nintroduce the topics. And then I'll see what text in the current\nuser's guide could plug into that outline, and what pieces might\nbe missing or could be improved.\n\nAt least, that's my thoughts for now. I don't know if I'll get around\nto it though, (we'll have to see if I get annoyed into doing that work\nlike I got annoyed into this first project).\n\n> \"git help init\" would give man page. The time when the short\n> help is given is when you mistype options, as in:\n>\n> \t$ git init --huh?\n\nOh, and that's *really* short output. Just a summary of the\ncommand-line options and no description. If you look at \"hg help\" it\nhas a middle-ground option which is little more than a brief\ndescription and a very small number of options. I think that's a\nuseful thing to consider for \"git help\". Or, perhaps just carefully\nconstruct the man page so that this most important information is\nfirst. See \"git help clone\" for example which does have a better order\nthan \"git help init\" in my opinion.\n\nMeanwhile, \"git init --huh?\" is totally appropriate in just printing\nusage information. That's really all you want to see if you\nforget the exact name of a particular command-line option.\n\nTrying a couple of random examples though, git could be better in some\ncases:\n\n\t$ git log --pretty=complete\n\tfatal: invalid --pretty format: complete\n\nThat's a fairly specific error message, but no information on what I\nmight have meant to say. A fix should be be quite simple, (presumably\nthere's a list of --pretty options it just looped through and it might\nas well print them out).\n\n\t$ git log --format=fuller\n\tfatal: unrecognized argument: --format=fuller\n\nThere's no usage given in this case at all. It should print some usage\nstatement, hopefully containing --pretty. Admittedly, this one is\n*really* hard to fix entirely since there is a ridiculously large\nnumber of possible options to a command like \"git log\". But a aummary\nof the most common stuff should still help.\n\nThanks for the various typo fixes. I've implemented those, (and the\nthings submitted by others). There were some particularly bad markup\nproblems where \"git commit \" was being misinterpreted and\npresented as \"git commit\" which was fairly disastrous for my intended\nmeaning.\n\nHopefully it's much better now.\n\n-Carl\n"},{"id":"54388","messageId":"87bqbkstyq.wl%cworth@cworth.org","threadId":"10064","inReplyTo":"7v1wcinvth.fsf@gitster.siamese.dyndns.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-09-30T03:38:53Z","receivedAt":"2007-09-30T03:38:53Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 28 Sep 2007 17:45:30 -0700, Junio C Hamano wrote:\n> Thanks for starting this. It was an interesting read.\n\nYou're welcome. I hope it's useful for people.\n\nThe original goal was to demonstrate that git is no harder to learn\nthan mercurial. So that attempt is done, now, (whether successful or\nnot, I can't really judge).\n\nNow, after getting some initial feedback, it's clear that the document\ncould further be improved by focusing on the \"git way\" of doing things\nthat aren't as natural in hg, (like multiple branches in a single\nrepository).\n\nRather than extending the current document, though, I think I'll just\ndraw up on outline based on what I think would be a good order to\nintroduce the topics. And then I'll see what text in the current\nuser's guide could plug into that outline, and what pieces might\nbe missing or could be improved.\n\nAt least, that's my thoughts for now. I don't know if I'll get around\nto it though, (we'll have to see if I get annoyed into doing that work\nlike I got annoyed into this first project).\n\n> \"git help init\" would give man page. The time when the short\n> help is given is when you mistype options, as in:\n>\n> \t$ git init --huh?\n\nOh, and that's *really* short output. Just a summary of the\ncommand-line options and no description. If you look at \"hg help\" it\nhas a middle-ground option which is little more than a brief\ndescription and a very small number of options. I think that's a\nuseful thing to consider for \"git help\". Or, perhaps just carefully\nconstruct the man page so that this most important information is\nfirst. See \"git help clone\" for example which does have a better order\nthan \"git help init\" in my opinion.\n\nMeanwhile, \"git init --huh?\" is totally appropriate in just printing\nusage information. That's really all you want to see if you\nforget the exact name of a particular command-line option.\n\nTrying a couple of random examples though, git could be better in some\ncases:\n\n\t$ git log --pretty=complete\n\tfatal: invalid --pretty format: complete\n\nThat's a fairly specific error message, but no information on what I\nmight have meant to say. A fix should be be quite simple, (presumably\nthere's a list of --pretty options it just looped through and it might\nas well print them out).\n\n\t$ git log --format=fuller\n\tfatal: unrecognized argument: --format=fuller\n\nThere's no usage given in this case at all. It should print some usage\nstatement, hopefully containing --pretty. Admittedly, this one is\n*really* hard to fix entirely since there is a ridiculously large\nnumber of possible options to a command like \"git log\". But a summary\nof the most common stuff should still help.\n\nThanks for the various typo fixes. I've implemented those, (and the\nthings submitted by others). There were some particularly bad markup\nproblems where \"git commit \" was being misinterpreted and\npresented as \"git commit\" which was fairly disastrous for my intended\nmeaning.\n\nHopefully it's much better now.\n\n-Carl\n"},{"id":"54398","messageId":"E8851B12-AAA5-4B4D-9F28-C5AB5AEF0E57@zib.de","threadId":"10064","inReplyTo":"7vlkapjeir.fsf@gitster.siamese.dyndns.org","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-30T08:15:10Z","receivedAt":"2007-09-30T08:15:10Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 30, 2007, at 12:25 AM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>> - git push: prints updates of remote heads. A message about\n>> failing to update a remote head may get lost.\n>\n> Please do not remove the report of successful update, as people\n> often say \"git push\" or \"git push $there\" without explicitly\n> saying which refs to push. When pushing out to publish, I say\n> \"git push ko\" (to mean k.org) and I _want_ my positive feedback.\n\nYes but it's pretty technical.\n\nA much simpler output could be easier to scan by a human\n\nupdating 'refs/heads/master' .. fast forward .. ok.\nupdating 'refs/heads/pu' .. forced non-fast forward .. ok.\nupdating 'refs/heads/next' ..\nERROR: 'refs/heads/next' not updating to non-fast forward\nexit(1) here.\n\nIf we exit after the very first problem it can't get lost.\nAfter fixing the issue you can just 'git push' again.\n\n\n>> - git merge: the fact that a merge is a fast forward merge gets\n>> printed at the very top, followed by (often a lot of) diffstat.\n>> I know diffstat can help to judge if the merge did what you\n>> expected. But even more important is the fact that the merge\n>> was just a fast forward, which may get buried under lots of output.\n>\n> I do not think fast-forwardness is particularly interesting. If\n> you find fast-forwardness interesting, I suspect you would even\n> want to know what _your_ change that were not in the other side\n> of the merge, which is something that we do not even report\n> right now.\n\nI use it to advance a branch to a temporary integration branch.\nAt that point I expect that the merge is a fast forward. Here's\nwhat I do.\n\n git checkout -b for/master master\n git merge branch-with-good-topics\n git branch -f scratch\n git push compileservers # pushes scratch for automatic builds\n\nNow I wait for compiles to finish. Typically I continue not before\nthe next morning. If everything's ok I do.\n\n git checkout master\n git merge for/master\n git push\n\nThe last merge must be a fast forward. This is the only fact I'm\ninterested in. I could do 'git reset' or 'git branch -f' but then\nI'd loose the check if it's a fast forward.\n\nI don't merge directly to master to avoid any accidentally push.\nI can also easily revert by just deleting 'for/master'.\n\nMaybe there's a better workflow?\n\n\n>> Maybe git should become more quiet, as other unix tools are, and\n>> per default only report problems. Technical details and progress\n>> could be requested explicitly by '--verbose' or similar.\n>\n> I'd agree with this sentiment in principle, and many of the\n> things you propose to remove above fall into the \"unnecessary\n> clutter\" category. But some of the existing output fall into\n> the \"necessary info\" category --- diffstart after merge\n\nI agree. Could we print the note about fast forward _after_ the\ndiffstat? Maybe there are more useful oneline information that\ncould be output there.\n\n> and report of successful remote ref updates are such things, so we\n> should be careful not to go overboard.\n\nBut the output could be less technical and more human readable.\n\nAlso diffstat's output and \"git push\" are different. diffstats\nchange with the content of your repo. \"git push\" just succeeds\nor fails. If is succeeds it updates remote refs according to your\nconfiguration. There is no new information in the output beyond\nsuccess or failure [which is not quite true if you depend on\ngit push finding matching refs automatically -- I don't]. I don't\nthink the sha1's printed are needed by anyone. And if someone\nneeds them, he could call push with '--verbose'.\n\nI asked about a '--dry-run' switch to \"git push\" some time ago,\nwhich would only report what \"git push\" would do without actually\nchanging anything on the remote side. I'd use this to check what\nI expect to do. Just in case I messed up my configuration. At the\ntime \"git push\" is actually pushing it's too late to fix a broken\nconfiguration. I know '--dry-run' it's not trivial to implement\nand I'll likely have no time to look into it.\n\n\tSteffen\n"},{"id":"54399","messageId":"D4E42E0D-99CB-4F4E-AC89-CD94DA061FDC@zib.de","threadId":"10064","inReplyTo":"Pine.LNX.4.64.0709300022080.28395@racer.site","subject":"Re: [PATCH] WinGit: include html pages from official git.git's html branch","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-30T08:19:52Z","receivedAt":"2007-09-30T08:19:52Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 30, 2007, at 1:23 AM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Sat, 29 Sep 2007, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>>\n>>> On Sat, 29 Sep 2007, Steffen Prohaska wrote:\n>>>\n>>>> It is assumed that a matching version of the html documentation is\n>>>> available as the HEAD of /doc/git/html/.git. If not an error \n>>>> will be\n>>>> reported.\n>>>>\n>>>> This patch doesn't include a mechanism to fetch the html pages to\n>>>> /doc/git/html/.git. You should manually clone them. Maybe this \n>>>> could\n>>>> handled as a submodule of msysgit?\n>>>\n>>> I'd rather handle it as in git.git, as another branch, and not check\n>>> it out in /git/html/, but rather use \"git read-tree\n>>> --prefix=/tmp/WinGit/share/git/html origin/html\", or some such.\n>>\n>> This is starting to smell like an opportunity to use the gitlink \n>> stuff,\n>> isn't it?\n>\n> I'd agree that we could have a submodule in /doc/git/html/. This way,\n> even users of msysGit and GitMe would benefit.\n\nAnd we could completely tag a WinGit release. The version of the\nhtml docs included would be defined by the submodule's head in\n/doc/git/html. This is what I had in mind when submitting the\npatch. Maybe I didn't express this clearly.\n\nI do not yet understand submodules sufficiently. Therefore I didn't\nadd a patch that actually sets up the submodule in /doc/git/html.\nMaybe I'll do so later today.\n\n\tSteffen\n"},{"id":"54402","messageId":"7vr6kgh2yy.fsf@gitster.siamese.dyndns.org","threadId":"10064","inReplyTo":"E8851B12-AAA5-4B4D-9F28-C5AB5AEF0E57@zib.de","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-30T10:17:25Z","receivedAt":"2007-09-30T10:17:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> ... If everything's ok I do.\n>\n> git checkout master\n> git merge for/master\n> git push\n>\n> The last merge must be a fast forward.\n\nLast week I saw somebody (I think it was Shawn) mentioned a\ntrick:\n\n\tgit push . thisbranch:thatbranch\n\nwill moves thatbranch to thisbranch iff thisbranch is a\ndescendant of thatbranch. So doing\n\n\tgit push . for-master:master\n\ninstead of that checkout + merge command sequence would\nobviously be a good solution for your particular use case.\n\nHaving said that it may make sense to swap the order so that the\ndiffstat is shown first and then a single line \"Merge made by\nrecursive\" or \"Updatting A..B, Fast Forward\" concludes the\nreport. At least, I do not think such a swapping would hurt the\nusability, although people used to the UI may first feel uneasy.\nI would not object to such a patch in principle.\n"},{"id":"54407","messageId":"Pine.LNX.4.64.0709301343000.28395@racer.site","threadId":"10064","inReplyTo":"E8851B12-AAA5-4B4D-9F28-C5AB5AEF0E57@zib.de","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-30T12:44:48Z","receivedAt":"2007-09-30T12:44:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 30 Sep 2007, Steffen Prohaska wrote:\n\n> \n> On Sep 30, 2007, at 12:25 AM, Junio C Hamano wrote:\n> \n> > Steffen Prohaska writes:\n> > \n> > > - git push: prints updates of remote heads. A message about\n> > > failing to update a remote head may get lost.\n> > \n> > Please do not remove the report of successful update, as people often \n> > say \"git push\" or \"git push $there\" without explicitly saying which \n> > refs to push. When pushing out to publish, I say \"git push ko\" (to \n> > mean k.org) and I _want_ my positive feedback.\n> \n> Yes but it's pretty technical.\n> \n> A much simpler output could be easier to scan by a human\n> \n> updating 'refs/heads/master' .. fast forward .. ok.\n> updating 'refs/heads/pu' .. forced non-fast forward .. ok.\n> updating 'refs/heads/next' ..\n> ERROR: 'refs/heads/next' not updating to non-fast forward\n> exit(1) here.\n\nNo, please no. This is way too short.\n\nIf at all, please let 8c3275abcacb83ea3f4c4f4ceb2376799fc282bd be an \nexample, and make git respect several different output levels, but not \nchanging the default (at first).\n\nCiao,\nDscho\n"},{"id":"54406","messageId":"912CB4AE-83B9-42D7-A591-E721D1E22439@wincent.com","threadId":"10064","inReplyTo":"20070929090121.GA4216@artemis.corp","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-09-30T12:45:34Z","receivedAt":"2007-09-30T12:45:34Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 29/9/2007, a las 11:01, Pierre Habouzit escribió:\n\n> Many git commands output are still messy and indeed, having them \n> in C\n> should help in that regard. The usual culprit are I think:\n>\n> * git fetch/clone/pull/.. ;\n> * git push ;\n> * git repack/gc/... ;\n> * git merge (even with the merge.verbosity set to the minimum it's\n> still not very readable and confusing).\n>\n>\n> I do believe that the quite verbose output git commands sometimes \n> have\n> is quite confusing, and let the user think it's messy. I believe that\n> porcelains should be more silent, it's OK for the plumbing to spit\n> progress messages and so on, because people using the plumbing are \n> able\n> to understand those, but porcelains should not.\n\nI think that most people just want to know, \"Did it work or not?\" and \nso when the commands chatter too much they go into filter mode, don't \nreally read the output, let alone try to understand it, and just skim \nit. Ideally Git would be much less \"chattery\" in general when things \nwork, and only be more verbose when things go wrong; of course, \nfinding that balance point is where the art lies.\n\nWincent\n"},{"id":"54410","messageId":"D6FD584E-9B14-4566-8955-ACA1BAFB0456@zib.de","threadId":"10064","inReplyTo":"Pine.LNX.4.64.0709301343000.28395@racer.site","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-09-30T13:41:56Z","receivedAt":"2007-09-30T13:41:56Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Sep 30, 2007, at 2:44 PM, Johannes Schindelin wrote:\n\n>>\n>> A much simpler output could be easier to scan by a human\n>>\n>> updating 'refs/heads/master' .. fast forward .. ok.\n>> updating 'refs/heads/pu' .. forced non-fast forward .. ok.\n>> updating 'refs/heads/next' ..\n>> ERROR: 'refs/heads/next' not updating to non-fast forward\n>> exit(1) here.\n>\n> No, please no. This is way too short.\n>\n> If at all, please let 8c3275abcacb83ea3f4c4f4ceb2376799fc282bd be an\n> example, and make git respect several different output levels, but not\n> changing the default (at first).\n\ngood idea.\n\n\tSteffen\n"},{"id":"54411","messageId":"20070930134937.GG22560@artemis.corp","threadId":"10064","inReplyTo":"912CB4AE-83B9-42D7-A591-E721D1E22439@wincent.com","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-09-30T13:49:37Z","receivedAt":"2007-09-30T13:49:37Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Sep 30, 2007 at 12:45:34PM +0000, Wincent Colaiuta wrote:\n> El 29/9/2007, a las 11:01, Pierre Habouzit escribió:\n> \n> > Many git commands output are still messy and indeed, having them in C\n> >should help in that regard. The usual culprit are I think:\n> >\n> > * git fetch/clone/pull/.. ;\n> > * git push ;\n> > * git repack/gc/... ;\n> > * git merge (even with the merge.verbosity set to the minimum it's\n> > still not very readable and confusing).\n> >\n> >\n> > I do believe that the quite verbose output git commands sometimes have\n> >is quite confusing, and let the user think it's messy. I believe that\n> >porcelains should be more silent, it's OK for the plumbing to spit\n> >progress messages and so on, because people using the plumbing are able\n> >to understand those, but porcelains should not.\n> \n> I think that most people just want to know, \"Did it work or not?\" and so \n> when the commands chatter too much they go into filter mode, don't really \n> read the output, let alone try to understand it, and just skim it. \n> Ideally Git would be much less \"chattery\" in general when things work, \n> and only be more verbose when things go wrong; of course, finding that \n> balance point is where the art lies.\n\n That's true for git merge that is fast. But people also want to know\nthe command is not stuck in an infinite loop, and for that progress bars\nor little \\|/- animation.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54414","messageId":"9FDE609B-ABC1-45D7-AFF9-211381CAF830@wincent.com","threadId":"10064","inReplyTo":"20070930134937.GG22560@artemis.corp","subject":"Re: A tour of git: the basics (and notes on some unfriendly messages)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-09-30T14:31:50Z","receivedAt":"2007-09-30T14:31:50Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 30/9/2007, a las 15:49, Pierre Habouzit escribió:\n\n> On Sun, Sep 30, 2007 at 12:45:34PM +0000, Wincent Colaiuta wrote:\n>>\n>> I think that most people just want to know, \"Did it work or not?\" \n>> and so\n>> when the commands chatter too much they go into filter mode, don't \n>> really\n>> read the output, let alone try to understand it, and just skim it.\n>> Ideally Git would be much less \"chattery\" in general when things \n>> work,\n>> and only be more verbose when things go wrong; of course, finding \n>> that\n>> balance point is where the art lies.\n>\n> That's true for git merge that is fast. But people also want to know\n> the command is not stuck in an infinite loop, and for that progress \n> bars\n> or little \\|/- animation.\n\nYes, I agree. I probably should have said that they either want to \nknow \"*Did* it work?\" for near-instant operations (most Git \noperations, hopefully), and \"*Is* it working?\" for long-running ones \n(network ops, for example) and in those cases you're right that a \nprogress bar would be a nice enhancement.\n\nCheers,\nWincent\n"}]}