{"thread":{"id":"43119","subject":"Re: What's in git.git (stable)","startedAt":"2006-12-13T21:35:08Z","lastAt":"2006-12-16T22:04:54Z","messageCount":102,"participants":["Junio C Hamano","Andy Parkins","Nicolas Pitre","Linus Torvalds","Shawn Pearce","Jakub Narebski","Carl Worth","Johannes Schindelin","Andreas Ericsson","Peter Baumann","Steven Grimm","Shawn O. Pearce","Raimund Bauer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295307","messageId":"7v4przfpir.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":null,"subject":"What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-13T21:35:08Z","receivedAt":"2006-12-13T21:35:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"We have a handful fixes on 'maint'; I will be cutting v1.4.4.3 by\nthe end of the week.\n\nOn the 'master' front, this round has many topics (most of which\nhave been cooking in the 'next' branch) merged since the last\nannouncement.\n\n - Johannes Schindelin's built-in shortlog is in.\n\n - Johannes Schindelin's built-in 'RCS merge replacement' is\n in. Hopefully this would make merge-recursive more portable\n and faster.\n\n - Shawn Pearce and Johannes Schindelin spotted and fixed a few\n corner cases in merge-recursive.\n\n - Updates to gitk from Paul Mackerras to fix longstanding menu\n issues on Mac OS X.\n\n - Eric Wong fixed use of rerere in many places.\n\n - Eric also has quite a few fixes to git-svn.\n\n - Nico updated 'git-add' to really mean 'add contents', not\n 'add to the set of tracked paths'. Also updated was the\n documentation for 'git commit' to make it easier to teach new\n people after a long discussion.\n\n - Lars Hjemli taught 'git-branch' to rename branches.\n\n - Andy Parkins taught 'git-branch' to be colorful.\n\n - Robin Rosenberg improved cvsexportcommit for unusual\n pathnames.\n\n - 'git push $URL :refs/tags/that' (notice the colon) can be\n used to delete 'that' tag from the remote repository; this\n needs the latest git on both ends.\n\n - branch.\"master\".{remote,merge} configuration items are set up\n by 'git-clone', thanks to Andy Parkins.\n\n - 'git-commit' gives 'diff --summary' output to remind mode\n changes and added/deleted files.\n\n - 'git-diff --numstat' matches 'git-apply --numstat' when\n talking about binary changes.\n\n - 'git-merge' is now a first class UI, not just a mere driver\n for strategies.\n\nI am hoping that we can start a stabilization cycle for v1.5.0\nbased on what we have in 'master'. The theme is \"usability and\nteachability\".\n\nThings that need to be done to complete what have been merged to\n'master' are:\n\n - 'git-rm' needs to be fixed up as Linus outlined; remove\n working tree file and index entry but have a sanity check to\n make sure the working tree file match the index and HEAD.\n\n - 'git-branch' may need to be taught about renaming the\n matching per-branch configuration at the same time.\n\n - 'git-merge-file' needs to be documented and linked from\n git.txt.\n\n - 'git-clone' probably should be updated to use wild-card in\n remote.origin.fetch, instead of listing all the branches it\n found when the clone was made.\n\n - tutorials and other Porcelain documentation pages need to be\n updated to match the updated 'git-add' and 'git-rm' (to be\n updated), and their description should be made much less\n about implementation; they should talk in terms of end-user\n workflows. I will send a draft for 'git diff' out later, but\n somebody needs a full sweep on Porcelain-ish documentation.\n\n - 'git diff --index' patch should be reverted (already done in\n 'next'), although we may have to come up with a better\n wording for --cached.\n\n----------------------------------------------------------------\n* The 'maint' branch has these fixes since v1.4.4.2.\n\n Alex Riesen (1):\n Clarify fetch error for missing objects.\n\n Brian Gernhardt (1):\n Move Fink and Ports check to after config file\n\n Chris Wright (1):\n no need to install manpages as executable\n\n Eric Wong (2):\n git-svn: exit with status 1 for test failures\n git-svn: correctly display fatal() error messages\n\n Jim Meyering (1):\n Don't use memcpy when source and dest. buffers may overlap\n\n Martin Langhoff (1):\n cvsserver: Avoid miscounting bytes in Perl v5.8.x\n\n Shawn O. Pearce (1):\n Make sure the empty tree exists when needed in merge-recursive.\n\n\n* The 'master' branch has these since the last announcement.\n\n Alex Riesen (3):\n git-blame: fix rev parameter handling.\n Make perl/ build procedure ActiveState friendly.\n Clarify fetch error for missing objects.\n\n Andreas Ericsson (2):\n ls-files: Give hints when errors happen.\n git-diff: Introduce --index and deprecate --cached.\n\n Andy Parkins (6):\n Use .git/config for storing \"origin\" shortcut repository\n Document git-repo-config --bool/--int options.\n De-emphasise the symbolic link documentation.\n Explicitly add the default \"git pull\" behaviour to .git/config on clone\n Colourise git-branch output\n Allow subcommand.color and color.subcommand color configuration\n\n Brian Gernhardt (1):\n Move Fink and Ports check to after config file\n\n Chris Wright (1):\n no need to install manpages as executable\n\n David Miller (1):\n Pass -M to diff in request-pull\n\n Eric Wong (21):\n git-svn: use ~/.subversion config files when using SVN:: libraries\n git-svn: enable delta transfers during fetches when using SVN:: libs\n git-svn: update tests for recent changes\n git-svn: error out when the SVN connection fails during a fetch\n git-svn: fix output reporting from the delta fetcher\n git-svn: color support for the log command\n git-svn: documentation updates\n git-svn: fix multi-init\n git-svn: avoid fetching files twice in the same revision\n git-svn: avoid network timeouts for long-running fetches\n git-svn: extra error check to ensure we open a file correctly\n git-svn: use do_switch for --follow-parent if the SVN library supports it\n rerere: add clear, diff, and status commands\n rerere: record (or avoid misrecording) resolved, skipped or aborted rebase/am\n git-svn: enable logging of information not supported by git\n git-svn: allow dcommit to take an alternate head\n git-svn: correctly display fatal() error messages\n git-svn: correctly handle packed-refs in refs/remotes/\n git-svn: exit with status 1 for test failures\n git-svn: correctly display fatal() error messages\n git-svn: correctly handle \"(no author)\" when using an authors file\n\n Han-Wen Nienhuys (1):\n ident.c: Trim hint printed when gecos is empty.\n\n J. Bruce Fields (4):\n cvs-migration: improved section titles, better push/commit explanation\n Documentation: reorganize cvs-migration.txt\n Documentation: update git-clone man page with new behavior\n Documentation: simpler shared repository creation\n\n Jakub Narebski (4):\n gitweb: Fix Atom feed : it is $logo, not $logo_url\n git-clone: Rename --use-immingled-remote option to --no-separate-remote\n Document git-diff whitespace flags -b and -w\n gitweb: Allow PNG, GIF, JPEG images to be displayed in \"blob\" view\n\n Jeff King (1):\n shortlog: fix segfault on empty authorname\n\n Jim Meyering (2):\n Set permissions of each new file before \"cvs add\"ing it.\n Don't use memcpy when source and dest. buffers may overlap\n\n Johannes Schindelin (18):\n Build in shortlog\n shortlog: do not crash on parsing \"[PATCH\"\n shortlog: read mailmap from ./.mailmap again\n shortlog: handle email addresses case-insensitively\n shortlog: fix \"-n\"\n shortlog: use pager\n sha1_object_info(): be consistent with read_sha1_file()\n xdiff: add xdl_merge()\n xdl_merge(): fix an off-by-one bug\n xdl_merge(): fix thinko\n git-mv: search more precisely for source directory in index\n diff -b: ignore whitespace at end of line\n xdl_merge(): fix and simplify conflict handling\n cvs-migration document: make the need for \"push\" more obvious\n Add builtin merge-file, a minimal replacement for RCS merge\n merge-file: support -p and -q; fix compile warnings\n Get rid of the dependency on RCS' merge program\n merge-recursive: add/add really is modify/modify with an empty base\n\n Josef Weidendorfer (1):\n Add branch.*.merge warning and documentation update\n\n Junio C Hamano (45):\n Store peeled refs in packed-refs file.\n remove merge-recursive-old\n git-merge: make it usable as the first class UI\n merge: allow merging into a yet-to-be-born branch.\n Store peeled refs in packed-refs (take 2).\n git-fetch: reuse ls-remote result.\n git-fetch: fix dumb protocol transport to fetch from pack-pruned ref\n git-fetch: allow glob pattern in refspec\n Allow git push to delete remote ref.\n git-shortlog: fix common repository prefix abbreviation.\n git-shortlog: make common repository prefix configurable with .mailmap\n git-commit: show --summary after successful commit.\n git-fetch: allow forcing glob pattern in refspec\n fetch-pack: do not barf when duplicate re patterns are given\n git-merge: tighten error checking.\n git-merge: do not leak rev-parse output used for checking internally.\n cvsimport: style fixup.\n git blame -C: fix output format tweaks when crossing file boundary.\n tutorial: talk about user.name early and don't start with commit -a\n git-merge: fix confusion between tag and branch\n xmerge: make return value from xdl_merge() more usable.\n merge-recursive: use xdl_merge().\n receive-pack: do not insist on fast-forward outside refs/heads/\n unpack-trees: make sure \"df_conflict_entry.name\" is NUL terminated.\n read-tree: further loosen \"working file will be lost\" check.\n Loosen \"working file will be lost\" check in Porcelain-ish\n read-tree: document --exclude-per-directory\n git-reset to remove \"$GIT_DIR/MERGE_MSG\"\n git-merge: squelch needless error message.\n git-merge: fix \"fix confusion between tag and branch\" for real\n Fix perl/ build.\n git-rerere: add 'gc' command.\n Documentation/git-commit: rewrite to make it more end-user friendly.\n git-commit: allow --only to lose what was staged earlier.\n shortlog: remove \"[PATCH]\" prefix from shortlog output\n shortlog: fix segfault on empty authorname\n diff --numstat: show binary with '-' to match \"apply --numstat\"\n add test case for recursive merge\n git-push: document removal of remote ref with : pathspec\n git merge: reword failure message.\n spurious .sp in manpages\n git-push: accept tag as advertised.\n send-pack: tighten checks for remote names\n branch --color: change default color selection.\n config documentation: group color items together.\n\n Lars Hjemli (3):\n git-branch: add options and tests for branch renaming\n rename_ref: use lstat(2) when testing for symlink\n git-branch: let caller specify logmsg\n\n Martin Langhoff (1):\n cvsserver: Avoid miscounting bytes in Perl v5.8.x\n\n Michael Loeffler (1):\n git-fetch: ignore dereferenced tags in expand_refs_wildcard\n\n Nicolas Pitre (4):\n builtin git-shortlog is broken\n pack-objects: remove redundent status information\n make 'git add' a first class user friendly interface to the index\n change the unpack limit treshold to a saner value\n\n Paul Mackerras (1):\n gitk: Fix enabling/disabling of menu items on Mac OS X\n\n René Scharfe (1):\n shortlog: remove range check\n\n Robin Rosenberg (1):\n Make cvsexportcommit work with filenames with spaces and non-ascii characters.\n\n Sean Estabrooks (1):\n Update documentation to remove incorrect GIT_DIFF_OPTS example.\n\n Shawn O. Pearce (17):\n Teach git-completion.bash how to complete git-merge.\n Hide plumbing/transport commands from bash completion.\n Teach bash how to complete options for git-name-rev.\n Add current branch in PS1 support to git-completion.bash.\n Teach bash how to complete git-format-patch.\n Teach bash how to complete git-cherry-pick.\n Teach bash how to complete git-rebase.\n Teach bash about git log/show/whatchanged options.\n Support bash completion of refs/remote.\n Teach bash about git-repo-config.\n Support --strategy=x completion in addition to --strategy x.\n Cache the list of merge strategies and available commands during load.\n Teach bash about git-am/git-apply and their whitespace options.\n Teach bash how to complete long options for git-commit.\n Fix broken bash completion of local refs.\n Make sure the empty tree exists when needed in merge-recursive.\n Remove uncontested renamed files during merge.\n\n Uwe Zeisberger (1):\n Fix documentation copy&paste typo\n\n\n"},{"id":"293928","messageId":"200612132237.10051.andyparkins@gmail.com","threadId":"43119","inReplyTo":"7v4przfpir.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-13T22:37:09Z","receivedAt":"2006-12-13T22:37:09Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:\n> I am hoping that we can start a stabilization cycle for v1.5.0\n> based on what we have in 'master'. The theme is \"usability and\n> teachability\".\n\nThis is what I have in my \"niggles\" list. These are surface level things that \nI think are easy to fix. A large part of the scariness is (I think) git's \nunfriendly output. Too many messages require understanding of git internals. \n\nThe major barrier to implementing these sorts of changes is, I think, worries \nabout users of the output of these commands in scripts. I say: screw them, \nporcelain is there for the breaking :-)\n\n * git-fetch has to be in working root. If I can do git-push from anywhere in \n my tree, why can't I do git-fetch?\n * git-reset has to be in working root. If you typically sit in, say \"src/\", \n it's annoying to have to change directory to do a reset.\n * git-commit doesn't (generally) have output - after a commit, it's difficult\n to know if anything happened. Get users used to the idea of hashes to \n identify commits by telling them which one they just made. Tell them if \n they made a branch as well, which branch they are now on.\n * git-init-db says \"defaulting to local storage area\", as if that is\n meant to be a helpful message\n * git-revert should be called git-invert. It doesn't remove a change\n from history, it simply applies another commit that does the\n opposite of whatever commit you are \"revert\"ing. That's an inversion.\n * git-merge output is horrible - this affects git-pull, git-rebase,\n and git-cherry-pick. Issuing \"fatal\" errors and then carrying on is very\n confusing. Errors in merges appear multiple times. The files upon which\n which there is a conflict are spread throughout the output. Most of the\n output is not relevant to an average user.\n * git-apply output is horrible. It says a few things about whitespace on \n stdin then just finishes. When it succeeds. When it fails, it just says\n failed, it doesn't say why a particular hunk failed.\n * git-branch is not verbose enough when creating a new branch, for a new user\n a little reassurance that what they meant to happen has happened would be \n nice.\n * git-commit without \"-a\" and without an \"update-index\" says \"nothing\n to commit\", which isn't an adequate message to help a user who hasn't\n realised they need to update the index\n * git-rebase --skip requires that the offending file be clean with\n git-checkout HEAD file\n before the skip will work. Why? The fact of the skip is enough\n knowledge for rebase to know that I don't care if the merge is lost\n * git-rebase/git-cherry-pick/git-reset/etc should all tell the user that they \n need to run git-prune to tidy up after themselves.\n * git-add has no output, whether it works or not\n * git-cat-file is badly named. git-cat-object would be slightly\n better.\n * git-fetch output is confusing:\n remote: Generating pack...\n remote: Done counting 189146 objects.\n remote: Result has 186566 objects.\n remote: Deltifying 186566 objects.\n remote: 100% (186566/186566) done\n Unpacking 186566 objects\n 24% (44792/186566) done\n Some questions from the point of view of a newbie: what is a pack? what is \n an object? Why is the remote counting them? Which remote am I reading \n from? What am I fetching? What is \"Deltifying\"? How much data do I have \n to download (number of objects doesn't tell me). How long has this taken? \n How long is left to go?\n * Similar things can be said about git-clone\n * Similar things can be said about git-push\n * git-show-branch output is cryptic.\n * In general the principle for messages should be the same as for \n presentations:\n - say what you're going to do\n - do it\n - say what you did\n So for example, \"git-branch newbranch existingbranch\" would say\n Branching at \"existingbranch\", hash XXXXXXXXXXXXXXXXXX\n - created branch \"newbranch\"\n - your working branch is \"existingbranch\"\n Rather than the nothing that it currently outputs.\n * It would be really nice to be able to do an arbitrary checkout, rather than\n having to make a branch for it. Then I could do\n git-checkout remotes/origin/master && make\n (obviously committing with a non-branch HEAD would be prevented)\n * git-verify-tag would be nicer as a switch to git-tag\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"295168","messageId":"elpvro$rvj$1@sea.gmane.org","threadId":"43119","inReplyTo":"200612132237.10051.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-13T22:48:44Z","receivedAt":"2006-12-13T22:48:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> This is what I have in my \"niggles\" list.  These are surface level things that \n> I think are easy to fix.  A large part of the scariness is (I think) git's \n> unfriendly output.  Too many messages require understanding of git internals.\n\nNice list, although I'd rather add extra output only if command is used\nwith -v/--verbose (or -V/--verbose) option; if not, then add -q/--quiet\n(or -s/--silent) option to be used in scripts. I'm partial to --verbose\nsolution, as advanced users are not interested in any output; they know\nthe commands, and want them to be fast. C.f GNU tar: it outputs something\nonly with -v/--verbose option.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295850","messageId":"7vk60vbcfz.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"200612132237.10051.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-13T23:31:12Z","receivedAt":"2006-12-13T23:31:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> The major barrier to implementing these sorts of changes is, I\n> think, worries about users of the output of these commands in\n> scripts. I say: screw them, porcelain is there for the\n> breaking :-)\n\nI like that ;-).\n\nThanks for the list. I'll comment only on no brainers. Things\nI cannot decide to agree or disagree are not mentioned in this\nmessage.\n\n> * git-fetch has to be in working root. If I can do git-push\n> from anywhere in my tree, why can't I do git-fetch?\n> * git-reset has to be in working root. If you typically sit\n> in, say \"src/\", it's annoying to have to change directory to\n> do a reset.\n> * git-verify-tag would be nicer as a switch to git-tag\n\nTrue and true and true; let's make them happen.\n\n> * git-commit doesn't (generally) have output - after a\n> commit, it's difficult to know if anything happened. Get\n> users used to the idea of hashes to identify commits by\n> telling them which one they just made.\n\nI am moderately against making a command verbosely report when\nit did exactly what it was told to do, _unless_ the command is\nexpected to take longer than other commands in git suite, or it\nis something the user rarely runs.\n\n> * git-branch is not verbose enough when creating a new\n> branch, for a new user a little reassurance that what they\n> meant to happen has happened would be nice.\n\nThe same comment applies here. \n\nHowever, perhaps you could make lack of \"[user] expert = true\"\nin ~/.gitconfig to trigger more verbose messages that say \"yes\nsir I did what I was told to do\".\n\nNot interested in implementing that myself at all, though.\n\n> Tell them if they\n> made a branch as well, which branch they are now on.\n\nI think you are talking about \"checkout -b\" not commit here;\nthis might be a borderline (branch creation is less often done\nand it might warrant assuring feedback), but I think it still\nfalls into the \"doing exactly what it was told to do\" category.\n\n> * git-init-db says \"defaulting to local storage area\", as if that is\n> meant to be a helpful message\n\nIt probably used to be back when the original tutorial Linus\nwrote was still called tutorial.txt; but I agree that the\nmessage is not helpful anymore.\n\n> * git-merge output is horrible - this affects git-pull,\n> git-rebase, and git-cherry-pick. Issuing \"fatal\" errors and\n> then carrying on is very confusing. Errors in merges appear\n> multiple times. The files upon which which there is a\n> conflict are spread throughout the output. Most of the\n> output is not relevant to an average user.\n\nYes.\n\n> * git-apply output is horrible. It says a few things about\n> whitespace on stdin then just finishes. When it succeeds.\n> When it fails, it just says failed, it doesn't say why a\n> particular hunk failed.\n\nNo. It either says patch is corrupt, or a hunk at this line\ndoes not apply. I do not see what more would you would want to\nask it to say.\n\n> * git-commit without \"-a\" and without an \"update-index\" says \"nothing\n> to commit\", which isn't an adequate message to help a user who hasn't\n> realised they need to update the index\n\nPerhaps.\n\n\"\\n(hint: 'git add' to stage your changes, or 'git commit --all')\\n\"\nin wt-status.c under \"[user] expert = false\" mode?\n\n> * git-rebase --skip requires that the offending file be clean with\n> git-checkout HEAD file\n> before the skip will work. Why? The fact of the skip is enough\n> knowledge for rebase to know that I don't care if the merge is lost\n\nAs long as your solution does not accidentally lose local,\nunrelated changes, changing \"git-rebase --skip\" to do the needed\nclean-up itself for the user would be Ok (I think we would want\nto loosen the requirement for starting in a totally clean\nworking tree in the future).\n\n> * git-rebase/git-cherry-pick/git-reset/etc should all tell\n> the user that they need to run git-prune to tidy up after\n> themselves.\n\nWhile I agree the users need to be taught about 'prune', I do\nthink immediately after running the above commands is exactly\nthe wrong point to run 'prune'. 'prune' should not be run while\nyou are busily munging the tip of the branch with rebase and\nreset to come up with something that you can call \"oh, I am done\nwith this series for now.\" Otherwise even lost-found would not\nbe able to help you.\n\nAlso, this sequence creates crufts that need to be pruned:\n\n\tedit hello.c\n\tgit add hello.c\n edit hello.c\n git add hello.c\n\nI do not think we would want to suggest 'git prune' upon every\n'git add'.\n\n> * git-add has no output, whether it works or not\n\n\"git add no-such-file\" complains, and I think that is adequate.\nNow with Nico's 'add means adding contents, not path' change is\nin, we _might_ want to differentiate adding a path that was\nuntracked before and updating the contents, but I think this\nagain falls into \"doing exactly as told\" category.\n\n> * git-cat-file is badly named. git-cat-object would be slightly\n> better.\n\nNot a Porcelain.\n\nWe might want to add a pair of built-in internal aliases though:\n\n\t[alias]\n \tcat = cat-file -p\n less = -p cat-file -p\n\nor have these as samples in template .git/config file.\n\n> * In general the principle for messages should be the same as for \n> presentations:\n> - say what you're going to do\n> - do it\n> - say what you did\n> So for example, \"git-branch newbranch existingbranch\" would say\n> Branching at \"existingbranch\", hash XXXXXXXXXXXXXXXXXX\n> - created branch \"newbranch\"\n> - your working branch is \"existingbranch\"\n> Rather than the nothing that it currently outputs.\n\nIn general the principle ought to be not to say anything if the\ncommand does exactly what it was told to do successfully, unless\nthe operation is expected to take longer than other normal\ncommands in the git suite, or something that is rarely used.\n\nPerhaps under \"[user] expert\" control.\n"},{"id":"295659","messageId":"slrneo14if.qkg.Peter.B.Baumann@xp.machine.xx","threadId":"43119","inReplyTo":"7vk60vbcfz.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-12-13T23:52:47Z","receivedAt":"2006-12-13T23:52:47Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":">> * git-branch is not verbose enough when creating a new\n>> branch, for a new user a little reassurance that what they\n>> meant to happen has happened would be nice.\n>\n> The same comment applies here. \n>\n> However, perhaps you could make lack of \"[user] expert = true\"\n> in ~/.gitconfig to trigger more verbose messages that say \"yes\n> sir I did what I was told to do\".\n>\n> Not interested in implementing that myself at all, though.\n>\n>> Tell them if they\n>> made a branch as well, which branch they are now on.\n>\n> I think you are talking about \"checkout -b\" not commit here;\n> this might be a borderline (branch creation is less often done\n> and it might warrant assuring feedback), but I think it still\n> falls into the \"doing exactly what it was told to do\" category.\n>\n\nYes. checkout -b works. But only _if_ you have read the manpage.\nSomeone thinking about branching at the current commit would just have\n\n\tgit branch\n\nin mind (so would I). Its not obvious to say\n\n\tgit checkout -b oldbranch\n\nbecouse checkout implies to advance to another version.\n\n-Peter\n"},{"id":"297596","messageId":"Pine.LNX.4.63.0612140113340.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"7vk60vbcfz.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T00:16:35Z","receivedAt":"2006-12-14T00:16:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Dec 2006, Junio C Hamano wrote:\n\n> Andy Parkins writes:\n> \n> > * git-cat-file is badly named. git-cat-object would be slightly\n> > better.\n> \n> Not a Porcelain.\n> \n> We might want to add a pair of built-in internal aliases though:\n> \n> \t[alias]\n> \tcat = cat-file -p\n> less = -p cat-file -p\n> \n> or have these as samples in template .git/config file.\n\nI sent a patch which makes \"git show\" have that functionality, and \nfrankly, I disagree \"less\" would be a good name for it. It uses the \n_pager_, which is not always \"less\", and besides, what it does is to show \nthat particular blob. So obviously, I think my patch is the best approach.\n\nBTW if you now say \"git show master:README\" it will show _nothing_, not \neven an error message.\n\nCiao,\n"},{"id":"296705","messageId":"Pine.LNX.4.63.0612140116430.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"200612132237.10051.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T00:22:18Z","receivedAt":"2006-12-14T00:22:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Dec 2006, Andy Parkins wrote:\n\n> On Wednesday 2006, December 13 21:35, Junio C Hamano wrote:\n>\n> * git-revert should be called git-invert. It doesn't remove a change\n> from history, it simply applies another commit that does the\n> opposite of whatever commit you are \"revert\"ing. That's an inversion.\n\nNo. An inversion is the _opposite_. Not an undo.\n\nBesides, The fact that revert _adds_ to history is a nice way to \ndocument that you reverted that change. And you can even explain in the \ncommit message, why you did it.\n\n> * git-fetch output is confusing:\n> remote: Generating pack...\n> remote: Done counting 189146 objects.\n> remote: Result has 186566 objects.\n> remote: Deltifying 186566 objects.\n> remote: 100% (186566/186566) done\n> Unpacking 186566 objects\n> 24% (44792/186566) done\n> Some questions from the point of view of a newbie: what is a pack? what is \n> an object? Why is the remote counting them? Which remote am I reading \n> from? What am I fetching? What is \"Deltifying\"? How much data do I have \n> to download (number of objects doesn't tell me). How long has this taken? \n> How long is left to go?\n\nIMHO it is better for a newbie to see that _something_ is happening. A \nnewbie cannot, and does not want to, understand exactly what is going on.\n\nSo, think of it as our response to Windows' non-progress-bar: when you \nstart up Windows, there is a progress-bar, except that it does not show \nprogress, but a Knight Rider like movement, only indicating that it does \nsomething.\n\nCiao,\nDscho\n"},{"id":"298560","messageId":"Pine.LNX.4.64.0612132231050.18171@xanadu.home","threadId":"43119","inReplyTo":"Pine.LNX.4.63.0612140113340.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-14T03:32:52Z","receivedAt":"2006-12-14T03:32:52Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Wed, 13 Dec 2006, Junio C Hamano wrote:\n> \n> > We might want to add a pair of built-in internal aliases though:\n> > \n> > \t[alias]\n> > \tcat = cat-file -p\n> > less = -p cat-file -p\n> > \n> > or have these as samples in template .git/config file.\n> \n> I sent a patch which makes \"git show\" have that functionality, and \n> frankly, I disagree \"less\" would be a good name for it. It uses the \n> _pager_, which is not always \"less\", and besides, what it does is to show \n> that particular blob. So obviously, I think my patch is the best approach.\n\nI think your approach is pretty sensible too.\n\n\n"},{"id":"295947","messageId":"7vy7pb9eit.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612132231050.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T06:29:14Z","receivedAt":"2006-12-14T06:29:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Thu, 14 Dec 2006, Johannes Schindelin wrote:\n>\n>> I sent a patch which makes \"git show\" have that functionality, and \n>> frankly, I disagree \"less\" would be a good name for it. It uses the \n>> _pager_, which is not always \"less\", and besides, what it does is to show \n>> that particular blob. So obviously, I think my patch is the best approach.\n>\n> I think your approach is pretty sensible too.\n\nI think so too for a few reasons.\n\n * cat-file is a very low level plumbing. Giving it -p was a\n mistake made by somebody lazy long time ago back when we were\n not all that hot about \"user friendliness in Porcelain-ish\"\n (the option -p was not originally even meant to be the user\n level; it was merely a helper feature for verify-tag).\n\n * If we were to call something 'cat' and make a user-level\n command, adding the feature to 'show' is a lot more sensible\n than cat-file; the former takes more than one args already.\n People expect 'cat' to concatenate the arguments. cat-file\n doesn't.\n\n * Throwing ls-tree output is the most sensible thing to do at\n 'cat-file -p ' level, but not at the UI level (Andy\n compared ls-tree with 'svn list' today). With 'git show', it\n would be more natural to show ls-tree --name-only by default\n for tree-ish objects, and control the verbosity level with\n command line option.\n\nOne minor issue we may need to decide is what to do when show is\ngiven a tag object. Personally I think the current behaviour of\ndereferencing it to commit is fine (people who want to see the\ntag can always do 'git-verify-tag -v').\n\n\n\n"},{"id":"295987","messageId":"Pine.LNX.4.63.0612140855400.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"7vy7pb9eit.fsf@assigned-by-dhcp.cox.net","subject":"git-show, was Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T07:59:18Z","receivedAt":"2006-12-14T07:59:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Dec 2006, Junio C Hamano wrote:\n\n> One minor issue we may need to decide is what to do when show is\n> given a tag object. Personally I think the current behaviour of\n> dereferencing it to commit is fine (people who want to see the\n> tag can always do 'git-verify-tag -v').\n\nHow about adding the command line option \"--tag\" to git-show, which makes \nit only show that tag. I'd also vote for a \"--verbose|-v\" flag to show the \ncontents of the tag _before_ showing the referenced object.\n\nCiao,\nDscho\n"},{"id":"297878","messageId":"7vbqm6anjz.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"Pine.LNX.4.63.0612140855400.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-show, was Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T08:28:48Z","receivedAt":"2006-12-14T08:28:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Wed, 13 Dec 2006, Junio C Hamano wrote:\n>\n>> One minor issue we may need to decide is what to do when show is\n>> given a tag object. Personally I think the current behaviour of\n>> dereferencing it to commit is fine (people who want to see the\n>> tag can always do 'git-verify-tag -v').\n>\n> How about adding the command line option \"--tag\" to git-show, which makes \n> it only show that tag. I'd also vote for a \"--verbose|-v\" flag to show the \n> contents of the tag _before_ showing the referenced object.\n\nSounds sensible. Please make it so.\n"},{"id":"297901","messageId":"45810B49.2000706@op5.se","threadId":"43119","inReplyTo":"7vk60vbcfz.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-14T08:28:57Z","receivedAt":"2006-12-14T08:28:57Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andy Parkins writes:\n> \n>> * git-add has no output, whether it works or not\n> \n> \"git add no-such-file\" complains, and I think that is adequate.\n> Now with Nico's 'add means adding contents, not path' change is\n> in, we _might_ want to differentiate adding a path that was\n> untracked before and updating the contents, but I think this\n> again falls into \"doing exactly as told\" category.\n> \n\nWell, it should really let the user know if it fails. I for one would \nlike to know that. I wasn't aware of the fact that it was silent even in \nthose situations (perhaps because I've never run across it).\n\nThe errors that need to be reported are, afaics:\nContent in 'path/to/file' is ignored according to path/to/.gitignore.\nSystem error X happened while attempting Y.\nHash collisions.\n\nHash collisions wouldn't be too bad to check for in git add, because it \nonly has to compare a single object, although I agree that it probably \nisn't necessary.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"298244","messageId":"200612140927.27259.andyparkins@gmail.com","threadId":"43119","inReplyTo":"elpvro$rvj$1@sea.gmane.org","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T09:27:25Z","receivedAt":"2006-12-14T09:27:25Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 December 13 22:48, Jakub Narebski wrote:\n\n> Nice list, although I'd rather add extra output only if command is used\n> with -v/--verbose (or -V/--verbose) option; if not, then add -q/--quiet\n> (or -s/--silent) option to be used in scripts. I'm partial to --verbose\n\nI'd rather have the scripts requiring \"--quiet\"; because otherwise it's \nanother switch for a newbie to guess at. However, I don't think that \nswitches is the answer. Output for these porcelain-level commands is not \nstructured enough to be used in scripts anyway (e.g. git-pull), but what it \ndoes output is a confusing lump.\n\n> solution, as advanced users are not interested in any output; they know\n> the commands, and want them to be fast. C.f GNU tar: it outputs something\n> only with -v/--verbose option.\n\ntar is doing a considerably less complicated sequence of operations than many \nof git's commands, so I don't think that's a fair comparison.\n\nAlso; I don't think \"experts\" should care about the extra output - I can't \nimagine that an extra few lines of text is going to slow git down. Further, \nI think the problem in most cases is that git outputs _too much_. Also, I'm \nnot imagining that \"git-add .\" would list every file that it added - who is \nthat going to help? It should say \"added X files to index\" or similar. You \nsurely can't be arguing that that slows down your expert workflow?\n\nI believe that a good set of output will be useful to both newbies and experts \nalike. The idea that experts don't like to know what's going on is simply \nnot true. The idea that newbies want to see every file listed and every \noperation described is simply not true.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"295006","messageId":"20061214093637.GC1747@spearce.org","threadId":"43119","inReplyTo":"200612140927.27259.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-14T09:36:37Z","receivedAt":"2006-12-14T09:36:37Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins wrote:\n> I think the problem in most cases is that git outputs _too much_. Also, I'm \n> not imagining that \"git-add .\" would list every file that it added - who is \n> that going to help? It should say \"added X files to index\" or similar. You \n> surely can't be arguing that that slows down your expert workflow?\n\ngit-commit-tree's \"committing initial tree\" and git-init-db's\n\"defaulting to local storage area\" are both probably too verbose\nand should just get removed.\n\nThe progress meters in git-pack-objects that you see during clone,\nrepack, fetch and push at least keep the user amused. I do read\nthe output of repack every so often, but in general I don't care\nabout the output of clone, fetch or push - all I care about is\nthat my objects got to the remote system and were accepted, or not.\nWhich means that at least for me the output could be reduced down\nto just the bandwidth transfer meter, for really slow links.\n\nBut I'm not sure that git-add should output anything. Last I checked\nthe 'mv' command in Linux doesn't say \"Move 5 files\" when I move 5\nfiles into a directory. Likewise I don't think that knowing that\n6781 files were added is useful, what if it should have really been\n6782 files? I'm unlikely to know, care, or realize it.\n\nYour niggle list (is that what you called it) has been useful\nfodder for discussion. I'm glad you took the time to write it up,\nand to argue it so well on the list. There's a number of items on\nit that I'd like to see happen too; enough that I may code some of\nthem if nobody beats me to it.\n\n-- \n"},{"id":"296394","messageId":"200612140959.19209.andyparkins@gmail.com","threadId":"43119","inReplyTo":"7vk60vbcfz.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T09:59:17Z","receivedAt":"2006-12-14T09:59:17Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 December 13 23:31, Junio C Hamano wrote:\n\n> I am moderately against making a command verbosely report when\n\nI'm not sure \"verbose\" is the word for one extra line of output:\n\n$ git commit\nRevision XXXXXXXXXXXXXXXXXX successfully added.\n\nI'd actually argue that git-commit is a particular problem because it's too \nfast. You quit editing your commit message and bang, you're back at the \ncommand line. Then you run git-log to make sure it really was committed.\n\n> it did exactly what it was told to do, _unless_ the command is\n> expected to take longer than other commands in git suite, or it\n> is something the user rarely runs.\n\nIn the specific case of commit I really think the hash that was added needs to \nbe printed. I often do a series of git-commits on separate files; to find \nout the hash of one of those recent commits I then hop over to qgit to look. \nIf it were right there on my terminal I wouldn't need to have qgit open all \nthe time.\n\n> > * git-branch is not verbose enough when creating a new\n> The same comment applies here.\n\nRight back at you. \"what it was told to do\", is not a clear cut thing. Bear \nin mind that users make mistakes (I certainly do), so what I told it to do \nwas not necessarily what I wanted it to do. With no output to tell me what \nactually happened, it makes it harder to go back and see what you did wrong.\n\n> However, perhaps you could make lack of \"[user] expert = true\"\n> in ~/.gitconfig to trigger more verbose messages that say \"yes\n> sir I did what I was told to do\".\n\nI've always thought that programs that needed an expert/beginner split were \nbadly designed.\n\nI'm not sure you're characterising the messages correctly with \"yes\nsir I did what I was told to do\". That sort of output would truly be useless. \nHowever, going back to my git-commit example, I didn't say \"commit and give \nthis the hash XXXXXXXX\", I said \"commit\". git makes up the hash for me, and \nso should really tell me that hash.\n\n> Not interested in implementing that myself at all, though.\n\nI've gotten a far more positive response than I'd expected, so it doesn't \nsurprise me.\n\n> > Tell them if they\n> > made a branch as well, which branch they are now on.\n>\n> I think you are talking about \"checkout -b\" not commit here;\n> this might be a borderline (branch creation is less often done\n> and it might warrant assuring feedback), but I think it still\n> falls into the \"doing exactly what it was told to do\" category.\n\nYou're right, I was. The reason I think feedback is useful is because of the \ntwo ways of making a new branch:\n - git-branch XYZ\n This makes a new branch but DOESN'T leave me on XYZ\n - git-commit -b XYZ\n This makes a new branch and switches to XYZ\nI can't tell you the number of times I get this wrong. It's not because I \ndon't know if I stop to think, it's because I'm thinking about the project, \nnot the VCS.\n\n> No. It either says patch is corrupt, or a hunk at this line\n> does not apply. I do not see what more would you would want to\n> ask it to say.\n\nI've been building a repository that contains every kernel release since \nv1.0.0; I did it by downloading every patch and \"git-apply\"ing them one at a \ntime. Along the way, I had a few occasions where the patch didn't apply. I \nwould get the \"hunk didn't apply\" message. (e.g. v1.1/patch54.bz2 if you're \ninterested)\n\nNow - it /should/ apply, this is a published patch; I investigated each one, \nand it was always down to a whitespace problem. The current version didn't \nhave the same whitespace as the patch was expecting; often part of a much \nlarger patch which mostly applied. git-apply could have told me...\n\nWhile applying hunk #17, the following update would not apply to the file\nthis/that/theother.c\n-#endif\n+#endif\n\nInstead I had to git-checkout HEAD; bzcat patch | git-apply --reject; \nfind . -name \"*.rej\"; vim; git update-index; blah, blah blah.\n\n> As long as your solution does not accidentally lose local,\n> unrelated changes, changing \"git-rebase --skip\" to do the needed\n> clean-up itself for the user would be Ok (I think we would want\n\nOf course; never discarding data always takes precedence.\n\n> While I agree the users need to be taught about 'prune', I do\n> think immediately after running the above commands is exactly\n> the wrong point to run 'prune'. 'prune' should not be run while\n> you are busily munging the tip of the branch with rebase and\n> reset to come up with something that you can call \"oh, I am done\n> with this series for now.\" Otherwise even lost-found would not\n> be able to help you.\n\nAbsolutely; I wasn't suggesting that the message should say \"now run \ngit-prune\"; otherwise we might as well run git-prune ourselves. I don't \nreally know that the solution is; but I do think we need one.\n\n> In general the principle ought to be not to say anything if the\n> command does exactly what it was told to do successfully, unless\n> the operation is expected to take longer than other normal\n> commands in the git suite, or something that is rarely used.\n\ngit is its own worst enemy here I think. I still have doubts that something \nactually happened when I run commands because they return so quickly.\n\n> Perhaps under \"[user] expert\" control.\n\nI think the problem with that is going to be that there will be disagreement \nabout which commands should output what in which mode. \"I like git-commit to \ntell me what it committed, but don't want git-add to list files\" sorts of \nthing.\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296206","messageId":"200612141003.58418.andyparkins@gmail.com","threadId":"43119","inReplyTo":"20061214093637.GC1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T10:03:57Z","receivedAt":"2006-12-14T10:03:57Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 14 09:36, Shawn Pearce wrote:\n\n> But I'm not sure that git-add should output anything. Last I checked\n> the 'mv' command in Linux doesn't say \"Move 5 files\" when I move 5\n> files into a directory. Likewise I don't think that knowing that\n> 6781 files were added is useful, what if it should have really been\n> 6782 files? I'm unlikely to know, care, or realize it.\n\nThat's a very particular example you've picked out there. Of course the user \nwon't know if it should be 6781 or 6782; they might know if it should have \nbeen 2 or 10 though; 0 or 100. In your example, output like \"about six and a \nhalf thousand\", would probably be perfectly useful, but why not just output \nthe number?\n\n> Your niggle list (is that what you called it) has been useful\n> fodder for discussion. I'm glad you took the time to write it up,\n> and to argue it so well on the list. There's a number of items on\n> it that I'd like to see happen too; enough that I may code some of\n> them if nobody beats me to it.\n\nI'm glad it was useful. I never know how many disclaimers to put on these \nthings. I always feel that every message I write should begin with \"I love \ngit and use it every day, so please don't take this the wrong way, but...\"\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294723","messageId":"200612141021.12637.andyparkins@gmail.com","threadId":"43119","inReplyTo":"Pine.LNX.4.63.0612140116430.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T10:21:11Z","receivedAt":"2006-12-14T10:21:11Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 14 00:22, Johannes Schindelin wrote:\n\n> > * git-revert should be called git-invert. It doesn't remove a change\n> > from history, it simply applies another commit that does the\n> > opposite of whatever commit you are \"revert\"ing. That's an inversion.\n>\n> No. An inversion is the _opposite_. Not an undo.\n\nThat's what I'm saying, we are applying the opposite of the given commit - \nthat commit is being inverted and applied again. It most certainly isn't an \nundo, because the original commit still exists. It's not a reversion \nbecause \"reversion\" is to regress to a previous time or state. In that sense \ngit-revert is not doing what it says on the tin. A revert would be to remove \nall the revisions from now until the specified commit - i.e. what git-reset \nnow does.\n\n(Note: I don't think git-reset should be renamed, as it's possible to use \ngit-reset to move a branch forward as well as backward).\n\n> Besides, The fact that revert _adds_ to history is a nice way to\n> document that you reverted that change. And you can even explain in the\n> commit message, why you did it.\n\nI'm not disputing that the /operation/ is useful, I'm arguing that it is \nincorrectly named.\n\n> IMHO it is better for a newbie to see that _something_ is happening. A\n\nI'm not arguing that we should show nothing; I'm arguing that the something we \ndo show should be more clear than what is now shown. The choice is \ntherefore \"show something confusing\" or \"show something clear\".\n\n> newbie cannot, and does not want to, understand exactly what is going on.\n\n\"newbie\" doesn't mean \"idiot\". Everybody wants to understand what is going \non.\n\n> So, think of it as our response to Windows' non-progress-bar: when you\n> start up Windows, there is a progress-bar, except that it does not show\n> progress, but a Knight Rider like movement, only indicating that it does\n> something.\n\nGiven the choice between nothing and a non-progress \"doing something\" bar, I \nwould of course pick the \"doing something\" bar. However, given the choice \nbetween a \"doing something\" bar and a progress bar, I'd rather have the \nprogress bar.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296089","messageId":"7v7iwu93rv.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"200612140959.19209.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T10:21:24Z","receivedAt":"2006-12-14T10:21:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> $ git commit\n> Revision XXXXXXXXXXXXXXXXXX successfully added.\n>\n> I'd actually argue that git-commit is a particular problem because it's too \n> fast. You quit editing your commit message and bang, you're back at the \n> command line. Then you run git-log to make sure it really was committed.\n\nYou keep repeating that you want to know the object name of the\nnewly created commit. I would very strongly agree with you that\nit would be a fatal UI bug of git-commit if that information\nwere vital for the end user after making each commit.\n\nBut you never communicate with your own git repository using the\nSHA-1 object names when talking about commits you made recently\n(you would have the SHA-1 output from your updated version of\n'git commit' command on the screen or in your scrollbuffer for\nthem -- you would need to refer to commits older than what your\nscrollbuffer has in different way anyway). Git gives branch~\nnotation, and commands like \"git log --pretty=short\" and friends\nwould show them which you can easily cut&paste. When people\ntalk about object names on the mailing list, they do so by\nasking \"git log\" and friends to find them out -- it is pretty\nmuch \"on demand\" type of thing and I do not think continually\nmentioning SHA-1 object names buys us anything.\n\nIn other words, the following transcript would be possible but\nnot realistic:\n\n\t$ git commit\n Revision deadbeef0000 created.\n : now what did I do?\n $ git show deadbeef0000\n : oops, that is wrong\n $ git reset --hard deadbeef0000^\n\nSo I do not think \"git commit\" is a valid example. I also agree\nwith Shawn that \"git add\" that says 6781 files were added is\npointless.\n\n>> However, perhaps you could make lack of \"[user] expert = true\"\n>> in ~/.gitconfig to trigger more verbose messages that say \"yes\n>> sir I did what I was told to do\".\n>\n> I've always thought that programs that needed an expert/beginner split were \n> badly designed.\n\nThere probably is a truth in that. Let's not add verbosity\nunnecessarily.\n\nI agree with you that making some commands with progress\nindication less chatty would be a good clean-up.\n"},{"id":"296467","messageId":"Pine.LNX.4.63.0612141121010.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"7vbqm6anjz.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-show, was Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T10:25:53Z","receivedAt":"2006-12-14T10:25:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Dec 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Hi,\n> >\n> > On Wed, 13 Dec 2006, Junio C Hamano wrote:\n> >\n> >> One minor issue we may need to decide is what to do when show is\n> >> given a tag object. Personally I think the current behaviour of\n> >> dereferencing it to commit is fine (people who want to see the\n> >> tag can always do 'git-verify-tag -v').\n> >\n> > How about adding the command line option \"--tag\" to git-show, which makes \n> > it only show that tag. I'd also vote for a \"--verbose|-v\" flag to show the \n> > contents of the tag _before_ showing the referenced object.\n> \n> Sounds sensible. Please make it so.\n\nActually, I rethought it. A tag _without_ what it tags makes no sense. See \nmy upcoming patch. And git-show really is as Porcelain as it gets, so it \nshould Do What I Mean.\n\nCiao,\nDscho\n"},{"id":"295908","messageId":"Pine.LNX.4.63.0612141147200.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"200612141021.12637.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T10:51:02Z","receivedAt":"2006-12-14T10:51:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Dec 2006, Andy Parkins wrote:\n\n> On Thursday 2006 December 14 00:22, Johannes Schindelin wrote:\n> \n> > > * git-revert should be called git-invert. It doesn't remove a change\n> > > from history, it simply applies another commit that does the\n> > > opposite of whatever commit you are \"revert\"ing. That's an inversion.\n> >\n> > No. An inversion is the _opposite_. Not an undo.\n> \n> That's what I'm saying, we are applying the opposite of the given commit \n> - that commit is being inverted and applied again.\n\nAhh! I get what you are thinking. I was talking about reverting a change \nfrom the _content's viewpoint_. I _never_ want to revert history (I am no \npolitician, you know?)\n\n> > newbie cannot, and does not want to, understand exactly what is going \n> > on.\n> \n> \"newbie\" doesn't mean \"idiot\". Everybody wants to understand what is \n> going on.\n\nI heartly disagree. I saw so many faces _begging_ me to just say _what_ to \ndo, not _why_, and quickly, please.\n\n> > So, think of it as our response to Windows' non-progress-bar: when you \n> > start up Windows, there is a progress-bar, except that it does not \n> > show progress, but a Knight Rider like movement, only indicating that \n> > it does something.\n> \n> Given the choice between nothing and a non-progress \"doing something\" \n> bar, I would of course pick the \"doing something\" bar. However, given \n> the choice between a \"doing something\" bar and a progress bar, I'd \n> rather have the progress bar.\n\nIf I have the choice between a \"doing something\" bar and a Windows \nExplorer \"14 seconds left\" bar showing the same message for two minutes, \nI'd rather have a Mars bar ;-)\n\nCiao,\nDscho\n"},{"id":"294622","messageId":"200612141123.02346.andyparkins@gmail.com","threadId":"43119","inReplyTo":"Pine.LNX.4.63.0612141147200.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T11:23:01Z","receivedAt":"2006-12-14T11:23:01Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 14 10:51, Johannes Schindelin wrote:\n\n> If I have the choice between a \"doing something\" bar and a Windows\n> Explorer \"14 seconds left\" bar showing the same message for two minutes,\n> I'd rather have a Mars bar ;-)\n\nGahhhhhhhhh! Oh how I hate that window.\n\nOn this we can wholeheartedly agree. Unfortunately it's not just windows; \nmost applications that have a progress bar go like this:\n\n0%, ..., 0%,..., 0%,.., 1 , 2, 3, 4, 5, 6, 33%, ..., 33%, ..., 33%, 35, 36, \n85%, ..., 85%, ..., 85%, ..., 99%, 100%, ..., 100%, ... (yes, I'm completely \nfinished, but still working), ... 100%.\n\nI reckon, unless the window with a progress bar in it has an ETA, then the \nprogress should be an ETA itself. If it's not going to monotonically \nincrease, then the \"percentage\" is meaningless.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296941","messageId":"Pine.LNX.4.63.0612141224330.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"200612141123.02346.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T11:27:43Z","receivedAt":"2006-12-14T11:27:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Dec 2006, Andy Parkins wrote:\n\n> On Thursday 2006 December 14 10:51, Johannes Schindelin wrote:\n> \n> > If I have the choice between a \"doing something\" bar and a Windows\n> > Explorer \"14 seconds left\" bar showing the same message for two minutes,\n> > I'd rather have a Mars bar ;-)\n> \n> Gahhhhhhhhh! Oh how I hate that window.\n> \n> On this we can wholeheartedly agree. Unfortunately it's not just windows; \n> most applications that have a progress bar go like this:\n> \n> 0%, ..., 0%,..., 0%,.., 1 , 2, 3, 4, 5, 6, 33%, ..., 33%, ..., 33%, 35, 36, \n> 85%, ..., 85%, ..., 85%, ..., 99%, 100%, ..., 100%, ... (yes, I'm completely \n> finished, but still working), ... 100%.\n> \n> I reckon, unless the window with a progress bar in it has an ETA, then the \n> progress should be an ETA itself. If it's not going to monotonically \n> increase, then the \"percentage\" is meaningless.\n\nAnd now you know one of the reasons we have no true progress bar.\n\nAnother reason is that it would be relatively expensive to calculate, \nsince the total _size_ is not known beforehand (remember, the pack is \ncalculated on the fly).\n\nYet another reason is that all estimates there are unstable by nature: the \nload of the server, the net load, the load of the client, the speed of \npacking and unpacking, and the luck if deltas can be reused, are all \ncontributors to this unstability.\n\nCiao,\nDscho\n"},{"id":"297693","messageId":"200612141136.59041.andyparkins@gmail.com","threadId":"43119","inReplyTo":"7v7iwu93rv.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T11:36:57Z","receivedAt":"2006-12-14T11:36:57Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 14 10:21, Junio C Hamano wrote:\n\n> You keep repeating that you want to know the object name of the\n\nOh dear, you're right; I am terribly repetative. Sorry.\nOh dear, you're right; I am terribly repetative. Sorry.\n\n;-)\n\n> But you never communicate with your own git repository using the\n> SHA-1 object names when talking about commits you made recently\n\nHow's this then:\n\n$ git commit\n$ git commit\n$ git commit\n$ git reset HEAD^^^\n\n\"AGGGHHHHHH! I meant HEAD^^\"\n\nAt this point I start running \"git-prune -n | grep commit\" and some liberal \nuse of git-show to try and find the hash of the object so I can do\n\n$ git reset --hard HASH_OF_OBJECT_I_STUPIDLY_ORPHANED\n\n> So I do not think \"git commit\" is a valid example. I also agree\n> with Shawn that \"git add\" that says 6781 files were added is\n> pointless.\n\nOkay.\n\n> > I've always thought that programs that needed an expert/beginner split\n> > were badly designed.\n>\n> There probably is a truth in that. Let's not add verbosity\n> unnecessarily.\n\nMy habit is always to be overly verbose in program output; however, I realise \nthat not everybody likes that. None of these things cause me any difficulty \nin my use of git. However, my Dad also is an engineer, but he's not so \ncomfortable with VCS; for him almost every part of git is a mystery. \nCommands that run and don't say anything are confusing because he didn't \nreally know what they were /meant/ to do; he's just got a set of recipes that \nhe knows to type. He's probably an extreme case, and not a good model for \ntypical user - on the other hand, I would say that if he can use it, then it \nis officially newbie-friendly. :-)\n\n> I agree with you that making some commands with progress\n> indication less chatty would be a good clean-up.\n\nThese are actually the ones I feel more strongly about. Too much output just \ndrowns out the information that people really need.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294110","messageId":"20061214114546.GI1747@spearce.org","threadId":"43119","inReplyTo":"200612141136.59041.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-14T11:45:46Z","receivedAt":"2006-12-14T11:45:46Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins wrote:\n> How's this then:\n> \n> $ git commit\n> $ git commit\n> $ git commit\n> $ git reset HEAD^^^\n> \n> \"AGGGHHHHHH! I meant HEAD^^\"\n> \n> At this point I start running \"git-prune -n | grep commit\" and some liberal \n> use of git-show to try and find the hash of the object so I can do\n\nAt this point I usually try to politely suggest that users do:\n\n git repo-config --global core.logAllRefUpdates true\n\nand in the future do something like:\n\n> $ git commit # {4}\n> $ git commit # {3}\n> $ git commit # {2}\n> $ git reset HEAD^^^ # {1}\n> \n> \"AGGGHHHHHH! I meant HEAD^^\"\n\n $ git reset HEAD@{4}\n\nshould give you what\n\n $ git reset HEAD^^\n\nwould have given had you not added the extra ^. :-)\n \n-- \n"},{"id":"298536","messageId":"8764ce6654.wl%cworth@cworth.org","threadId":"43119","inReplyTo":"20061214114546.GI1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-14T11:58:31Z","receivedAt":"2006-12-14T11:58:31Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 14 Dec 2006 06:45:46 -0500, Shawn Pearce wrote:\n> At this point I usually try to politely suggest that users do:\n>\n> git repo-config --global core.logAllRefUpdates true\n>\n> and in the future do something like:\n\nThis when-you-first-learn-you-want-them-it's-too-late-to-get-them\naspect of ref logs is really annoying. It sets up an unkind trap for\nusers.\n\nI know several people have suggested they be enabled by\ndefault. What's the status of that suggestion? Rejected? Just\nawaiting a patch?\n\n-Carl\n"},{"id":"295191","messageId":"200612141200.42875.andyparkins@gmail.com","threadId":"43119","inReplyTo":"Pine.LNX.4.63.0612141224330.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T12:00:41Z","receivedAt":"2006-12-14T12:00:41Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 14 11:27, Johannes Schindelin wrote:\n\n> And now you know one of the reasons we have no true progress bar.\n>\n> Another reason is that it would be relatively expensive to calculate,\n> since the total _size_ is not known beforehand (remember, the pack is\n> calculated on the fly).\n\nHmmm; just thinking out loud now... I used to calculate ETA's for simulations \nI ran that had similar problems - i.e. you don't know how long it takes until \nits done (it was with genetic programming function trees, and of course you \ndon't know what operations will be in the next generations tree, so you can't \nestimate a time). I just showed \"something\" by doing a standard: how long \ndid n/N take therefore N will take... then I plotted the error in the ETA \nafter the simulation completed. Interestingly it was always a -exp(-x) \nshape. In other words it got more accurate towards the end (of course); \nwhich is exactly the sort of accuracy you would want. At the beginning you \njust want a broad \"this will take a few hours\" measure. Towards the end, you \nwant to know \"there is 1m50s remaining\".\n\nI wonder if the number of objects is a reasonable measure of progress. Let's \nsay we're transferring 100,000 objects. Let's also say that the average size \nof objects is 100 bytes. Let's finally say that the object sizes are evenly \ndistributed throughout the 100,000 objects. This would mean that the first \n1,000 objects are just as representative as the last 1,000 objects; or any \nother randomly chosen 1,000 objects. In which case, the size of the first \nthousand objects would be approximately one hundredth the size of the total \ntransfer. Volia: an estimate of the total size of the transfer.\n\nObviously this estimate would be continuously updated, and would become more \naccurate as more objects are transferred. The data rate would of course be \nbased on only the previous X objects rather than the total transferred to \ntake account of changing server conditions. From these ETA could be \nestimated.\n\nObviously the ETA is unstable, but it's only for giving users an idea of how \nlong is left; not for strict accounting.\n\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296950","messageId":"20061214120518.GL1747@spearce.org","threadId":"43119","inReplyTo":"8764ce6654.wl%cworth@cworth.org","subject":"Re: What's in git.git (stable)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-14T12:05:18Z","receivedAt":"2006-12-14T12:05:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Carl Worth wrote:\n> This when-you-first-learn-you-want-them-it's-too-late-to-get-them\n> aspect of ref logs is really annoying. It sets up an unkind trap for\n> users.\n\nYes. Which is why its in my ~/.gitconfig. :-(\n \n> I know several people have suggested they be enabled by\n> default. What's the status of that suggestion? Rejected? Just\n> awaiting a patch?\n\nIts been suggested and discussed.\n\nBut the problem raised is that there are many types of repositories,\nand not all should always have reflogs enabled, and its hard to\ntell which one should and which shouldn't by default, and its even\nworse to force it into a user's ~/.gitconfig as then repositories\nwhich should not have reflogs are getting them anyway.\n\n * Normal working repository (wants reflogs);\n * Bare private (backup) repository (wants reflogs);\n * Bare shared repository (probably doesn't want reflogs);\n * Import generated repository (probably doesn't want reflogs);\n\n...\n\nFind a way to make git-init-db know the difference magically and\nyou'll probably see a patch emerge quickly afterwards. But right\nnow I don't think anyone really has a great solution to the problem.\n\nI know Junio wrote something on this not too long ago (and it was a\ngood writeup too) but I can never find threads in gmane's archives,\nso I'm just going to leave that to someone else...\n\n-- \n"},{"id":"295035","messageId":"20061214121048.GM1747@spearce.org","threadId":"43119","inReplyTo":"200612141200.42875.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-14T12:10:48Z","receivedAt":"2006-12-14T12:10:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins wrote:\n> I wonder if the number of objects is a reasonable measure of progress. Let's \n> say we're transferring 100,000 objects. Let's also say that the average size \n> of objects is 100 bytes. Let's finally say that the object sizes are evenly \n> distributed throughout the 100,000 objects. This would mean that the first \n> 1,000 objects are just as representative as the last 1,000 objects; or any \n> other randomly chosen 1,000 objects. In which case, the size of the first \n> thousand objects would be approximately one hundredth the size of the total \n> transfer. Volia: an estimate of the total size of the transfer.\n\nAh, but much like those stock scam emails, \"prior performance does\nnot predict future results\"... The size of objects in the pack\ntends to be small up front (commits/trees) and larger in the back\n(blobs). The size distribution probably also gets more erratic\nnear the back as the blob sizes may not follow a nice distribution.\n\nE.g. I have a repository with a blob that is 23 MiB. But I also\nhave some 5 MiB blobs, and then a very large number of relatively\nsmall blobs. That 23 MiB blob really gums up any estimate.\n\nBut as you state, its easy to refine it over time, and the closer we\nget to the end the more likely it is to be correct. Unless its that\n23 MiB blob. As it takes up about 85% of that repository's pack.\n\n-- \n"},{"id":"295254","messageId":"200612141320.26729.andyparkins@gmail.com","threadId":"43119","inReplyTo":"20061214121048.GM1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T13:20:24Z","receivedAt":"2006-12-14T13:20:24Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 14 12:10, Shawn Pearce wrote:\n\n> not predict future results\"... The size of objects in the pack\n> tends to be small up front (commits/trees) and larger in the back\n> (blobs). The size distribution probably also gets more erratic\n> near the back as the blob sizes may not follow a nice distribution.\n\nOh well; that pretty much settles it then.\n\n> But as you state, its easy to refine it over time, and the closer we\n> get to the end the more likely it is to be correct. Unless its that\n> 23 MiB blob. As it takes up about 85% of that repository's pack.\n\nI had imagined (foolishly), that most objects would be diffs, and would be \nsimilarly sized.\n\nScratch that.\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296466","messageId":"Pine.LNX.4.63.0612141459160.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"20061214120518.GL1747@spearce.org","subject":"reflog by default?, was Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T14:03:36Z","receivedAt":"2006-12-14T14:03:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Dec 2006, Shawn Pearce wrote:\n\n> * Normal working repository (wants reflogs);\n> * Bare private (backup) repository (wants reflogs);\n> * Bare shared repository (probably doesn't want reflogs);\n> * Import generated repository (probably doesn't want reflogs);\n\nIn contrast, I think that reflogs make lots of sense for shared repos, \nand less sense for bare (non-shared) ones...\n\nSo, I'd say: enable reflog by default, unless it is bare _and_ not shared. \nBut then, cmd_init_db() no longer knows if it was called with \"--bare\" or \nnot.\n\nCiao,\nDscho\n"},{"id":"296631","messageId":"Pine.LNX.4.64.0612141205490.18171@xanadu.home","threadId":"43119","inReplyTo":"20061214093637.GC1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-14T17:06:44Z","receivedAt":"2006-12-14T17:06:44Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Shawn Pearce wrote:\n\n> But I'm not sure that git-add should output anything. Last I checked\n> the 'mv' command in Linux doesn't say \"Move 5 files\" when I move 5\n> files into a directory. Likewise I don't think that knowing that\n> 6781 files were added is useful, what if it should have really been\n> 6782 files? I'm unlikely to know, care, or realize it.\n\ngit-add -v does output added files already.\n\n\n"},{"id":"297337","messageId":"Pine.LNX.4.64.0612141221300.18171@xanadu.home","threadId":"43119","inReplyTo":"200612141021.12637.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-14T17:23:45Z","receivedAt":"2006-12-14T17:23:45Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Andy Parkins wrote:\n\n> > Besides, The fact that revert _adds_ to history is a nice way to\n> > document that you reverted that change. And you can even explain in the\n> > commit message, why you did it.\n> \n> I'm not disputing that the /operation/ is useful, I'm arguing that it is \n> incorrectly named.\n\nWell, people are used to say they've \"reverted\" a change. Although the \ncommand might appear slightly misnamed wrt its operation, it still does \nwhat most people are expecting from such a name.\n\n\n"},{"id":"295636","messageId":"Pine.LNX.4.64.0612141245380.18171@xanadu.home","threadId":"43119","inReplyTo":"20061214114546.GI1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-14T17:47:15Z","receivedAt":"2006-12-14T17:47:15Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Shawn Pearce wrote:\n\n> Andy Parkins wrote:\n> > How's this then:\n> > \n> > $ git commit\n> > $ git commit\n> > $ git commit\n> > $ git reset HEAD^^^\n> > \n> > \"AGGGHHHHHH! I meant HEAD^^\"\n> > \n> > At this point I start running \"git-prune -n | grep commit\" and some liberal \n> > use of git-show to try and find the hash of the object so I can do\n> \n> At this point I usually try to politely suggest that users do:\n> \n> git repo-config --global core.logAllRefUpdates true\n> \n\nAnd this is where I politely say that this option should be true by \ndefault for everybody.\n\nI don't recall why it isn't so yet.\n\n\n"},{"id":"294604","messageId":"Pine.LNX.4.64.0612141251520.18171@xanadu.home","threadId":"43119","inReplyTo":"20061214120518.GL1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-14T18:06:18Z","receivedAt":"2006-12-14T18:06:18Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Shawn Pearce wrote:\n\n> But the problem raised is that there are many types of repositories,\n> and not all should always have reflogs enabled, and its hard to\n> tell which one should and which shouldn't by default, and its even\n> worse to force it into a user's ~/.gitconfig as then repositories\n> which should not have reflogs are getting them anyway.\n\nThank you for reminding me the reasons why.\n\nHowever I'd argue that the lack of reflog data is much much worse than \nneedlessly having it.\n\nIt is therefore much saner to disable it in the config and remove the \nunwanted reflog files than being sorry because it wasn't enabled when \nyou would have needed it.\n\n> * Normal working repository (wants reflogs);\n> * Bare private (backup) repository (wants reflogs);\n> * Bare shared repository (probably doesn't want reflogs);\n> * Import generated repository (probably doesn't want reflogs);\n\nAnd what would be the actual problem if reflog was enabled (i.e. was not \nexplicitly disabled if enabled by default) in those last two cases?\n\n> Find a way to make git-init-db know the difference magically and \n> you'll probably see a patch emerge quickly afterwards. But right now \n> I don't think anyone really has a great solution to the problem.\n\nI'd say screw that. The solution should really be this patch:\n\ndiff --git a/environment.c b/environment.c\nindex 84d870c..98275b2 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -15,7 +15,7 @@ int use_legacy_headers = 1;\n int trust_executable_bit = 1;\n int assume_unchanged;\n int prefer_symlink_refs;\n-int log_all_ref_updates;\n+int log_all_ref_updates = 1;\n int warn_ambiguous_refs = 1;\n int repository_format_version;\n char git_commit_encoding[MAX_ENCODING_LENGTH] = \"utf-8\";\n\n> I know Junio wrote something on this not too long ago (and it was a\n> good writeup too) but I can never find threads in gmane's archives,\n> so I'm just going to leave that to someone else...\n\nWell I must have missed it.\n\nBut unless there is real harm to have reflog enabled even when you don't \nneed it I really think the default should be set to enabled.\n\n\n"},{"id":"294557","messageId":"7vy7pa45m8.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612141251520.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T19:52:47Z","receivedAt":"2006-12-14T19:52:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> I'd say screw that. The solution should really be this patch:\n>\n> diff --git a/environment.c b/environment.c\n> index 84d870c..98275b2 100644\n> --- a/environment.c\n> +++ b/environment.c\n> @@ -15,7 +15,7 @@ int use_legacy_headers = 1;\n> int trust_executable_bit = 1;\n> int assume_unchanged;\n> int prefer_symlink_refs;\n> -int log_all_ref_updates;\n> +int log_all_ref_updates = 1;\n> int warn_ambiguous_refs = 1;\n> int repository_format_version;\n> char git_commit_encoding[MAX_ENCODING_LENGTH] = \"utf-8\";\n>\n\nThat changes what the command does to existing repositories,\nwhich is somewhat impolite.\n\nI am not opposed too much to an updated version of the tool that\nsets the configuration on by default for newly created\nrepositories, though.\n\n"},{"id":"298161","messageId":"20061214195803.GA25828@spearce.org","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612141251520.18171@xanadu.home","subject":"[PATCH] Enable reflogs by default in all repositories.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-14T19:58:03Z","receivedAt":"2006-12-14T19:58:03Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"New and experienced Git users alike are finding out too late that\nthey forgot to enable reflogs in the current repository, and cannot\nuse the information stored within it to recover from an incorrectly\nentered command such as `git reset --hard HEAD^^^` when they really\nmeant HEAD^^ (aka HEAD~2).\n\nSo enable reflogs by default in all future versions of Git, unless\nthe user specifically disables it with:\n\n [core]\n logAllRefUpdates = false\n\nin their .git/config or ~/.gitconfig.\n\nDocumentation was also updated to indicate the new default behavior.\nWe probably should start to teach usuing the reflog to recover\nfrom mistakes in some of the tutorial material, as new users are\nlikely to make a few along the way and will feel better knowing\nthey can recover from them quickly and easily, without fsck-objects'\nlost+found features.\n\nSigned-off-by: Shawn O. Pearce \n---\n Documentation/config.txt | 3 ++-\n environment.c | 2 +-\n 2 files changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex a3587f8..e093bcd 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -80,7 +80,8 @@ core.logAllRefUpdates::\n \n \tThis information can be used to determine what commit\n \twas the tip of a branch \"2 days ago\". This value is\n-\tfalse by default (no automated creation of log files).\n+\ttrue by default to activate automated creation of log\n+\tfiles for all branch heads.\n \n core.repositoryFormatVersion::\n \tInternal variable identifying the repository format and layout\ndiff --git a/environment.c b/environment.c\nindex 84d870c..98275b2 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -15,7 +15,7 @@ int use_legacy_headers = 1;\n int trust_executable_bit = 1;\n int assume_unchanged;\n int prefer_symlink_refs;\n-int log_all_ref_updates;\n+int log_all_ref_updates = 1;\n int warn_ambiguous_refs = 1;\n int repository_format_version;\n char git_commit_encoding[MAX_ENCODING_LENGTH] = \"utf-8\";\n-- \n"},{"id":"295918","messageId":"20061214200245.GP1747@spearce.org","threadId":"43119","inReplyTo":"7vy7pa45m8.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-14T20:02:45Z","receivedAt":"2006-12-14T20:02:45Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> \n> > I'd say screw that. The solution should really be this patch:\n> >\n> > diff --git a/environment.c b/environment.c\n> > index 84d870c..98275b2 100644\n> > --- a/environment.c\n> > +++ b/environment.c\n> > @@ -15,7 +15,7 @@ int use_legacy_headers = 1;\n> > int trust_executable_bit = 1;\n> > int assume_unchanged;\n> > int prefer_symlink_refs;\n> > -int log_all_ref_updates;\n> > +int log_all_ref_updates = 1;\n> > int warn_ambiguous_refs = 1;\n> > int repository_format_version;\n> > char git_commit_encoding[MAX_ENCODING_LENGTH] = \"utf-8\";\n> >\n> \n> That changes what the command does to existing repositories,\n> which is somewhat impolite.\n\nYes, but users are forgetting to enable them. They will work in\na new repository having that feature, move to an older one and not\nhave it, but expect it to be there.\n\nAs I recall the primary objection to enabling them by default\nwhen I first introduced them was that core.logAllRefUpdates=true\nmeant that refs/tags/ were also being logged. This was not a\ngreat idea as tags generally did not change once they were created.\nYou fixed that and now it just makes sense to enable it for branch\nheads all of the time.\n\n> I am not opposed too much to an updated version of the tool that\n> sets the configuration on by default for newly created\n> repositories, though.\n\nI almost did that in my patch - but decided against it for the\nreason I just noted above.\n\nDoes anyone on the mailing list really have an objection to having\nreflogs on by default?\n\nAbout the only trouble that can cause is a failed push when\ngit-receive-pack needs to generate the reflog entry but cannot\nget the user's committer data because their gecos information\ndoesn't exist.\n\n-- \n"},{"id":"295401","messageId":"Pine.LNX.4.64.0612141507200.18171@xanadu.home","threadId":"43119","inReplyTo":"7vy7pa45m8.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-14T20:17:19Z","receivedAt":"2006-12-14T20:17:19Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > I'd say screw that. The solution should really be this patch:\n> >\n> > diff --git a/environment.c b/environment.c\n> > index 84d870c..98275b2 100644\n> > --- a/environment.c\n> > +++ b/environment.c\n> > @@ -15,7 +15,7 @@ int use_legacy_headers = 1;\n> > int trust_executable_bit = 1;\n> > int assume_unchanged;\n> > int prefer_symlink_refs;\n> > -int log_all_ref_updates;\n> > +int log_all_ref_updates = 1;\n> > int warn_ambiguous_refs = 1;\n> > int repository_format_version;\n> > char git_commit_encoding[MAX_ENCODING_LENGTH] = \"utf-8\";\n> >\n> \n> That changes what the command does to existing repositories,\n> which is somewhat impolite.\n\nYou must be kidding, aren't you?\n\nJust in case you really are serious, let's pretend that being impolite \nfor something that has the potential of saving people's arses is \ncertainly worth it, much more that the little inconvenience of having \nlog files mysteriously appear and make no harm otherwise.\n\n> I am not opposed too much to an updated version of the tool that\n> sets the configuration on by default for newly created\n> repositories, though.\n\nHmmm....\n\nWell it is just that I strongly believe users with existing repos have \nno really valid reason to not have this feature enabled. But making it \non in a default config file at repo creation time is better than \nnothing.\n\n\n"},{"id":"293973","messageId":"Pine.LNX.4.64.0612141519380.18171@xanadu.home","threadId":"43119","inReplyTo":"20061214200245.GP1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-14T20:22:51Z","receivedAt":"2006-12-14T20:22:51Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Shawn Pearce wrote:\n\n> Junio C Hamano wrote:\n> > That changes what the command does to existing repositories,\n> > which is somewhat impolite.\n> \n> Yes, but users are forgetting to enable them. They will work in\n> a new repository having that feature, move to an older one and not\n> have it, but expect it to be there.\n\nI concur entirely.\n\n> > I am not opposed too much to an updated version of the tool that\n> > sets the configuration on by default for newly created\n> > repositories, though.\n> \n> I almost did that in my patch - but decided against it for the\n> reason I just noted above.\n> \n> Does anyone on the mailing list really have an objection to having\n> reflogs on by default?\n\nI certainly don't.\n\n\n"},{"id":"293873","messageId":"7vtzzy19t9.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612141507200.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T20:50:26Z","receivedAt":"2006-12-14T20:50:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n>> That changes what the command does to existing repositories,\n>> which is somewhat impolite.\n>\n> You must be kidding, aren't you?\n\nI am dead serious. I do not have _any_ issue on existing\nrepositories with a working tree, but I care deeply about public\ndistribution points. See my other message.\n"},{"id":"296910","messageId":"200612142102.45724.andyparkins@gmail.com","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612141221300.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T21:02:42Z","receivedAt":"2006-12-14T21:02:42Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006, December 14 17:23, Nicolas Pitre wrote:\n\n> Well, people are used to say they've \"reverted\" a change. Although the\n> command might appear slightly misnamed wrt its operation, it still does\n> what most people are expecting from such a name.\n\nActually , not only is git-revert misnamed, it doesn't match up with most \nother SCMs.\n\n\"svn revert\" is git-reset.\n\"bzr revert\" is git-reset.\n\"darcs revert\" is git-reset.\n\"hg revert\" is git-reset.\n\"svk revert\" is git-reset.\n\"monotone revert\" is git-reset.\n\nMost people must surely be expecting it to do what it does in every other SCM; \nas it doesn't my argument is that we should just drop the name \"revert\" and \ncall it git-invert instead, which is more accurately named and doesn't \nconflict with the standard meaning.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"295143","messageId":"7vmz5q18cn.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"200612140959.19209.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T21:22:00Z","receivedAt":"2006-12-14T21:22:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n>> > Tell them if they\n>> > made a branch as well, which branch they are now on.\n>>\n>> I think you are talking about \"checkout -b\" not commit here;\n>> this might be a borderline (branch creation is less often done\n>> and it might warrant assuring feedback), but I think it still\n>> falls into the \"doing exactly what it was told to do\" category.\n>\n> You're right, I was. The reason I think feedback is useful is\n> because of the two ways of making a new branch:\n>\n> - git-branch XYZ\n> This makes a new branch but DOESN'T leave me on XYZ\n> - git-commit -b XYZ\n> This makes a new branch and switches to XYZ\n>\n> I can't tell you the number of times I get this wrong. It's not because I \n> don't know if I stop to think, it's because I'm thinking about the project, \n> not the VCS.\n\nThis is interesting. You said \"commit -b\", were pointed out\nthat you were talking about \"checkout -b\", and just after saying\n\"yup, that is right, I was\", you again say \"commit -b\".\n\nMaybe the users often need this sequence (I personally don't,\nbut others might):\n\n\t$ git checkout ;# or the previous day ended with a clean state\n\t$ edit edit hack\n $ git checkout -b XYZ ;# the changes are about different stuff\n $ git commit ;# commit the changes there\n $ git checkout master ;# or whatever branch you usually are on\n\nand \"git commit -b \" might be a handy shortcut for\nthe last three commands. I dunno.\n\nAnd if we had such a variant of commit, then it is doing\nsomething unusual, so I would not oppose (actually I would\nprobably favor) if the transcript went something like this:\n\n\t$ git commit -b XYZ -m \"implement 'foo' subcommand\" -a\n\tcommitted changes to newly created branch XYZ, back on 'master'.\n\t$ git show-branch master XYZ\n * [master] finishing touches to 'hello world'\n ! [XYZ] implement foo subcommand\n --\n + [XYZ] implement foo subcommand\n -- [master] finishing touches to 'hello world'\n\t$ exit\n\nEarlier I said that the command should be silent if it did\nexactly what it was told to do with some 'unless'es.\n\n * If the command fails, we should report (no question).\n\n * If the command succeeds the usual way, staying silent is\n preferable, at least to me.\n\n * If the command can have more than one mode of successful\n outcome, stating success in which way is not a useless\n verbosity. E.g. 'git merge' should probably tell you if it\n did a usual three-way or a fast-forward (if the difference\n matters). Especially reporting an unusual case a bit more\n verbosely than usual is a good thing.\n"},{"id":"295120","messageId":"4581C83A.10907@op5.se","threadId":"43119","inReplyTo":"20061214200245.GP1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-14T21:55:06Z","receivedAt":"2006-12-14T21:55:06Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn Pearce wrote:\n> \n> About the only trouble that can cause is a failed push when\n> git-receive-pack needs to generate the reflog entry but cannot\n> get the user's committer data because their gecos information\n> doesn't exist.\n> \n\nIn that case, it would be best if it let the commit go through using \nonly the username. Reflogs are fixable afterwards, so there's no real \nharm done.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"296238","messageId":"7v4pry16n5.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"20061214114546.GI1747@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T21:58:54Z","receivedAt":"2006-12-14T21:58:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Andy Parkins wrote:\n>> How's this then:\n>> \n>> $ git commit\n>> $ git commit\n>> $ git commit\n>> $ git reset HEAD^^^\n>> \n>> \"AGGGHHHHHH! I meant HEAD^^\"\n>> \n>> At this point I start running \"git-prune -n | grep commit\" and some liberal \n>> use of git-show to try and find the hash of the object so I can do\n>\n> At this point I usually try to politely suggest that users do:\n>\n> git repo-config --global core.logAllRefUpdates true\n>\n> and in the future do something like:\n>\n>> $ git commit # {4}\n>> $ git commit # {3}\n>> $ git commit # {2}\n>> $ git reset HEAD^^^ # {1}\n>> \n>> \"AGGGHHHHHH! I meant HEAD^^\"\n>\n> $ git reset HEAD@{4}\n>\n> should give you what\n>\n> $ git reset HEAD^^\n>\n> would have given had you not added the extra ^. :-)\n\nCorrect but a bad example that does not demonstrate the real\npower of reflog. Andy's AGGGHHHHHH can be recovered with a\nsimple:\n\n\t$ git reset ORIG_HEAD\n\nThe real beauty of reflog is that you can usually count number\nof commands (not just commit) the way you did and recover with\nthe @{n} syntax. With one caveat -- a porcelain might implement\nwhat it does as more than one transaction on the ref, in which\ncase counting commands does not help. You need to first make\nsure the value of n in @{n} you thought is appropriate is really\nthe one you want; you would always run \"git show -s HEAD@{4}\"\nbefore doing the recovering reset in practice, in other words.\n\nAnd it is not very easy to view where ref was in each step with\nexisting set of tools.\n\nNot until the attached patch, which was very lightly tested.\nYou would use it like this:\n\n $ git-show-branch --reflog next\n ! [next@{0}] Merge branch 'js/show' into next\n ! [next@{1}] Merge branch 'jc/cdup' into next\n ! [next@{2}] Merge branch 'master' into next\n ! [next@{3}] Merge branch 'jc/cdup' into next\n ----\n - [next@{0}] Merge branch 'js/show' into next\n + [next@{0}^2] git-show: grok blobs, trees and tags, too\n -- [next@{1}] Merge branch 'jc/cdup' into next\n ++ [next@{1}^2] git-reset [--mixed] [--] ...\n ++ [next@{1}^2^] git-reset: make it work from within a subdirectory.\n ++ [next@{1}^2~2] git-fetch: make it work from within a subdirectory.\n ++ [next@{0}^2^] INSTALL: no need to have GNU diff installed\n -- [next@{0}^2~2] Merge branch 'maint'\n ++ [next@{0}^2~2^2] Bypass expensive content comparsion during...\n - [next@{3}] Merge branch 'jc/cdup' into next\n + [next@{3}^2] git-reset [--mixed] [--] ...\n + [next@{3}^2^] git-reset: make it work from within a subdirectory.\n + [next@{3}^2~2] git-fetch: make it work from within a subdirectory.\n + [next@{3}^2~3] Bypass expensive content comparsion during re...\n ++ + [next@{0}^2~3] Update git-diff documentation\n -- - [next@{0}^2~4] Merge branch 'jc/diff--cached'\n ++ + [next@{0}^2~5] git-svn: allow both diff.color and color.diff\n ++ + [next@{0}^2~6] repacked packs should be read-only\n ---- [next@{2}] Merge branch 'master' into next\n\nThis shows the actual reflog from the 'next' branch on my\nprimary repository. It shows that I did a merge of jc/cdup\nbranch into 'next' to run tests at next@{3}, but later rewound\nthat merge at next@{2} and merged the rebased jc/cdup again\nlater at next@{1} [*1*]. \n\n\n[Footnote]\n\n*1* Of course, I did all of the above rewinding and rebasing\nbefore pushing the result out, so the general public do not have\nto worry about rewinding and rebasing.\n\n\n---\n\ndiff --git a/builtin-show-branch.c b/builtin-show-branch.c\nindex fb1a400..559bb18 100644\n--- a/builtin-show-branch.c\n+++ b/builtin-show-branch.c\n@@ -6,7 +6,7 @@\n #include \"builtin.h\"\n \n static const char show_branch_usage[] =\n-\"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [...]\";\n+\"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [...] | --reflog[=n] \";\n \n static int default_num;\n static int default_alloc;\n@@ -17,6 +17,8 @@ static const char **default_arg;\n #define REV_SHIFT\t 2\n #define MAX_REVS\t(FLAG_BITS - REV_SHIFT) /* should not exceed bits_per_int - REV_SHIFT */\n \n+#define DEFAULT_REFLOG\t4\n+\n static struct commit *interesting(struct commit_list *list)\n {\n \twhile (list) {\n@@ -570,6 +572,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)\n \tint head_at = -1;\n \tint topics = 0;\n \tint dense = 1;\n+\tint reflog = 0;\n \n \tgit_config(git_show_branch_config);\n \n@@ -615,6 +618,15 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)\n \t\t\tdense = 0;\n \t\telse if (!strcmp(arg, \"--date-order\"))\n \t\t\tlifo = 0;\n+\t\telse if (!strcmp(arg, \"--reflog\")) {\n+\t\t\treflog = DEFAULT_REFLOG;\n+\t\t}\n+\t\telse if (!strncmp(arg, \"--reflog=\", 9)) {\n+\t\t\tchar *end;\n+\t\t\treflog = strtoul(arg + 9, &end, 10);\n+\t\t\tif (*end != '\\0')\n+\t\t\t\tdie(\"unrecognized reflog count '%s'\", arg + 9);\n+\t\t}\n \t\telse\n \t\t\tusage(show_branch_usage);\n \t\tac--; av++;\n@@ -622,7 +634,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)\n \tac--; av++;\n \n \t/* Only one of these is allowed */\n-\tif (1 < independent + merge_base + (extra != 0))\n+\tif (1 < independent + merge_base + (extra != 0) + (!!reflog))\n \t\tusage(show_branch_usage);\n \n \t/* If nothing is specified, show all branches by default */\n@@ -631,9 +643,22 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)\n \n \tif (all_heads + all_tags)\n \t\tsnarf_refs(all_heads, all_tags);\n-\twhile (0 < ac) {\n-\t\tappend_one_rev(*av);\n-\t\tac--; av++;\n+\tif (reflog) {\n+\t\tint reflen;\n+\t\tif (!ac)\n+\t\t\tdie(\"--reflog option needs one branch name\");\n+\t\treflen = strlen(*av);\n+\t\tfor (i = 0; i < reflog; i++) {\n+\t\t\tchar *name = xmalloc(reflen + 20);\n+\t\t\tsprintf(name, \"%s@{%d}\", *av, i);\n+\t\t\tappend_one_rev(name);\n+\t\t}\n+\t}\n+\telse {\n+\t\twhile (0 < ac) {\n+\t\t\tappend_one_rev(*av);\n+\t\t\tac--; av++;\n+\t\t}\n \t}\n \n \thead_p = resolve_ref(\"HEAD\", head_sha1, 1, NULL);\n\n\n\n\n"},{"id":"294997","messageId":"200612142250.27766.andyparkins@gmail.com","threadId":"43119","inReplyTo":"7v4pry16n5.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T22:50:26Z","receivedAt":"2006-12-14T22:50:26Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006, December 14 21:58, Junio C Hamano wrote:\n\n> Correct but a bad example that does not demonstrate the real\n> power of reflog. Andy's AGGGHHHHHH can be recovered with a\n> simple:\n>\n> \t$ git reset ORIG_HEAD\n\nHAHA! I knew reading this mailing list would pay off.\n\nIt amazes me that there is always an answer. It's almost becoming a \npantomime - I say \"well git can't do this\", and you say \"oh yes it can\".\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"297056","messageId":"200612142255.33564.andyparkins@gmail.com","threadId":"43119","inReplyTo":"7vmz5q18cn.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T22:55:32Z","receivedAt":"2006-12-14T22:55:32Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006, December 14 21:22, Junio C Hamano wrote:\n\n> This is interesting. You said \"commit -b\", were pointed out\n> that you were talking about \"checkout -b\", and just after saying\n> \"yup, that is right, I was\", you again say \"commit -b\".\n\nThere truly is something wrong with me. Is there some sort of record for \nnumber of mistakes made in one thread? Have I won yet?\n\nI'm not sure about your \"commit -b\"; is it wise to have /another/ way of \nmaking a branch? I mean - I'm clearly confused enough, have a heart :-)\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"295904","messageId":"20061214230307.GE26202@spearce.org","threadId":"43119","inReplyTo":"200612132237.10051.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-14T23:03:07Z","receivedAt":"2006-12-14T23:03:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins wrote:\n> * git-show-branch output is cryptic.\n\nAgreed. I still don't know how to read its output. So I just\ndon't use it. Ever. :-)\n\n-- \n"},{"id":"295045","messageId":"7vk60uyrau.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"200612142255.33564.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T23:46:17Z","receivedAt":"2006-12-14T23:46:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:\n>\n>> This is interesting. You said \"commit -b\", were pointed out\n>> that you were talking about \"checkout -b\", and just after saying\n>> \"yup, that is right, I was\", you again say \"commit -b\".\n>\n> There truly is something wrong with me.\n\nI did not mean it that way. I only took it as a sign that maybe\n\"first create and switch to a branch and then work and commit\nthere, in separate steps\", which is how git encourages things to\nbe done, does not match people's mental model so well.\n\n> I'm not sure about your \"commit -b\"; is it wise to have /another/ way of \n> making a branch? I mean - I'm clearly confused enough, have a heart :-)\n\nI said \"commit -b \" and deliberately avoided saying\n\"commit -b \", because I did not want to open another\ncan of worms while we are discussing so many good things\nalready, and my head can hold only a handful topics at once.\n\nBut people on the list (and #git channel) sometimes wished an\neasy way to help the following workflow.\n\n * I am in the middle of working on a new feature. As a good\n git user, I am on a topic branch dedicated for that purpose.\n\n * While working on it, I find an obvious bug that I would not\n want to fix on the branch (the topic branch I am currently on\n is not about fixing that bug).\n\n * But I fix it in the working tree anyway, because otherwise I\n would forget. It happens to be in an isolated file that my\n current topic does not need to modify (say, I was looking at\n a function in that file that my new feature needs to call and\n I wanted to study its calling convention. And I found a typo in\n the comment near the function).\n\n * The fix does not belong to the current topic, but can go to\n the 'master' branch straight. It's a fix in the comment that\n cannot possibly break things, and I can/will test it later\n anyway.\n\n * So with the existing set of tools, I would go there, commit\n and then come back:\n\n\t$ git checkout [-m] master\n $ git commit -m 'fix typo in that-file' that-file\n $ git checkout [-m] topic\n\n But it might be faster to say:\n\n \t$ git commit -b master -m 'fix typo in that-file' that-file\n\n to make a commit on the other branch and come back\n immediately afterwards.\n\n * In the same situation, when the 'master' is closed for some\n administrative reason (e.g. \"deep freeze before a release and\n strict bugfixes and nothing else are allowed\"), I would create\n a new 'typofix' branch and do the same. I can rebase it\n later on 'master' when it reopens.\n\n\t$ git commit -b typofix -m 'fix typo in that-file' that-file\n\n\t... much later when master reopens ...\n $ git rebase --onto master topic typofix\n\nIt's just a possible typesaver, but I am likely not using it\nmyself (my fingers are already trained to do the three command\nsequence dance).\n\nI do agree that it adds one more way to do the same thing and\nwould make the documentation noisier, potentially adding more to\nthe confusion. So let's not go there.\n\n"},{"id":"297041","messageId":"Pine.LNX.4.63.0612150051290.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"200612142255.33564.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T23:53:47Z","receivedAt":"2006-12-14T23:53:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Dec 2006, Andy Parkins wrote:\n\n> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:\n> \n> > This is interesting. You said \"commit -b\", were pointed out\n> > that you were talking about \"checkout -b\", and just after saying\n> > \"yup, that is right, I was\", you again say \"commit -b\".\n> \n> There truly is something wrong with me. Is there some sort of record \n> for number of mistakes made in one thread? Have I won yet?\n\nHonestly, I do not see anything you have done wrong. After all, a good \nidea came from it.\n\n> I'm not sure about your \"commit -b\"; is it wise to have /another/ way of \n> making a branch? I mean - I'm clearly confused enough, have a heart :-)\n\nI actually would _love_ that feature. Yeah, it's possible with existing \ngit commands, but it would be _convenient_.\n\nCiao,\nDscho\n"},{"id":"297402","messageId":"Pine.LNX.4.64.0612141343200.18171@xanadu.home","threadId":"43119","inReplyTo":"7v7iwu93rv.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-15T04:07:03Z","receivedAt":"2006-12-15T04:07:03Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Junio C Hamano wrote:\n\n> Andy Parkins writes:\n> \n> > $ git commit\n> > Revision XXXXXXXXXXXXXXXXXX successfully added.\n> >\n> > I'd actually argue that git-commit is a particular problem because it's too \n> > fast. You quit editing your commit message and bang, you're back at the \n> > command line. Then you run git-log to make sure it really was committed.\n> \n> You keep repeating that you want to know the object name of the\n> newly created commit. I would very strongly agree with you that\n> it would be a fatal UI bug of git-commit if that information\n> were vital for the end user after making each commit.\n\nI think this is not the point.\n\nOf course the name of the newly created commit isn't _that_ important.\n\nBut so is the \"Committing initial tree 5220388...\" message.\n\nAnd in the commit case, you are left with a blank screen and just a \nshell prompt after you quit the text editor for the log message, which \nis a bit worrisome. My initial reflex is not to think \"ah it just did \nwhat I asked it\" but rather \"hmmm has it just crashed on me?\"\n\nHaving a single line of feedback when a commit has completed would not \nbe overly verbose and remove that impression of committing into a \nvoid I'd think.\n\nNote that, as I said in another thread, I'm really not advocating for \ngit-add to do the same. The git-add is a relatively simple and \nlightweight operation that has not the same impact as a commit has \n_conceptually_. It doesn't clear the screen for one thing so just \nreturning to the shell prompt (unless -v is used) is plenty sufficient.\n\nI'm following up with a patch to implement what I think should be done.\n\n\n"},{"id":"298599","messageId":"Pine.LNX.4.64.0612142307160.18171@xanadu.home","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612141343200.18171@xanadu.home","subject":"[PATCH] make commit message a little more consistent and conforting","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-15T04:15:44Z","receivedAt":"2006-12-15T04:15:44Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"It is nicer to let the user know when a commit succeeded all the time, \nnot only the first time. Also the commit sha1 is much more useful than \nthe tree sha1 in this case.\n\nThis patch also introduces a -q switch to supress this message as well \nas the summary of created/deleted files.\n\nSigned-off-by: Nicolas Pitre \n\n---\n\ndiff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt\nindex 47505aa..1c31159 100644\n--- a/Documentation/core-tutorial.txt\n+++ b/Documentation/core-tutorial.txt\n@@ -336,17 +336,9 @@ $ commit=$(echo 'Initial commit' | git-commit-tree $tree)\n $ git-update-ref HEAD $commit\n ------------------------------------------------\n \n-which will say:\n-\n-----------------\n-Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb\n-----------------\n-\n-just to warn you about the fact that it created a totally new commit\n-that is not related to anything else. Normally you do this only *once*\n-for a project ever, and all later commits will be parented on top of an\n-earlier commit, and you'll never see this \"Committing initial tree\"\n-message ever again.\n+In this case this creates a totally new commit that is not related to\n+anything else. Normally you do this only *once* for a project ever, and\n+all later commits will be parented on top of an earlier commit.\n \n Again, normally you'd never actually do this by hand. There is a\n helpful script called `git commit` that will do all of this for you. So\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 97d66ef..0b74cd7 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -113,6 +113,9 @@ but can be used to amend a merge commit.\n \tas well. This is usually not what you want unless you\n \tare concluding a conflicted merge.\n \n+-q|--quiet::\n+\tSupress commit summary message.\n+\n \\--::\n \tDo not interpret any more arguments as options.\n \ndiff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt\nindex 6389de5..8606381 100644\n--- a/Documentation/tutorial-2.txt\n+++ b/Documentation/tutorial-2.txt\n@@ -22,14 +22,14 @@ defaulting to local storage area\n $ echo 'hello world' > file.txt\n $ git add .\n $ git commit -a -m \"initial commit\"\n-Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe\n+Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7\n create mode 100644 file.txt\n $ echo 'hello world!' >file.txt\n $ git commit -a -m \"add emphasis\"\n+Created commit c4d59f390b9cfd4318117afde11d601c1085f241\n ------------------------------------------------\n \n-What are the 40 digits of hex that git responded to the first commit\n-with?\n+What are the 40 digits of hex that git responded to the commit with?\n \n We saw in part one of the tutorial that commits have names like this.\n It turns out that every object in the git history is stored under\n@@ -39,13 +39,25 @@ the same data twice (since identical data is given an identical SHA1\n name), and that the contents of a git object will never change (since\n that would change the object's name as well).\n \n+It is expected that the content of the commit object you created while\n+following the example above generates a different SHA1 hash than\n+the one shown above because the commit object records the time when\n+it was created and the name of the person performing the commit.\n+\n We can ask git about this particular object with the cat-file\n-command--just cut-and-paste from the reply to the initial commit, to\n-save yourself typing all 40 hex digits:\n+command. Don't copy the 40 hex digits from this example but use those\n+from your own version. Note that you can shorten it to only a few\n+characters to save yourself typing all 40 hex digits:\n \n ------------------------------------------------\n-$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe\n-tree\n+$ git-cat-file -t 54196cc2\n+commit\n+$ git-cat-file commit 54196cc2\n+tree 92b8b694ffb1675e5975148e1121810081dbdffe\n+author J. Bruce Fields 1143414668 -0500\n+committer J. Bruce Fields 1143414668 -0500\n+\n+initial commit\n ------------------------------------------------\n \n A tree can refer to one or more \"blob\" objects, each corresponding to\n@@ -102,8 +114,7 @@ $ find .git/objects/\n \n and the contents of these files is just the compressed data plus a\n header identifying their length and their type. The type is either a\n-blob, a tree, a commit, or a tag. We've seen a blob and a tree now,\n-so next we should look at a commit.\n+blob, a tree, a commit, or a tag.\n \n The simplest commit to find is the HEAD commit, which we can find\n from .git/HEAD:\ndiff --git a/builtin-commit-tree.c b/builtin-commit-tree.c\nindex e2e690a..856f3cd 100644\n--- a/builtin-commit-tree.c\n+++ b/builtin-commit-tree.c\n@@ -107,8 +107,6 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)\n \t\tif (new_parent(parents))\n \t\t\tparents++;\n \t}\n-\tif (!parents)\n-\t\tfprintf(stderr, \"Committing initial tree %s\\n\", argv[1]);\n \n \tinit_buffer(&buffer, &size);\n \tadd_buffer(&buffer, &size, \"tree %s\\n\", sha1_to_hex(tree_sha1));\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 05828bb..395bcd2 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -80,6 +80,7 @@ no_edit=\n log_given=\n log_message=\n verify=t\n+quiet=\n verbose=\n signoff=\n force_author=\n@@ -241,6 +242,10 @@ $1\"\n \t\tsignoff=t\n \t\tshift\n \t\t;;\n+\t-q|--q|--qu|--qui|--quie|--quiet)\n+\t\tquiet=t\n+\t\tshift\n+\t\t;;\n \t-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)\n \t\tverbose=t\n \t\tshift\n@@ -615,11 +620,17 @@ then\n \tgit-rerere\n fi\n \n-if test -x \"$GIT_DIR\"/hooks/post-commit && test \"$ret\" = 0\n+if test \"$ret\" = 0\n then\n-\t\"$GIT_DIR\"/hooks/post-commit\n+\tif test -x \"$GIT_DIR\"/hooks/post-commit \n+\tthen\n+\t\t\"$GIT_DIR\"/hooks/post-commit\n+\tfi\n+\tif test -z \"$quiet\"\n+\tthen\n+\t\techo \"Created${initial_commit:+ initial} commit $commit\"\n+\t\tgit-diff-tree --summary --root --no-commit-id HEAD\n+\tfi\n fi\n \n-test \"$ret\" = 0 && git-diff-tree --summary --root --no-commit-id HEAD\n-\n"},{"id":"296368","messageId":"20061215042459.GC27343@spearce.org","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612142307160.18171@xanadu.home","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-15T04:24:59Z","receivedAt":"2006-12-15T04:24:59Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> It is nicer to let the user know when a commit succeeded all the time, \n> not only the first time. Also the commit sha1 is much more useful than \n> the tree sha1 in this case.\n\nI agree the commit sha1 is more useful than the tree sha1, but I'm\nnot really sure its useful to show the commit sha1 post commit.\nIf you want to show something the diffstat like what git merge does\nis better.\n\nFor one thing it confirms that git accepted the changes. For another\nit shows you *which* changes it accepted. Plus it responds just\nlike git-merge or git-pull does.\n\nOf course the meaning of the diffstat is entirely different in both\ncases; in the commit case its what has been recorded while in the\nmerge case its not only what has been recorded into your current\nbranch history but also what has been done to your working directory.\n\n-- \n"},{"id":"295661","messageId":"45825E0B.5010200@op5.se","threadId":"43119","inReplyTo":"20061215042459.GC27343@spearce.org","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-15T08:34:19Z","receivedAt":"2006-12-15T08:34:19Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn Pearce wrote:\n> Nicolas Pitre wrote:\n>> It is nicer to let the user know when a commit succeeded all the time, \n>> not only the first time. Also the commit sha1 is much more useful than \n>> the tree sha1 in this case.\n> \n> I agree the commit sha1 is more useful than the tree sha1, but I'm\n> not really sure its useful to show the commit sha1 post commit.\n> If you want to show something the diffstat like what git merge does\n> is better.\n> \n\ndiffstats can be huge though. I'd rather have those only with -v option.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294899","messageId":"200612150858.25988.andyparkins@gmail.com","threadId":"43119","inReplyTo":"7vk60uyrau.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-15T08:58:24Z","receivedAt":"2006-12-15T08:58:24Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 14 23:46, Junio C Hamano wrote:\n\n> > There truly is something wrong with me.\n>\n> I did not mean it that way. I only took it as a sign that maybe\n\nDon't worry; I've got thicker skin than that. I was simply amazed at my lack \nof comprehension ability. :-)\n\n> > I'm not sure about your \"commit -b\"; is it wise to have /another/ way of\n> > making a branch? I mean - I'm clearly confused enough, have a heart :-)\n>\n> I said \"commit -b \" and deliberately avoided saying\n> \"commit -b \", because I did not want to open another\n> can of worms while we are discussing so many good things\n> already, and my head can hold only a handful topics at once.\n\nAbsolutely. I'd agree that only is worth even considering.\n\n> * While working on it, I find an obvious bug that I would not\n> want to fix on the branch (the topic branch I am currently on\n> is not about fixing that bug).\n\nI find myself swayed by this. This is indeed something that happens to me a \nlot. In certain circumstances I've been defeated by git because I couldn't \nswitch to the other branch to make that quick commit because my local changes \nconflicted with that other branch. The solution I use is to commit the bug \nfix in the wrong branch, finish my current on-topic commit then \nrebase/reset/etc to put everything where it should be.\n\n> I do agree that it adds one more way to do the same thing and\n> would make the documentation noisier, potentially adding more to\n> the confusion. So let's not go there.\n\nYep. Although you've persuaded me with the above example, I think this is the \ncorrect path. It's not wise to add every bell and whistle just because we \ncan. As long as there is /a/ way to achieve every task, that's good enough, \nwe don't need every way to achieve every task. We might even argue that \ngit's flexibility is what makes it harder to learn. It's similar to UNIX in \nthat respect - hard to learn, easy to use.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"298581","messageId":"002401c7202f$34f2af20$0b0aa8c0@abf.local","threadId":"43119","inReplyTo":"200612150858.25988.andyparkins@gmail.com","subject":"RE: What's in git.git (stable)","fromName":"Raimund Bauer","fromEmail":"ray@softwarelandschaft.com","sentAt":"2006-12-15T09:55:51Z","receivedAt":"2006-12-15T09:55:51Z","isPatch":false,"sender":{"key":"ray@softwarelandschaft.com","avatar":null},"body":"> Yep. Although you've persuaded me with the above example, I \n> think this is the \n> correct path. It's not wise to add every bell and whistle \n> just because we \n> can. As long as there is /a/ way to achieve every task, \n> that's good enough, \n> we don't need every way to achieve every task. We might even \n> argue that \n> git's flexibility is what makes it harder to learn. It's \n> similar to UNIX in \n> that respect - hard to learn, easy to use.\n\nSo we prefer to tell users \"You can do what you want with these 3 commands,\nsince we don't want to confuse use with another option to do it with just\n1\"?\n\n> Andy\n\n-- \nbest regards\n\n Ray\n"},{"id":"295782","messageId":"elub92$v7q$4@sea.gmane.org","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612141205490.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T14:28:09Z","receivedAt":"2006-12-15T14:28:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> On Thu, 14 Dec 2006, Shawn Pearce wrote:\n> \n>> But I'm not sure that git-add should output anything. Last I checked\n>> the 'mv' command in Linux doesn't say \"Move 5 files\" when I move 5\n>> files into a directory. Likewise I don't think that knowing that\n>> 6781 files were added is useful, what if it should have really been\n>> 6782 files? I'm unlikely to know, care, or realize it.\n> \n> git-add -v does output added files already.\n\nHa! Now only get it to accept --verbose as long alternative to -v option,\nand add -v/--verbose option to other similar commands (git-mv for example).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297100","messageId":"elubv2$6ag$1@sea.gmane.org","threadId":"43119","inReplyTo":"45810B49.2000706@op5.se","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T14:39:53Z","receivedAt":"2006-12-15T14:39:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n> Junio C Hamano wrote:\n>> Andy Parkins writes:\n>> \n>>> * git-add has no output, whether it works or not\n>> \n>> \"git add no-such-file\" complains, and I think that is adequate.\n>> Now with Nico's 'add means adding contents, not path' change is\n>> in, we _might_ want to differentiate adding a path that was\n>> untracked before and updating the contents, but I think this\n>> again falls into \"doing exactly as told\" category.\n>> \n> \n> Well, it should really let the user know if it fails. I for one would \n> like to know that. I wasn't aware of the fact that it was silent even in \n> those situations (perhaps because I've never run across it).\n> \n> The errors that need to be reported are, afaics:\n> Content in 'path/to/file' is ignored according to path/to/.gitignore.\n\nThis is not an error, just a warning. Sometimes user want's to add a file\nwhich is otherwise ignored (e.g. due to glob), sometimes user adds ignored\nfile by mistake.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294197","messageId":"20061215150909.GE17860@spearce.org","threadId":"43119","inReplyTo":"45825E0B.5010200@op5.se","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-15T15:09:09Z","receivedAt":"2006-12-15T15:09:09Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andreas Ericsson wrote:\n> Shawn Pearce wrote:\n> >Nicolas Pitre wrote:\n> >>It is nicer to let the user know when a commit succeeded all the time, \n> >>not only the first time. Also the commit sha1 is much more useful than \n> >>the tree sha1 in this case.\n> >\n> >I agree the commit sha1 is more useful than the tree sha1, but I'm\n> >not really sure its useful to show the commit sha1 post commit.\n> >If you want to show something the diffstat like what git merge does\n> >is better.\n> >\n> \n> diffstats can be huge though. I'd rather have those only with -v option.\n\nBut they are on by default for pull/merge, and disabled by -n.\n\nThey are on to tell you what you just got during the pull/merge.\nIf we want commit to confirm it did something successfully, I think\nhaving it confirm what it committed by way of diffstat makes a lot\nof sense.\n\nUnfortunately -n is taken to mean --no-verify by git-commit, so\nwe probably cannot repurpose it to mean --no-summary, like it is\nfor merge/pull.\n\n-- \n"},{"id":"296404","messageId":"eluemi$gc0$1@sea.gmane.org","threadId":"43119","inReplyTo":"200612141136.59041.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T15:26:33Z","receivedAt":"2006-12-15T15:26:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\nBy the way, could you use slightly smaller number of columns? TIA.\n\n> On Thursday 2006 December 14 10:21, Junio C Hamano wrote:\n\n>> But you never communicate with your own git repository using the\n>> SHA-1 object names when talking about commits you made recently\n> \n> How's this then:\n> \n> $ git commit\n> $ git commit\n> $ git commit\n> $ git reset HEAD^^^\n> \n> \"AGGGHHHHHH! I meant HEAD^^\"\n> \n> At this point I start running \"git-prune -n | grep commit\" and some liberal \n> use of git-show to try and find the hash of the object so I can do\n> \n> $ git reset --hard HASH_OF_OBJECT_I_STUPIDLY_ORPHANED\n\nThat is what reflog is for. By the way, is core.logAllRefUpdates set\nto \"true\" (or \"heads\") by default now?\n\nAlthough I'm not against\n\n $ git commit -v\n Revision XXXXXXXXXXXXXXXXXX successfully added.\n \nNotice -v/-verbose option.\n\n>> So I do not think \"git commit\" is a valid example. I also agree\n>> with Shawn that \"git add\" that says 6781 files were added is\n>> pointless.\n> \n> Okay.\n\nAnd git-add has -v option (although not --verbose).\n\n>>> I've always thought that programs that needed an expert/beginner split\n>>> were badly designed.\n>>\n>> There probably is a truth in that. Let's not add verbosity\n>> unnecessarily.\n> \n> My habit is always to be overly verbose in program output; however, I realise \n> that not everybody likes that. None of these things cause me any difficulty \n> in my use of git. However, my Dad also is an engineer, but he's not so \n> comfortable with VCS; for him almost every part of git is a mystery. \n> Commands that run and don't say anything are confusing because he didn't \n> really know what they were /meant/ to do; he's just got a set of recipes that \n> he knows to type. He's probably an extreme case, and not a good model for \n> typical user - on the other hand, I would say that if he can use it, then it \n> is officially newbie-friendly. :-)\n\nIt would be nice to have some generic place in git config to specify\ndefault options to git commands (at least for interactive shell). It\ncannot be done using aliases. Perhaps defaults. config variable?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"293932","messageId":"Pine.LNX.4.64.0612151029080.18171@xanadu.home","threadId":"43119","inReplyTo":"eluemi$gc0$1@sea.gmane.org","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-15T15:30:43Z","receivedAt":"2006-12-15T15:30:43Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 15 Dec 2006, Jakub Narebski wrote:\n\n> It would be nice to have some generic place in git config to specify\n> default options to git commands (at least for interactive shell). It\n> cannot be done using aliases. Perhaps defaults. config variable?\n\nI would say the alias facility has to be fixed then.\n\nIn bash you can alias \"ls\" to \"ls -l\" and it just works.\n\n\n"},{"id":"295889","messageId":"4582C022.3030706@op5.se","threadId":"43119","inReplyTo":"20061215150909.GE17860@spearce.org","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-15T15:32:50Z","receivedAt":"2006-12-15T15:32:50Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn Pearce wrote:\n> Andreas Ericsson wrote:\n>> Shawn Pearce wrote:\n>>> Nicolas Pitre wrote:\n>>>> It is nicer to let the user know when a commit succeeded all the time, \n>>>> not only the first time. Also the commit sha1 is much more useful than \n>>>> the tree sha1 in this case.\n>>> I agree the commit sha1 is more useful than the tree sha1, but I'm\n>>> not really sure its useful to show the commit sha1 post commit.\n>>> If you want to show something the diffstat like what git merge does\n>>> is better.\n>>>\n>> diffstats can be huge though. I'd rather have those only with -v option.\n> \n> But they are on by default for pull/merge, and disabled by -n.\n> \n\nYes, but it makes sense for merges where you generally pull someone \nelses work or one of your topic branches because it gives a general feel \nfor the amount of modifications and are a sort of conclusion. Commits \nare a different thing, because you should know what kind of changes \nyou've just done. If you don't you have other problems. I for one run \ngit diff quite frequently when I'm getting close to a commit to make \nsure I don't get only the changes I want. I imagine others do too, so \ngetting a diffstat when issuing the actual commit would just be noisy \nand irritating.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294620","messageId":"elufdn$jqt$1@sea.gmane.org","threadId":"43119","inReplyTo":"200612142250.27766.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T15:38:54Z","receivedAt":"2006-12-15T15:38:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> On Thursday 2006, December 14 21:58, Junio C Hamano wrote:\n> \n>> Correct but a bad example that does not demonstrate the real\n>> power of reflog. Andy's AGGGHHHHHH can be recovered with a\n>> simple:\n>>\n>> $ git reset ORIG_HEAD\n> \n> HAHA! I knew reading this mailing list would pay off.\n> \n> It amazes me that there is always an answer. It's almost becoming a \n> pantomime - I say \"well git can't do this\", and you say \"oh yes it can\".\n\nAnd it is mentioned in git-reset(1), although:\n\n * it would be nice to have example with ORIG_HEAD about how\n to recover from bad (wrong) git reset in EXAMPLES section.\n\n * it would be nice to mention that the first example can\n be now done with simply \"edit; git commit -a --amend\"\n instead of \"git reset --soft HEAD^; edit; git commit -a -c ORIG_HEAD\"\n (which can fail for merges).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296948","messageId":"20061215154025.GF17860@spearce.org","threadId":"43119","inReplyTo":"4582C022.3030706@op5.se","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-15T15:40:25Z","receivedAt":"2006-12-15T15:40:25Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andreas Ericsson wrote:\n> Yes, but it makes sense for merges where you generally pull someone \n> elses work or one of your topic branches because it gives a general feel \n> for the amount of modifications and are a sort of conclusion. Commits \n> are a different thing, because you should know what kind of changes \n> you've just done. If you don't you have other problems. I for one run \n> git diff quite frequently when I'm getting close to a commit to make \n> sure I don't get only the changes I want. I imagine others do too, so \n> getting a diffstat when issuing the actual commit would just be noisy \n> and irritating.\n\nI do the same (diff a lot before commit) and thus find commit\noutputting anything at all to be noisy and irritating. Frankly\nthe new\n\n git-diff-tree --summary --root --no-commit-id HEAD\n\nthat Junio put on the end is already irritating.\n\nBut it was added to help users verify that commit did what they\nthought it would (see 61f5cb7f). By the same token sometimes users\naccidentally commit files they didn't mean to, or forget to include\nfiles they meant to include. Showing a diffstat would also be a\nfinal sanity check for them.\n\n-- \n"},{"id":"298686","messageId":"4582C3CE.3000902@op5.se","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612151029080.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-15T15:48:30Z","receivedAt":"2006-12-15T15:48:30Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n> On Fri, 15 Dec 2006, Jakub Narebski wrote:\n> \n>> It would be nice to have some generic place in git config to specify\n>> default options to git commands (at least for interactive shell). It\n>> cannot be done using aliases. Perhaps defaults. config variable?\n> \n> I would say the alias facility has to be fixed then.\n> \n> In bash you can alias \"ls\" to \"ls -l\" and it just works.\n> \n\nI think this is because git scripts that need a certain git command to \nwork a certain way don't want some alias to kick in and destroy things \nfor them. Shell-scripts would have the same problem if you alias \"awk\" \nto \"grep\" f.e., which is why prudent shell-scripters use the \"unalias \n-a\" thing.\n\nAnyways, this should be largely solvable by inventing a \"--no-aliases\" \nswitch to the git wrapper, or by the scripts calling the programs they \nneed directly which, afaik, bypasses the alias logic. If it doesn't, it \nshould.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"297460","messageId":"4582C442.5050704@op5.se","threadId":"43119","inReplyTo":"20061215154025.GF17860@spearce.org","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-15T15:50:26Z","receivedAt":"2006-12-15T15:50:26Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn Pearce wrote:\n> Andreas Ericsson wrote:\n>> Yes, but it makes sense for merges where you generally pull someone \n>> elses work or one of your topic branches because it gives a general feel \n>> for the amount of modifications and are a sort of conclusion. Commits \n>> are a different thing, because you should know what kind of changes \n>> you've just done. If you don't you have other problems. I for one run \n>> git diff quite frequently when I'm getting close to a commit to make \n>> sure I don't get only the changes I want. I imagine others do too, so \n>> getting a diffstat when issuing the actual commit would just be noisy \n>> and irritating.\n> \n> I do the same (diff a lot before commit) and thus find commit\n> outputting anything at all to be noisy and irritating. Frankly\n> the new\n> \n\nI could live with one line (Committed revision %d), but a diffstat is \nalways 3 lines minimum, which might well turn out to be 2 lines more \nthan I changed. That's way too noisy.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"297080","messageId":"Pine.LNX.4.64.0612151032240.18171@xanadu.home","threadId":"43119","inReplyTo":"20061215150909.GE17860@spearce.org","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-15T16:01:55Z","receivedAt":"2006-12-15T16:01:55Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Dec 2006, Shawn Pearce wrote:\n\n> Nicolas Pitre wrote:\n> > It is nicer to let the user know when a commit succeeded all the time, \n> > not only the first time. Also the commit sha1 is much more useful than \n> > the tree sha1 in this case.\n> \n> I agree the commit sha1 is more useful than the tree sha1, but I'm\n> not really sure its useful to show the commit sha1 post commit.\n\nIt is useful, even if it is not essential.\n\nSince I believe it is a good thing to display _something_ by default \n(and not only with -v as suggested -- please see the reasoning I posted \nyesterday as to what should have some output and what shouldn't), it \ndoesn't hurt to display the commit sha1 as well.\n\nFirst it has the very desirable side effect of making the user slightly \naware of how git identifies things. From the first commit a new user \nwill notice that git doesn't use any incremental version number but a \nunique identifier that has nothing to do with sequence. It is not \nexpected that people will start _using_ the information printed, but it \nwill at least give a feel of how git works. And it is not like if the \nwhole thing took multiple lines to be displayed.\n\nNext it _might_ be used by people. The fact that it is there might turn \nto be useful. It is useful in the context of Documentation/tutorial-2.txt\nfor one where the notion of objects and their relationship is explained \nbased on the least amount of steps possible.\n\nSo in short I do think there should be something shown after a \nsuccessful commit, and including the commit sha1 doesn't hurt.\n\n> If you want to show something the diffstat like what git merge does\n> is better.\n> \n> For one thing it confirms that git accepted the changes. For another\n> it shows you *which* changes it accepted. Plus it responds just\n> like git-merge or git-pull does.\n\nI disagree. My patch does confirm that git accepted the change with \nonly one line. As to which changes were accepted I think that when you \ndo the commit you certainly have a pretty good idea already of what is \ngoing to be committed (you modified/added/removed files yourself, and by \ndefault git-commit provides you with a summary in the text editor for \nthe commit message).\n\nOn Fri, 15 Dec 2006, Shawn Pearce wrote:\n\n> Andreas Ericsson wrote:\n> > diffstats can be huge though. I'd rather have those only with -v option.\n> \n> But they are on by default for pull/merge, and disabled by -n.\n> \n> They are on to tell you what you just got during the pull/merge.\n\nThe pull/merge case is different. You are most likely to not know in \nadvance what the overall changes will be. Of course you're supposed to \nknow what you're pulling, but unlikely to know about the detail since \nwhat you merge is remote to your current working tree by definition, and \neven if you happen to be the one who did the changes in the other \nbranch/repo, it is certainly not as fresh in your mind than the changes \nyou did prior a commit.\n\nAnd it is true that diffstat can be quite large. I wouldn't mind the \ndiffstat to be added to the commit message summary in the text editor \nthough. And displaying it when -v is used makes also a lot of sense. \nBut not by default please.\n\n\n"},{"id":"298146","messageId":"Pine.LNX.4.64.0612151104120.18171@xanadu.home","threadId":"43119","inReplyTo":"20061215154025.GF17860@spearce.org","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-15T16:06:00Z","receivedAt":"2006-12-15T16:06:00Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 15 Dec 2006, Shawn Pearce wrote:\n\n> I do the same (diff a lot before commit) and thus find commit\n> outputting anything at all to be noisy and irritating. Frankly\n> the new\n> \n> git-diff-tree --summary --root --no-commit-id HEAD\n> \n> that Junio put on the end is already irritating.\n> \n> But it was added to help users verify that commit did what they\n> thought it would (see 61f5cb7f). By the same token sometimes users\n> accidentally commit files they didn't mean to, or forget to include\n> files they meant to include. Showing a diffstat would also be a\n> final sanity check for them.\n\nMake it with -v.\n\nIf the --summary is already irritating to you, imagine how a diffstat \ncould be.\n\n\n"},{"id":"298234","messageId":"Pine.LNX.4.64.0612151106580.18171@xanadu.home","threadId":"43119","inReplyTo":"4582C3CE.3000902@op5.se","subject":"Re: What's in git.git (stable)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-15T16:08:28Z","receivedAt":"2006-12-15T16:08:28Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 15 Dec 2006, Andreas Ericsson wrote:\n\n> Nicolas Pitre wrote:\n> > On Fri, 15 Dec 2006, Jakub Narebski wrote:\n> > \n> > > It would be nice to have some generic place in git config to specify\n> > > default options to git commands (at least for interactive shell). It\n> > > cannot be done using aliases. Perhaps defaults. config variable?\n> > \n> > I would say the alias facility has to be fixed then.\n> > \n> > In bash you can alias \"ls\" to \"ls -l\" and it just works.\n> > \n> \n> I think this is because git scripts that need a certain git command to work a\n> certain way don't want some alias to kick in and destroy things for them.\n> Shell-scripts would have the same problem if you alias \"awk\" to \"grep\" f.e.,\n> which is why prudent shell-scripters use the \"unalias -a\" thing.\n\nWouldn't it be possible for aliases to be effective only when issued \nfrom an interactive shell? It is certainly true that aliases just make \nno sense in a script.\n\n\n"},{"id":"296297","messageId":"20061215160833.GH17860@spearce.org","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612151032240.18171@xanadu.home","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-15T16:08:33Z","receivedAt":"2006-12-15T16:08:33Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> On Fri, 15 Dec 2006, Shawn Pearce wrote:\n> > Andreas Ericsson wrote:\n> > > diffstats can be huge though. I'd rather have those only with -v option.\n> > \n> > But they are on by default for pull/merge, and disabled by -n.\n> \n> And it is true that diffstat can be quite large. I wouldn't mind the \n> diffstat to be added to the commit message summary in the text editor \n> though. And displaying it when -v is used makes also a lot of sense. \n> But not by default please.\n\nOK, two votes against diffstats by default in commit. Since I\nhaven't written a patch for it yet consider it dropped. ;-)\n\n-- \n"},{"id":"297366","messageId":"20061215161257.GI17860@spearce.org","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612151106580.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-15T16:12:57Z","receivedAt":"2006-12-15T16:12:57Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> Wouldn't it be possible for aliases to be effective only when issued \n> from an interactive shell? It is certainly true that aliases just make \n> no sense in a script.\n\nProbably, but on Cygwin gitk needs to use 'git foo' to invoke a\ncommand, even if 'git-foo' exists, because 'git-foo' might be a shell\nscript and the Cygwin wish process cannot execute shell scripts.\n\nWorse it cannot pass down environment variables to git commands.\nSo it may be a little hard to tell in the git wrapper we are being\nrun from within gitk (or git-gui)...\n\n-- \n"},{"id":"297831","messageId":"4582C9B9.8090401@op5.se","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612151106580.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-15T16:13:45Z","receivedAt":"2006-12-15T16:13:45Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n> On Fri, 15 Dec 2006, Andreas Ericsson wrote:\n> \n>> Nicolas Pitre wrote:\n>>> On Fri, 15 Dec 2006, Jakub Narebski wrote:\n>>>\n>>>> It would be nice to have some generic place in git config to specify\n>>>> default options to git commands (at least for interactive shell). It\n>>>> cannot be done using aliases. Perhaps defaults. config variable?\n>>> I would say the alias facility has to be fixed then.\n>>>\n>>> In bash you can alias \"ls\" to \"ls -l\" and it just works.\n>>>\n>> I think this is because git scripts that need a certain git command to work a\n>> certain way don't want some alias to kick in and destroy things for them.\n>> Shell-scripts would have the same problem if you alias \"awk\" to \"grep\" f.e.,\n>> which is why prudent shell-scripters use the \"unalias -a\" thing.\n> \n> Wouldn't it be possible for aliases to be effective only when issued \n> from an interactive shell? It is certainly true that aliases just make \n> no sense in a script.\n> \n\nYes, but then aliases wouldn't work in one-liners, which would be a bit \nof a shame and pretty likely to cause some \"interesting\" bugreports. \nPerhaps an environment variable GIT_IGNORE_ALIAS=yes that git-scripts \ncan set at the beginning of execution?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"296713","messageId":"eluhk3$pv7$1@sea.gmane.org","threadId":"43119","inReplyTo":"20061214230307.GE26202@spearce.org","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T16:16:26Z","receivedAt":"2006-12-15T16:16:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn Pearce wrote:\n\n> Andy Parkins wrote:\n>> * git-show-branch output is cryptic.\n> \n> Agreed. I still don't know how to read its output. So I just\n> don't use it. Ever. :-)\n\nAnd the way it uses it's options is even more cryptic, and differs from\nother similar commands. So I'd rather use qgit (or gitk, if gitk would\ncorrect the error with remembering wrong window size).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294117","messageId":"7vvekdvxeo.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612151032240.18171@xanadu.home","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T18:14:55Z","receivedAt":"2006-12-15T18:14:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> So in short I do think there should be something shown after a \n> successful commit, and including the commit sha1 doesn't hurt.\n> ...\n> And it is true that diffstat can be quite large. I wouldn't mind the \n> diffstat to be added to the commit message summary in the text editor \n> though. And displaying it when -v is used makes also a lot of sense. \n> But not by default please.\n\nI agree with everything you said in your message, including that\ncommit object name might help as a learning aid.\n\nWe could give something like this, though, if we wanted to:\n\n\t$ git commit\n 4 files changed, 17 insertions(+), 10 deletions(-)\n mode change 100755 => 100644 test.sh\n\n"},{"id":"295420","messageId":"7vmz5pvx4c.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"20061215154025.GF17860@spearce.org","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T18:21:07Z","receivedAt":"2006-12-15T18:21:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> I do the same (diff a lot before commit) and thus find commit\n> outputting anything at all to be noisy and irritating. Frankly\n> the new\n>\n> git-diff-tree --summary --root --no-commit-id HEAD\n>\n> that Junio put on the end is already irritating.\n>\n> But it was added to help users verify that commit did what they\n> thought it would (see 61f5cb7f).\n\nThe credit should go Pasky's way. Add/delete/mode are rarer\nevents and reminding them is sensible.\n\nWe do not show the 'summary' when we are concluding a merge that\nconflicted. Otherwise you will be seeing other people's huge\nchanges that was just brought in.\n"},{"id":"294868","messageId":"Pine.LNX.4.64.0612151317380.18171@xanadu.home","threadId":"43119","inReplyTo":"7vvekdvxeo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-15T20:13:41Z","receivedAt":"2006-12-15T20:13:41Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 15 Dec 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > So in short I do think there should be something shown after a \n> > successful commit, and including the commit sha1 doesn't hurt.\n> > ...\n> > And it is true that diffstat can be quite large. I wouldn't mind the \n> > diffstat to be added to the commit message summary in the text editor \n> > though. And displaying it when -v is used makes also a lot of sense. \n> > But not by default please.\n> \n> I agree with everything you said in your message, including that\n> commit object name might help as a learning aid.\n> \n> We could give something like this, though, if we wanted to:\n> \n> \t$ git commit\n> 4 files changed, 17 insertions(+), 10 deletions(-)\n> mode change 100755 => 100644 test.sh\n\nActually that would really be nice to have all the time for the\ndiff --summary output whenever --stat is not provided. Or maybe a \n--shortstat option.\n\nWhat about this (on top of my previous patch):\n\nSigned-off-by: Nicolas Pitre \n\n---\n\ndiff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt\nindex 9cdd171..f12082e 100644\n--- a/Documentation/diff-options.txt\n+++ b/Documentation/diff-options.txt\n@@ -21,6 +21,11 @@\n \tdeleted lines in decimal notation and pathname without\n \tabbreviation, to make it more machine friendly.\n \n+--shortstat::\n+\tOutput only the last line of the --stat format containing total\n+\tnumber of modified files, as well as number of added and deleted\n+\tlines.\n+\n --summary::\n \tOutput a condensed summary of extended header information\n \tsuch as creations, renames and mode changes.\ndiff --git a/diff.c b/diff.c\nindex 0b284b3..d754280 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -809,6 +809,35 @@ static void show_stats(struct diffstat_t* data, struct diff_options *options)\n \t set, total_files, adds, dels, reset);\n }\n \n+static void show_shortstats(struct diffstat_t* data)\n+{\n+\tint i, adds = 0, dels = 0, total_files = data->nr;\n+\n+\tif (data->nr == 0)\n+\t\treturn;\n+\n+\tfor (i = 0; i < data->nr; i++) {\n+\t\tif (!data->files[i]->is_binary &&\n+\t\t !data->files[i]->is_unmerged) {\n+\t\t\tint added = data->files[i]->added;\n+\t\t\tint deleted= data->files[i]->deleted;\n+\t\t\tif (!data->files[i]->is_renamed &&\n+\t\t\t (added + deleted == 0)) {\n+\t\t\t\ttotal_files--;\n+\t\t\t} else {\n+\t\t\t\tadds += added;\n+\t\t\t\tdels += deleted;\n+\t\t\t}\n+\t\t}\n+\t\tfree(data->files[i]->name);\n+\t\tfree(data->files[i]);\n+\t}\n+\tfree(data->files);\n+\n+\tprintf(\" %d files changed, %d insertions(+), %d deletions(-)\\n\",\n+\t total_files, adds, dels);\n+}\n+\n static void show_numstat(struct diffstat_t* data, struct diff_options *options)\n {\n \tint i;\n@@ -1767,6 +1796,7 @@ int diff_setup_done(struct diff_options *options)\n \t\toptions->output_format &= ~(DIFF_FORMAT_RAW |\n \t\t\t\t\t DIFF_FORMAT_NUMSTAT |\n \t\t\t\t\t DIFF_FORMAT_DIFFSTAT |\n+\t\t\t\t\t DIFF_FORMAT_SHORTSTAT |\n \t\t\t\t\t DIFF_FORMAT_SUMMARY |\n \t\t\t\t\t DIFF_FORMAT_PATCH);\n \n@@ -1777,6 +1807,7 @@ int diff_setup_done(struct diff_options *options)\n \tif (options->output_format & (DIFF_FORMAT_PATCH |\n \t\t\t\t DIFF_FORMAT_NUMSTAT |\n \t\t\t\t DIFF_FORMAT_DIFFSTAT |\n+\t\t\t\t DIFF_FORMAT_SHORTSTAT |\n \t\t\t\t DIFF_FORMAT_SUMMARY |\n \t\t\t\t DIFF_FORMAT_CHECKDIFF))\n \t\toptions->recursive = 1;\n@@ -1868,6 +1899,9 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)\n \telse if (!strcmp(arg, \"--numstat\")) {\n \t\toptions->output_format |= DIFF_FORMAT_NUMSTAT;\n \t}\n+\telse if (!strcmp(arg, \"--shortstat\")) {\n+\t\toptions->output_format |= DIFF_FORMAT_SHORTSTAT;\n+\t}\n \telse if (!strncmp(arg, \"--stat\", 6)) {\n \t\tchar *end;\n \t\tint width = options->stat_width;\n@@ -2642,7 +2676,7 @@ void diff_flush(struct diff_options *options)\n \t\tseparator++;\n \t}\n \n-\tif (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_NUMSTAT)) {\n+\tif (output_format & (DIFF_FORMAT_DIFFSTAT|DIFF_FORMAT_SHORTSTAT|DIFF_FORMAT_NUMSTAT)) {\n \t\tstruct diffstat_t diffstat;\n \n \t\tmemset(&diffstat, 0, sizeof(struct diffstat_t));\n@@ -2656,6 +2690,8 @@ void diff_flush(struct diff_options *options)\n \t\t\tshow_numstat(&diffstat, options);\n \t\tif (output_format & DIFF_FORMAT_DIFFSTAT)\n \t\t\tshow_stats(&diffstat, options);\n+\t\telse if (output_format & DIFF_FORMAT_SHORTSTAT)\n+\t\t\tshow_shortstats(&diffstat);\n \t\tseparator++;\n \t}\n \ndiff --git a/diff.h b/diff.h\nindex 101b2b5..eff4455 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -29,6 +29,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,\n #define DIFF_FORMAT_NUMSTAT\t0x0004\n #define DIFF_FORMAT_SUMMARY\t0x0008\n #define DIFF_FORMAT_PATCH\t0x0010\n+#define DIFF_FORMAT_SHORTSTAT\t0x0020\n \n /* These override all above */\n #define DIFF_FORMAT_NAME\t0x0100\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 395bcd2..b9e49ea 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -629,7 +629,7 @@ then\n \tif test -z \"$quiet\"\n \tthen\n \t\techo \"Created${initial_commit:+ initial} commit $commit\"\n-\t\tgit-diff-tree --summary --root --no-commit-id HEAD\n+\t\tgit-diff-tree --shortstat --summary --root --no-commit-id HEAD\n \tfi\n fi\n"},{"id":"296127","messageId":"7vslfgomdg.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"4581C83A.10907@op5.se","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T21:55:07Z","receivedAt":"2006-12-15T21:55:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Shawn Pearce wrote:\n>>\n>> About the only trouble that can cause is a failed push when\n>> git-receive-pack needs to generate the reflog entry but cannot\n>> get the user's committer data because their gecos information\n>> doesn't exist.\n>\n> In that case, it would be best if it let the commit go through using\n> only the username. Reflogs are fixable afterwards, so there's no real\n> harm done.\n\nThis sounds sensible, regardless of the current discussion on\nthe default 'logallrefupdates' setting.\n\nVolunteers?\n"},{"id":"298429","messageId":"7vmz5oomdf.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"200612150858.25988.andyparkins@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T21:55:08Z","receivedAt":"2006-12-15T21:55:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Thursday 2006 December 14 23:46, Junio C Hamano wrote:\n> ...\n>> I said \"commit -b \" and deliberately avoided saying\n>> \"commit -b \", because I did not want to open another\n>> can of worms while we are discussing so many good things\n>> already, and my head can hold only a handful topics at once.\n>\n> Absolutely. I'd agree that only is worth even considering.\n\nJust for the record, I do not necessarily agree. Committing a\nsmall and obvious change out of context to an existing branch\nmakes just as much sense.\n\nAfter all, with the example workflow in my message you responded\nto, after running the \"commit -b typofix\" (which creates a new\nbranch) to record the first typo fix, I am sure that I would\nwant to record the second typofix I would find while on my topic\nto go to the same typofix branch I previously created.\n\nThe 'can of worms' is that switching to an existing branch could\nfail with conflicts. Although \"git checkout -m\" can help\nsometimes, that is not something we would want to do in the\nmiddle of doing something else on a topic. That's why I do not\nthink \"commit -b \" is a good idea.\n\nAllowing the form for only a new branch makes an inconsistency\nthat is hard to explain to new people, and that is why I am not\nin favor of having \"commit -b \" either.\n\n\n"},{"id":"298000","messageId":"7vhcvwomde.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"eluhk3$pv7$1@sea.gmane.org","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T21:55:09Z","receivedAt":"2006-12-15T21:55:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Shawn Pearce wrote:\n>\n>> Andy Parkins wrote:\n>>> * git-show-branch output is cryptic.\n>> \n>> Agreed. I still don't know how to read its output. So I just\n>> don't use it. Ever. :-)\n>\n> And the way it uses it's options is even more cryptic, and differs from\n> other similar commands.\n\n(Jakub, please do not drop people from cc: list; you were asked\nmore than once).\n\nOk, so what's the action you guys are proposing?\n\n (1) show-branch output is cryptic and it does not do anything\n useful. Drop it.\n\n (2) show-branch output is cryptic and I do not understand what\n it is trying to do. Document it better.\n\n (3) While I agree what show-branch is trying to do is useful,\n its output is useless. Instead of showing an example\n situation like this:\n\n\t[ picture here ]\n\n It should show the same situation like this:\n\n\t[ improved picture here ]\n\n (4) None of the above.\n\nThe same question goes for its input branch specification.\n\nPersonally, I find its input branch globbing very handy, and\noften wish that 'git branch' had a '--list' option that lists\nbranches that match the glob pattern given on the command line,\nnot just listing everything when no parameter is given.\n"},{"id":"294360","messageId":"200612152348.17997.jnareb@gmail.com","threadId":"43119","inReplyTo":"7vhcvwomde.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T22:48:16Z","receivedAt":"2006-12-15T22:48:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n>> Shawn Pearce wrote:\n>>\n>>> Andy Parkins wrote:\n>>>> * git-show-branch output is cryptic.\n>>> \n>>> Agreed. I still don't know how to read its output. So I just\n>>> don't use it. Ever. :-)\n>>\n>> And the way it uses it's options is even more cryptic, and differs from\n>> other similar commands.\n> \n> (Jakub, please do not drop people from cc: list; you were asked\n> more than once).\n\nThe problem is that I'm not subscribed to git mailing list; I usually\nread it via GMane news<->mail interface, at\n nntp://news.gmane.org/gmane.comp.version-control.git\nFirst, in this interface I have only the last author and not the full\nCc: list. Second, when I reply _both_ via email (adding authors if\nnecessary) and to news, people receiving my reply don't have (I guess)\ngit@vger.kernel.org in Cc: list, so sometimes the discussion drops off\nthe list. Third, if I add git mailing list address when replying via\nmail, vger server blocks email from gmane stating\n\n Technical details of permanent failure:\n PERM_FAILURE: SMTP Error (state 9): 501 5.1.3 Path data: Had characters unsuitable for an rfc821-string\n\nWhen email is sent _directly_ to me (i.e. I'm on Cc: list) I try\nto preserve Cc: list.\n\n> Ok, so what's the action you guys are proposing?\n> \n> (1) show-branch input is cryptic and it does not do anything\n> useful. Drop it.\n> \n> (2) show-branch input is cryptic and I do not understand what\n> it is trying to do. Document it better.\n[...]\n\nI'm just used to the way revisions are specified to other history\nviewers: git-log (via git-rev-list), gitk, qgit. git-show-branch\nis a bit odd man out here. \"git-show-branch ref1 ref2 ref3\"\nis (without --more=n) like \n\n git rev-list ref1 ref2 ref3 --not $(git merge-base ref1 ref2 ref3)\n\nWhich is handy for git-show-branch, but odd. Perhaps we should add\n--xor option to git rev list for the above, i.e.\n\n git rev-list A...B == \n == git rev-list A B --not $(git merge-base A B)\n git rev-list --xor A B C ==\n == git rev-list A B C --not $(git merge-base A B C) \n \n> Personally, I find its input branch globbing very handy, and\n> often wish that 'git branch' had a '--list' option that lists\n> branches that match the glob pattern given on the command line,\n> not just listing everything when no parameter is given.\n \nIt is odd (git branch not having --list with globbing) also because\n'git tag' has globbing support.\n\n-- \nJakub Narebski\n"},{"id":"294470","messageId":"87odq44vo9.wl%cworth@cworth.org","threadId":"43119","inReplyTo":"7vmz5oomdf.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-15T22:54:30Z","receivedAt":"2006-12-15T22:54:30Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"> The 'can of worms' is that switching to an existing branch could\n> fail with conflicts.\n\nOne fix for this would be the idea I've proposed to have a new flag\nfor \"git checkout\" to 'stash' the dirty state in the current branch\nbefore switching.\n\nThen, there wouldn't be a problem to implement \"commit -b \"\non top of the stashing checkout.\n\nI think the only real problem with the idea of having dirty changes\nstashed in a branch is that git already allows dirty changes to be\ncarried while switching to a branch, (with or without -m). And doing\nboth of those at once would lead to an ugly new conflict situation,\n(where _neither_ of the conflicted states exist as exposed tree\nobjects). Even if there were no conflict, it would mingle two\ndifferent sets of local modifications, and that could be unkind as it\nmight be hard for the user to separate them if they didn't want them\nmingled.\n\nIf someone were to pursue this idea, I think it would be reasonable to\njust make that case an error, \"Cannot carry local modifications when\nchecking out a branch with stashed modifications.\" That message could\neven suggest the user use the stash option to leave the local\nmodifications behind when doing the checkout.\n\n-Carl\n"},{"id":"295491","messageId":"Pine.LNX.4.63.0612160020590.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612151029080.18171@xanadu.home","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-15T23:22:29Z","receivedAt":"2006-12-15T23:22:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 15 Dec 2006, Nicolas Pitre wrote:\n\n> On Fri, 15 Dec 2006, Jakub Narebski wrote:\n> \n> > It would be nice to have some generic place in git config to specify\n> > default options to git commands (at least for interactive shell). It\n> > cannot be done using aliases. Perhaps defaults. config variable?\n> \n> I would say the alias facility has to be fixed then.\n> \n> In bash you can alias \"ls\" to \"ls -l\" and it just works.\n\nSo, why not use bash aliases?\n\nFrankly, what git aliases try to achieve is a little bit different from \nbash aliases. Bash knows exactly when a command is interactive, and has a \nclear advantage there. Git _cannot_ know.\n\nCiao,\nDscho\n"},{"id":"296821","messageId":"Pine.LNX.4.63.0612160023340.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"200612152348.17997.jnareb@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-15T23:25:31Z","receivedAt":"2006-12-15T23:25:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 15 Dec 2006, Jakub Narebski wrote:\n\n> Junio C Hamano wrote:\n>\n> > (Jakub, please do not drop people from cc: list; you were asked\n> > more than once).\n> \n> The problem is that I'm not subscribed to git mailing list;\n\nSo subscribe. I am sure I lost quite some of your responses to my emails, \n_just_ because you happen to kill me from the Cc: list.\n\nIOW if you expect answers, _please_ adher to net standards.\n\nCiao,\nDscho\n"},{"id":"294682","messageId":"7vejr0n2u7.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"200612152348.17997.jnareb@gmail.com","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T23:42:24Z","receivedAt":"2006-12-15T23:42:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> I'm just used to the way revisions are specified to other history\n> viewers: git-log (via git-rev-list), gitk, qgit. git-show-branch\n> is a bit odd man out here. \"git-show-branch ref1 ref2 ref3\"\n> is (without --more=n) like \n>\n> git rev-list ref1 ref2 ref3 --not $(git merge-base ref1 ref2 ref3)\n>\n> Which is handy for git-show-branch, but odd.\n\nI hate to sound harsh, but...\n\nThen you do not understand show-branch at all. Not having to\nsay the \"--not merge-base\" part is NOT about being handy, but is\nthe central part of what show-branch does. The command is about\nshowing the commits that are on only some of the branches but\nnot on others.\n\nOther commands you listed above are all based on rev-list logic\nof painting commits in two colors (either UNINTERESTING or\n~UNINTERESTING) and being able to combine the set using \"A..B\",\n\"^A B\", and \"A B --not C\" notations all make sense. All\ncombinations work as set operation -- start from union of\ncommits reachable from positive (i.e. not prefixed with ^) refs,\nand subtract set of commits reachable from any negative ref.\n\nWhat show-branch does cannot be expressed with that two-color\nlogic; it needs to use N colors for N input refs. After digging\nfrom the tips deep enough, you would find the common merge-base\nand after that point it is not interesting to show anything\nanymore, and that is how it stops output.\n"},{"id":"294893","messageId":"7vac1on2oh.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"Pine.LNX.4.63.0612160023340.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T23:45:50Z","receivedAt":"2006-12-15T23:45:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 15 Dec 2006, Jakub Narebski wrote:\n>\n>> Junio C Hamano wrote:\n>>\n>> > (Jakub, please do not drop people from cc: list; you were asked\n>> > more than once).\n>> \n>> The problem is that I'm not subscribed to git mailing list;\n>\n> So subscribe. I am sure I lost quite some of your responses to my emails, \n> _just_ because you happen to kill me from the Cc: list.\n>\n> IOW if you expect answers, _please_ adher to net standards.\n\nFWIW, I also read the list traffic through gmane news gateway.\n\nI am subscribed and my mail filter drops the mails from the list\ninto a dedicated mailbox, but that is purely for my own backup\nand I usually do not look at it otherwise.\n"},{"id":"295597","messageId":"Pine.LNX.4.63.0612160113090.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"7vac1on2oh.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-16T00:14:02Z","receivedAt":"2006-12-16T00:14:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 15 Dec 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Fri, 15 Dec 2006, Jakub Narebski wrote:\n> >\n> >> Junio C Hamano wrote:\n> >>\n> >> > (Jakub, please do not drop people from cc: list; you were asked\n> >> > more than once).\n> >> \n> >> The problem is that I'm not subscribed to git mailing list;\n> >\n> > So subscribe. I am sure I lost quite some of your responses to my emails, \n> > _just_ because you happen to kill me from the Cc: list.\n> >\n> > IOW if you expect answers, _please_ adher to net standards.\n> \n> FWIW, I also read the list traffic through gmane news gateway.\n\nSo, how do you tackle the problem Jakub evidently has, namely to reply to \nall the people who your reply refers to?\n\nCiao,\nDscho\n"},{"id":"297357","messageId":"7v4prwn0lp.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"Pine.LNX.4.63.0612160113090.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-16T00:30:42Z","receivedAt":"2006-12-16T00:30:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> FWIW, I also read the list traffic through gmane news gateway.\n>\n> So, how do you tackle the problem Jakub evidently has, namely to reply to \n> all the people who your reply refers to?\n\nI do not \"tackle\".\n\nI just tell Gnus to follow-up, which does not always do the\nright thing [*1*], and I just try to be careful and fix up To:\nand Cc: fields by hand as necessary. The time spent on that on\nmy part is _worth_ spending than inconveniencing others.\n\nIt's just a common courtesy, not \"tackling\".\n\n\n[Footnote]\n\n*1* ... most likely because I haven't configured it to do the\nright thing, and/or the sender or the gateway puts a wrong\nReply-To: or Mail-Followup-To: header and it ends up honoring\nthem.\n"},{"id":"295555","messageId":"20061216025421.GB19636@spearce.org","threadId":"43119","inReplyTo":"7vslfgomdg.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-16T02:54:21Z","receivedAt":"2006-12-16T02:54:21Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson writes:\n> \n> > Shawn Pearce wrote:\n> >>\n> >> About the only trouble that can cause is a failed push when\n> >> git-receive-pack needs to generate the reflog entry but cannot\n> >> get the user's committer data because their gecos information\n> >> doesn't exist.\n> >\n> > In that case, it would be best if it let the commit go through using\n> > only the username. Reflogs are fixable afterwards, so there's no real\n> > harm done.\n> \n> This sounds sensible, regardless of the current discussion on\n> the default 'logallrefupdates' setting.\n> \n> Volunteers?\n\nIts a good idea. I'll do it later tonight, after dinner.\n\n-- \n"},{"id":"297251","messageId":"7vk60sl5xa.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"Pine.LNX.4.64.0612151317380.18171@xanadu.home","subject":"Re: [PATCH] make commit message a little more consistent and conforting","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-16T06:18:41Z","receivedAt":"2006-12-16T06:18:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> What about this (on top of my previous patch):\n\nLooks good.\n"},{"id":"294443","messageId":"7vfybgjj7k.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"7v4przfpir.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-clone: use wildcard specification for tracking branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-16T09:14:39Z","receivedAt":"2006-12-16T09:14:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This stops enumerating the set of branches found on the remote\nside when a clone was made in the configuration file. Instead,\na single entry that maps each remote branch to the local\ntracking branch for the remote under the same name is created.\n\nDoing it this way not only shortens the configuration file, but\nautomatically adjusts to a new branch added on the remote side\nafter the clone is made.\n\nUnfortunately this cannot be done for the traditional layout,\nwhere we always need to special case the 'master' to 'origin'\nmapping within the local branch namespace. But that is Ok; it\nwill be going away before v1.5.0.\n\nWe could also lose the \"primary branch\" mapping at the\nbeginning, but that has to wait until we implement the \"forbid\n'git pull' when we do not have branch.$current.merge for the\ncurrent branch\" policy we earlier discussed. That should also\nbe in v1.5.0\n\nSigned-off-by: Junio C Hamano \n\n---\nJunio C Hamano writes:\n\n> Things that need to be done to complete what have been merged to\n> 'master' are:\n> ...\n> - 'git-clone' probably should be updated to use wild-card in\n> remote.origin.fetch, instead of listing all the branches it\n> found when the clone was made.\n\n git-clone.sh | 47 ++++++++++++++++++++++++++++++-----------------\n 1 files changed, 30 insertions(+), 17 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 1f5d07a..422499a 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -366,41 +366,54 @@ then\n \t\t)\n \t)\n \n-\t# Write out remotes/$origin file, and update our \"$head_points_at\".\n+\t# Write out remote.$origin config, and update our \"$head_points_at\".\n \tcase \"$head_points_at\" in\n \t?*)\n-\t\tmkdir -p \"$GIT_DIR/remotes\" &&\n+\t\t# Local default branch\n \t\tgit-symbolic-ref HEAD \"refs/heads/$head_points_at\" &&\n+\n+\t\t# Tracking branch for the primary branch at the remote.\n \t\tcase \"$use_separate_remote\" in\n \t\tt)\torigin_track=\"$remote_top/$head_points_at\"\n \t\t\tgit-update-ref HEAD \"$head_sha1\" ;;\n \t\t*)\torigin_track=\"$remote_top/$origin\"\n \t\t\tgit-update-ref \"refs/heads/$origin\" \"$head_sha1\" ;;\n \t\tesac &&\n+\n+\t\t# Upstream URL and the primary branch tracking\n \t\tgit-repo-config remote.\"$origin\".url \"$repo\" &&\n \t\tgit-repo-config remote.\"$origin\".fetch \\\n \t\t\t\"refs/heads/$head_points_at:$origin_track\" &&\n-\t\t(cd \"$GIT_DIR/$remote_top\" && find . -type f -print) |\n-\t\twhile read dotslref\n-\t\tdo\n-\t\t\tname=`expr \"$dotslref\" : './\\(.*\\)'`\n-\t\t\tif test \"z$head_points_at\" = \"z$name\"\n-\t\t\tthen\n-\t\t\t\tcontinue\n-\t\t\tfi\n-\t\t\tif test \"$use_separate_remote\" = '' &&\n-\t\t\t test \"z$origin\" = \"z$name\"\n-\t\t\tthen\n-\t\t\t\tcontinue\n-\t\t\tfi\n-\t\t\tgit-repo-config remote.\"$origin\".fetch \"refs/heads/${name}:$remote_top/${name}\" '^$'\n-\t\tdone &&\n+\n+\t\t# Set up the mappings to track the remaining branches.\n+\t\tcase \"$use_separate_remote\" in\n+\t\tt)\n+\t\t\tgit-repo-config remote.\"$origin\".fetch \\\n+\t\t\t\t\"refs/heads/*:$remote_top/*\" '^$'\n+\t\t\t;;\n+\t\t*)\n+\t\t\t(cd \"$GIT_DIR/$remote_top\" && find . -type f -print) |\n+\t\t\twhile read dotslref\n+\t\t\tdo\n+\t\t\t\tname=`expr \"$dotslref\" : './\\(.*\\)'`\n+\t\t\t\tif test \"z$head_points_at\" = \"z$name\" ||\n+\t\t\t\t\ttest \"z$origin\" = \"z$name\"\n+\t\t\t\tthen\n+\t\t\t\t\tcontinue\n+\t\t\t\tfi\n+\t\t\t\tgit-repo-config remote.\"$origin\".fetch \\\n+\t\t\t\t\"refs/heads/${name}:$remote_top/${name}\" '^$'\n+\t\t\tdone\n+\t\t\t;;\n+\t\tesac &&\n+\n \t\tcase \"$use_separate_remote\" in\n \t\tt)\n \t\t\trm -f \"refs/remotes/$origin/HEAD\"\n \t\t\tgit-symbolic-ref \"refs/remotes/$origin/HEAD\" \\\n \t\t\t\t\"refs/remotes/$origin/$head_points_at\"\n \t\tesac &&\n+\n \t\tgit-repo-config branch.\"$head_points_at\".remote \"$origin\" &&\n \t\tgit-repo-config branch.\"$head_points_at\".merge \"refs/heads/$head_points_at\"\n \tesac\n"},{"id":"295609","messageId":"7v3b7gji73.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"7vfybgjj7k.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-pull: refuse default merge without branch.*.merge","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-16T09:36:32Z","receivedAt":"2006-12-16T09:36:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Everybody hated the pull behaviour of merging the first branch\nlisted on remotes/* file (or remote.*.fetch config) into the\ncurrent branch. This finally corrects that UI wart by\nforbidding \"git pull\" without an explicit branch name on the\ncommand line or branch.$current.merge for the current branch.\n\nThe matching change to git-clone was made to prepare the default\nbranch.*.merge entry for the primary branch some time ago.\n\nSigned-off-by: Junio C Hamano \n\n---\nJunio C Hamano writes:\n\n> We could also lose the \"primary branch\" mapping at the\n> beginning, but that has to wait until we implement the \"forbid\n> 'git pull' when we do not have branch.$current.merge for the\n> current branch\" policy we earlier discussed. That should also\n> be in v1.5.0\n\n And this does exactly that.\n\n git-parse-remote.sh | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\nindex 6ae534b..7cd79c2 100755\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -144,7 +144,8 @@ canon_refs_list_for_fetch () {\n \t\t\tcurr_branch=$(git-symbolic-ref HEAD | \\\n \t\t\t sed -e 's|^refs/heads/||')\n \t\t\tmerge_branches=$(git-repo-config \\\n-\t\t\t --get-all \"branch.${curr_branch}.merge\")\n+\t\t\t --get-all \"branch.${curr_branch}.merge\") ||\n+\t\t\tmerge_branches=.this.would.never.match.any.ref.\n \t\tfi\n \t\tset x $(expand_refs_wildcard \"$@\")\n \t\tshift\n"},{"id":"298421","messageId":"em0eo3$122$1@sea.gmane.org","threadId":"43119","inReplyTo":"7vfybgjj7k.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-clone: use wildcard specification for tracking branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-16T09:39:38Z","receivedAt":"2006-12-16T09:39:38Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> This stops enumerating the set of branches found on the remote\n> side when a clone was made in the configuration file.  Instead,\n> a single entry that maps each remote branch to the local\n> tracking branch for the remote under the same name is created.\n> \n> Doing it this way not only shortens the configuration file, but\n> automatically adjusts to a new branch added on the remote side\n> after the clone is made.\n[...]\n\nDoes this deal with non-fast-forward branches like 'pu'? Does\nit add $head_points_at at the beginning, before glob... wait,\nthis is not needed if there is branch.$head_points_at.merge.\nBut perhaps it still would be better to have:\n\n [remote \"origin\"]\n url = git://git.kernel.org/pub/scm/git/git.git\n fetch = refs/heads/master:refs/remotes/origin/master\n fetch = refs/heads/*:refs/remotes/origin/*\n fetch =+refs/heads/pu:refs/remotes/origin/pu\n\n [branch \"master\"]\n remote = origin\n merge = refs/heads/master ;# full spec of remote branch\n\nBut this is very nice. Thanks.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296867","messageId":"7vvekci3ds.fsf_-_@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"7v3b7gji73.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-clone: lose the artificial \"first\" fetch refspec","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-16T09:41:51Z","receivedAt":"2006-12-16T09:41:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Now we lost the \"first refspec is the one that is merged by default\"\nrule, there is no reason for clone to list the remote primary branch\nin the config file explicitly anymore.\n\nWe still need it for the traditional layout for other reasons,\nthough.\n\nSigned-off-by: Junio C Hamano \n\n---\n> Junio C Hamano writes:\n>\n>> We could also lose the \"primary branch\" mapping at the\n>> beginning, but that has to wait until we implement the \"forbid\n>> 'git pull' when we do not have branch.$current.merge for the\n>> current branch\" policy we earlier discussed. That should also\n>> be in v1.5.0\n>\n> And this does exactly that.\n\n Next step will be to remove the traditional layout altogether.\n With the recent flurry of UI updates, I think it is sane to do\n that before v1.5.0; opinions?\n\n git-clone.sh | 8 ++++----\n 1 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 422499a..68dc4f2 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -380,18 +380,18 @@ then\n \t\t\tgit-update-ref \"refs/heads/$origin\" \"$head_sha1\" ;;\n \t\tesac &&\n \n-\t\t# Upstream URL and the primary branch tracking\n+\t\t# Upstream URL\n \t\tgit-repo-config remote.\"$origin\".url \"$repo\" &&\n-\t\tgit-repo-config remote.\"$origin\".fetch \\\n-\t\t\t\"refs/heads/$head_points_at:$origin_track\" &&\n \n-\t\t# Set up the mappings to track the remaining branches.\n+\t\t# Set up the mappings to track the remote branches.\n \t\tcase \"$use_separate_remote\" in\n \t\tt)\n \t\t\tgit-repo-config remote.\"$origin\".fetch \\\n \t\t\t\t\"refs/heads/*:$remote_top/*\" '^$'\n \t\t\t;;\n \t\t*)\n+\t\t\tgit-repo-config remote.\"$origin\".fetch \\\n+\t\t\t\t\"refs/heads/$head_points_at:$origin_track\" &&\n \t\t\t(cd \"$GIT_DIR/$remote_top\" && find . -type f -print) |\n \t\t\twhile read dotslref\n \t\t\tdo\n"},{"id":"295499","messageId":"7virgci2ux.fsf_-_@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"7vvekci3ds.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] git-clone: lose the traditional 'no-separate-remote' layout","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-16T09:53:10Z","receivedAt":"2006-12-16T09:53:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finally.\n\nThe separate-remote layout is so much more organized than\ntraditional and easier to work with especially when you need to\ndeal with remote repositories with multiple branches and/or you\nneed to deal with more than one remote repositories, and using\ntraditional layout for new repositories simply does not make\nmuch sense.\n\nInternally we still have code for 1:1 mappings to create a bare\nclone; that is a good thing and will not go away.\n\nSigned-off-by: Junio C Hamano \n---\nJunio C Hamano writes:\n\n> Next step will be to remove the traditional layout altogether.\n> With the recent flurry of UI updates, I think it is sane to do\n> that before v1.5.0; opinions?\n\n And this drops it; modulo bugs, I think this is about it for\n v1.5.0 around this area.\n\n Documentation/git-clone.txt | 15 +----------\n git-clone.sh | 58 +++++++++----------------------------------\n 2 files changed, 13 insertions(+), 60 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex bfddb21..874934a 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -11,8 +11,7 @@ SYNOPSIS\n [verse]\n 'git-clone' [--template=] [-l [-s]] [-q] [-n] [--bare]\n \t [-o ] [-u ] [--reference ]\n-\t [--use-separate-remote | --no-separate-remote] \n-\t []\n+\t []\n \n DESCRIPTION\n -----------\n@@ -99,18 +98,6 @@ OPTIONS\n \tif unset the templates are taken from the installation\n \tdefined default, typically `/usr/share/git-core/templates`.\n \n---use-separate-remote::\n-\tSave remotes heads under `$GIT_DIR/refs/remotes/origin/` instead\n-\tof `$GIT_DIR/refs/heads/`. Only the local master branch is\n-\tsaved in the latter. This is the default.\n-\n---no-separate-remote::\n-\tSave remotes heads in the same namespace as the local\n-\theads, `$GIT_DIR/refs/heads/'. In regular repositories,\n-\tthis is a legacy setup git-clone created by default in\n-\tolder Git versions, and will be removed before the next\n-\tmajor release.\n-\n ::\n \tThe (possibly remote) repository to clone from. It can\n \tbe any URL git-fetch supports.\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 68dc4f2..490f3e4 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -14,7 +14,7 @@ die() {\n }\n \n usage() {\n-\tdie \"Usage: $0 [--template=] [--no-separate-remote] [--reference ] [--bare] [-l [-s]] [-q] [-u ] [--origin ] [-n] []\"\n+\tdie \"Usage: $0 [--template=] [--reference ] [--bare] [-l [-s]] [-q] [-u ] [--origin ] [-n] []\"\n }\n \n get_repo_base() {\n@@ -137,11 +137,9 @@ while\n \t*,--template=*)\n \t template=\"$1\" ;;\n \t*,-q|*,--quiet) quiet=-q ;;\n-\t*,--use-separate-remote)\n-\t\t# default\n-\t\tuse_separate_remote=t ;;\n+\t*,--use-separate-remote) ;;\n \t*,--no-separate-remote)\n-\t\tuse_separate_remote= ;;\n+\t\tdie \"clones are always made with separate-remote layout\" ;;\n \t1,--reference) usage ;;\n \t*,--reference)\n \t\tshift; reference=\"$1\" ;;\n@@ -327,12 +325,8 @@ cd \"$D\" || exit\n \n if test -z \"$bare\" && test -f \"$GIT_DIR/REMOTE_HEAD\"\n then\n-\t# Figure out which remote branch HEAD points at.\n-\tcase \"$use_separate_remote\" in\n-\t'')\tremote_top=refs/heads ;;\n-\t*)\tremote_top=\"refs/remotes/$origin\" ;;\n-\tesac\n-\n+\t# a non-bare repository is always in separate-remote layout\n+\tremote_top=\"refs/remotes/$origin\"\n \thead_sha1=`cat \"$GIT_DIR/REMOTE_HEAD\"`\n \tcase \"$head_sha1\" in\n \t'ref: refs/'*)\n@@ -373,46 +367,18 @@ then\n \t\tgit-symbolic-ref HEAD \"refs/heads/$head_points_at\" &&\n \n \t\t# Tracking branch for the primary branch at the remote.\n-\t\tcase \"$use_separate_remote\" in\n-\t\tt)\torigin_track=\"$remote_top/$head_points_at\"\n-\t\t\tgit-update-ref HEAD \"$head_sha1\" ;;\n-\t\t*)\torigin_track=\"$remote_top/$origin\"\n-\t\t\tgit-update-ref \"refs/heads/$origin\" \"$head_sha1\" ;;\n-\t\tesac &&\n+\t\torigin_track=\"$remote_top/$head_points_at\" &&\n+\t\tgit-update-ref HEAD \"$head_sha1\" &&\n \n \t\t# Upstream URL\n \t\tgit-repo-config remote.\"$origin\".url \"$repo\" &&\n \n \t\t# Set up the mappings to track the remote branches.\n-\t\tcase \"$use_separate_remote\" in\n-\t\tt)\n-\t\t\tgit-repo-config remote.\"$origin\".fetch \\\n-\t\t\t\t\"refs/heads/*:$remote_top/*\" '^$'\n-\t\t\t;;\n-\t\t*)\n-\t\t\tgit-repo-config remote.\"$origin\".fetch \\\n-\t\t\t\t\"refs/heads/$head_points_at:$origin_track\" &&\n-\t\t\t(cd \"$GIT_DIR/$remote_top\" && find . -type f -print) |\n-\t\t\twhile read dotslref\n-\t\t\tdo\n-\t\t\t\tname=`expr \"$dotslref\" : './\\(.*\\)'`\n-\t\t\t\tif test \"z$head_points_at\" = \"z$name\" ||\n-\t\t\t\t\ttest \"z$origin\" = \"z$name\"\n-\t\t\t\tthen\n-\t\t\t\t\tcontinue\n-\t\t\t\tfi\n-\t\t\t\tgit-repo-config remote.\"$origin\".fetch \\\n-\t\t\t\t\"refs/heads/${name}:$remote_top/${name}\" '^$'\n-\t\t\tdone\n-\t\t\t;;\n-\t\tesac &&\n-\n-\t\tcase \"$use_separate_remote\" in\n-\t\tt)\n-\t\t\trm -f \"refs/remotes/$origin/HEAD\"\n-\t\t\tgit-symbolic-ref \"refs/remotes/$origin/HEAD\" \\\n-\t\t\t\t\"refs/remotes/$origin/$head_points_at\"\n-\t\tesac &&\n+\t\tgit-repo-config remote.\"$origin\".fetch \\\n+\t\t\t\"refs/heads/*:$remote_top/*\" '^$' &&\n+\t\trm -f \"refs/remotes/$origin/HEAD\"\n+\t\tgit-symbolic-ref \"refs/remotes/$origin/HEAD\" \\\n+\t\t\t\"refs/remotes/$origin/$head_points_at\" &&\n \n \t\tgit-repo-config branch.\"$head_points_at\".remote \"$origin\" &&\n \t\tgit-repo-config branch.\"$head_points_at\".merge \"refs/heads/$head_points_at\"\n"},{"id":"294934","messageId":"7vejr0i2lw.fsf@assigned-by-dhcp.cox.net","threadId":"43119","inReplyTo":"7v4przfpir.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-16T09:58:35Z","receivedAt":"2006-12-16T09:58:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">> I am hoping that we can start a stabilization cycle for v1.5.0\n>> based on what we have in 'master'. The theme is \"usability and\n>> teachability\".\n>> \n>> Things that need to be done to complete what have been merged to\n>> 'master' are:\n>> \n>> - 'git-rm' needs to be fixed up as Linus outlined; remove\n>> working tree file and index entry but have a sanity check to\n>> make sure the working tree file match the index and HEAD.\n>> \n>> - 'git-branch' may need to be taught about renaming the\n>> matching per-branch configuration at the same time.\n>> \n>> - 'git-merge-file' needs to be documented and linked from\n>> git.txt.\n>> \n>> - 'git-clone' probably should be updated to use wild-card in\n>> remote.origin.fetch, instead of listing all the branches it\n>> found when the clone was made.\n>> \n>> - tutorials and other Porcelain documentation pages need to be\n>> updated to match the updated 'git-add' and 'git-rm' (to be\n>> updated), and their description should be made much less\n>> about implementation; they should talk in terms of end-user\n>> workflows. I will send a draft for 'git diff' out later, but\n>> somebody needs a full sweep on Porcelain-ish documentation.\n>> \n>> - 'git diff --index' patch should be reverted (already done in\n>> 'next'), although we may have to come up with a better\n>> wording for --cached.\n\nI'm done with 2 out of the above six (\"diff --index\", and\n\"clone\") and a bit of the \"documentation\" item so far, and will\ngo to bed now. Any takers for the remaining tasks while I'll be\nsleeping ;-)?\n\n\n\n\n"},{"id":"296363","messageId":"Pine.LNX.4.63.0612161221071.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43119","inReplyTo":"7vejr0i2lw.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Document git-merge-file","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-16T11:22:18Z","receivedAt":"2006-12-16T11:22:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nMost of this is derived from the documentation of RCS merge.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Sat, 16 Dec 2006, Junio C Hamano wrote:\n\n\t> >> - 'git-merge-file' needs to be documented and linked from\n\t> >> git.txt.\n\n Documentation/git-merge-file.txt | 92 ++++++++++++++++++++++++++++++++++++++\n Documentation/git.txt | 3 +\n 2 files changed, 95 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-merge-file.txt b/Documentation/git-merge-file.txt\nnew file mode 100644\nindex 0000000..0b41d66\n--- /dev/null\n+++ b/Documentation/git-merge-file.txt\n@@ -0,0 +1,92 @@\n+git-merge-file(1)\n+============\n+\n+NAME\n+----\n+git-merge-file - threeway file merge\n+\n+\n+SYNOPSIS\n+--------\n+[verse]\n+'git-merge-file' [-L [-L [-L ]]]\n+\t[-p|--stdout] [-q|--quiet] \n+\n+\n+DESCRIPTION\n+-----------\n+git-file-merge incorporates all changes that lead from the ``\n+to `` into ``. The result ordinarily goes into\n+``. git-merge-file is useful for combining separate changes\n+to an original. Suppose `` is the original, and both\n+`` and `` are modifications of ``.\n+Then git-merge-file combines both changes.\n+\n+A conflict occurs if both `` and `` have changes\n+in a common segment of lines. If a conflict is found, git-merge-file\n+normally outputs a warning and brackets the conflict with <<<<<<< and\n+>>>>>>> lines. A typical conflict will look like this:\n+\n+\t<<<<<<< A\n+\tlines in file A\n+\t=======\n+\tlines in file B\n+\t>>>>>>> B\n+\n+If there are conflicts, the user should edit the result and delete one of\n+the alternatives.\n+\n+The exit value of this program is negative on error, and the number of\n+conflicts otherwise. If the merge was clean, the exit value is 0.\n+\n+git-merge-file is designed to be a minimal clone of RCS merge, that is, it\n+implements all of RCS merge's functionality which is needed by\n+gitlink:git[1].\n+\n+\n+OPTIONS\n+-------\n+\n+-L