{"thread":{"id":"43092","subject":"Re: svn versus git","startedAt":"2006-12-13T22:00:37Z","lastAt":"2006-12-16T00:26:58Z","messageCount":43,"participants":["Andreas Ericsson","Andy Parkins","Shawn Pearce","Jakub Narebski","J. Bruce Fields","Junio C Hamano","Johannes Schindelin","Arkadiusz Miskiewicz","Robin Rosenberg","Nguyen Thai Ngoc Duy","Peter Baumann","Nicolas Pitre","Seth Falcon"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"293922","messageId":"200612132200.41420.andyparkins@gmail.com","threadId":"43092","inReplyTo":null,"subject":"svn versus git","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-13T22:00:37Z","receivedAt":"2006-12-13T22:00:37Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nWith all the discussion about user interface difficulties, I started to write \na comparison with subversion document.  (I was assuming that people find \nsubversion easy).  As much as I love git, I was expecting to find that it's \nhard to use interface would have subversion as the clear winner.  I was \nhoping that would then give guidance as to what could be fixed in git.\n\nI was surprised, therefore, to find that in each case I was finding that git \nwas the winner.\n\nThis is only the first draft, so it's not very pretty; given that I now think \nit's fairly pointless, I doubt very much that there will be a second draft.  \nHowever, before I consign it to the waste bin; I thought I'd share what I had \nin case someone here had a use for it.\n\nExecutive summary: for the subset of features that git supplies that would \nmake it a subversion replacement; the UI for git is broadly compatible and \nmostly better.  The areas that make git look scary are:\n - git-clone\n - git-checkout\n - git-help\n - \"svn cat\" is missing from git\n - git-ls-tree\n - git-fsck-objects/git-repack/git-prune\n - \"svn revert\" is missing from git\n\nAs always, please take the following with liberal amounts of IMHO.\n\n\n---------------------------------\nSubversion Versus Git\n=====================\nAndy Parkins <andyparkins@gmail.com>\n\n\nIntroduction\n------------\n\nGit is often accused of having a difficult user interface.  I had\nimagined that was the case too.  I decided to write this comparison to\nshow the areas for which a simple version control system (like\nsubversion) had got the user interface right, and git had it wrong.\n\nI was surprised to find that the areas of difficulty were a lot fewer\nthan I had expected.  There is no reason why a user familiar with\nsubversion couldn't quickly cope with git's commands.   I realised I had\nbeen looking at Subversion through rose-tinted glasses.  For the set of\nfeatures that Subversion supports, git is just as easy to use - if not\neasier.\n\nNote that this comparison is not of features, but of interface.  Git\neasily wins in terms of features.  When it comes to using the more\nadvanced features of git, for which there is no Subversion equivalent,\nthen obviously there will be things to be learned.  This comparison\nhowever is limited to the subset of features of git that would make it\nas near an equivalent to subversion as possible.\n\n\nComparison\n----------\n\nsvn add::\nPut files and directories under version control, scheduling them for\naddition to repository.  They will be added in next commit.  This\ndoesn't really add anything, it just schedules.\ngit add::\nAdd files to the index file.  This command does not simply schedule.  It\ntakes the current contents of the file and copies it to the git staging\narea.\n\nThe git index makes this command more complicated for git; however git\nis using the verb \"add\" more correctly.  In the subversion case, nothing\nis actually added to a repository, it is merely scheduled for addition.\nAlthough one could argue that by its nature, everything in subversion is\nmerely scheduling the action.  Subversion being inherently simpler,\nmakes this easier to understand for the subversion user.\n\n\nsvn blame::\nOutput the content of specified files or URLs with revision and author\ninformation inline.\ngit blame::\nShow what revision and author last modified each line of a file.\n\nThis one is a draw.  However, in terms of output, git is signficantly\nbetter, it is much more intelligent about renames and copies and is much\nfaster.\n\n\nsvn cat::\nOutput the contents of specified files or URLs.  Optionally at a\nspecific revision.\ngit cat-file -p $(git-ls-tree $REV $file | cut -d \" \" -f 3 | cut -f 1)::\ngit-ls-tree lists the object ID for $file in revision $REV, this is cut\nout of the output and used as an argument to git-cat-file, which should\nreally be called git-cat-object, and simply dumps that object to stdout.\n\nSubversion wins.  This is a distinctly non-user friendly way of reading\na file.\n\n\nsvn checkout::\nCheckout a working copy from a repository.  You may check out an\narbitrary revision.\ngit clone::\ngit checkout::\nGit, of course, is different from subversion, as the whole repository is\nalways available.  git-checkout is nearest in concept to svn-checkout\nthough.  It changes the current working directory to a particular\nbranch.  You may not checkout an arbitrary revision.  git-clone might\nalso be considered as an svn checkout analog.  However, \n\nSubversion wins.  The output from Subversion's checkout is clear.  The\noutput from git-clone gives output that is only understandable by\nsomeone familiar with git internals.\n\n\nsvn cleanup::\nRecursively clean up the working copy, removing locks, resuming\nunfinished operations, etc.\ngit fsck-objects::\ngit prune::\ngit repack::\nCheck the repository for consistency, remove unreferenced objects, or\nrecompress existing objects.\n\nThey don't really serve the exact same purpose, but they are all\nmaintenance commands.\n\nSubversion wins, as it only has one command and you don't need to\nunderstand the repository in order to understand what its doing.\n\n\nsvn commit::\nPushes changes to the upstream respository from your working copy.\ngit commit -a::\nSaves changes to the working copy as a new revision in the local\nrepository.\n\nThe need for \"-a\" (or not) because of git's staging area (the index)\nhere makes it more confusing than svn-commit for new users.  However,\nthe ability to do \"git --amend\" more than makes up for it.  Fixing a\ntypo in your last log message is difficult in subversion.  Also, git's\ncommit message template is much better: both uses the output of their\nstatus commands which is far clearer in git than in Subversion.\n\nGit wins.\n\n\nsvn copy::\nDuplicate something in working copy or repository, remembering history.\ncp A B; git add B::\nGit doesn't have a direct equivalent of svn copy.  It's arguable whether\nit needs it once the user knows they can git-add so easily.\n\nGit wins.  Git's ability to detect copies after-the-fact, mean that a\ngit-copy isn't necessary.\n\n\nsvn delete::\nRemove files and directories from version control.\ngit rm::\nRemove files from the working copy and the staging area.\n\nGit wins.  Git wins this because it doesn't need the git-rm at all.  It\nnotices when a file has been removed anyway in git-commit -a; so for\nthis comparison, we can say that git-rm is not needed.  For more complex\ncases, were a user wants to remove a file from version control, but not\nfrom disk, git-rm might be needed.\n\n\nsvn diff::\nDisplay the differences between two paths.  Defaults to showing the\ndifferences between HEAD and the working copy.\ngit diff::\nAs for svn; but is arguably more powerful.  It also has the distinct\nadvantage that it colourises its output, making it much easier to read.\n\nGit wins.  More powerful functionality available, but its default output\nis fine as it is.\n\n\nsvn export::\nCreate an unversioned copy of a tree.\ngit archive::\nCreates an archive of the files in the named tree.\n\nGit wins.  It can make zip/tar directly and add directory prefixes\nshould you want them.  It could perhaps be a modicum easier if it had a\ndefault output format so that \"git-archive HEAD\" would do something.\n\n\nsvn help::\ngit help::\nBoth of these operate in the same way, so this one will be judged on\nutility of the output.\n\nSubversion wins.  The output from subversion often fits on a single\nscreen, and is merely there to give a reminder of what each option does.\ngit help simply forwards the user to a man page; which is very thorough,\nbut usually more than you need for a quick reference.\n\n\nsvn import::\nCommit an unversioned file or tree into the repository.\ngit-init-db; git-add::\nGit doesn't import external trees.  Mainly because it doesn't need to.\nAny directory can be quickly turned into a repository because\ngit-init-db and git-add are so fast.  It can easily be turned back\nbecause git only keeps one special directory (\".git\") at the top of the\nworking tree whereas subversion keeps one \".svn\" directory per working\ndirectory.  Conversely, there is no way in subversion to adopt an\nexisting directory structure.  It must be imported then checked out\nsomewhere else.\n\nGit wins.  It's fast and simple.  There is only the most minimal change\nto the users working tree.\n\n\nsvn info::\nDisplay information about a local or remote item.\n[no git equivalent]::\nApart from manually running git-log, git-show, git-diff, etc.  There is\nno way to get the simple summary that subversion provides about a given\nitem.\n\n\nsvn list::\nList directory entries in the repository.  Showing an arbitrary revision\nif wanted.\ngit ls-tree::\nLists the content of a tree object.\n\nSubversion wins.  The output of git-ls-tree is not user friendly; it\nrequires some understanding of git internals.\n\nsvn lock::\nsvn unlock::\nLock working copy paths in the repository so that no other user can\ncommit changes to them.\n[no git equivalent]::\nGit can't do this; nor should it.  Your repository is your own so there\nis no point in locking any part of it.\n\nGit wins.  Being distributed makes this function unnecessary in git.\nThis makes one less command to learn.\n\n\nsvn log::\nShow the log messages for a set of revision(s) and/or file(s).\ngit log::\nShow commit logs.\n\nGit wins.  The log command is equally as simple to use, but git supports\nmore output formats (--pretty=online I find particularly useful).  It\nalso colours it and formats it for much easier viewing.  It can also\naccept much more human-convenient filters (git log --since=\"2 weeks\nago\").\n\n\nsvn merge::\nApply the differences between two sources to a working copy path.\ngit pull::\nPull and merge from another repository or a local branch.\n\nIt could be argued that \"pull\" is a bad name for this command.  Apart\nfrom that however, git-pull is significantly easier to use than svn\nmerge.  It's output isn't as easy to understand, as it dumps loads of\nconfusing information to the user.\n\nGit wins.  Once you've used it, it's nowhere near as terrifying to use,\nbecause it can be easily undone.  It's harder to do damage because git\ntracks merges whereas svn doesn't.  It's better at merging.  You will\nspend a good five minutes thinking about what you must type for an\nsvn-merge.  git-pull is a no-brainer.\n\n\nsvn mkdir::\nCreate a new directory under version control.\n[no git equivalent]::\nGit doesn't track directories, so doesn't need this command.  Simply\nadding content that is in a subdirectory is sufficient.\n\nGit wins.   It does the right thing for you and you needn't remember to\nwrap your \"mkdir\"s with your VCS.  Also, one-less-command.\n\n\nsvn move::\nMove and/or rename something in working copy or repository.\ngit-mv::\nMove or rename a file, directory or symlink.\n\nGit wins.  The two are equivalent except that git can do multiple moves\nin one command, just like normal \"mv\".  So \"git mv src/* newsrc/\" works\nwhile \"svn mv src/* newsrc/\" doesn't.  Additionally, if you forget to do\nmoves with git and instead use the command line, you can easily use\n\"update-index\" to tell git about the move after the fact.  In subversion\nyou have to undo all the moves and do them again with subversion.  This\nmakes it inconvenient to use tools like \"rename\" to do regexp moves.\n\n\nsvn resolved::\nRemove 'conflicted' state on working copy files or directories.\ngit update-index::\ngit checkout::\nGit doesn't have a direct \"resolved\"; after you fix conflicts, you push\nthe changes into the staging area with \"git-update-index\".\nAlternatively you can simply accept the version in HEAD by checking out\nthat version.\n\nDraw.  \"svn-resolved\" is rubbish, as it doesn't do any checks, it just\nremoves the conflict markers.  Git could do with something that makes\nlife easier than understanding the index.\n\n\nsvn revert::\nRestore pristine working copy file (undo most local edits).\ngit reset --hard::\nReset the repository to an arbitrary point in the past, updating the\nworking copy as well.\ngit checkout -f HEAD <file>::\nChecks out <file> from HEAD, forcing an overwrite of any working\ndirectory changes to that file.\n\nDraw.  There is no easy way to undo changes that have already been\ncommitted to a subversion repository, so git would win.  However, it's\nuncomfortable to revert a single file using checkout.\n\n\nsvn status::\nPrint the status of working copy files and directories.\ngit status::\nShow working tree status.\n\nGit wins.  Git's status output is colorised and doesn't rely on you\nremembering single letter codes for file status.  Instead is arranges\nthe changes in sections and describes the status in English.  It shows\nrenames clearly, and sorts the file list instead of leaving it in a\nrandom order (which makes it difficult to find particular files).\n\n\nsvn switch::\nUpdate the working copy to a different URL.\n[no git equivalent]::\ngit is distributed and can fetch from any number of remote repositories.\nThe URL can be typed on the command line of git-fetch, or can be given a\nshortcut as a \"remote\".  If we're talking about a single repository\n(which we have to to compare against subversion), the repository is\nlocal anyway.\n\nGit wins.  Command is unnecessary.\n\n\nsvn update::\nBring changes from the repository into the working copy.\ngit fetch; git pull::\ngit-fetch synchronises a tracking branch with a remote repository.  Git\npull can be used to merge those changes into your working branch.\n\nGit wins.  The ability to track an upstream repository in a separate\nbranch, without having to merge until you're ready is a boon.  The\ncommands \"git-fetch\" and \"git-pull\" are badly named, but the fact that\nthey are separate functions makes it far less traumatic to regularly run\n\"git-fetch\" than \"svn update\".\n\n\n[no svn equivalent]::\ngit ls-files::\nInformation about files in the index/working directory.\n\nGit wins.  git-ls-files can show modified files, tracked files, ignored\nfiles, deleted files, untracked files - all in a format that is easily\npiped to other commands.  \n\n\nDiscussion\n----------\n\nWhat would git need to do to win in every section?\n\nSubversion won:\n - svn cat: the git equivalent is too complicated.\n   It wouldn't be hard to write a git-cat; if git's aliases allowed\n   pipes, it could be done instantly.\n - svn checkout: the output from git-clone is unfriendly.\n   -------------------\n   remote: Generating pack...\n   remote: Done counting 6 objects.\n   remote: Deltifying 6 objects.\n   remote:  100% (6/6) done\n   Indexing 6 objects.\n   remote: Total 6, written 6 (delta 0), reused 0 (delta 0)\n    100% (6/6) done\n   -------------------\n   What are \"objects\"?  What is deltifying?  Why does object count\n   matter to me?  What is indexing?  How much data was transferred?  How\n   long did it take?  How big is my local clone?\n   \n   While transferring: how long is it going to take to finish?  How much\n   data is there to transfer in total?\n - svn list: this only wins because the default output of git-ls-tree is\n   so user unfriendly.\n - svn cleanup: git-fsck-objects, git-prune and git-repack all need too\n   specific knowledge of git.\n   \n   They also need running too often on the user's initiative.  It would\n   be nice, for example, if git-reset, git-rebase and git-branch could\n   detect when a prune is going to be needed and give the user a hint.\n\n   As to git-repack and git-fsck-objects - when _should_ these be run?\n   How is the user meant to know?\n - svn help: subversion only won this because the help for almost every\n   command fits on a page.  Git commands have so many options that need\n   such a lot of explanation that it's almost impossible to think of a\n   way that this problem could be solved.\n\nGit draws with Subversion:\n - svn resolved: Subversion only knows files are conflicted because they\n   are marked as such.  git has good ways of detecting conflicting files\n   but has no interface around them.  It would be nice to have a\n   git-resolve command that could pick \"ours\", \"theirs\" or \"mine\" and\n   update the index accordingly.\n - svn revert: it's not easy to revert a single file in git; especially\n   once we bring the index into play.  Restoring a single file in the index\n   to HEAD while leaving the rest of the index AND the working directory\n   untouched requires something like \n   ----------------------------------------------------\n   git-ls-tree file | git-update-index --index-info\n   ----------------------------------------------------\n   Which isn't simple enough for a typical user.\n\n\nConclusion\n----------\n\nGit is a perfectly adequate Subversion replacement.  For a user who\nwould only want the features that they already have, they could surely\nget to grips with the git UI quickly.\n\n---------------------------------\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"294177","messageId":"20061213221841.GB4928@fieldses.org","threadId":"43092","inReplyTo":"200612132200.41420.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-12-13T22:18:41Z","receivedAt":"2006-12-13T22:18:41Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Dec 13, 2006 at 10:00:37PM +0000, Andy Parkins wrote:\n> svn add::\n> Put files and directories under version control, scheduling them for\n> addition to repository.  They will be added in next commit.  This\n> doesn't really add anything, it just schedules.\n> git add::\n> Add files to the index file.  This command does not simply schedule.  It\n> takes the current contents of the file and copies it to the git staging\n> area.\n> \n> The git index makes this command more complicated for git; however git\n> is using the verb \"add\" more correctly.  In the subversion case, nothing\n> is actually added to a repository, it is merely scheduled for addition.\n\nWell, you could argue whether adding something to the index is really\nadding it to \"a repository\".\n\n> svn cat::\n> Output the contents of specified files or URLs.  Optionally at a\n> specific revision.\n> git cat-file -p $(git-ls-tree $REV $file | cut -d \" \" -f 3 | cut -f 1)::\n> git-ls-tree lists the object ID for $file in revision $REV, this is cut\n> out of the output and used as an argument to git-cat-file, which should\n> really be called git-cat-object, and simply dumps that object to stdout.\n> \n> Subversion wins.  This is a distinctly non-user friendly way of reading\n> a file.\n\nStill, unfriendly, but not quite as bad:\n\n\tgit -p cat-file -p revision:path\n\n> svn diff::\n> Display the differences between two paths.  Defaults to showing the\n> differences between HEAD and the working copy.\n> git diff::\n> As for svn;\n\nthough note slightly different default.  (Diffs against index, not\nHEAD).\n\n"},{"id":"295443","messageId":"elpun9$qp1$1@sea.gmane.org","threadId":"43092","inReplyTo":"200612132200.41420.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-13T22:29:16Z","receivedAt":"2006-12-13T22:29:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"By the way, it would be nice to have this discussion added to GitWiki:\n  http://git.or.cz/gitwiki/GitSvnComparsion\n\nAndy Parkins wrote:\n\n> svn cat::\n> Output the contents of specified files or URLs.  Optionally at a\n> specific revision.\n\n> git cat-file -p $(git-ls-tree $REV $file | cut -d \" \" -f 3 | cut -f 1)::\n> git-ls-tree lists the object ID for $file in revision $REV, this is cut\n> out of the output and used as an argument to git-cat-file, which should\n> really be called git-cat-object, and simply dumps that object to stdout.\n\nYou can use extended sha1 syntax, described in git-rev-parse(1) (although\nit would be nice to have relevant parts of documentation repeated in\ngit-cat-file(1)), namely\n  git cat-file -p REV:file\n(and you can use \"git cat-file -p ::file\" to get index/staging area\nversion)\n \nAs for alias: what about \"alias.less = --paginate cat-file -p\",\nset using \"git repo-config alias.less '--paginate cat-file -p'\"?\n \n> svn cleanup::\n> Recursively clean up the working copy, removing locks, resuming\n> unfinished operations, etc.\n> git fsck-objects::\n> git prune::\n> git repack::\n> Check the repository for consistency, remove unreferenced objects, or\n> recompress existing objects.\n> \n> They don't really serve the exact same purpose, but they are all\n> maintenance commands.\n> \n> Subversion wins, as it only has one command and you don't need to\n> understand the repository in order to understand what its doing.\n\ngit-fsck-objects is needed only if something doesn't work when\nit should. \"git repack\" is safe, \"git repack -a -d\" is almost safe,\nwhile \"git prune\" is not.\n \n> svn export::\n> Create an unversioned copy of a tree.\n> git archive::\n> Creates an archive of the files in the named tree.\n> \n> Git wins.  It can make zip/tar directly and add directory prefixes\n> should you want them.  It could perhaps be a modicum easier if it had a\n> default output format so that \"git-archive HEAD\" would do something.\n\nPerhaps git-archive should support \"tree\" format, i.e. writing\nunversioned copy of a tree to filesystem.\n \n> svn resolved::\n> Remove 'conflicted' state on working copy files or directories.\n> git update-index::\n> git checkout::\n> Git doesn't have a direct \"resolved\"; after you fix conflicts, you push\n> the changes into the staging area with \"git-update-index\".\n> Alternatively you can simply accept the version in HEAD by checking out\n> that version.\n> \n> Draw.  \"svn-resolved\" is rubbish, as it doesn't do any checks, it just\n> removes the conflict markers.  Git could do with something that makes\n> life easier than understanding the index.\n\nThere was discussion about adding thin wrapper around git-update-index\nto specifically mark resolved merge conflicts. The option to pick up\nours, theirs, ancestor version is another argument for having such command.\n \n> svn revert::\n> Restore pristine working copy file (undo most local edits).\n> git reset --hard::\n> Reset the repository to an arbitrary point in the past, updating the\n> working copy as well.\n> git checkout -f HEAD <file>::\n> Checks out <file> from HEAD, forcing an overwrite of any working\n> directory changes to that file.\n> \n> Draw.  There is no easy way to undo changes that have already been\n> committed to a subversion repository, so git would win.  However, it's\n> uncomfortable to revert a single file using checkout.\n\nThere was talk about adding \"git reset [<commit-ish>] -- <file>\".\n\n> Discussion\n> ----------\n> \n> What would git need to do to win in every section?\n> \n> Subversion won:\n>  - svn cat: the git equivalent is too complicated.\n>    It wouldn't be hard to write a git-cat; if git's aliases allowed\n>    pipes, it could be done instantly.\n\nIt can be done without pipes: \"git cat-file -p REV:file\".\nYou can use aliases to have shorter name for that.\n\n>  - svn checkout: the output from git-clone is unfriendly.\n>    -------------------\n>    remote: Generating pack...\n>    remote: Done counting 6 objects.\n>    remote: Deltifying 6 objects.\n>    remote:  100% (6/6) done\n>    Indexing 6 objects.\n>    remote: Total 6, written 6 (delta 0), reused 0 (delta 0)\n>     100% (6/6) done\n>    -------------------\n>    What are \"objects\"?  What is deltifying?  Why does object count\n>    matter to me?  What is indexing?  How much data was transferred?  How\n>    long did it take?  How big is my local clone?\n>    \n>    While transferring: how long is it going to take to finish?  How much\n>    data is there to transfer in total?\n\nHmmm... I thought that some progress indicator of download/upload was\nadded... guess I was wrong.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296013","messageId":"200612132251.17202.andyparkins@gmail.com","threadId":"43092","inReplyTo":"elpun9$qp1$1@sea.gmane.org","subject":"Re: svn versus git","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-13T22:51:15Z","receivedAt":"2006-12-13T22:51:15Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"\n> You can use extended sha1 syntax, described in git-rev-parse(1) (although\n> it would be nice to have relevant parts of documentation repeated in\n> git-cat-file(1)), namely\n>   git cat-file -p REV:file\n> (and you can use \"git cat-file -p ::file\" to get index/staging area\n> version)\n\nYes; I didn't remember that one.  However, it's still not friendly.\n\n> git-fsck-objects is needed only if something doesn't work when\n> it should. \"git repack\" is safe, \"git repack -a -d\" is almost safe,\n> while \"git prune\" is not.\n\nYes - /I/ know that; bear in mind though that this is intended as a comparison \nagainst subversion for a user who doesn't want to know how it works.  How is \nthat sort of user meant to know when they should run each of these commands?  \nGit doesn't tell them, it doesn't even give hints.  As you say, \"git-prune\" \nis not necessarilly safe - how does a new user know that?  It's in the output \nof \"git\".\n\n> Perhaps git-archive should support \"tree\" format, i.e. writing\n> unversioned copy of a tree to filesystem.\n\nI think git is pretty good in the archive department.  git-archive does \nexactly what it says on the tin, which is exactly what you would want.\n\n> There was discussion about adding thin wrapper around git-update-index\n> to specifically mark resolved merge conflicts. The option to pick up\n> ours, theirs, ancestor version is another argument for having such command.\n\nI think it's definitely a good idea.  If you introduce git-update-index as a \ncommand a normal user will type, you've got a lot of explaining to do as to \nwhat else it does and why it does it.\n\n> It can be done without pipes: \"git cat-file -p REV:file\".\n> You can use aliases to have shorter name for that.\n\nThis is the problem though.  I realise that git can technically do an awful \nlot of these things, how many new users are going to stick around when you \ntell them that they have to learn about the config file and aliases before \nthey can use the command they want?\n\n> Hmmm... I thought that some progress indicator of download/upload was\n> added... guess I was wrong.\n\nYou're not wrong, there is a progress indicator, but it's measured \nin \"objects\" not megabytes.  It's got a percentage as well.  Neither of these \nthings is a whole lot of use if I want to know how much data (in megabytes) \nhas been transferred, how much is there left to go and how long is it going \nto take.\n\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"298166","messageId":"20061213225627.GC32568@spearce.org","threadId":"43092","inReplyTo":"200612132200.41420.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-13T22:56:27Z","receivedAt":"2006-12-13T22:56:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> wrote:\n> svn cat::\n> Output the contents of specified files or URLs.  Optionally at a\n> specific revision.\n> git cat-file -p $(git-ls-tree $REV $file | cut -d \" \" -f 3 | cut -f 1)::\n\nbetter:\n\n  git cat-file -p $REV:$file\n\nnot sure how much easier it gets than that.  Load in the bash\ncompletion from contrib/completion and you can even tab complete\nthe $file part.\n\n> Subversion wins.  This is a distinctly non-user friendly way of reading\n> a file.\n\nDocumentation flaw that the above wasn't clear?  Or is \"-file\" and\n\"-p\" the losing part for Git?\n \n> svn cleanup::\n> git fsck-objects::\n> git prune::\n> git repack::\n> \n> Subversion wins, as it only has one command and you don't need to\n> understand the repository in order to understand what its doing.\n\nTrue, but I'm not sure its fair to Git.  svn cleanup is also a\ntechnical command that one needs to learn either when something\nwent wrong or later once the user has gotten used to using SVN.\nGit's fsck-objects, prune and repack aren't usually needed until\nthe user has had a chance to use it for a while and accumulate a\nnumber of loose objects.\n\nThe last time I ran fsck-objects was when I was trying to debug\nthat empty tree object missing in git-merge-recursive.  Usually I\ndon't see repository corruption, and even there wasn't any.\n\n> svn merge::\n> Apply the differences between two sources to a working copy path.\n> git pull::\n> Pull and merge from another repository or a local branch.\n> \n> It could be argued that \"pull\" is a bad name for this command.  Apart\n> from that however, git-pull is significantly easier to use than svn\n> merge.  It's output isn't as easy to understand, as it dumps loads of\n> confusing information to the user.\n\nor git merge now.  :-)\n \n> Git wins.  Once you've used it, it's nowhere near as terrifying to use,\n> because it can be easily undone.  It's harder to do damage because git\n> tracks merges whereas svn doesn't.  It's better at merging.  You will\n> spend a good five minutes thinking about what you must type for an\n> svn-merge.  git-pull is a no-brainer.\n\nThis is one of Git's killer features over SVN.  Git does merges\nright.  SVN doesn't.  Though I keep hearing its on their TODO list.\n\n> svn mkdir::\n> Create a new directory under version control.\n> [no git equivalent]::\n> Git doesn't track directories, so doesn't need this command.  Simply\n> adding content that is in a subdirectory is sufficient.\n> \n> Git wins.   It does the right thing for you and you needn't remember to\n> wrap your \"mkdir\"s with your VCS.  Also, one-less-command.\n\nSome people like having the empty directory tracked by the VCS, as\nthen the build system doesn't need to create it.  I perfer keeping\nall object files in a single directory which the build system\ncreates, as cleaning up is just \"rm -rf output\" (or whatever it is)\nso I could care less about empty directory tracking; I think most\npeople are that way.\n \n>  - svn cat: the git equivalent is too complicated.\n>    It wouldn't be hard to write a git-cat; if git's aliases allowed\n>    pipes, it could be done instantly.\n\nSee above.\n\n>  - svn list: this only wins because the default output of git-ls-tree is\n>    so user unfriendly.\n\nHow is it unfriendly?  What specifically would you change to make\nit more friendly?\n\n>  - svn cleanup: git-fsck-objects, git-prune and git-repack all need too\n>    specific knowledge of git.\n>    \n>    They also need running too often on the user's initiative.  It would\n>    be nice, for example, if git-reset, git-rebase and git-branch could\n>    detect when a prune is going to be needed and give the user a hint.\n\nYou don't want to prune every time these happen.  When you start to\nmake use of the reflog pruning too often is a huge loss.  I actually\nmaybe prune my active repositories once every couple of months,\nthe extra garbage hanging out is usually peanuts.\n \n>    As to git-repack and git-fsck-objects - when _should_ these be run?\n>    How is the user meant to know?\n\nAs to the former it depends on your OS (Windows you want to pack\nmore often) but git-count-objects gives you a good indication of how\nmany loose objects exist.  git-fsck-objects probably only needs to\nbe run if something is not working right and you suspect an object\nis missing.\n\n-- \n"},{"id":"294043","messageId":"elq1c8$37d$1@sea.gmane.org","threadId":"43092","inReplyTo":"200612132251.17202.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-13T23:14:37Z","receivedAt":"2006-12-13T23:14:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n>> Hmmm... I thought that some progress indicator of download/upload was\n>> added... guess I was wrong.\n> \n> You're not wrong, there is a progress indicator, but it's measured \n> in \"objects\" not megabytes.  It's got a percentage as well.  Neither of these \n> things is a whole lot of use if I want to know how much data (in megabytes) \n> has been transferred, how much is there left to go and how long is it going \n> to take.\n\nNo, what you see is if I understand correctly progress indicator for\nlocal and remote generating pack to send / exploding pack into loose\nobjects (or not). There was some patch to add download/upload progress\nindicator, but I guess it was not applied.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297787","messageId":"20061213231754.GD32568@spearce.org","threadId":"43092","inReplyTo":"elq1c8$37d$1@sea.gmane.org","subject":"Re: svn versus git","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-13T23:17:54Z","receivedAt":"2006-12-13T23:17:54Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> wrote:\n> Andy Parkins wrote:\n> \n> >> Hmmm... I thought that some progress indicator of download/upload was\n> >> added... guess I was wrong.\n> > \n> > You're not wrong, there is a progress indicator, but it's measured \n> > in \"objects\" not megabytes.  It's got a percentage as well.  Neither of these \n> > things is a whole lot of use if I want to know how much data (in megabytes) \n> > has been transferred, how much is there left to go and how long is it going \n> > to take.\n> \n> No, what you see is if I understand correctly progress indicator for\n> local and remote generating pack to send / exploding pack into loose\n> objects (or not). There was some patch to add download/upload progress\n> indicator, but I guess it was not applied.\n\nThere is one that gets started when the transfer is taking a while,\nbut it shows the total number of MiB transferred and the current\ntransfer rate.  I don't think there's a way to tell when it will be\ndone, just that its running and running slower than you might like.\n:-)\n\nPart of the problem is the remote end doesn't know how many bytes\nare needed for the pack its sending until after it has finished\nsending the pack.  Sort of a catch-22.\n\n-- \n"},{"id":"295681","messageId":"elq1ig$4ie$1@sea.gmane.org","threadId":"43092","inReplyTo":"20061213225627.GC32568@spearce.org","subject":"Re: svn versus git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-13T23:17:56Z","receivedAt":"2006-12-13T23:17:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn Pearce wrote:\n\n>   git cat-file -p $REV:$file\n> \n> not sure how much easier it gets than that.  Load in the bash\n> completion from contrib/completion and you can even tab complete\n> the $file part.\n\nActually, tab completion allows to complete both $REV and $file part.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295496","messageId":"20061213232056.11218.67473.stgit@lathund.dewire.com","threadId":"43092","inReplyTo":"20061213221841.GB4928@fieldses.org","subject":"[PATCH] Document the simple way of using of git-cat-file","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2006-12-13T23:20:57Z","receivedAt":"2006-12-13T23:20:57Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"From: Robin Rosenberg <robin.rosenberg@dewire.com>\n\nSince you can give a version and a path name to git-cat-file,\nmention it in the man page.\n\nSigned-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>\n---\n\n Documentation/git-cat-file.txt |    8 ++++++--\n 1 files changed, 6 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt\nindex 5e9cbf8..7abbf27 100644\n--- a/Documentation/git-cat-file.txt\n+++ b/Documentation/git-cat-file.txt\n@@ -8,13 +8,14 @@ git-cat-file - Provide content or type i\n \n SYNOPSIS\n --------\n-'git-cat-file' [-t | -s | -e | -p | <type>] <object>\n+'git-cat-file' [-t | -s | -e | -p | <type>] [<object> | <commit-ish>:<path> ]\n \n DESCRIPTION\n -----------\n Provides content or type of objects in the repository. The type\n is required unless '-t' or '-p' is used to find the object type,\n-or '-s' is used to find the object size.\n+or '-s' is used to find the object size. The more user friendly variant\n+takes a revision and a path name corresponding to the blob you want to see.\n \n OPTIONS\n -------\n@@ -57,6 +58,9 @@ If '-p' is specified, the contents of <o\n Otherwise the raw (though uncompressed) contents of the <object> will\n be returned.\n \n+If you don't know the object id, you can supply a version identifies,\n+such as a branch name, a commit id or tag followed by a colon and a\n+path name.\n \n Author\n"},{"id":"296205","messageId":"200612140024.17739.robin.rosenberg.lists@dewire.com","threadId":"43092","inReplyTo":"200612132200.41420.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-12-13T23:24:17Z","receivedAt":"2006-12-13T23:24:17Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 13 december 2006 23:00 skrev Andy Parkins:\n[...]\n> svn checkout::\n> Checkout a working copy from a repository.  You may check out an\n> arbitrary revision.\n> git clone::\n> git checkout::\n> Git, of course, is different from subversion, as the whole repository is\n> always available.  git-checkout is nearest in concept to svn-checkout\n> though.  It changes the current working directory to a particular\n> branch.  You may not checkout an arbitrary revision.  git-clone might\n> also be considered as an svn checkout analog.  However,\n>\n> Subversion wins.  The output from Subversion's checkout is clear.  The\n> output from git-clone gives output that is only understandable by\n> someone familiar with git internals.\nI'd say svn clone is the nearest equivalent as it does the initial fetch of \ndata, no checkout is necessary after clone. it checks out master. Then\nyou git-checkout to switch branch, which corresponds to svn switch.\n\n> svn commit::\n> Pushes changes to the upstream respository from your working copy.\n> git commit -a::\n> Saves changes to the working copy as a new revision in the local\n> repository.\n>\n> The need for \"-a\" (or not) because of git's staging area (the index)\n> here makes it more confusing than svn-commit for new users.  However,\n> the ability to do \"git --amend\" more than makes up for it.  Fixing a\n> typo in your last log message is difficult in subversion.  Also, git's\n> commit message template is much better: both uses the output of their\n> status commands which is far clearer in git than in Subversion.\n>\n> Git wins.\nYou'll need to push too in order to get a copy in a central repository. \ngit-commit stays locally, and you need a place to push to. If your SVN\nrepo isn't local this does not apply. git gives more freedom here.\n\n> svn copy::\n> Duplicate something in working copy or repository, remembering history.\n> cp A B; git add B::\n> Git doesn't have a direct equivalent of svn copy.  It's arguable whether\n> it needs it once the user knows they can git-add so easily.\n>\n> Git wins.  Git's ability to detect copies after-the-fact, mean that a\n> git-copy isn't necessary.\nsvn copy is more like git checout -b, i.e. it's primary purpose is not \nto \"copy\" things, it is to create branches. You generally do not copy\ncode (I hope).\n\n> svn move::\n> Move and/or rename something in working copy or repository.\n> git-mv::\n> Move or rename a file, directory or symlink.\n>\n> Git wins.  The two are equivalent except that git can do multiple moves\n> in one command, just like normal \"mv\".  So \"git mv src/* newsrc/\" works\n> while \"svn mv src/* newsrc/\" doesn't.  Additionally, if you forget to do\n> moves with git and instead use the command line, you can easily use\n> \"update-index\" to tell git about the move after the fact.  In subversion\n> you have to undo all the moves and do them again with subversion.  This\n> makes it inconvenient to use tools like \"rename\" to do regexp moves.\nIn svn this also renames a branch.\n\n> svn switch::\n> Update the working copy to a different URL.\n> [no git equivalent]::\n> git is distributed and can fetch from any number of remote repositories.\n> The URL can be typed on the command line of git-fetch, or can be given a\n> shortcut as a \"remote\".  If we're talking about a single repository\n> (which we have to to compare against subversion), the repository is\n> local anyway.\n>\n> Git wins.  Command is unnecessary.\nsvn switch corresponds to git-checkout. I don't think you can change the URL\nunless the new URL actually points to the same repository.\n\n> Discussion\n> ----------\n[...]\n>  - svn revert: it's not easy to revert a single file in git; especially\n>    once we bring the index into play.  Restoring a single file in the index\n>    to HEAD while leaving the rest of the index AND the working directory\n>    untouched requires something like\n>    ----------------------------------------------------\n>    git-ls-tree file | git-update-index --index-info\n>    ----------------------------------------------------\n>    Which isn't simple enough for a typical user.\nTypically the user want to restore the index AND the working directory. \nComparing typical workflows is more interesting than finding exact \nequivalents.\n\n"},{"id":"293992","messageId":"20061213232637.GF32568@spearce.org","threadId":"43092","inReplyTo":"elq1ig$4ie$1@sea.gmane.org","subject":"Re: svn versus git","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-13T23:26:37Z","receivedAt":"2006-12-13T23:26:37Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> wrote:\n> Shawn Pearce wrote:\n> \n> >   git cat-file -p $REV:$file\n> > \n> > not sure how much easier it gets than that.  Load in the bash\n> > completion from contrib/completion and you can even tab complete\n> > the $file part.\n> \n> Actually, tab completion allows to complete both $REV and $file part.\n\nGood point.  Unless $REV is a SHA1 in hex format, as tab completion\nfor commits in hex SHA1 isn't supported.\n\nThough I have thought about implementing it.  ;-)\n\n-- \n"},{"id":"296052","messageId":"slrneo13co.o4k.Peter.B.Baumann@xp.machine.xx","threadId":"43092","inReplyTo":"elpun9$qp1$1@sea.gmane.org","subject":"Re: svn versus git","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2006-12-13T23:32:40Z","receivedAt":"2006-12-13T23:32:40Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"[...]\n>> svn revert::\n>> Restore pristine working copy file (undo most local edits).\n>> git reset --hard::\n>> Reset the repository to an arbitrary point in the past, updating the\n>> working copy as well.\n>> git checkout -f HEAD <file>::\n>> Checks out <file> from HEAD, forcing an overwrite of any working\n>> directory changes to that file.\n>> \n>> Draw.  There is no easy way to undo changes that have already been\n>> committed to a subversion repository, so git would win.  However, it's\n>> uncomfortable to revert a single file using checkout.\n>\n> There was talk about adding \"git reset [<commit-ish>] -- <file>\".\n>\n\nI would appreciate this. The first thing which comes to my mind if I\nhave to actualy revert a change I made was\n\n\tgit reset file\n\nAfter that didn't work I figured out I have to use the seperating -- and typed\n\n\tgit reset -- file\n\nand that didn't work, too. After several hours (ok, I'am just\nexaggerating, it took me only about 15 minutes) reading manpages I figured out\nthat I have to use   git checkout [<revision>] -- file\n\nAfter putting some thought into the mental model behind git checkout -- file\nthis command it looks obvious and understantable, but in _my_ mental modell\n\n\tgit reset [<revision] -- file\n\nwould be a much better fit.\n\n-Peter\n"},{"id":"295459","messageId":"7vfybjbbsx.fsf@assigned-by-dhcp.cox.net","threadId":"43092","inReplyTo":"200612132200.41420.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-13T23:45:02Z","receivedAt":"2006-12-13T23:45:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> ...  The output of git-ls-tree is not user friendly; it\n> requires some understanding of git internals.\n\nls-tree is not Porcelain and has right to expose the internals\nby default.  \"git ls-tree --name-only\" could be aliased to give\n\"git ls\" if you wanted to, but I wonder how often you would want\nto run:\n\n\tsvn list -r538\n\nand for what purpose?\n\nI often find myself doing\n\n\tgit diff -r --name-status v1.3.0 HEAD\n\nto check if a file was already in v1.3.0 version, and I could do\nthe same thing with\n\n\tgit list v1.3.0 >/var/tmp/1\n        git list HEAD >/var/tmp/2\n        diff -u /var/tmp/[12]\n\nbut that certainly is awkward.\n\nWhat do people use \"svn list -r538\" for and how often?  In other\nwords, when does it become necessary to get the full list of\npaths in an arbitrary revision?\n\n"},{"id":"298767","messageId":"elq3pa$93b$1@sea.gmane.org","threadId":"43092","inReplyTo":"20061213232056.11218.67473.stgit@lathund.dewire.com","subject":"Re: [PATCH] Document the simple way of using of git-cat-file","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-13T23:55:43Z","receivedAt":"2006-12-13T23:55:43Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robin Rosenberg wrote:\n\n> Since you can give a version and a path name to git-cat-file,\n> mention it in the man page.\n\nVery nice, with the exception that git cat-file can be used also\nfor trees and commits (although hit-ls-tree and git-show are usually\nused) and for tags, not only for files.\n\nI thought rather about copying last (or two last) entries about\nextended sha1 syntax from git-rev-parse(1).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294432","messageId":"Pine.LNX.4.63.0612140127520.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43092","inReplyTo":"elq3pa$93b$1@sea.gmane.org","subject":"Re: [PATCH] Document the simple way of using of git-cat-file","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T00:29:17Z","receivedAt":"2006-12-14T00:29:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Dec 2006, Jakub Narebski wrote:\n\n> Robin Rosenberg wrote:\n> \n> > Since you can give a version and a path name to git-cat-file,\n> > mention it in the man page.\n> \n> Very nice, with the exception that git cat-file can be used also\n> for trees and commits (although hit-ls-tree and git-show are usually\n> used) and for tags, not only for files.\n\nThe point is: you are much more likely to look at a blob that at a tree. \nAnd if you want to do that, you can always use git-ls-tree.\n\nBut as I mentioned in another thread, I'd rather see git-show do the job \nof showing blobs, too, in addition to commits as it does already.\n\nCiao,\nDscho\n"},{"id":"294436","messageId":"200612140135.33745.jnareb@gmail.com","threadId":"43092","inReplyTo":"Pine.LNX.4.63.0612140127520.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Document the simple way of using of git-cat-file","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-14T00:35:32Z","receivedAt":"2006-12-14T00:35:32Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Thu, 14 Dec 2006, Jakub Narebski wrote:\n> \n>> Robin Rosenberg wrote:\n>> \n>>> Since you can give a version and a path name to git-cat-file,\n>>> mention it in the man page.\n>> \n>> Very nice, with the exception that git cat-file can be used also\n>> for trees and commits (although hit-ls-tree and git-show are usually\n>> used) and for tags, not only for files.\n> \n> The point is: you are much more likely to look at a blob that at a tree. \n> And if you want to do that, you can always use git-ls-tree.\n> \n> But as I mentioned in another thread, I'd rather see git-show do the job \n> of showing blobs, too, in addition to commits as it does already.\n\nMore important is that git-cat-file is used for _tags_; git-show used\nfor tag takes tag as <commit-ish>, so it cannot show tag.\n-- \nJakub Narebski\n"},{"id":"294064","messageId":"200612140908.36952.andyparkins@gmail.com","threadId":"43092","inReplyTo":"20061213225627.GC32568@spearce.org","subject":"Re: svn versus git","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T09:08:34Z","receivedAt":"2006-12-14T09:08:34Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:\n\n>   git cat-file -p $REV:$file\n>\n> not sure how much easier it gets than that.  Load in the bash\n> completion from contrib/completion and you can even tab complete\n> the $file part.\n\nYes.  I was a little unfair on that one; I forgot about the REV:file syntax.  \nHowever, it's still not simple for a new user; I think I'd say \"draw\" if \nthe \"-p\" weren't a requirement.\n\n> Documentation flaw that the above wasn't clear?  Or is \"-file\" and\n> \"-p\" the losing part for Git?\n\nYep.  Especially when combined with the fact that the command is called \ngit-cat-file.  A new user could be forgiven for thinking that meant that they \ncould cat one of their files held by git.  Also: they have to read a man page \nto find out that they need an option and which option is correct.  I reckon \ngit-cat-object would be a better name (\"no chance!\", I hear you cry ;-))\n\nI've just noticed as well that the documentation is wrong:\n $ git-cat-file HEAD:Makefile\n usage: git-cat-file [-t|-s|-e|-p|<type>] <sha1>\nThe square brackets indicate \"optional\", and those items clearly aren't.  I'll \nfix the documentation.\n\n> > svn cleanup::\n> > git fsck-objects::\n> > git prune::\n> > git repack::\n> >\n> > Subversion wins, as it only has one command and you don't need to\n> > understand the repository in order to understand what its doing.\n>\n> True, but I'm not sure its fair to Git.  svn cleanup is also a\n> technical command that one needs to learn either when something\n> went wrong or later once the user has gotten used to using SVN.\n\nMy point is that a user can run \"svn cleanup\" without thinking, or needing to \nreally know what it does.  Not so for git's maintenance commands.  Also, \nthere are more commands.  I'm not saying they're not useful or necessary, but \nit's certainly more complicated than subversion.\n\nFor example: I used subversion for a long time - I don't think I ever had \ncause to run \"cleanup\", I'm not even really sure what it does.  I /have/ had \ncause to learn what git's maintenance commands do; which in turn meant I had \nto learn how the git repository works.  (I personally don't mind learning \nthose things, but it's wrong to expect every user to do so).\n\n> The last time I ran fsck-objects was when I was trying to debug\n> that empty tree object missing in git-merge-recursive.  Usually I\n> don't see repository corruption, and even there wasn't any.\n\nMe too.  I've never run it in fact; but the command exists and therefore needs \nlearning.\n\n> or git merge now.  :-)\n\nHurrah!  However, at the time I wrote the comparison (and with \n1.4.4.1.g3ece-dirty I've got here) git-merge is still the old, more \ncomplicated, command line.\n\n> This is one of Git's killer features over SVN.  Git does merges\n> right.  SVN doesn't.  Though I keep hearing its on their TODO list.\n\nAbsolutely.  Although, even if SVN does implement it, it's going to be a hack.  \nIt'll just be an extra svn:special property set somewhere in the repository, \nor similar.  I can't see how they can do merges properly with the methodology \nthat SVN uses.\n\n> Some people like having the empty directory tracked by the VCS, as\n> then the build system doesn't need to create it.  I perfer keeping\n\nYou're right; as it happens I'd prefer it if git could store empty \ndirectories.  However, in terms of \"what I have to learn\", git definitely \nwins this category because there is nothing to learn - make whatever \ndirectories you like; it will generally sort itself out.\n\n> How is it unfriendly?  What specifically would you change to make\n> it more friendly?\n\n$ git-ls-tree v1.0.0\n100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8    Makefile\n\nI'm a newbie:  what's that number at the front?  What's a blob?  What's that \ngreat big number - I've only seen commit hashes that look like that, and that \nisn't one.  Definitely not friendly.\n\n$ svn list -r 14\nMakefile\n\nIt could probably be fixed by making git-ls-files capable of understanding \ntree-ish.\n\n> >  - svn cleanup: git-fsck-objects, git-prune and git-repack all need too\n> >    specific knowledge of git.\n> >\n> >    They also need running too often on the user's initiative.  It would\n> >    be nice, for example, if git-reset, git-rebase and git-branch could\n> >    detect when a prune is going to be needed and give the user a hint.\n>\n> You don't want to prune every time these happen.  When you start to\n\nYou are correct of course.  They don't need running regularly, and in a way \nthat makes it worse.  How is a user who isn't familiar with git internals \nmeant to know they should run git-prune?  How are they meant to know when \nthey should run it?  How are they meant to know that it is git-reset, et al, \nthat create conditions that need them to run git-prune?\n\n> make use of the reflog pruning too often is a huge loss.  I actually\n> maybe prune my active repositories once every couple of months,\n> the extra garbage hanging out is usually peanuts.\n\nPersonally I like my repository pruned fairly often.  This makes it much \neasier to find the commit I need to restore when I've accidentally done a \ngit-reset I didn't mean to.  If I had to search through three months worth of \ndead objects it would take me all day.  However, I don't think that affects a \nnew user at all.  Recovery from disasters should be expected to be hard.\n\n> As to the former it depends on your OS (Windows you want to pack\n> more often) but git-count-objects gives you a good indication of how\n> many loose objects exist.  git-fsck-objects probably only needs to\n> be run if something is not working right and you suspect an object\n> is missing.\n\nYep, /I/ know.  How is my imaginary new user meant to know?\n\nMy rhetorical questions are the key to making git friendly I think.  Each one \nrepresents a hole - it's not that there is no answer, it's that there \nshouldn't be a question.  The hard part (as always I suppose) is that we have \nto imagine a new user; this makes all my babblings above highly subjective.  \nAs such I won't be that upset if I'm told to \"blow it out my ear\".  Whatever \nthat means.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"295838","messageId":"200612140919.30495.andyparkins@gmail.com","threadId":"43092","inReplyTo":"7vfybjbbsx.fsf@assigned-by-dhcp.cox.net","subject":"Re: svn versus git","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T09:19:29Z","receivedAt":"2006-12-14T09:19:29Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 December 13 23:45, Junio C Hamano wrote:\n\n> ls-tree is not Porcelain and has right to expose the internals\n\nOf course; but there is no porcelain to do that operation.\n\n> by default.  \"git ls-tree --name-only\" could be aliased to give\n> \"git ls\" if you wanted to, but I wonder how often you would want\n> to run:\n>\n> \tsvn list -r538\n>\n> and for what purpose?\n\nI've never done it.  However, the command is there in subversion, so I was \ncomparing git's implementation of that command.  I wouldn't completely write \nit off though.  It doesn't seem unreasonable to want to see what files were \nin an old revision.\n\n> I often find myself doing\n> \tgit diff -r --name-status v1.3.0 HEAD\n\nI can live with that as an acceptable alternative to \"svn list\"; however, as \nusual, how does my imaginary ex-svn user find out about that?  man git-diff \nisn't the first place /I'd/ go; and even if you do, you won't find the \"-r\" \nor \"--name-status\" options; you have to go to git-diff-files, git-diff-index \nor git-diff-tree - and you're meant to guess which is the right one.\n\nBear in mind that my current theme isn't \"can git do...?\" it's \"how does a \nuser know that git can do...?\"\n\n> What do people use \"svn list -r538\" for and how often?  In other\n> words, when does it become necessary to get the full list of\n> paths in an arbitrary revision?\n\nMe: I don't do it often.  It's not something I'd lose sleep over if git \ndoesn't have an easy way of doing it.  However, it was in the output \nof \"svn --help\"; so I included it.\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294952","messageId":"7vodq695ha.fsf@assigned-by-dhcp.cox.net","threadId":"43092","inReplyTo":"200612140908.36952.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-14T09:44:33Z","receivedAt":"2006-12-14T09:44:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:\n>\n>>   git cat-file -p $REV:$file\n>>\n>> not sure how much easier it gets than that.  Load in the bash\n>> completion from contrib/completion and you can even tab complete\n>> the $file part.\n>\n> Yes.  I was a little unfair on that one; I forgot about the REV:file syntax.  \n> However, it's still not simple for a new user; I think I'd say \"draw\" if \n> the \"-p\" weren't a requirement.\n\nI would say pretending as if cat-file is a Porcelain is the\nunfair part.\n\n> $ git-ls-tree v1.0.0\n> 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8    Makefile\n>\n> I'm a newbie:  what's that number at the front?  What's a blob?  What's that \n> great big number - I've only seen commit hashes that look like that, and that \n> isn't one.  Definitely not friendly.\n\nAgain, mistaking ls-tree as if it was a Porcelain is the true\ncause of the newbie confusion.\n\n> It could probably be fixed by making git-ls-files capable of understanding \n> tree-ish.\n\nI think that's a wrong way to go about.  The primary purpose of\nls-files is to read the index and show information around it;\nls-tree is about reading one tree and show information around\nit.  They are both plumbing and meant to be used by scripts when\nthey want to inspect the index or a tree respectively.\n\nIf a Porcelain level \"ls\" is needed (and I am doubtful about\nusefulness of \"svn list -r538\" like command), that is the\ncommand you would want to teach about using ls-files and ls-tree\ndepending on what the end users want in their workflow.\n"},{"id":"298447","messageId":"200612141042.09453.andyparkins@gmail.com","threadId":"43092","inReplyTo":"7vodq695ha.fsf@assigned-by-dhcp.cox.net","subject":"Re: svn versus git","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-14T10:42:08Z","receivedAt":"2006-12-14T10:42:08Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 December 14 09:44, Junio C Hamano wrote:\n\n> I would say pretending as if cat-file is a Porcelain is the\n> unfair part.\n\nI had to; there is no other equivalent of \"svn cat\" in git.\n\n> Again, mistaking ls-tree as if it was a Porcelain is the true\n> cause of the newbie confusion.\n\nAgain, there is no other equivalent of \"svn list\" in git.\n\n> If a Porcelain level \"ls\" is needed (and I am doubtful about\n> usefulness of \"svn list -r538\" like command), that is the\n\nMe too.  I was in no way advocating that git should try to be SVN (shudder).  \nAs I was comparing though, I had to pick git commands that did at least what \nSVN could do.\n\n> command you would want to teach about using ls-files and ls-tree\n> depending on what the end users want in their workflow.\n\nPersonally, I think qgit fills an awfully big hole in svn that makes them all \nirrelevant.  qgit is a much better repository browsing tool than \"svn list\" \nis.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296439","messageId":"fcaeb9bf0612140708w6bc691f6k2e08fbab2a651421@mail.gmail.com","threadId":"43092","inReplyTo":"7vodq695ha.fsf@assigned-by-dhcp.cox.net","subject":"Re: svn versus git","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-12-14T15:08:28Z","receivedAt":"2006-12-14T15:08:28Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 12/14/06, Junio C Hamano <junkio@cox.net> wrote:\n> If a Porcelain level \"ls\" is needed (and I am doubtful about\n> usefulness of \"svn list -r538\" like command), that is the\n> command you would want to teach about using ls-files and ls-tree\n> depending on what the end users want in their workflow.\n\n+1. Any chance git-ls can go to 1.5.0?\n-- \n"},{"id":"294709","messageId":"Pine.LNX.4.63.0612141630240.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43092","inReplyTo":"fcaeb9bf0612140708w6bc691f6k2e08fbab2a651421@mail.gmail.com","subject":"Re: svn versus git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T15:31:15Z","receivedAt":"2006-12-14T15:31:15Z","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, Nguyen Thai Ngoc Duy wrote:\n\n> On 12/14/06, Junio C Hamano <junkio@cox.net> wrote:\n> > If a Porcelain level \"ls\" is needed (and I am doubtful about\n> > usefulness of \"svn list -r538\" like command), that is the\n> > command you would want to teach about using ls-files and ls-tree\n> > depending on what the end users want in their workflow.\n> \n> +1. Any chance git-ls can go to 1.5.0?\n\nTwo questions arise naturally:\n\n- what do you need it for?\n\n- have you seen the patch for git-show today, which would include this \nfunctionality?\n\nCiao,\nDscho\n"},{"id":"298606","messageId":"m2slfilbfi.fsf@ziti.local","threadId":"43092","inReplyTo":"20061213225627.GC32568@spearce.org","subject":"Re: svn versus git","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2006-12-14T15:55:13Z","receivedAt":"2006-12-14T15:55:13Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> Andy Parkins <andyparkins@gmail.com> wrote:\n>> svn cat::\n>> Output the contents of specified files or URLs.  Optionally at a\n>> specific revision.\n>> git cat-file -p $(git-ls-tree $REV $file | cut -d \" \" -f 3 | cut -f 1)::\n>\n> better:\n>\n>   git cat-file -p $REV:$file\n\nFWIW, after some amount of git experience, I had a need for git\ncat-file and I found it hard to use.  Why?  Because following the\npattern of some other commands, I really expected the following to work:\n\n   git cat-file -p HEAD^2 $file\n\nSince that is similar to\n\n   git diff HEAD^^ $file\n   git checkout HEAD $file\n   \nWhere else uses the colon syntax?\n\nMy $0.02.\n\n"},{"id":"296487","messageId":"fcaeb9bf0612140832v1c80bf7dgd61897111292d31@mail.gmail.com","threadId":"43092","inReplyTo":"Pine.LNX.4.63.0612141630240.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: svn versus git","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-12-14T16:32:57Z","receivedAt":"2006-12-14T16:32:57Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi,\n\nOn 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Two questions arise naturally:\n>\n> - what do you need it for?\n\nfor being user-friendly and consistent. Git porcelain commands seem to\nbe grouped by function. So it would be natural to have git-ls as a\nfront-end for both ls-files and ls-tree. I don't really care about\nls-tree but I do about ls-files to examine index.\n\n> - have you seen the patch for git-show today, which would include this\n> functionality?\n\nI didn't. From the patch, it seems git-show can show the index via\n::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is\nnot intuitive though. Perhaps you should mention that it can show\nindex (and how) in the git-show document\n-- \n"},{"id":"296350","messageId":"Pine.LNX.4.63.0612141754420.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43092","inReplyTo":"fcaeb9bf0612140832v1c80bf7dgd61897111292d31@mail.gmail.com","subject":"Re: svn versus git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T16:55:43Z","receivedAt":"2006-12-14T16:55: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, Nguyen Thai Ngoc Duy wrote:\n\n> On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > Two questions arise naturally:\n> > \n> > - what do you need it for?\n> \n> for being user-friendly and consistent.\n\nOkay, I only thought you had a use case, which could have been possibly \nbetter served by other commands.\n\n> > - have you seen the patch for git-show today, which would include this\n> > functionality?\n> \n> I didn't. From the patch, it seems git-show can show the index via\n> ::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is\n> not intuitive though. Perhaps you should mention that it can show\n> index (and how) in the git-show document\n\nWell, you can reference blobs that way, but not trees.\n\nCiao,\nDscho\n"},{"id":"295949","messageId":"fcaeb9bf0612140910t6aff44e1m9570b20850a41b87@mail.gmail.com","threadId":"43092","inReplyTo":"Pine.LNX.4.63.0612141754420.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: svn versus git","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-12-14T17:10:15Z","receivedAt":"2006-12-14T17:10:15Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi,\n\nOn 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > - have you seen the patch for git-show today, which would include this\n> > > functionality?\n> >\n> > I didn't. From the patch, it seems git-show can show the index via\n> > ::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is\n> > not intuitive though. Perhaps you should mention that it can show\n> > index (and how) in the git-show document\n>\n> Well, you can reference blobs that way, but not trees.\n\nOh, yeah. Isn't this a good oppotunity to add --index option to git-show?\ngit-show --index will show the index. git-show --index file will show\nthe file content. This makes git-show a little unconsistent though as\nit may or may not require argument <object>.\n\nAnother option is treat '::' alone specially -- call git-ls-files.\n-- \n"},{"id":"297221","messageId":"200612142000.54409.arekm@maven.pl","threadId":"43092","inReplyTo":"200612132200.41420.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"Arkadiusz Miskiewicz","fromEmail":"arekm@maven.pl","sentAt":"2006-12-14T19:00:54Z","receivedAt":"2006-12-14T19:00:54Z","isPatch":false,"sender":{"key":"arekm@maven.pl","avatar":null},"body":"On Wednesday 13 December 2006 23:00, Andy Parkins wrote:\n> Hello,\n>\n> With all the discussion about user interface difficulties, I started to\n> write a comparison with subversion document.  (I was assuming that people\n> find subversion easy).  As much as I love git, I was expecting to find that\n> it's hard to use interface would have subversion as the clear winner.  I\n> was hoping that would then give guidance as to what could be fixed in git.\n>\n> I was surprised, therefore, to find that in each case I was finding that\n> git was the winner.\n\nsubversion is a winner when it comes to options handling (especially --help) \nand better (error) messages. That's one of reason why people find it easy.\n\nps. I'm blind or there is no documentation about what utilities are needed to \nget git fully working? (like sed, coreutils, grep, rcs package (merge tool \nafaik needed)...). \n\n-- \nArkadiusz Miśkiewicz        PLD/Linux Team\n"},{"id":"296542","messageId":"4581CB38.8050401@op5.se","threadId":"43092","inReplyTo":"200612142000.54409.arekm@maven.pl","subject":"Re: svn versus git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-14T22:07:52Z","receivedAt":"2006-12-14T22:07:52Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Arkadiusz Miskiewicz wrote:\n> On Wednesday 13 December 2006 23:00, Andy Parkins wrote:\n>> Hello,\n>>\n>> With all the discussion about user interface difficulties, I started to\n>> write a comparison with subversion document.  (I was assuming that people\n>> find subversion easy).  As much as I love git, I was expecting to find that\n>> it's hard to use interface would have subversion as the clear winner.  I\n>> was hoping that would then give guidance as to what could be fixed in git.\n>>\n>> I was surprised, therefore, to find that in each case I was finding that\n>> git was the winner.\n> \n> subversion is a winner when it comes to options handling (especially --help) \n> and better (error) messages. That's one of reason why people find it easy.\n> \n\nYup. Most discussions about what git can do to improve usually ends up \nin a patch that fixes either documentation or error- / help-messages.\n\n> ps. I'm blind or there is no documentation about what utilities are needed to \n> get git fully working? (like sed, coreutils, grep, rcs package (merge tool \n> afaik needed)...). \n> \n\nperl and the standard coreutils, which afaik are required to be present \non all unix systems. We no longer require external merge tools.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\n"},{"id":"294541","messageId":"200612142313.27741.arekm@maven.pl","threadId":"43092","inReplyTo":"4581CB38.8050401@op5.se","subject":"Re: svn versus git","fromName":"Arkadiusz Miskiewicz","fromEmail":"arekm@maven.pl","sentAt":"2006-12-14T22:13:27Z","receivedAt":"2006-12-14T22:13:27Z","isPatch":false,"sender":{"key":"arekm@maven.pl","avatar":null},"body":"On Thursday 14 December 2006 23:07, Andreas Ericsson wrote:\n\n> > ps. I'm blind or there is no documentation about what utilities are\n> > needed to get git fully working? (like sed, coreutils, grep, rcs package\n> > (merge tool afaik needed)...).\n>\n> perl and the standard coreutils, which afaik are required to be present\n> on all unix systems. \nThat's not all. sed and grep is also used. There may be some others hidden \ndeep in git and it would be good to have that docummented (I've hit the \nproblem already with missing some tool when preparing chroot for git).\n\n> We no longer require external merge tools. \nStarting from which version?\n\n-- \nArkadiusz Miśkiewicz        PLD/Linux Team\n"},{"id":"296066","messageId":"20061214222301.GB26202@spearce.org","threadId":"43092","inReplyTo":"200612142313.27741.arekm@maven.pl","subject":"Re: svn versus git","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-14T22:23:01Z","receivedAt":"2006-12-14T22:23:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Arkadiusz Miskiewicz <arekm@maven.pl> wrote:\n> > We no longer require external merge tools. \n> Starting from which version?\n\nNot released yet, its sitting in 'next'.  Hopefully 1.5.\n\n-- \n"},{"id":"294742","messageId":"Pine.LNX.4.63.0612150009230.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43092","inReplyTo":"200612142000.54409.arekm@maven.pl","subject":"Re: svn versus git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-14T23:10:02Z","receivedAt":"2006-12-14T23:10: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, Arkadiusz Miskiewicz wrote:\n\n> ps. I'm blind or there is no documentation about what utilities are \n> needed to get git fully working? (like sed, coreutils, grep, rcs package \n> (merge tool afaik needed)...).\n\nOpen the file \"INSTALL\".\n\nHth,\nDscho\n"},{"id":"298207","messageId":"Pine.LNX.4.63.0612150118190.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43092","inReplyTo":"fcaeb9bf0612140910t6aff44e1m9570b20850a41b87@mail.gmail.com","subject":"Re: svn versus git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-15T00:19:58Z","receivedAt":"2006-12-15T00:19:58Z","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, Nguyen Thai Ngoc Duy wrote:\n\n> On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > > - have you seen the patch for git-show today, which would include this\n> > > > functionality?\n> > >\n> > > I didn't. From the patch, it seems git-show can show the index via\n> > > ::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is\n> > > not intuitive though. Perhaps you should mention that it can show\n> > > index (and how) in the git-show document\n> > \n> > Well, you can reference blobs that way, but not trees.\n> \n> Oh, yeah. Isn't this a good oppotunity to add --index option to git-show?\n> git-show --index will show the index. git-show --index file will show\n> the file content. This makes git-show a little unconsistent though as\n> it may or may not require argument <object>.\n> \n> Another option is treat '::' alone specially -- call git-ls-files.\n\nHmm. I don't know... It would make the code rather messy. And are you \nreally interested in the content stored in the index? In all cases I can \nthink of, you are better off with a diff vs. working directory or ref.\n\nCiao,\nDscho\n"},{"id":"293834","messageId":"45826269.1060405@op5.se","threadId":"43092","inReplyTo":"200612142313.27741.arekm@maven.pl","subject":"Re: svn versus git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-15T08:52:57Z","receivedAt":"2006-12-15T08:52:57Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Arkadiusz Miskiewicz wrote:\n> On Thursday 14 December 2006 23:07, Andreas Ericsson wrote:\n> \n>>> ps. I'm blind or there is no documentation about what utilities are\n>>> needed to get git fully working? (like sed, coreutils, grep, rcs package\n>>> (merge tool afaik needed)...).\n>> perl and the standard coreutils, which afaik are required to be present\n>> on all unix systems. \n> That's not all. sed and grep is also used. There may be some others hidden \n> deep in git and it would be good to have that docummented (I've hit the \n> problem already with missing some tool when preparing chroot for git).\n> \n\nsed and grep are, along with awk, part of the tools that are required to \nbe present on all unix systems. Sorry for the confusion with coreutils \n(the package / software project).\n\nWhen you set up a chroot environment, you want to at least copy /bin, \n/lib and /sbin to the new root and then remove whatever you *know* you \ndon't need from them. Those directories should hold all programs the \nsystem needs to properly boot up.\n\n>> We no longer require external merge tools. \n> Starting from which version?\n> \n\nLatest only. It was added 2006-12-06 and the dependency on external \nmerge program was removed in a commit created 2006-12-13. Junio merged \nthe merge-code into master one hour later. It is not in the maint \nbranch, so I don't know if any distributions ship git with the new \nxdl_merge() thing. It's *very* good though. Kudos to Johannes Schindelin \nfor really making things right.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\n"},{"id":"295929","messageId":"elu0n5$u0i$1@sea.gmane.org","threadId":"43092","inReplyTo":"200612140908.36952.andyparkins@gmail.com","subject":"Re: svn versus git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T11:27:53Z","receivedAt":"2006-12-15T11:27:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> On Wednesday 2006 December 13 22:56, Shawn Pearce wrote:\n> \n>>   git cat-file -p $REV:$file\n>>\n>> not sure how much easier it gets than that.  Load in the bash\n>> completion from contrib/completion and you can even tab complete\n>> the $file part.\n> \n> Yes.  I was a little unfair on that one; I forgot about the REV:file syntax.  \n> However, it's still not simple for a new user; I think I'd say \"draw\" if \n> the \"-p\" weren't a requirement.\n\n  $ git repo-config alias.less \"-p cat-file -p\"\n  $ git repo-config alias.cat     \"cat-file -p\"\n\nremedies that.\n\n[...]\n>> How is it unfriendly?  What specifically would you change to make\n>> it more friendly?\n> \n> $ git-ls-tree v1.0.0\n> 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8    Makefile\n> \n> I'm a newbie:  what's that number at the front?  What's a blob?  What's that \n> great big number - I've only seen commit hashes that look like that, and that \n> isn't one.  Definitely not friendly.\n\nThe number in front is octal mode of a file or directory. \"blob\"\nis a file (or symbolic link), \"tree\" is a directory, all of this\ncan be found in git(7).\n\nThe \"great big number\" is blob hash. All objects are identified\nand referenced by SHA-1 hash of its contents: be it commits, blobs\n(contents of a file), trees (content of a directory), tags.\n\nYou can always use --abbrev option to have it shortened.\n\n> $ svn list -r 14\n> Makefile\n> \n> It could probably be fixed by making git-ls-files capable of understanding \n> tree-ish.\n\nPerhaps we should add git-ls which would be porcelain frontend\nto git-ls-files and git-ls-tree, just like git-diff is frontend\nto git-diff-files, git-diff-index and git-diff-tree (and also does\npure blob diff).\n\n\"svn list -r 14\" equivalent is \"git ls-tree --name-only v1.0.0\".\nYou can always do\n\n  $ git repo-config alias.list \"ls-tree --name-only\"\n\n(or use --name-status instead of --name-only).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294722","messageId":"elu15f$u0i$2@sea.gmane.org","threadId":"43092","inReplyTo":"m2slfilbfi.fsf@ziti.local","subject":"Re: svn versus git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T11:35:32Z","receivedAt":"2006-12-15T11:35:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Seth Falcon wrote:\n\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n>> Andy Parkins <andyparkins@gmail.com> wrote:\n>>> svn cat::\n>>> Output the contents of specified files or URLs.  Optionally at a\n>>> specific revision.\n>>> git cat-file -p $(git-ls-tree $REV $file | cut -d \" \" -f 3 | cut -f 1)::\n>>\n>> better:\n>>\n>>   git cat-file -p $REV:$file\n> \n> FWIW, after some amount of git experience, I had a need for git\n> cat-file and I found it hard to use.  Why?  Because following the\n> pattern of some other commands, I really expected the following to work:\n> \n>    git cat-file -p HEAD^2 $file\n> \n> Since that is similar to\n> \n>    git diff HEAD^^ $file\n>    git checkout HEAD $file\n\nYou mean\n\n    git diff HEAD^^ -- $file\n    git checkout HEAD -- $file\n\nIt's not $file, it is $path, and it is limiter. git-cat-file (the name\nis certainly historical artefact and it should be git-cat-object) doesn't\nsupport limiters.\n    \n> Where else uses the colon syntax?\n\nEverything where you have <object> or <tree-ish> you can use colon\nsyntax. For example:\n\n  $ git ls-tree pu:Documentation\n  $ git grep -e --merge next:Documentation\n  $ git diff v1.4.2:gitweb/gitweb.cgi gitweb/web:gitweb/gitweb.perl\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298473","messageId":"200612151208.56286.andyparkins@gmail.com","threadId":"43092","inReplyTo":"elu0n5$u0i$1@sea.gmane.org","subject":"Re: svn versus git","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-15T12:08:54Z","receivedAt":"2006-12-15T12:08:54Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2006 December 15 11:27, Jakub Narebski wrote:\n\n> > $ git-ls-tree v1.0.0\n> > 100644 blob 906e98492080d2fde9467a9970fc92d7a8cfeaf8    Makefile\n> >\n> > I'm a newbie:  what's that number at the front?  What's a blob?  What's\n> > that great big number - I've only seen commit hashes that look like that,\n> > and that isn't one.  Definitely not friendly.\n>\n> The number in front is octal mode of a file or directory. \"blob\"\n> is a file (or symbolic link), \"tree\" is a directory, all of this\n> can be found in git(7).\n\nSorry, when I said \"I'm a newbie\", I meant \"pretend I'm a newbie\" :-)\n\nMy point was that this is all too confusing for a newbie; the fact that you \nhad to descend to talk about SHA-1 and blob hashes, really serves to \nstrengthen my point.  What does a non-developer care about hashes, blobs, \ntrees, commits, or objects?\n\nIn this case however, I withdrew my complaint because it's argued that \ngit-ls-files is not the right tool for this purpose anyway.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294730","messageId":"elu5tk$g4c$1@sea.gmane.org","threadId":"43092","inReplyTo":"Pine.LNX.4.63.0612150009230.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: svn versus git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T12:56:41Z","receivedAt":"2006-12-15T12:56:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Thu, 14 Dec 2006, Arkadiusz Miskiewicz wrote:\n> \n>> ps. I'm blind or there is no documentation about what utilities are \n>> needed to get git fully working? (like sed, coreutils, grep, rcs package \n>> (merge tool afaik needed)...).\n> \n> Open the file \"INSTALL\".\n\nWhich doesn't mention 'sed' for example. \n\n\nI have checked only commands in POSIX shell script; this list does not\ninclude tests in t/ directory, which uses multitude of other tools.\n\nGit has built-in grep since at least v1.4.0, but 'grep' is used in\ngenerate-cmdlist.sh, git-commit.sh, git-instaweb.sh, git-quiltimport.sh and\ngit-tag.sh. \n\n'cut' is used only in git-instaweb.sh; other commands do without it.\n'sort' is used in check-builtins.sh, generate-cmdlist.sh, git-ls-remote.sh,\ngit-tag.sh. Both tools are from coreutils package. And git uses other tools\nfrom coreutils too: uniq, printf, tail,...\n\nGit has built-in diff since at least v1.4.0, but diff is used in\ngit-merge-one-file.sh\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298539","messageId":"fcaeb9bf0612150726o40527552l8b3564ddcc3adb94@mail.gmail.com","threadId":"43092","inReplyTo":"Pine.LNX.4.63.0612150118190.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: svn versus git","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-12-15T15:26:09Z","receivedAt":"2006-12-15T15:26:09Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi,\n\nOn 12/15/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:\n>\n> > On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > > > - have you seen the patch for git-show today, which would include this\n> > > > > functionality?\n> > > >\n> > > > I didn't. From the patch, it seems git-show can show the index via\n> > > > ::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is\n> > > > not intuitive though. Perhaps you should mention that it can show\n> > > > index (and how) in the git-show document\n> > >\n> > > Well, you can reference blobs that way, but not trees.\n> >\n> > Oh, yeah. Isn't this a good oppotunity to add --index option to git-show?\n> > git-show --index will show the index. git-show --index file will show\n> > the file content. This makes git-show a little unconsistent though as\n> > it may or may not require argument <object>.\n> >\n> > Another option is treat '::' alone specially -- call git-ls-files.\n>\n> Hmm. I don't know... It would make the code rather messy. And are you\n> really interested in the content stored in the index? In all cases I can\n> think of, you are better off with a diff vs. working directory or ref.\n\nWhen I worked with index the first time, I had difficulty knowing what\nwas in index. Index is, unlike working directory, intangible. I could\nuse git-diff (and actually did), but it was still better if I could\nhave seen what exactly was in index.\n\nTo me, index and object database are (to some extent) the same: both\nare used to store files. If I can examine git object database, why not\nindex?\n\nAbout adding index support to git-show, yes it's really messy. index\ndoesn't have tree objects. If a user wants to list a subdirectory in\nindex, git-show will have to do more work, I think. Perhaps we should\nforget this for now.\n-- \n"},{"id":"296157","messageId":"Pine.LNX.4.63.0612152115000.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43092","inReplyTo":"fcaeb9bf0612150726o40527552l8b3564ddcc3adb94@mail.gmail.com","subject":"Re: svn versus git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-15T20:15:59Z","receivedAt":"2006-12-15T20:15:59Z","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, Nguyen Thai Ngoc Duy wrote:\n\n> About adding index support to git-show, yes it's really messy. index\n> doesn't have tree objects.\n\nInsofar, it is not messy: git-show only shows _objects_. For example, \"git \nshow :README\" works as expected if you have a file called \"README\" in the \nindex...\n\nCiao,\nDscho\n"},{"id":"296811","messageId":"Pine.LNX.4.63.0612152117390.3635@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43092","inReplyTo":"Pine.LNX.4.63.0612152115000.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: svn versus git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-15T20:19:16Z","receivedAt":"2006-12-15T20:19:16Z","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, Johannes Schindelin wrote:\n\n> On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:\n> \n> > About adding index support to git-show, yes it's really messy. index\n> > doesn't have tree objects.\n> \n> Insofar, it is not messy: git-show only shows _objects_. For example, \"git \n> show :README\" works as expected if you have a file called \"README\" in the \n> index...\n\nNote: this is not completely true. The index contains cache_trees. But \nthey do not need to be up-to-date, which would mean that \"git show :./\" \nwould have to remake the cache_tree, and _then_ show it.\n\nCiao,\nDscho\n"},{"id":"294313","messageId":"7v64ccomdc.fsf@assigned-by-dhcp.cox.net","threadId":"43092","inReplyTo":"Pine.LNX.4.63.0612152117390.3635@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: svn versus git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-15T21:55:11Z","receivedAt":"2006-12-15T21:55:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Hi,\n>\n> On Fri, 15 Dec 2006, Johannes Schindelin wrote:\n>\n>> On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:\n>> \n>> > About adding index support to git-show, yes it's really messy. index\n>> > doesn't have tree objects.\n>> \n>> Insofar, it is not messy: git-show only shows _objects_. For example, \"git \n>> show :README\" works as expected if you have a file called \"README\" in the \n>> index...\n>\n> Note: this is not completely true. The index contains cache_trees...\n\nLet's not go there.\n\nI was reviewing the list of plumbing in Documentation/git.txt\nlast night, and I think ls-files is the only command that user\nmay still want to use from the command line every day.\n\nI originally thought that it would only be after a conflicted\nmerge, always with -u option, but some people seem to find that\n\"ls-files --others\" and friends are useful (I never use that\nmyself) and if so what it does really in the realm of Porcelain.\n\nI haven't formed a firm opinion on this yet, but possibilities\nare:\n\n * we reclassify ls-files as a Porcelain-ish (but do not change\n   its UI nor defaults at all); we might want to give a shorter\n   alias to the command, though, if we go this route.\n\n * we give '--list' option to 'git show' and in such a case,\n   lack of objects does not default to HEAD -- when no object is\n   given it internally diverts to cmd_ls_files() instead;\n\n * we add 'git ls' command to give Porcelain-ish access to\n   ls-tree and ls-files.\n\n"},{"id":"296113","messageId":"Pine.LNX.4.64.0612151736470.18171@xanadu.home","threadId":"43092","inReplyTo":"7v64ccomdc.fsf@assigned-by-dhcp.cox.net","subject":"Re: svn versus git","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-15T22:37:24Z","receivedAt":"2006-12-15T22:37:24Z","isPatch":false,"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>  * we add 'git ls' command to give Porcelain-ish access to\n>    ls-tree and ls-files.\n\nThat seems the most sensible to me.\n\n\n"},{"id":"297200","messageId":"fcaeb9bf0612151626k1442daa9ib2bf90f7563c4835@mail.gmail.com","threadId":"43092","inReplyTo":"Pine.LNX.4.64.0612151736470.18171@xanadu.home","subject":"Re: svn versus git","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-12-16T00:26:58Z","receivedAt":"2006-12-16T00:26:58Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 12/16/06, Nicolas Pitre <nico@cam.org> wrote:\n> On Fri, 15 Dec 2006, Junio C Hamano wrote:\n>\n> >  * we add 'git ls' command to give Porcelain-ish access to\n> >    ls-tree and ls-files.\n>\n> That seems the most sensible to me.\n\nI agree.\n\n-- \n"}]}