{"thread":{"id":"13882","subject":"freedesktop.org not really up to date?","startedAt":"2008-06-10T13:07:58Z","lastAt":"2008-06-10T15:03:28Z","messageCount":2,"participants":["Andreas Ericsson","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"79339","messageId":"484E7CAE.4040403@op5.se","threadId":"13882","inReplyTo":null,"subject":"freedesktop.org not really up to date?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-06-10T13:07:58Z","receivedAt":"2008-06-10T13:07:58Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"I just stumbled across this freedesktop.org site from 2007-06-03:\nhttp://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws\n\nIt seems to me that since then most of the issues have been worked out.\nAre any of them still valid points? If so, which ones and how should we\ngo about addressing them?\n\nJakub Cc'd as he was the last one to edit the (now immutable) wiki page.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"79354","messageId":"200806101703.29571.jnareb@gmail.com","threadId":"13882","inReplyTo":"484E7CAE.4040403@op5.se","subject":"Re: freedesktop.org not really up to date?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-10T15:03:28Z","receivedAt":"2008-06-10T15:03:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 10 Jun 2008, Andreas Ericsson wrote:\n\n> I just stumbled across this freedesktop.org site from 2007-06-03:\n> http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws\n> \n> It seems to me that since then most of the issues have been worked\n> out. Are any of them still valid points? If so, which ones and how\n> should we go about addressing them?\n\nSee below for detailed response. It looks like all, or almost all \nissues got addressed...\n \n> Jakub Cc'd as he was the last one to edit the (now immutable) wiki\n> page. \n\nI wonder why it was made immutable (static page)... errr, it is not \nimmutable, you just are required to login to edit.\n\nBelow detailed analysis of the contents of the page\n\n-------------------------------------------------------------------\nInfrastructure/git/UIFlaws:\n\n> This page attempts to document the most egregious git UI offenses,\n> in the hope that they'll get fixed someday. It would be pleasant if\n> git had a bugzilla. In git's defence, 1.5 appears to be making great\n> strides towards usability. \n\nI'm not sure if having bug tracker would help. Git development works \nquite well with RelNotes, git mailing list and its searchable archives.\n\n> * git-revert will refuse to back out multi-parent commits, ie, merges.\n> The obvious behaviour is to do basically what \n> git-show [commit] | patch -p1 -R\n> would do, ie, roll back the tree state to the branch you came from.\n\nGit has now \"-m |--mainline \" option to \ngit-cherry-pick and git-revert, which would allow to revert merge \ncommit. You usually don't want to do this, by the way.\n\n> * \"git rebase foo\" is a noop, when foo is the name of local branch.\n> You would expect it to fetch the branch named foo from upstream,\n> and rebase your foo branch on top of it.\n\nUse \"git pull --rebase\" for this.\n\nYou wouldn't expect \"git merge\" to _fetch_ from upstream (would you?), \nso why \"git rebase\" would be expected to fetch?\n\n> * git-fetch requires that the branch be named on both sides of the :.\n> It should treat foo as an alias for foo:foo. \n\n>From git-fetch(1) manpage:\n\n Some short-cut notations are also supported\n [...]\n\n * A parameter without a colon is equivalent to : when\n pulling/fetching, so it merges into the current branch\n without storing the remote branch anywhere locally\n\nThere was discussion on git mailing list on changing this default, but \namong others backward compatibility prevents it. That and the fact \nthat current behavior makes most sense (usually with git-pull, not \ngit-fetch) for one-shot fetches; if you want to contact given \nrepository periodically, you would set up remote configuration (using \ngit-remote for example) and wouldn't use refspecs anyway.\n\n> * git-rebase claims you should git-rebase --continue after you fix up\n> the merges; it really means you should git-update-index followed by\n> git-rebase --continue.\n\n(Actually now it is git-add, not git-update-index).\n\nI don't know if it changed. There was recurring idea about adding \n\"git resolved\" command, but it was never implemented, probably because \nit would add another comand to already large set, an that its name and \na bit semantic were not sufficiently clear. git-mergetool should \nreduce occurences where you have to manually git-add before continuing \nrebase.\n\n> * The command to merge branch B onto branch A is not git-merge A B.\n> Instead it's git-checkout A && git-pull . B.\n\nIt _cannot_ be \"git merge A B\", as there can be conflicts, so one side \n_has_ to be checked out. But nowadays \"git checkout A && git merge B\"\nis enough, and you don't have to use bit cryptic \"git pull . B\" syntax.\n\n> * There is no way to tell git-fetch (or therefore git-pull) to grab\n> all newly available branches. You have to ask for them by two names\n> (as above), and then there's no way to get those names automatically\n> into your remotes list (also as above).\n\nWith globbing refspecs it is now possible.\n\n> * git pull's default behaviour on a branch is unhelpful: even when\n> there is an explicit Pull: branch1:branch1 line, a git pull with\n> branch1 checked out will still pull in master.\n\nYou can now use branch configuration to avoid this confusion, I think.\n\n> * Fundamentally, the entire approach of making the UI painful to deal\n> with and forcing the user to deal with all the warts (instead of\n> just making the hairy low-level commands available), because people\n> will write nice wrappers around it, is the same reason people\n> laughed at tla, and still do.\n\nErrr, what?!? The idea never was to make UI horrible. The idea was \nbottom-up approach, building low-level plumbing first, and evolving \nporcelain commands next (with a bit of help from Cogito...).\n\n> * The index should be second-class, i.e. no -a flags to avoid the\n> index.\n\nWell, Linux and Junio disagree. \n\nBeside, having index visible is useful, and sometimes necessary.\n\n> * branch:branch-origin (or something) should be the default pull.\n\n\"git remote add \" sets up globbing refspec in the form\n'refs/heads/*:refs/remotes//*'. \n\n\"origin\" remote is default remote (\"git pull\"), but you can set \ndifferent remotes, even per branch default remotes.\n\nI don't know which of this thing author wanted to have.\n\n> * branch:branch should be the default push for all branches, but only\n> push the current branch unless a flag is added.\n\nLong discussion on git mailing list about \"git push --current\" vs \n\"git push --matching\" and which should be the default. You can push \ncurrent branch now with \"git push HEAD\" (or I think even with \n\"git push HEAD\"), changing the default for the backwards compatibility \nreasons would have to wait, even if we agree that it is a good change.\n\n> * An update command should be created that:\n> o fetches the current branch's upstream to its -origin locally\n> (or all branches, perhaps); \n> o merges the current branch origin to the branch locally;\n> o commits if it was a fast-forward, and leaves uncommitted\n> diffs otherwise. \n\nThere is \"git remote update\", there are globbing refspecs, there is (or \nwould be) --ff / --ff=only option and --no-commmit option... what I am \nnot sure if the workflow described is actually useful... especially \nwith easy rollback in \"git reset --hard ORIG_HEAD\" and \"git commit \n--amend\" at fingertips.\n\n-- \nJakub Narebski\nPoland\n"}]}