{"thread":{"id":"10194","subject":"Re: Git User's Survey 2007 unfinished summary continued","startedAt":"2007-10-08T20:55:49Z","lastAt":"2007-10-26T23:29:18Z","messageCount":161,"participants":["Jakub Narebski","Frank Lichtenheld","Johannes Schindelin","J. Bruce Fields","Shawn O. Pearce","Andreas Ericsson","David Kastrup","Linus Torvalds","david@lang.hm","Reece Dunn","Steven Grimm","Nicolas Pitre","David Tweed","Matthew Andrews","Federico Mena Quintero","Steffen Prohaska","Dmitry Potapov","Wincent Colaiuta","David Symonds","Nguyen Thai Ngoc Duy","Robin Rosenberg","Daniel Barkalow","Alex Riesen","Karl Hasselström","Catalin Marinas","Peter Baumann","Theodore Tso","Mike Hommey","Junio C Hamano","Carl Worth","Steven Walter"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55208","messageId":"8fe92b430710081355i7d3dbaa2q9a8939b55d7ca7dc@mail.gmail.com","threadId":"10194","inReplyTo":null,"subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-08T20:55:49Z","receivedAt":"2007-10-08T20:55:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"This is continuation of partial summary of Git User's Survey 2007,\nending at state from 28 September 2007.\n\nThe survey can be found here:\n http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9\n http://tinyurl.com/26774s\n\nThe data this summary is based on can be found here:\n http://git.or.cz/gitwiki/GitSurvey2007?action=AttachFile&do=get&target=surveydata.csv\n http://tinyurl.com/yusomo\n\n----\nThere were 683 individual responses\n\nAbout you\n~~~~~~~~~\n\n00. Date of response\n\n Date | Count\n ------------------------------------------\n Before | 7\n During | 584\n After | 92\n ------------------------------------------\n\nThe ranges 'before', 'during' and 'after' refers to official duration\nof Git User's Survey 2007, from 20 August 2007 to 10 September 2007.\nActually they are corrected to take into account the fact that local\ndate on survey's server (or UTC date) might be different from local\ndate on user computer, so duration of survey is taken as from\n2007-08-19 to 2007-09-11.\n\nMost responses are from the start of survey, 20 and 21 August (133 and\n103 responses respectively). If anyone is interested I can provide\nfull date by date histogram.\n\n\nGetting started with GIT\n~~~~~~~~~~~~~~~~~~~~~~~~\n\n07. What helped you most in learning to use it?\n\n TO DO\n 646 / 683 non-empty responses\n\nSome of the responses:\n * documentation (generic)\n * man pages\n * examples / usage cases in man pages\n * everyday GIT, tutorials and user's manual\n * wiki examples\n * reading mailing list / comp.version-control.git\n * people on IRC (not only #git)\n * advice from other users / friends / colleagues\n * (unofficial) documentation on the web: guides, articles, blogs etc.\n [here probably should be a sublist of them, with count]\n * a development community and/or its documentation, mailing list\n e.g. WINE wiki, Source Mage GNU/Linux development community\n * Google (Google searches)\n * helpful error messages\n * source code, reading the parts of git in shell script\n * cogito\n * using git in a live project / experimenting / trial and error\n (That I was able to just delete the entire repository and start\n over. That all my mistakes stayed local and didn't affect upstream\n repos.)\n * working on an established project that had documented processes for\n using git\n * writing code for both plumbing and Porcelain\n writing documentation / tutorial for project / article\n * understanding the internal representation of the repository;\n good / simple design, basic principles; understanding concepts\n * experience of working in software industry;\n prior experience with version control systems (GNU Arch, SVN, BK, hg)\n * version 1.5\n * gitk, qgit; git-gui\n\nOne of more interesting:\n * We hired a consultant to give us a tutorial\n\n\n08. What did you find hardest?\n\n TO DO\n 596 / 683 non-empty responses\n\nSome of the responses:\n * the level of complexity\n * user interface:\n too much / inconsistent commands, too many / cryptic options\n distinction between plumbing and porcelain\n many ways to do a task\n insufficient error messages\n 'git --help' prints manpage, not concise help summary\n * obtuse command messages\n * weak porcelain\n e.g. git-update-index very central\n * git-merge was plumbing\n * remote / tracking branches\n fetching, pushing and pulling, synchronizing repositories\n the fact that push is not an opposite of pull\n understanding the difference between committing and publishing\n * handling multiple remote repositories\n * merge vs rebase, deciding on proper workflow\n working with topic branches\n modifying a patch series\n * merge defaults (which branch gets merged)\n * git vs StGIT: slightly different merge conflict handling\n * making it work in non-POSIX environments\n working with git on case-insensitive and other strange filesystems\n compiling on exotic OS, for example AIX\n generating man pages\n * lack of / bad / outdated / insufficient / badly structured docs\n hard to find something in the documentation\n git lingo in documentation, documentation for users who know git\n using Cogito in some of documentation\n * understanding of concepts, thinking in git way\n understanding basic concepts and terminology\n * distributed SCM concepts, paradigm shift\n idea of non-linear history\n * index (staging area): understanding, having it visible\n * git-diff not showing added files\n * commands named differently from equivalents in other SCM\n differences from other SCM: git-commit needs '-a' to commit all\n changes, strange semantics of git-add, multiple branches in repo\n understanding terminology\n * importing history from other SCM (bzr, svn)\n * reverting changes, amending commit, undoing a commit\n * keeping track of where am I, of which version I'm working with\n finding which branch the change was made on\n * lerning to use it as maintainer\n maintaining \"perfect patch series\", keeping history clean\n rewritig history before 'git rebase -i'\n * dealing with merge conflicts\n figuring how to undo failed merge and restart it\n * learning conventions git expects but didn't document clearly\n like commit message formatting\n * setting up shared repo / shared server\n setting up remote repository\n * dealing with modified files (dirty tree) when switching branches,\n merging (pulling) and rebasing\n * checking out past revisions (or tagged revisions) with the\n intention to return to newer revision\n * creating independent branch, i.e. branch without ancestry\n * exploring the history and previous versions of particular files\n which are renamed and/or moved around, especially before --follow\n was added\n * some hot-shot peple in the community (on the mailing list)\n * setting up gitweb\n * having to use CLI interface\n * no documentation\n\nMore interesting:\n * All idiosyncrasies that make (made) sense for Linus' workflow but\n aren't really orthogonal or predictable.\n * Listening to whiners complain about how hard it was to learn\n * Thinking outside the narrow box defined by previous SCMs.\n * Not having used an SCM before!\n * Following the explosive growth of features.\n * Having a day job taking most of my time away from git.\n * Convincing my boss to use it.\n\nConclusions:\n - some of the things got corrected, like separate remote layout being\n default for non-bare repositories, using git-add (porcelain)\n instead of git-update-index (plumbing) in documentation and command\n messages, promoting git-merge to porcelain, creating git-remote for\n managing multiple repositories and remote branches, better\n documentation including creating git user's manual.\n - some things are hard because of historical reasons, such like\n naming of commands, or consistency of options, and would be\n difficult to change.\n - doing things \"git way\", such as making index visible (and requiring\n 'git commit -a' to commit changes in all files), or rename\n detection instead of rename tracking, or storing filenames and file\n contents 'as-is' (without translation) are I think here to stay\n - some of things are intrinsically hard, and would stay that way,\n for example the distributed SCM concept, or nonlinear history.\n\n\nHow you use GIT\n~~~~~~~~~~~~~~~\n\n22. What projects do you track (or download) using GIT\n (or git web interface)?\n\n TO TABULARIZE\n 560 / 683 non-empty responses\n\nA note: this question was meant to list projects which one _tracks_,\nnot the ones he/she maintains, meaning the projects in the remotes\n(section).\n\nTracked projects can be divided into the following categories:\n * undisclosed: proprietary code / work projects, own projects, etc.\n * Linux kernel an kernel related projects (like udev or kvm)\n * git related: git, gitk, git-gui, git-gui-i18n, stgit, tig,...\n * freedesktop (and related) projects: XCB, Compiz, Mesa3D, Cairo,...\n * Linux distributions: Source Mage, Slind,... (a few)\n * tracked via git-svn, e.g. nsd, KDE, GIMP, FreeCiv\n * others with official git repositories (like XMMS2 or ELinks)\n * others with unofficial git repositories (like OpenOffice.org)\n\nThere are more that 100 different projects tracked mentioned in survey\n(not all of them _choose_ git as their SCM).\n\n\nInternationalization\n~~~~~~~~~~~~~~~~~~~~\n\n32. What do you need translated?\n\n TO TABULARIZE\n 172 / 683 non-empty responses\n\nSummary of responses, without count (which I guess is most important):\n * user interface: command messages and error messages\n * GUI: git-gui, gitk\n * man pages and commands usage\n ('git --help' , git --usage')\n * user's manual, tutorials, intro, howtos\n * website / homepage\n\n-- \nJakub Narebski\nPoland\n(temporarily away from Internet)\n"},{"id":"55576","messageId":"8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com","threadId":"10194","inReplyTo":"8fe92b430710081355i7d3dbaa2q9a8939b55d7ca7dc@mail.gmail.com","subject":"Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-12T22:08:18Z","receivedAt":"2007-10-12T22:08:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"This is continuation of partial summary of Git User's Survey 2007,\nending at state from 28 September 2007.\n(response ident \"46f95167c967b\").\n\nThe survey can be found here:\n http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9\n http://tinyurl.com/26774s\n\nThe data this summary is base on can be found here:\n\n\n----\nThere were 683 individual responses\n\n\nOther SCMs\n~~~~~~~~~~\n\n13. What would you require from GIT to enable you to change,\n if you use other SCM for your project?\n\n TO DO\n 474 / 683 non-empty responses\n\nList of answers, without count (which for this question is, I think,\nless important), divided into broad categories, is shown below\n\nGeneric\n * being more user-friendly, easier to use\n more friendly output from commands\n better and clearer error messages\n stable command semantics\n * reduced number of (visible) commands\n clear separation of plumbing and porcelain\n * consistent set of commands\n consistency if command flags\n * easier to learn (easier learning curve)\n * more stability\n * support UTF-16\n\n * A clearer UI. Read the monotone list archive. 70% of the mails are\n UI related. The result is an clear and easy to use intuitive UI\n that does what you expect in most cases.\n\nPerformance\n * better performance on massive trees (FreeBSD)\n * good speed on NTFS (MS WIndows)\n\nDocumentation\n * a good documentation\n user/installation documentation\n troubleshooting guide\n 'Git For Dummies', 'The Git Book'\n * documented workflows (including centralized repo workflow, or at\n least documenting how and why replace it with better workflow)\n * development model tutorials\n more example usage\n best practices\n case studies\n * guide for designing a branch policy for a shared repository\n * screencasts\n * documentation in one's native language\n * good in-depth administative documentation\n * maybe git-tutor program\n\nSpecific features\n * partial-tree checkouts (partial checkout)\n checking out arbitrary subdirectories\n * granular permissions (ACL) within the tree\n e.g. restricting translators to the po/ subdirectory\n * shallow clone from a given commit: git clone --depth \n * automatic (re)packing\n * lightweight working copies\n * better and well documented submodule support\n * multi-project support / multiple sandboxes support\n * git-bind/unbind (like in bzr)\n * git-sync\n * cvs-compatible syntax as an option\n * tracking empty directories\n * more friendliness with corporate firewalls\n * ability to preserve permissions/modes/EA of files and directories\n access control features / visibility access control\n disabling some users from accessing certain parts of the repository\n * being able to merge directories (instead of branches)\n * FastCGI gitweb\n * some embedded keyword capabilities similar to those provided by CVS\n and Subversion\n * ignore files during merge\n * R/W git server (allow push), with NIS, LDAP support\n * pull/rebase into dirty tree\n * clearcase dynamic view-like support (externally?)\n * better http(s) push via WebDAV: hooks\n working and easy to setup push over https\n * plain simple FTP upload (push) and download (clone, fetch)\n * better working through corporate firewalls\n\nPortability\n * native MS Windows support, easy installer package\n even better support for all platforms\n easier setup on Solaris and AIX\n * pre-prepared _static_ binaries for FreeBSD, MacOS X, MS Windows\n * less dependencies\n * support for more platforms\n * a portable version of git, one binary + library (gitbox)\n * Windows version(s) mentioned on homepage\n\nGUI\n * better (G)UI\n TortoiseGit for MS Windows, or other Windows front-end\n good, advanced GTK+ 2.x tool to visualize git\n * history graph conected to file tree in GUIs\n * easier management of remotes using GUI\n * better diff viewing tools (side-by-side, like KDiff3)\n\nOther SCMs\n * seamless import\n BitKeeper / ClearCase import/sync\n tool to import TeamWare history into Git\n better SCM interop\n * SCM rosetta / \"Git for users\" documentation\n * import/export tools supporting incremental import and export\n * 100% subversion interoperability\n * git update (stash, fetch, rebase, unstash) a la CVS\n * git-svnserve\n * svn:externals support\n\nTools\n * improved administrative tools\n * reasonable plugins for IDE (e.g. Visual Studio, KDevelop, NetBeans)\n full Eclipse / NetBeans / IntelliJ support\n * good integration with apps like Trac and Bugzilla\n work with continuous integration tools (cruise control etc...)\n * Git+Launchpad\n * libification (for tools support)\n\nOther\n * SourceForge / Gna! / Google Projects support\n (free) hosting with git facilities\n FOSS hosting sites supporting git\n * commercial support / corporate backing\n contractual service\n * number of users, to convince my co-workers that they're not\n a silly minority\n popularity\n * projects switching to git\n * user education\n * marketing, advocacy videos\n * convincing coworkers / other members / boss\n willingness of the other developers to learn to use it\n * training/certification\n * a stop to the constant bashing of other SCMs - this doesn't get you\n any friends drop the arrogant attitude, work with the rest of the\n community and try to make something people can understand in an\n hour\n\n * http://wiki.FreeBSD.org/VersionControl\n\n * At work it'd require some kind of miracle. Huge Perforce repository\n of highly interrelated stuff in which people can make sweeping\n changes in a single changelist. Lots of tools that access Perforce.\n Slow as hell.\n\n\n\nGetting help, staying in touch\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n61. Did you have problems getting GIT help on mailing list\n or on IRC channel? What were it? What could be improved?\n\n TO TABULARIZE\n 99 / 683 non-empty responses\n\n\nProblems and suggestion for mailing list:\n\n * I answered my own question and no one even commented it. User and\n development discussion should be separated. Just release\n announcements in the user list.\n\n You need another mailing list for users. The current mailing list\n is very developer centric.\n\n The mailing list feels like it's more for developers rather than\n users and it's a little intimidating to ask newbie questions there.\n Maybe separate git-users and git-dev lists would make sense.\n\n Git mailing list needs a users and developers list. Mixing up the\n two is intimidating with all the traffic and the number of patches\n and advanced topics that shoot around.\n\n Having separate git-users and git-devel lists would be nice. I\n might read both but I hate to ask a newbie question on a list where\n 50% of the submissions contain patches.\n\n (Other users find mailing list very responsive. Splitting the list\n into either git-devel and git-users, or git and git-announce has\n its advantages and disadvantages. You can always filter out patch\n submission and comments on patches thanks to the \"[PATCH .*]\"\n prefix convention present on mailing list.)\n\n * A question or two with no response at all. In hindsight my query\n was way too long-winded but it's still frustrating to be ignored.\n\n I answered my own question and no one even commented it.\n\n (See above)\n\n * The git mailing list is too high traffic to remain on. Maybe split\n it into a few lower traffic versions?\n\n Biggest problem is that smaller problems are getting lost in the\n growing size of the mailing list.\n\n The sheer amount of traffic makes the mailing list hard to deal\n with sometimes. Getting your email tools set up correctly can help\n (i.e. auto tag+archive in GMail), but ultimately you still have to\n wade around in hundreds of emails you don't care about in order to\n find the ones you do care about.\n\n (Most people find traffic levels on git mailing list OK, see\n question 58.)\n\n * Will not go through corporate firewall.\n\n (I think it was about mailing list, but perhaps it was about IRC)\n\n I no longer subscribe to the GIT mailing list as ML subscription is\n forbidden at my new job, and I have no time at home to read it all.\n\n (You can read git mailing list through many archives / web\n interfaces, including MARC and GMane ones, and throught NNTP\n (aka. Usenet, aka news) interface on GMane. You don't need to be\n subscribed to git mailing list to post.)\n\n * People responded quickly to mailing list queries usually helpfully.\n However there was occasionally a touch of annoying 'groupthink' to\n the responses; sometimes new users are just confused and really\n would be better served by just changing their working habits, but\n other times there appeared to be a bit of tunnel-vision on the part\n of the longtime git users.\n\n * Trolls could be thrown out ;-) Seriously we had only a few there,\n but they are mighty annoying.\n\n * Mostly no. But little help on applying email-patches in win32 using\n GMail. I'll get there though :)\n\n (Late addition of smtpserver (with ability to select port number),\n smtpuser, smtppass and smtpssl configuration variables / options to\n git-send-email should help with _sending_ patches using GMail. As\n to applying email-patches, git-am understand both mbox and maildir\n formats, not that it help much with win32 mail programs; but you\n can always try to save email in raw format from GMail WWW\n interface)\n\n\nProblems and suggestions for IRC:\n\n * The IRC channel has too few people who know answers to questions;\n if you're there at the wrong time of day when none of them happen\n to be around it's useless. But if you're there at the right time\n it's pretty good.\n\n * IRC channel seems to respond to newbie git users quite well, but\n mid-level experience often gets no response.\n\n * Traffic on the IRC channel is a bit high. It may need to be split\n into a few different high-level topics in the near future.\n\n (IRC channel or git mailing list? I don't remember IRC channel\n having high traffic...)\n\n * It's hard to improve IRC. It's such a poor medium for understanding\n the communication going on.\n\n (On the other hand it is responsive. I think pastebins helps to\n sidestep limitations of the medium. Nevertheless the main medium of\n communication is git mailing list, not #git channel.)\n\n * IRC is blocked from work :-( I may try it by tunneling out.\n\n (Any suggestions here?)\n\n\nGeneric problems and suggestions:\n\n * Sometimes you get no answer (on git mailing list or #git channel)\n but that happens\n\n * People seem to think the problem isn't with git, and yet I find git\n extremely buggy and non-intuitive. Your \"Git in 5 minutes\" doesn't\n even include +x a hook or mention of hooks; neither does linus\n speech. If you don't +x a hook, try to figure out what is going\n on. I dare you. Git fails silently a bunch, maybe half of the time\n by design. Which shouldn't be acceptable.\n\n Try addressing an ssh address in url format: it isn't consistent\n and it will fail in half the apps. Same thing with git-ls-remote:\n it might have an --upload-pack that works, but this isn't across\n the board! From my own debugging none of the shell scripts have an\n --upload-pack option that work.\n\n (Not here. This is question about getting help from people, not\n about documentation or what you find hardest in GIT.)\n\n * After the last thread the GIT FAQ is almost begging for a 'Please\n don't ask about C++' section.\n\n (Truly, Git FAQ (which resides on Git wiki, but perhaps we should\n consider extracting it and adding to distribution tarballs) needs\n maintenance, updating and adding new frequently asked\n questions. Currently there is no FAQ maintainer.)\n\n\nThe other side: getting help success stories:\n\n * Quite the contrary. When Source Mage GNU/Linux switched to using\n GIT our developers spent a considerable amount of time asking\n questions and discussing features and bugs on #git. The feedback\n that we got was fabulous: the GIT developers were helpful\n interested in our needs and productive when it came to fixing\n bugs. One bug we discovered was even handled by Linus Torvalds\n himself and in just a matter of hours! In our eyes the GIT\n development community gained rightful reputation as one of the most\n friendly and helpful communities there is.\n\n * No, the mailing list has been very responsive. I have never asked a\n question on IRC but I sometimes answer newbie questions.\n\n * Mailing list is very interesting especially as I'm working on\n egit. IRC is more immediately helpful.\n\n * I'd like to say that I consider #git to be the most useful IRC\n channel I've ever been to when it came to getting answers to my\n questions. Thanks guys!\n\n The IRC channel is wonderful. The people there do a good job with\n questions.\n\n * No problems. In fact the mailing list/IRC could substitute the\n documentation but I guess that\n (1) does not work in offline mode\n (2) _is_ going to get on peoples nerves after a while\n\t (recurring questions)\n\n\n\nOpen forum\n~~~~~~~~~~\n\n62. What other comments or suggestions do you have, that are not\n covered by the questions above?\n\n TO DO\n 141 / 683 non-empty responses\n\nThere are many \"keep up the great work!\" (and equivalent) as answers\nto this questions, and a few \"worst SCM I've used\". Those are excluded\nfrom the lists below.\n\n\nSuggestions for git:\n\n * One of the biggest complaints I hear is that mercurial's UI is much\n more 'intuitive' and user friendly. Perhaps looking at it's\n operation and comparing/contrasting would be good.\n\n (Note that changing names of commands for example might be\n impossible because of historical reasons and large usebase.\n On the other hand perhaps this is just a steep learning curve,\n unavoidable for a power tool)\n\n * Mercurial has an excellent tutorial which had my team up and\n running in less than a hour after a week struggling to make git do\n anything useful.\n\n (I hope that late work on \"Git User's Manual\" helps here)\n\n * Handling of Unicode (UTF-16 encoded) files is a big pain with git.\n Even SVN can do a diff of them.\n\n (The idea that blob is just a bag of bytes will not change; but we\n have input/output filters, and soon before-diff filters, connected\n with gitattributes)\n\n * I like how in Subversion the commands work relative to the current\n directory. With Git I always seem to be dealing with longer paths\n and/or have to change to the root.\n\n (Running git from within directory deep within repository structure\n should 'just work'. If not, then it is an error... unless in\n situation like referring to tree-ish, where path is almost always\n relative to project root).\n\n * Keep up the UI simplification and make sure the docs start off with\n usage somewhat similar to CVS/SVN. I think many users are scared by\n Git because they see the more powerful commands thrown around too\n early and get scared.\n\n Git is just too complicated for a typical project. I understand\n it's probably great for the Linux kernel but for a smaller project\n like mine (Mesa) it's overkill and a frustration. (...) With git\n everything seems hard. (...) I've _wasted_ hours trying to figure\n out git. That alone is a huge issue. I guess I could go into\n specific details about my problems with git but I've already spent\n enough time on this survey.\n\n Figure out why people find git hard to learn and eliminate those\n barriers to entry. Make git more task-oriented rather than\n data-model-oriented the way it is now.\n\n It's a great idea and a powerful tool but it's got a long way to go\n before it reaches wider adoption because it's so damn hard to use.\n\n (...) I'm evaluating Mercurial despite its being based on Python\n because it feels cleaner and simpler to use. I would prefer to use\n Git.\n\n (I think the 1.4 and 1.5 series is a good step in simplifying git\n for simple tasks and ordinary user. Core git porcelain improved\n much, and now there is no need to use plumbing for every-day tasks)\n\n * No one-pager cheat sheet with the 6 most basic commands on it so\n people can go use git.\n\n (This got corrected. There is git cheat sheet on the Internet;\n there is link on GitWiki to it)\n\n * Having a git library where other apps can integrate git, along with\n bindings for Python would be great.\n\n Make it easier to use by graphical clients like KGit.\n\n (The libification projects from Google Summer of Code would help\n there, I think)\n\n * I think that moving away from shell scripts to builtins is a\n necessary step but I don't really like it. It would help if you\n kept them around, perhaps in contrib/, so that others can learn how\n to use the plumbing (I learned a lot about git from reading these\n shell scripts).\n\n (Doing it: shell scripts which are moved to builtin are retired to\n contrib/examples/ directory).\n\n * Building git is a pain. (SHA1 sources being a problem). Can't git\n use autoconf? Also I've heard people have issues with git's\n portability (for example some BSD variant). Shell scrips weren't\n portable to non bash IIRC and often relied on GNU extensions in\n some programs. Native Windows port is also important.\n\n Probably the toughest challenge for Git IMO is that Mercurial,\n Darcs and Bazaar are good and similar. Lack of Windows support\n makes some people rule out Git altogether even though it may be\n better overall.\n\n I'd like to just stress support for windows and central\n repositories. (...) In fact most of my friends really wanted to use\n git but they wanted a solid native port.\n\n I think key to the adoption of git is that it is made to run on\n Windows as well as the other major OSes.\n\n (Git tries to use autoconf in a way that is totally optional, to do\n detection and write options for Makefile; you are welcome to\n contribute to configure.ac. People work on making git more\n portable, for example trying to make it work with dash, defining\n in the meantime minimal POSIX-like shell compatibility required.\n Native MinGW Windows port is in the development)\n\n * I think that it is very nice that git is in the native OS\n repositories for Fedora. The Debian version needs updating.\n\n (git Makefile has rpm target, and git.spec target; perhaps this is\n the cause)\n\n * git-blame is manageable (with gc and reduced history etc) but that\n slowness still seems to be a negative point for many of my peers. I\n wouldn't mind better performance there either. Maybe some kind of\n optional indexing for those who want fast blame?\n\n (I recall there were some ideas about how to make git-blame faster\n on git mailing list. Making it interactive for graphical blame\n tools reduced latency; there is I think a bit place for easy\n improvement for reblaming. Maybe packv4 would help with blame\n performance... What is I think unchangeable is the fact that\n snapshot driven / whole history driven SCMs _always_ would be\n slower at least a bit than single-file based SCMs. This tradeoff\n is not possible to avoid. But don't forget that git has other\n tools for examining history, like path (subsystem) limiting,\n searching commit messages, pickaxe search and graphical history\n browsing tools like gitk or qgit)\n\n * Get a mascot perhaps O'Reilly animal for O'Reilly GitBook\n (Git User's Manual) like the svnbook.\n\n (What animal could Git use for O'Reilly? Herd of horses, or a\n pony?)\n\n * I'm wondering what the overall goal is - git's origin as a neutral\n ground was fine but it hasn't seemed to take off as a viable\n alternative for general use. Do you care about that? Is it ok\n that git is it's own little niche?\n\n (Junio, Linus?)\n\n\nSuggestions about git mailing list:\n\n * Git adoption will be limited by the actions and attitudes of those\n on the mailing list. 'If you can't say anything nice...'\n\n (We are nice, I think... to a point)\n\n * The ML had way too much traffic. I think there should be at least a\n git-patches@ where people submit there patches and git@ remains for\n user/dev discussions.\n\n (Most users find level of traffic on git mailing list O.K. It is\n not that hard to separate patch submission and their discussion\n from the rest of traffic thanks to [PATCH] prefix convention used.)\n\n\nSuggestions and comments about this survey:\n\n * Various questions need 'other' options such as the programming\n language question. Various questions that already have 'other' as a\n possible choice need a text box to fill in the specifics.\n\n (I am not sure if it is possible mixing radiobutton/checkbox with\n text field with currently used free survey service, survey.net.nz)\n\n * The text fields (and text areas) of this survey are way too small!\n\n (I am not sure if changing this is possible with currently used\n free survey service, survey.net.nz)\n\n * You should do a survey of feature requests.\n\n (See questions 13, 38, 41 and especially 37)\n\n * Shorten survey length. This survey is too damn long. Make the\n survey shorter!\n\n Cut down the number of questions on this survey by a factor of 4.\n\n (I think removing the questions which asks very similar question\n but in different context be a good start. But that aside: which\n questions should be dropped, which concatenated (and which split);\n which are useful and which are not?)\n\n * Questions not asked: what can be improved on GitWiki, workflows\n used and tools used, kind of repository hosting used for project,\n programming experience level and version control experience, using\n git for non-programming repositories like ikiwiki or documents,\n perceived git stability and number of bugs.\n\n (The surveys is very long as it is now. Those questions are nice,\n but it would make survey too long I think.)\n\n * The survey asks about new features that are not in a stable version\n of git yet. git-stash comes to mind. This is silly. Not everybody\n will track your development branch. I certainly don't. I don't for\n other SCMs I use either.\n\n (I tried to put only features which are in released, i.e. numbered,\n version. git-stash is in 1.5.3, see Documentation/RelNotes-1.5.3.txt)\n\n * Regarding Q19 (How do you obtain GIT?). I actually use all three\n forms on different systems.\n Mac: pull from MacPorts\n Ubuntu: from git.git\n remote systems: tar balls.\n\n (Should it be made multiple choice question, then?)\n\n\nSome other comments:\n\n * I've been so busy with other projects. I didn't realize so many\n interfaces exist. Thanks to this survey I'll spend some time\n checking out the wiki for the other interfaces.\n\n I didn't even know about any of the new git features listed in\n question 43.\n\n I need to get an up to date version as there are things mentioned\n in this survey that I don't know about.\n\n * At the 'Solutions Linux 2007' exhibition in Paris I have been\n looking for a service provider that could propose some training\n sessions for Git. I couldn't find one. Maybe in 2008...\n\n-- \nJakub Narebski\n(away from Internet)\n"},{"id":"55578","messageId":"20071012233654.GX31659@planck.djpig.de","threadId":"10194","inReplyTo":"8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Frank Lichtenheld","fromEmail":"frank@lichtenheld.de","sentAt":"2007-10-12T23:36:54Z","receivedAt":"2007-10-12T23:36:54Z","isPatch":false,"sender":{"key":"frank@lichtenheld.de","avatar":"https://gravatar.com/avatar/b9f1d4b120e138f157c9e480d0818197c474628923786adb98f30017cdb99c3c?d=mp&s=160"},"body":"On Sat, Oct 13, 2007 at 12:08:18AM +0200, Jakub Narebski wrote:\n> * I think that it is very nice that git is in the native OS\n> repositories for Fedora. The Debian version needs updating.\n> \n> (git Makefile has rpm target, and git.spec target; perhaps this is\n> the cause)\n\nNah, the Debian problem is just bad timing. Debian stable is stuck with\n1.4.4 which is unfortunate but not fixable. unstable is very fast with\nupdates and backports.org is very good, too (but lacks at least 10 days\ndue to upload policy).\n\nGruesse,\n-- \nFrank Lichtenheld \nwww: http://www.djpig.de/\n"},{"id":"55580","messageId":"Pine.LNX.4.64.0710130130380.25221@racer.site","threadId":"10194","inReplyTo":"8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-13T00:46:40Z","receivedAt":"2007-10-13T00:46:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nJakub, thank you very much for doing this. It is a very tedious work, and \nI deem it invaluable.\n\nOn Sat, 13 Oct 2007, Jakub Narebski wrote:\n\n> * IRC is blocked from work :-( I may try it by tunneling out.\n> \n> (Any suggestions here?)\n\nI had the same problem, and somebody pointed me to \nhttp://ircatwork.com/cgi-bin/irc/irc.cgi\n\n(But please be nice, or else it will be shut down...)\n\n> * Keep up the UI simplification and make sure the docs start off with\n> usage somewhat similar to CVS/SVN. I think many users are scared by\n> Git because they see the more powerful commands thrown around too\n> early and get scared.\n> \n> Git is just too complicated for a typical project. I understand\n> it's probably great for the Linux kernel but for a smaller project\n> like mine (Mesa) it's overkill and a frustration. (...) With git\n> everything seems hard. (...) I've _wasted_ hours trying to figure\n> out git. That alone is a huge issue. I guess I could go into\n> specific details about my problems with git but I've already spent\n> enough time on this survey.\n\nI find it always a little strange how people want to use something like \ngit, but are unwilling to ask. Is this such a big attack on the manliness \nto admist one needs help or what?\n\n> Figure out why people find git hard to learn and eliminate those\n> barriers to entry. Make git more task-oriented rather than\n> data-model-oriented the way it is now.\n\nFrankly, expectations like these make me want to bang somebody's head on \nthe wall. Why do people expect others to work for them for free? Hard?\n\n> (...) I'm evaluating Mercurial despite its being based on Python\n> because it feels cleaner and simpler to use. I would prefer to use\n> Git.\n\nYou cannot do much about feelings, not with technical means, you can't.\n\n> * No one-pager cheat sheet with the 6 most basic commands on it so\n> people can go use git.\n> \n> (This got corrected. There is git cheat sheet on the Internet;\n> there is link on GitWiki to it)\n\nI think it'd be a good idea to put it on git://git.kernel.org/, linked \nright before the links to the man pages. Who has permissions to change \nthat page?\n\n> I'd like to just stress support for windows and central\n> repositories. (...) In fact most of my friends really wanted to use\n> git but they wanted a solid native port.\n\nIf you read what I wrote above, you know exactly what I want to do here.\n\n> * Get a mascot perhaps O'Reilly animal for O'Reilly GitBook\n> (Git User's Manual) like the svnbook.\n> \n> (What animal could Git use for O'Reilly? Herd of horses, or a\n> pony?)\n\nOMG Ponies!\n\nSeriously again, is the cheetah taken already?\n\nSpeaking of cheetah: there is a project called git-cheetah, its goal being \nto provide a TortoiseCVS lookalike for git.\n\nJust wanted to mention it, in case people want it, and are not too shy to \nparticipate in making it closer to the goal.\n\n> * I'm wondering what the overall goal is - git's origin as a neutral\n> ground was fine but it hasn't seemed to take off as a viable\n> alternative for general use. Do you care about that? Is it ok\n> that git is it's own little niche?\n> \n> (Junio, Linus?)\n\nI am neither, but FWIW I did not have the impression that it is in its own \nlittle niche.\n\nAt the GSoC mentor summit, I encountered a rather different stance: people \ndid not _know_ what distributed SCM means, and were rather afraid of the \nconcept. Some of them seemed to fight changing their known procedures \ntooth and nail. Which is fine by me (I don't have to force anybody to \nuse git, thankyouverymuch).\n\n\n\nA word about the GitFAQ... there was one suggestion that there should be a \nFAQ maintainer.\n\nI really have to ask myself why not more people just edit the GitFAQ on \nthe wiki. I mean, that is the whole purpose of it being on the wiki. \nIt's not hard either.\n\nLess hard in any case than to find a volunteer for a FAQ maintainer -- I \nmean, if most are too busy/lazy/shy to edit the FAQ at all, how do they \nexpect somebody else to step up?\n\nCiao,\nDscho\n"},{"id":"55581","messageId":"20071013021345.GA7499@fieldses.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710130130380.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-13T02:13:46Z","receivedAt":"2007-10-13T02:13:46Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sat, Oct 13, 2007 at 01:46:40AM +0100, Johannes Schindelin wrote:\n> On Sat, 13 Oct 2007, Jakub Narebski wrote:\n... (from survey response:)\n> > Figure out why people find git hard to learn and eliminate those\n> > barriers to entry. Make git more task-oriented rather than\n> > data-model-oriented the way it is now.\n> \n> Frankly, expectations like these make me want to bang somebody's head on \n> the wall. Why do people expect others to work for them for free? Hard?\n\nWell, hey, we asked for suggestions. Think of it as a project someone\nmight want to work on, rather than as a command.\n\nI don't know what they mean by \"make git more task-oriented rather than\ndata-model-oriented\", but the first suggestion (\"Find out why people\nfind git hard to learn...\") is certainly something I'd enjoy working on\nif I found the time.\n\n--b.\n"},{"id":"55583","messageId":"20071013025305.GI27899@spearce.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710130130380.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-13T02:53:05Z","receivedAt":"2007-10-13T02:53:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Sat, 13 Oct 2007, Jakub Narebski wrote:\n> > * I'm wondering what the overall goal is - git's origin as a neutral\n> > ground was fine but it hasn't seemed to take off as a viable\n> > alternative for general use. Do you care about that? Is it ok\n> > that git is it's own little niche?\n> > \n> > (Junio, Linus?)\n> \n> I am neither, but FWIW I did not have the impression that it is in its own \n> little niche.\n\nI'm neither too. But I don't think Git is in a niche. OK, well,\nin the overall world of software development its certainly in the\nniche of version control, as uh, it doesn't do Enterprise Resource\nPlanning and Large Scale Embezzlement of Monies (ERPaLSEM).\n\nActually I've seen a number of people on the interweb saying things\nlike they were switching their project to Git because they felt\nit had more staying power than say Monotone or Mercurial, partly\nbecause the kernel devs were actively using it, partly because the\nfile formats are so simple and sane, and partly because lots of\nother projects are using it or are seriously considering it.\n\n> At the GSoC mentor summit, I encountered a rather different stance: people \n> did not _know_ what distributed SCM means, and were rather afraid of the \n> concept. Some of them seemed to fight changing their known procedures \n> tooth and nail. Which is fine by me (I don't have to force anybody to \n> use git, thankyouverymuch).\n\nYes, this attitude *shocked the hell out of me*. I really did not\nexpect it. I nearly keeled over and died when I realized what the\nfolks in the back corner of the room were saying.\n\nWINE uses Git. Some folks were outright pissed off that there\nwas only one committer in WINE. I think they felt the project\nwas maybe going to die because there was only one committer who\ncould apply patches. That may wind up being true (there's only so\nfar that one human can scale without trusted helpers for different\nsubmodules of a large system) but its not Git's fault, or any other\nDVCS's fault for that matter. At least its easy to fork WINE.\n\nOn the other hand active participants of two major organizations (KDE\nand Eclipse) are starting to seriously look at Git. The interest\nin Git is growing in both of those groups, which can only be good\nfor us. We'll learn more about how these groups do development,\nand how we can best help them to accomplish more.\n \n-- \nShawn.\n"},{"id":"55584","messageId":"20071013030439.GJ27899@spearce.org","threadId":"10194","inReplyTo":"8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-13T03:04:40Z","receivedAt":"2007-10-13T03:04:40Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Other\n> * SourceForge / Gna! / Google Projects support\n> (free) hosting with git facilities\n> FOSS hosting sites supporting git\n\nWe may find support for Git on SourceForge in the future, but not\non Google Projects anytime soon, if ever.\n\nAt the Google Summer of Code Mentor Summit last Saturday Dscho had a\nshort chat with someone from the Google Code group. Apparently they\ndid at least look at Git briefly but concluded that they cannot\nimplement it on their site as our backend storage database is just\nplain files on the local filesystem.\n\nOne of the reasons (probably among many but whatever) that I think\nGoogle hired the \"SVN guys\" as employees is to develop a Google\nspecific backend for SVN (replaces fsfs and bdb) that stores the\nSVN revision data in a Google BigTable cell rather than on the\nlocal filesystem. This allows Google to efficently manage the\nentire site, including distributed replication, hot failover, etc...\nBigTable is one of their key technologies at this point.\n\nIf you don't know about BigTable but want to know more you can\nsearch for details about it via this awesome search engine I have\nheard about: http://www.google.com/ :-)\n\nI've managed to glean enough details on BigTable to know that the\nGit backend is *not* easily layered on top of it. But the SVN\nfsfs backend is actually fairly easy to translate into BigTable,\nso I imagine it didn't take the \"SVN guys\" very long to develop\nthe new backend, test it, and thus deploy SVN onto Google Projects.\n\n\nFunny aside: If you really want to know about BigTable apparently\nyou also need to visit (one of?) the men's room in building 43\non the second floor. There were tutorial posters hanging on the\nwall describing how to use BigTable and Sawzall to summerize a\nlarge dataset. Most pubs hang sports pages from the local paper;\nGoogle hangs BigTable documentation. Nerds. All of 'em.\n\n-- \nShawn.\n"},{"id":"55600","messageId":"20071013125845.GA31659@planck.djpig.de","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710130130380.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Frank Lichtenheld","fromEmail":"frank@lichtenheld.de","sentAt":"2007-10-13T12:58:45Z","receivedAt":"2007-10-13T12:58:45Z","isPatch":false,"sender":{"key":"frank@lichtenheld.de","avatar":"https://gravatar.com/avatar/b9f1d4b120e138f157c9e480d0818197c474628923786adb98f30017cdb99c3c?d=mp&s=160"},"body":"On Sat, Oct 13, 2007 at 01:46:40AM +0100, Johannes Schindelin wrote:\n> On Sat, 13 Oct 2007, Jakub Narebski wrote:\n> > Figure out why people find git hard to learn and eliminate those\n> > barriers to entry. Make git more task-oriented rather than\n> > data-model-oriented the way it is now.\n> \n> Frankly, expectations like these make me want to bang somebody's head on \n> the wall. Why do people expect others to work for them for free? Hard?\n\nIt's called \"User\". And since this is the Git _User's_ Survey, I guess\nyou will have to live with that. And anyway, where in the above you find\nsomething about \"expectation\" rather than \"suggestion\"?\n\nGruesse,\n-- \nFrank Lichtenheld \nwww: http://www.djpig.de/\n"},{"id":"55601","messageId":"Pine.LNX.4.64.0710131402400.25221@racer.site","threadId":"10194","inReplyTo":"20071013125845.GA31659@planck.djpig.de","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-13T13:04:47Z","receivedAt":"2007-10-13T13:04:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 13 Oct 2007, Frank Lichtenheld wrote:\n\n> On Sat, Oct 13, 2007 at 01:46:40AM +0100, Johannes Schindelin wrote:\n> > On Sat, 13 Oct 2007, Jakub Narebski wrote:\n> > > Figure out why people find git hard to learn and eliminate those\n> > > barriers to entry. Make git more task-oriented rather than\n> > > data-model-oriented the way it is now.\n> > \n> > Frankly, expectations like these make me want to bang somebody's head \n> > on the wall. Why do people expect others to work for them for free? \n> > Hard?\n> \n> It's called \"User\". And since this is the Git _User's_ Survey, I guess \n> you will have to live with that. And anyway, where in the above you find \n> something about \"expectation\" rather than \"suggestion\"?\n\n\"Figure out\" sounds to me like an imperative.\n\nBut my real point is: these guys know exactly what they find hard in git. \nWhy don't they just come and tell us?\n\nJust like Carl Worth did, way back when. And it worked, didn't it? Git \n1.5 is vastly more user friendly than pre 1.5.\n\nCiao,\nDscho\n"},{"id":"55620","messageId":"471107AB.2050807@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710130130380.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-13T18:00:11Z","receivedAt":"2007-10-13T18:00:11Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> \n> At the GSoC mentor summit, I encountered a rather different stance: people \n> did not _know_ what distributed SCM means, and were rather afraid of the \n> concept. Some of them seemed to fight changing their known procedures \n> tooth and nail. Which is fine by me (I don't have to force anybody to \n> use git, thankyouverymuch).\n> \n\nI recently attended a fairly large opensource conference in germany, where\ncompanies that somehow do business around the opensource network\nmonitoring tool named Nagios gather and drink themselves and each other\ninto insensibility once a year. I ran into much the same issues there, even though\nit would have made all our lives a whole lot easier if we could pull patches from\neach others repositories.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55624","messageId":"853awepyz6.fsf@lola.goethe.zz","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710130130380.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-13T19:59:41Z","receivedAt":"2007-10-13T19:59:41Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Jakub, thank you very much for doing this. It is a very tedious\n> work, and I deem it invaluable.\n\nAnd yet you trash the results.\n\n>> Git is just too complicated for a typical project. I understand\n>> it's probably great for the Linux kernel but for a smaller\n>> project like mine (Mesa) it's overkill and a frustration. (...)\n>> With git everything seems hard. (...) I've _wasted_ hours\n>> trying to figure out git. That alone is a huge issue. I guess I\n>> could go into specific details about my problems with git but\n>> I've already spent enough time on this survey.\n>\n> I find it always a little strange how people want to use something\n> like git, but are unwilling to ask. Is this such a big attack on\n> the manliness to admist one needs help or what?\n\nNot everybody likes getting the kind of treatment you find fit to dish\nout.\n\n>> Figure out why people find git hard to learn and eliminate those\n>> barriers to entry. Make git more task-oriented rather than\n>> data-model-oriented the way it is now.\n>\n> Frankly, expectations like these make me want to bang somebody's\n> head on the wall.\n\nAnd you wonder that people are unwilling to ask for things on the\nlist? When even mentioning something in a _survey_ makes core\ndevelopers want to bang their heads against a wall?\n\nI find it a pity that my suggestion to ask about how comfortable\npeople are with the tone on the list did not make it into the survey.\nEnough core developers make the tone sufficiently unconstructive to\nmake it quite understandable that people are unwilling to ask\nquestions here, in order to avoid getting their heads banged against a\nwall, virtual or not.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55644","messageId":"20071013202713.GA2467@fieldses.org","threadId":"10194","inReplyTo":"853awepyz6.fsf@lola.goethe.zz","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-13T20:27:13Z","receivedAt":"2007-10-13T20:27:13Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sat, Oct 13, 2007 at 09:59:41PM +0200, David Kastrup wrote:\n> Johannes Schindelin writes:\n> \n...survey quote:\n> >> Figure out why people find git hard to learn and eliminate those\n> >> barriers to entry. Make git more task-oriented rather than\n> >> data-model-oriented the way it is now.\n> >\n> > Frankly, expectations like these make me want to bang somebody's\n> > head on the wall.\n> \n> And you wonder that people are unwilling to ask for things on the\n> list? When even mentioning something in a _survey_ makes core\n> developers want to bang their heads against a wall?\n\nWell, he does have a point that they could have been more specific.\n\nBut, yes, \"I wish we could get people to be more specific\" might be the\nbetter way to put it.\n\n--b.\n"},{"id":"55648","messageId":"85myumohqv.fsf@lola.goethe.zz","threadId":"10194","inReplyTo":"20071013202713.GA2467@fieldses.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-13T20:57:12Z","receivedAt":"2007-10-13T20:57:12Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Sat, Oct 13, 2007 at 09:59:41PM +0200, David Kastrup wrote:\n>> Johannes Schindelin writes:\n>> \n> ...survey quote:\n>> >> Figure out why people find git hard to learn and eliminate those\n>> >> barriers to entry. Make git more task-oriented rather than\n>> >> data-model-oriented the way it is now.\n>> >\n>> > Frankly, expectations like these make me want to bang somebody's\n>> > head on the wall.\n>> \n>> And you wonder that people are unwilling to ask for things on the\n>> list? When even mentioning something in a _survey_ makes core\n>> developers want to bang their heads against a wall?\n>\n> Well, he does have a point that they could have been more specific.\n\nHe did not write \"vague phrasings like this\". He wrote\n\"_expectations_ like these make [him] want to bang somebody's head on\nthe wall\".\n\n> But, yes, \"I wish we could get people to be more specific\" might be\n> the better way to put it.\n\nIt is something entirely different.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55655","messageId":"Pine.LNX.4.64.0710140135020.25221@racer.site","threadId":"10194","inReplyTo":"20071013202713.GA2467@fieldses.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T00:36:54Z","receivedAt":"2007-10-14T00:36:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 13 Oct 2007, J. Bruce Fields wrote:\n\n> On Sat, Oct 13, 2007 at 09:59:41PM +0200, David Kastrup wrote:\n> > Johannes Schindelin writes:\n> > \n> ...survey quote:\n> > >> Figure out why people find git hard to learn and eliminate those\n> > >> barriers to entry. Make git more task-oriented rather than\n> > >> data-model-oriented the way it is now.\n> > >\n> > > Frankly, expectations like these make me want to bang somebody's\n> > > head on the wall.\n> > \n> > And you wonder that people are unwilling to ask for things on the\n> > list?\n\nThat is utter rubbish.\n\n> Well, he does have a point that they could have been more specific.\n> \n> But, yes, \"I wish we could get people to be more specific\" might be the \n> better way to put it.\n\nYes, there are politer ways to phrase it.\n\nMy main point is -- and always was -- that I'd like people to realise how \nmuch it depends on _them_ if (and when) their wishes come true.\n\nCiao,\nDscho\n"},{"id":"55658","messageId":"alpine.LFD.0.999.0710131810550.6887@woody.linux-foundation.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710140135020.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-14T01:13:18Z","receivedAt":"2007-10-14T01:13:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 14 Oct 2007, Johannes Schindelin wrote:\n>\n> My main point is -- and always was -- that I'd like people to realise how \n> much it depends on _them_ if (and when) their wishes come true.\n\nDscho, that's just not fair.\n\nThe fact is, stating what you wish for *is* taking an action. Starting to \ncomplain about people stating their wishes (which you have done several \ntimes) is simply unreasonable.\n\nYou don't have to *do* what they wish for, but I really wish you stopped \ncomplaining about people bringing up their hopes for improvement.\n\nComplain about it when somebody asks for something *stupid*. Explain why \nit would be wrong to do something like that. But don't complain about \npeople having wish-lists, even if those people may not work on them.\n\nNot everybody is a \"doer\". It's important to get input from people who are \njust plain users, or hope to be.\n\n\t\tLinus\n"},{"id":"55659","messageId":"20071014014445.GN27899@spearce.org","threadId":"10194","inReplyTo":"alpine.LFD.0.999.0710131810550.6887@woody.linux-foundation.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-14T01:44:45Z","receivedAt":"2007-10-14T01:44:45Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Sun, 14 Oct 2007, Johannes Schindelin wrote:\n> >\n> > My main point is -- and always was -- that I'd like people to realise how \n> > much it depends on _them_ if (and when) their wishes come true.\n> \n> Dscho, that's just not fair.\n...\n> Complain about it when somebody asks for something *stupid*. Explain why \n> it would be wrong to do something like that. But don't complain about \n> people having wish-lists, even if those people may not work on them.\n> \n> Not everybody is a \"doer\". It's important to get input from people who are \n> just plain users, or hope to be.\n\nI agree with both of you. My understanding of Dscho's original\ncomment was that people weren't saying *what* specifically their\nwish-list was, which means we have no hope as a community of meeting\ntheir requests.\n\nCarl and Andy both had submitted a long list of very specific issues\nthat they had with Git. The result of those lists being posted was\na number of people contributed improvements that lead us to 1.5.\nNobody can argue with that.\n\nBut just saying \"MY GOD FIX THE UI\" is not a wishlist item (yes,\nthat was a real survey answer). It provides the community no\nchance to understand what parts of the UI we need to work on, and\nwhat parts the end-user is OK with or just hasn't even tried to use.\n\n-- \nShawn.\n"},{"id":"55660","messageId":"Pine.LNX.4.64.0710140304430.25221@racer.site","threadId":"10194","inReplyTo":"alpine.LFD.0.999.0710131810550.6887@woody.linux-foundation.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T02:06:40Z","receivedAt":"2007-10-14T02:06:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 13 Oct 2007, Linus Torvalds wrote:\n\n> On Sun, 14 Oct 2007, Johannes Schindelin wrote:\n> >\n> > My main point is -- and always was -- that I'd like people to realise \n> > how much it depends on _them_ if (and when) their wishes come true.\n> \n> Dscho, that's just not fair.\n> \n> The fact is, stating what you wish for *is* taking an action. Starting \n> to complain about people stating their wishes (which you have done \n> several times) is simply unreasonable.\n\nWell, maybe I overreacted.\n\n> You don't have to *do* what they wish for, but I really wish you stopped \n> complaining about people bringing up their hopes for improvement.\n\nFair enough, I'll shut up about these issues.\n\nAt least as long as I can hold my breath ;-)\n\n> Complain about it when somebody asks for something *stupid*. Explain why \n> it would be wrong to do something like that. But don't complain about \n> people having wish-lists, even if those people may not work on them.\n> \n> Not everybody is a \"doer\". It's important to get input from people who are \n> just plain users, or hope to be.\n\nA pity, but you're probably right.\n\nCiao,\nDscho\n"},{"id":"55665","messageId":"alpine.LFD.0.999.0710132011270.6887@woody.linux-foundation.org","threadId":"10194","inReplyTo":"20071014014445.GN27899@spearce.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-14T03:15:03Z","receivedAt":"2007-10-14T03:15:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 13 Oct 2007, Shawn O. Pearce wrote:\n> \n> But just saying \"MY GOD FIX THE UI\" is not a wishlist item (yes,\n> that was a real survey answer). It provides the community no\n> chance to understand what parts of the UI we need to work on, and\n> what parts the end-user is OK with or just hasn't even tried to use.\n\nHeh. I do agree that some people just ask for unreasonable or stupid \nthings (or maybe they are just really bad at explaining them, and may have \nsomething non-stupid in mind but just cannot articulate it).\n\nAnd I also agree that there are tons of people who are just lazy and don't \neven bother to try to explain themselves.\n\nAnd I'll flame people myself. I can't even say that's a rare event. So I \nshouldn't throw _too_ many stones, or one of them might bounce back. \n\nBut at the same time, just accepting that there are people who will \npotentially never really be productive members of society (whether \n\"society\" is git or something bigger), is probably a good idea. They \naren't worth complaining about: they don't generally tend to take anything \naway from the community unless the community itself reacts negatively to \nthem.\n\n\t\t\tLinus\n"},{"id":"55666","messageId":"Pine.LNX.4.64.0710132037290.30704@asgard.lang.hm","threadId":"10194","inReplyTo":"alpine.LFD.0.999.0710132011270.6887@woody.linux-foundation.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-14T03:43:27Z","receivedAt":"2007-10-14T03:43:27Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 13 Oct 2007, Linus Torvalds wrote:\n\n> But at the same time, just accepting that there are people who will\n> potentially never really be productive members of society (whether\n> \"society\" is git or something bigger), is probably a good idea. They\n> aren't worth complaining about: they don't generally tend to take anything\n> away from the community unless the community itself reacts negatively to\n> them.\n\nI'll also point out that being a 'productive member of society' may have a \nwider definition then you may think initially.\n\nis a sysadmin who never contribures a line of code, but switches hundreds \nof servers to linux and assists friends in migrating to Linux a productive \nmember? he doesn't contribute any code, so some people would say no, but \nin spreading the use he is increasing the number of potential contributers \nso others would say yes.\n\nkeep this in mind before you assume that someone isn't worth anything.\n\nDavid Lang\n"},{"id":"55667","messageId":"alpine.LFD.0.999.0710132051440.6887@woody.linux-foundation.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710132037290.30704@asgard.lang.hm","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-14T03:55:12Z","receivedAt":"2007-10-14T03:55:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 13 Oct 2007, david@lang.hm wrote:\n>\n> I'll also point out that being a 'productive member of society' may have a\n> wider definition then you may think initially.\n\nI actually meant it in the absolutely most narrow possible meaning: you \ntake the least productive person imaginable, who is certainly not going to \ndo anything at all, and in the end, who cares? It's not like nonproductive \npeople really hurt.\n\nSome people in the open source / free software world get really upset \nabout \"freeloaders\". I think that's silly. First off, I agree with you \nthat a lot of people don't even end up being freeloaders - even if you \nnever code a single line of code, there are ton of ways to be usefully \ninvolved (and some of them will be entirely invisible to any developer - \nhelping random people outside the development lists, for example).\n\nBut more importantly, even somebody who really isn't productive at all \ngenerally can't be messing things up either - so it's a nonissue. Unless \nit results in tons of flaming ...\n\n\t\tLinus\n"},{"id":"55675","messageId":"4711D72B.2080107@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710140304430.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-14T08:45:31Z","receivedAt":"2007-10-14T08:45:31Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 13 Oct 2007, Linus Torvalds wrote:\n> \n>>\n>> Not everybody is a \"doer\". It's important to get input from people who are \n>> just plain users, or hope to be.\n> \n> A pity, but you're probably right.\n> \n\nIt's not a pity, and he's most definitely right. Users tend to think in terms\nof \"I'd like to get this task done\" while coders tend to think in terms of\n\"this would be cool/possible to implement\". The reason git actually *works* so\ngreat is, I'm sure, the fact that it was originally designed around a very specific\nneed by someone thinking like a *user*. The fact that it happened to be a pretty\ncompetent programmer just meant he could express his wishes as algorithms in a\nprogramming language and make it happen.\n\nI'm 100% sure that if Linus had been so interested in SCM's that he'd abandoned\nthe Linux kernel to be full-time maintainer for git instead, it would have had\nall sorts of oddities in it that nobody uses, just because they're possible to\ndo.\n\nI also think Linus made a very wise decision in picking Junio to maintain it. So\nfar, I haven't seen him accept a single feature-patch into git that wasn't\nexplained to solve a specific problem.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55688","messageId":"858x66nja8.fsf@lola.goethe.zz","threadId":"10194","inReplyTo":"4711D72B.2080107@op5.se","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-14T09:21:35Z","receivedAt":"2007-10-14T09:21:35Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Andreas Ericsson writes:\n\n> I also think Linus made a very wise decision in picking Junio to\n> maintain it. So far, I haven't seen him accept a single\n> feature-patch into git that wasn't explained to solve a specific\n> problem.\n\nWhile I hold Junio's technical judgment in high regard, it is actually\nthe area of communication skills and conversation tone where I would\nreally wish more to follow his example.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55693","messageId":"3f4fd2640710140320h5c1e1f7gf9f43a626aaa6897@mail.gmail.com","threadId":"10194","inReplyTo":"20071014014445.GN27899@spearce.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2007-10-14T10:20:30Z","receivedAt":"2007-10-14T10:20:30Z","isPatch":false,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 14/10/2007, Shawn O. Pearce wrote:\n> But just saying \"MY GOD FIX THE UI\" is not a wishlist item (yes,\n> that was a real survey answer). It provides the community no\n> chance to understand what parts of the UI we need to work on, and\n> what parts the end-user is OK with or just hasn't even tried to use.\n\nMy interpretation of that answer is that your average user\n(specifically Windows user) is more focused on a graphical interface,\nand will mean GUI when they say UI.\n\nThe core plumbing in git is solid. The porcelain, with the 1.5 series,\nmakes git simpler to use from the command line. Now, the GUI available\nfor git is seriously lacking.\n\nIf you look at the GUI tools available for CVS, SVN, Perforce and\nothers, these offer you the complete functionality of those tools from\nwithin them. They provide command line tools for those that need them,\nbut also come with a GUI application that allows the user to manage\ntheir files within the source control system they are using (e.g.\nWinCVS and P4V), shell integration (e.g. TortoiseCVS/SVN), IDE\nintegration and others.\n\nAt the moment, git has a good timeline view of commits through the\nGUI, but have found the mingw version to be slow in places (I can't\nremember when, but was likely before some performance improvements in\nthat area were made) and haven't tried out the Linux version yet. This\nis a good starting point to build on, but to be more useful it needs\nto extend to all of git's functionality.\n\n- Reece\n"},{"id":"55757","messageId":"47125BF7.2070503@midwinter.com","threadId":"10194","inReplyTo":"3f4fd2640710140320h5c1e1f7gf9f43a626aaa6897@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-14T18:12:07Z","receivedAt":"2007-10-14T18:12:07Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Reece Dunn wrote:\n> The core plumbing in git is solid. The porcelain, with the 1.5 series,\n> makes git simpler to use from the command line. Now, the GUI available\n> for git is seriously lacking.\n> \n\nI'm not sure I agree with that. Here's the section on git from the \n\"Comparison with other systems\" part of the Mercurial book. I'll \nreproduce it in its entirety here and add my own comments about each \nparagraph.\n\n > Git is a distributed revision control tool that was developed for \nmanaging the\n > Linux kernel source tree. Like Mercurial, its early design was \nsomewhat influenced\n > by Monotone.\n\nNo argument there.\n\n > Git has an overwhelming command set, with version 1.5.0 providing 139\n > individual commands. It has a reputation for being difficult to \nlearn. It does not have\n > a user manual, only documentation for individual commands.\n\nThe part about the user manual is bunk (and was bunk in version 1.5.0, \nIIRC, so I'm not sure where he gets that.) But the first part of that is \nthe key here. I admit that's even bitten me from time to time. I \ncouldn't remember the name of the \"git-instaweb\" command just yesterday; \ndoing \"ls /usr/local/bin/git-*\" was, I'd have to agree, pretty overwhelming.\n\nWe could probably solve that by tucking the plumbing commands away in a \nlib or libexec directory and only exposing the porcelain commands in the \ndirectory the end user is likely to look at.\n\nBut that's just an aspect of a more general fact: it's hard to use git \nwithout getting exposed to the plumbing at least a little. Another \nexample is the manpages: try to look up the commonly-used options to \n\"git diff\" (porcelain) and you will be forced to learn about \"git \nrev-parse\" (plumbing).\n\nThe point is, though, that this is a valid complaint about git's UI that \nhas nothing to do with GUIs.\n\n > In terms of performance, git is extremely fast. There are several \ncommon cases\n > in which it is faster than Mercurial, at least on Linux. However, its \nperformance\n > on (and general support for) Windows is, at the time of writing, far \nbehind that of\n > Mercurial.\n\nA fair statement, though of course that's been improving by leaps and \nbounds of late and hopefully will soon be an outdated argument. The \nWindows user experience has been subpar historically.\n\n > While a Mercurial repository needs no maintenance, a Git repository \nrequires frequent\n > manual “repacks” of its metadata. Without these, performance \ndegrades, while space\n > usage grows rapidly. A server that contains many Git repositories \nthat are not rigorously\n > and frequently repacked will become heavily disk-bound during \nbackups, and there\n > have been instances of daily backups taking far longer than 24 hours \nas a result.\n > A freshly packed Git repository is slightly smaller than a Mercurial \nrepository, but an\n > unpacked repository is several orders of magnitude larger.\n\nThis was true at the time the hg book was written. Now that we have the \nauto-packing code, hopefully it will be a moot point. So that's one \"fix \nthe UI\" complaint that has been addressed; whether *successfully* or \nnot, time will tell. But hg definitely had a user experience advantage \nhere until very recently.\n\n > The core of Git is written in C. Many Git commands are implemented as \nshell or Perl\n > scripts, and the quality of these scripts varies widely. I have \nencountered a number of\n > instances where scripts charged along blindly in the presence of \nerrors that should have\n > been fatal.\n\nNo doubt this is true as well. Obviously the C-ification process will \ntake care of a lot of this, though of course one can charge along \nblindly in the presence of errors in any language (including, shock of \nshocks given the implication here, Python.) To the extent we can find \nplaces where this is still true, obviously they should be fixed. I \nwonder if anyone knows the author of the book well enough to ferret some \nspecifics out of him toward that end.\n\nNow, about hg vs. git in general. I actually spent some time this \nweekend coming up to speed on hg basics just to see what all the UI fuss \nwas about. As far as I can see it is about a wash all told; some things \nare easier in git and some in hg. However, here's my speculation about \nwhy people might claim hg is easier. I see three things:\n\nMultiple branches per repo. Mercurial allows them, but you won't find \nthem mentioned anywhere in any of the beginner tutorials. They encourage \npeople to use a \"one repo per branch\" model. Having gotten used to git's \nbranching model, you'd have to pry that feature out of my cold, dead \nfingers, but it's fundamentally much easier to understand a model of \"if \nyou want to make two unrelated changes to your code, just make two \ncopies of the source tree.\" It's possible git's introductory \ndocumentation should delay talking about \"git branch\" until later, and \nstart off talking about how to work with one (checked out) branch per repo.\n\nUpdate to a dirty working copy. I think there's a tendency in these \nparts to vastly underestimate the importance of being able to pull down \nupdates from a master repository while you're in the middle of \ndevelopment. Mercurial's equivalent to bare \"git pull\", namely \"hg pull\" \nfollowed by \"hg update\", works fine if you have edits in your working \ncopy; if there are conflicting changes, it pops you into a conflict \nresolution UI (or adds conflict markers, depending on your settings) and \nyou continue on your merry way after resolving everything. This workflow \nis really common, especially in corporate settings where there's very \nfine-grained collaboration going on during initial development (a huge \ndifference from the open-source world where most of the time it's just \none person doing an initial prototype.) Right now working this way is a \npain in git. Less so now that we have \"git stash\", but it could still be \nmuch, much smoother.\n\nVerbosity. IMO Mercurial swings too far in this direction, but in \ngeneral it's either completely silent or very terse in its output. There \nis never, as far as I can see, any low-level diagnostic information spit \nout to the user unless an hg command is run with a \"verbose\" option. \nHere's \"hg pull; hg update\", for example (and \"pull\" is one of hg's \nchattier commands):\n\npulling from ../child1\nsearching for changes\nadding changesets\nadding manifests\nadding file changes\nadded 8 changesets with 8 changes to 3 files (+1 heads)\n(run 'hg heads' to see heads, 'hg merge' to merge)\n3 files updated, 0 files merged, 0 files removed, 0 files unresolved\n\nCompare with the equivalent \"git pull\" and put yourself in the shoes of \na user who is running that command for the first time:\n\nremote: Generating pack...\nremote: Counting objects: 9\nremote: Done counting 1118 objects.\nResult has 832 objects.\nremote: Deltifying 822 objects...\nremote: 100% (822/822) done\nIndexing 832 objects...\nremote: Total 832 (delta 668), reused 0 (delta 0)\n100% (832/832) done\nResolving 668 deltas...\n100% (668/668) done\n258 objects were added to complete this thin pack.\n* refs/remotes/origin/session-fix: fast forward to branch 'session-fix' \nof ssh://devrs005/~/www\nold..new: 3de27db..a3d44c1\nAlready up-to-date.\n\nSo anyway, there are a few specifics. That's based on just a bit of \nplaying around with hg; maybe the differences go deeper than this, but I \nthink there isn't a huge usability gap between the two systems any more.\n\n-Steve\n"},{"id":"55761","messageId":"20071014184050.GB31260@fieldses.org","threadId":"10194","inReplyTo":"47125BF7.2070503@midwinter.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-14T18:40:50Z","receivedAt":"2007-10-14T18:40:50Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Oct 14, 2007 at 11:12:07AM -0700, Steven Grimm wrote:\n> But that's just an aspect of a more general fact: it's hard to use git \n> without getting exposed to the plumbing at least a little. Another example \n> is the manpages: try to look up the commonly-used options to \"git diff\" \n> (porcelain) and you will be forced to learn about \"git rev-parse\" \n> (plumbing).\n\nAs \"plumbing\" goes, \"git rev-parse\" isn't that bad, and the reference\nhere (to the \"SPECIFYING REVISIONS\" section) strikes me as reasonable.\nWe could factor out the common documentation into a separate (hopefully\nmore user-friendly) manpage about specifying revisions, I guess, and\nrefer to it everywhere instead of git-rev-parse. I don't know--any\nother ideas?\n\n> It's possible git's introductory documentation should delay talking \n> about \"git branch\" until later, and start off talking about how to work \n> with one (checked out) branch per repo.\n\nOne frequent use case is the case of a tester that wants to try out a\nbugfix in some topic branch. You want to tell them: \"please test the\nfix-that-bug branch in git://myproject.org/~me/repo.git\". They need to\nget that checked out somehow. And they should be able to do it without\nre-cloning every time.\n\nThat's one motivation, among others, for including git-branch (and\ngit-remote) very early.\n\nThough actually the quickest way to checkout an arbitrary revision is\nwith detached heads, and that doesn't require learning git-branch right\naway. I've tried rewriting the user-manual start that way but wasn't\nhappy with the result and didn't get too far. (See\ngit://linux-nfs.org/~bfields/git.git docwork-detached.)\n\n> Update to a dirty working copy. I think there's a tendency in these parts \n> to vastly underestimate the importance of being able to pull down updates \n> from a master repository while you're in the middle of development. \n> Mercurial's equivalent to bare \"git pull\", namely \"hg pull\" followed by \"hg \n> update\", works fine if you have edits in your working copy; if there are \n> conflicting changes, it pops you into a conflict resolution UI (or adds \n> conflict markers, depending on your settings) and you continue on your \n> merry way after resolving everything. This workflow is really common, \n> especially in corporate settings where there's very fine-grained \n> collaboration going on during initial development (a huge difference from \n> the open-source world where most of the time it's just one person doing an \n> initial prototype.) Right now working this way is a pain in git. Less so \n> now that we have \"git stash\", but it could still be much, much smoother.\n\nI'm lost--how is \"hg pull\" different from \"git pull\" in this respect?\n\n> Verbosity. IMO Mercurial swings too far in this direction, but in general \n> it's either completely silent or very terse in its output.\n\nYes, there's a lot of low-hanging fruit here for someone that's\ninterested in streamlining the default git command output. The\nchallenge is to get it a little terser while still being helpful (and\npreserving progress meters, and not obscuring what's going on any more\nthan necessary).\n\n--b.\n"},{"id":"55763","messageId":"47126D27.4060409@midwinter.com","threadId":"10194","inReplyTo":"20071014184050.GB31260@fieldses.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-14T19:25:27Z","receivedAt":"2007-10-14T19:25:27Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"J. Bruce Fields wrote:\n> I'm lost--how is \"hg pull\" different from \"git pull\" in this respect?\n> \n\n(Pedantry alert: \"hg pull\" is equivalent to \"git fetch\" and doesn't \nupdate the working copy. I'll talk here about the \"hg pull; hg update\" \npair which seems to be standard procedure in hg land.)\n\nHere's a simple example in each system to demonstrate the difference.\n\n---\n mkdir parent\n cd parent\n git init\n echo 'my baloney has a first name' > song.txt\n echo \"it's o-s-c-a-r\" >> song.txt\n echo 'my baloney has a last name' >> song.txt\n git add song.txt\n git commit -m \"test file\"\n cd ..\n git clone parent child\n cd parent\n echo \"it's m-a-y-e-r\" >> song.txt\n git commit -a -m \"another line in the song\"\n cd ../child\n perl -pi -e 's/first name/given name/' song.txt\n git pull\n---\n\nResult: \"fatal: Entry 'song.txt not uptodate. Cannot merge.\"\n\n---\n mkdir hgparent\n cd hgparent\n hg init\n echo 'my baloney has a first name' > song.txt\n echo \"it's o-s-c-a-r\" >> song.txt\n echo 'my baloney has a last name' >> song.txt\n hg add song.txt\n hg commit -m \"test file\"\n cd ..\n hg clone hgparent hgchild\n cd hgparent\n echo \"it's m-a-y-e-r\" >> song.txt\n hg commit -m \"another line in the song\"\n cd ../hgchild\n perl -pi -e 's/first name/given name/' song.txt\n hg pull\n hg update\n---\n\nResult: \"0 files updated, 1 files merged, 0 files removed, 0 files \nunresolved\" and the file contains the change from the parent plus the \nchange from the child, with the latter still an uncommitted edit that \nshows up in \"hg diff\".\n\n-Steve\n"},{"id":"55764","messageId":"alpine.LFD.0.9999.0710141542020.19446@xanadu.home","threadId":"10194","inReplyTo":"47125BF7.2070503@midwinter.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-14T19:44:45Z","receivedAt":"2007-10-14T19:44:45Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 14 Oct 2007, Steven Grimm wrote:\n\n> Verbosity. IMO Mercurial swings too far in this direction, but in general it's\n> either completely silent or very terse in its output. There is never, as far\n> as I can see, any low-level diagnostic information spit out to the user unless\n> an hg command is run with a \"verbose\" option. Here's \"hg pull; hg update\", for\n> example (and \"pull\" is one of hg's chattier commands):\n> \n> pulling from ../child1\n> searching for changes\n> adding changesets\n> adding manifests\n> adding file changes\n> added 8 changesets with 8 changes to 3 files (+1 heads)\n> (run 'hg heads' to see heads, 'hg merge' to merge)\n> 3 files updated, 0 files merged, 0 files removed, 0 files unresolved\n> \n> Compare with the equivalent \"git pull\" and put yourself in the shoes of a user\n> who is running that command for the first time:\n\nBTW I have patches here reworking the progress code for a more compact \ndisplay which should mitigate this issue quite a bit.\n\n\nNicolas\n"},{"id":"55765","messageId":"471272F5.2000902@op5.se","threadId":"10194","inReplyTo":"20071014184050.GB31260@fieldses.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-14T19:50:13Z","receivedAt":"2007-10-14T19:50:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"J. Bruce Fields wrote:\n> On Sun, Oct 14, 2007 at 11:12:07AM -0700, Steven Grimm wrote:\n> \n>> It's possible git's introductory documentation should delay talking \n>> about \"git branch\" until later, and start off talking about how to work \n>> with one (checked out) branch per repo.\n> \n> One frequent use case is the case of a tester that wants to try out a\n> bugfix in some topic branch. You want to tell them: \"please test the\n> fix-that-bug branch in git://myproject.org/~me/repo.git\". They need to\n> get that checked out somehow. And they should be able to do it without\n> re-cloning every time.\n> \n> That's one motivation, among others, for including git-branch (and\n> git-remote) very early.\n> \n> Though actually the quickest way to checkout an arbitrary revision is\n> with detached heads, and that doesn't require learning git-branch right\n> away.\n\nBut the *easiest* way, where \"easiest\" means \"involves the fewest commands\nwith smallest risk of fscking up your own repo\", is to do\n\n\ngit clone other-devs-repo\ncd other-devs-repo\ngit checkout -b thebug \n\n\nThe proper command-sequence for any other way of doing it will inevitably\nbe different depending on whether or not the user has changes in his\nworktree or not, whether or not those changes conflict with the bug-spot,\nwhether or not he's got the other developer's repo added as a remote, etc,\netc.\n\nToo many ifs, really, whereas the first way is guaranteed to work exactly\nthe same way everytime, at the cost of almost always being ridiculously\nsuboptimal.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55769","messageId":"Pine.LNX.4.64.0710142117220.25221@racer.site","threadId":"10194","inReplyTo":"471272F5.2000902@op5.se","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T20:18:16Z","receivedAt":"2007-10-14T20:18:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Andreas Ericsson wrote:\n\n> J. Bruce Fields wrote:\n>\n> > Though actually the quickest way to checkout an arbitrary revision is \n> > with detached heads, and that doesn't require learning git-branch \n> > right away.\n> \n> But the *easiest* way, where \"easiest\" means \"involves the fewest \n> commands with smallest risk of fscking up your own repo\", is to do\n> \n> \n> git clone other-devs-repo\n> cd other-devs-repo\n> git checkout -b thebug \n\nI'd just do\n\n\tgit checkout ^{commit}\n\nand be done...\n\nCiao,\nDscho\n"},{"id":"55771","messageId":"47127A86.2040607@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710142117220.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-14T20:22:30Z","receivedAt":"2007-10-14T20:22:30Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 14 Oct 2007, Andreas Ericsson wrote:\n> \n>> J. Bruce Fields wrote:\n>>\n>>> Though actually the quickest way to checkout an arbitrary revision is \n>>> with detached heads, and that doesn't require learning git-branch \n>>> right away.\n>> But the *easiest* way, where \"easiest\" means \"involves the fewest \n>> commands with smallest risk of fscking up your own repo\", is to do\n>>\n>>\n>> git clone other-devs-repo\n>> cd other-devs-repo\n>> git checkout -b thebug \n> \n> I'd just do\n> \n> \tgit checkout ^{commit}\n> \n> and be done...\n> \n\nSo:\n\n\tif (have_bug_in_repo)\n\t\tdo_the_dscho_way()\n\telse ...\n\nSee what I mean?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55772","messageId":"20071014202438.GC31260@fieldses.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710142117220.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-14T20:24:38Z","receivedAt":"2007-10-14T20:24:38Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Oct 14, 2007 at 09:18:16PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 14 Oct 2007, Andreas Ericsson wrote:\n> \n> > J. Bruce Fields wrote:\n> >\n> > > Though actually the quickest way to checkout an arbitrary revision is \n> > > with detached heads, and that doesn't require learning git-branch \n> > > right away.\n> > \n> > But the *easiest* way, where \"easiest\" means \"involves the fewest \n> > commands with smallest risk of fscking up your own repo\", is to do\n> > \n> > \n> > git clone other-devs-repo\n> > cd other-devs-repo\n> > git checkout -b thebug \n> \n> I'd just do\n> \n> \tgit checkout ^{commit}\n> \n> and be done...\n\nThe detached-HEAD approach also has the advantage that you don't leave\naround stuff (new branch heads) that may have to be cleaned up or\nmodified in the future. So you can tell someone about\n\n\tgit clone git://url/\n\tgit fetch origin\n\tgit checkout \n\tgit remote add remotename git://other-url/\n\tgit fetch remotename\n\nand as long as they're not making changes, that's pretty much all\nthey'll ever need to do to checkout any version.\n\nSure, you can tell them to reclone every time, but I think they'll get\nfrustrated with that pretty soon.\n\n--b.\n"},{"id":"55775","messageId":"e1dab3980710141410k23debb25mc578eed07c714f11@mail.gmail.com","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710130130380.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"David Tweed","fromEmail":"david.tweed@gmail.com","sentAt":"2007-10-14T21:10:14Z","receivedAt":"2007-10-14T21:10:14Z","isPatch":false,"sender":{"key":"david.tweed@gmail.com","avatar":null},"body":"On 10/13/07, Johannes Schindelin wrote:\n> > Figure out why people find git hard to learn and eliminate those\n> > barriers to entry. Make git more task-oriented rather than\n> > data-model-oriented the way it is now.\n>\n> Frankly, expectations like these make me want to bang somebody's head on\n> the wall. Why do people expect others to work for them for free? Hard?\n\nSince no-one else has mentioned it, I -- and I suspect some others --\ntry to use the \"beer round\" model with FOSS. When I go out for drinks\nwith people from work, I don't try and keep a precisely tally of who\nhas bought a drink for me and so whom I shoud buy a drink, and worry\nabout what how the accounting changes if me or someone goes home\nearly. I generally take the view that all the imbalances will roughly\nbalance out over the future. Sure you keep an eye out for complete\nfreeloaders, but you don't get overexcited about a temporary\nimbalance.\n\nLikewise, I will sometimes make suggestions -- hopefully politely --\nof various projects where my skills don't fit. (Eg, I'm not going to\nadd non-trivial features to the git shell scripts because I just don't\nknow non-trivial shell.) Hopefully some minor patch I've submitted\nsomewhere has, possibly through helping someone else who's helped\nsomeone else.... , helped you some minuscule amount.\n\nI'm perfectly fine with someone politely saying \"no developers are\ninterested in this, so it won't happen if you don't implement it\nyourself\", but when you accuse people who just bring up a possible\nfeature of being free-loaders it makes them question whether other\nprojects would be more productive places to spend one's time.\n\nIt's the difference between being told \"I suspect you'll have to do it\nyourself\" and \"how dare you even ask that! do it yourself!\".\n\n-- \ncheers, dave tweed__________________________\ndavid.tweed@gmail.com\nRm 124, School of Systems Engineering, University of Reading.\n\"we had no idea that when we added templates we were adding a Turing-\ncomplete compile-time language.\" -- C++ standardisation committee\n"},{"id":"55778","messageId":"8fe92b430710141449r3f1b1a85oae2a5fb5b30c8b47@mail.gmail.com","threadId":"10194","inReplyTo":"853awepyz6.fsf@lola.goethe.zz","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-14T21:49:16Z","receivedAt":"2007-10-14T21:49:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/13/07, David Kastrup wrote:\n\n> I find it a pity that my suggestion to ask about how comfortable\n> people are with the tone on the list did not make it into the survey.\n> Enough core developers make the tone sufficiently unconstructive to\n> make it quite understandable that people are unwilling to ask\n> questions here, in order to avoid getting their heads banged against a\n> wall, virtual or not.\n\nI think next to last question in the survey\n\n 61. Did you have problems getting GIT help on mailing list or on IRC channel?\n What were it? What could be improved?\n\nwas the place to put complaints about git mailing list. I didn't want\nto add separate question because this survey has too many questions\n(is too long) already.\n\n-- \nJakub Narebski\n"},{"id":"55781","messageId":"Pine.LNX.4.64.0710142303170.25221@racer.site","threadId":"10194","inReplyTo":"8fe92b430710141449r3f1b1a85oae2a5fb5b30c8b47@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T22:08:22Z","receivedAt":"2007-10-14T22:08:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n> > I find it a pity that my suggestion to ask about how comfortable\n> > people are with the tone on the list did not make it into the survey.\n\nWell, everybody knows who wanted to have that question in the survey, and \neverybody knows why.\n\n> > Enough core developers make the tone sufficiently unconstructive to \n> > make it quite understandable that people are unwilling to ask \n> > questions here, in order to avoid getting their heads banged against a \n> > wall, virtual or not.\n\nMy experience is that people come here, ask questions, and get served. \nOften to stay. So it cannot be that bad.\n\nOn Sun, 14 Oct 2007, Jakub Narebski wrote:\n\n> I think next to last question in the survey\n> \n> 61. Did you have problems getting GIT help on mailing list or on IRC channel?\n> What were it? What could be improved?\n> \n> was the place to put complaints about git mailing list. I didn't want to \n> add separate question because this survey has too many questions (is too \n> long) already.\n\nThat is the problem of most surveys. Usually you can see that after \n50-75% of the questions, people are too bored, and just stop the survey \nright then and there. Or, if forced, give stupid answers because they are \nannoyed with them.\n\nGiven that only one answer hinted at that AFAIR (it was something along \nthe lines \"I already wasted too much time on this survey, so I cannot work \non git\" or some such), I think you did a good job, though.\n\nAgain, thanks for all the work that you did/will do. I know how tedious \nit is to evaluate such surveys, especially the free form answers. Must \nhave taken you days of real effort.\n\nCiao,\nDscho\n"},{"id":"55783","messageId":"85k5ppjqfu.fsf@lola.goethe.zz","threadId":"10194","inReplyTo":"8fe92b430710141449r3f1b1a85oae2a5fb5b30c8b47@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-14T22:12:53Z","receivedAt":"2007-10-14T22:12:53Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Jakub Narebski\" writes:\n\n> On 10/13/07, David Kastrup wrote:\n>\n>> I find it a pity that my suggestion to ask about how comfortable\n>> people are with the tone on the list did not make it into the survey.\n>> Enough core developers make the tone sufficiently unconstructive to\n>> make it quite understandable that people are unwilling to ask\n>> questions here, in order to avoid getting their heads banged against a\n>> wall, virtual or not.\n>\n> I think next to last question in the survey\n>\n> 61. Did you have problems getting GIT help on mailing list or on\n> IRC channel? What were it? What could be improved?\n>\n> was the place to put complaints about git mailing list.\n\nWhat if there are no problems getting help once you submit to letting\nyour head get bashed in?\n\nThe problem is not with getting help on the list: the list is\nbristling with competent people. The problem is the price to pay in\nself-esteem and comfort.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55786","messageId":"8fe92b430710141515g1c33481al97d9bacf92b6be5b@mail.gmail.com","threadId":"10194","inReplyTo":"85k5ppjqfu.fsf@lola.goethe.zz","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-14T22:15:36Z","receivedAt":"2007-10-14T22:15:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/15/07, David Kastrup wrote:\n> \"Jakub Narebski\" writes:\n>\n> > On 10/13/07, David Kastrup wrote:\n> >\n> >> I find it a pity that my suggestion to ask about how comfortable\n> >> people are with the tone on the list did not make it into the survey.\n> >> Enough core developers make the tone sufficiently unconstructive to\n> >> make it quite understandable that people are unwilling to ask\n> >> questions here, in order to avoid getting their heads banged against a\n> >> wall, virtual or not.\n> >\n> > I think next to last question in the survey\n> >\n> > 61. Did you have problems getting GIT help on mailing list or on\n> > IRC channel? What were it? What could be improved?\n> >\n> > was the place to put complaints about git mailing list.\n>\n> What if there are no problems getting help once you submit to letting\n> your head get bashed in?\n>\n> The problem is not with getting help on the list: the list is\n> bristling with competent people. The problem is the price to pay in\n> self-esteem and comfort.\n\n\"What could be improved?\"\n\n-- \nJakub Narebski\n"},{"id":"55787","messageId":"85fy0djq7s.fsf@lola.goethe.zz","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710142303170.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-14T22:17:43Z","receivedAt":"2007-10-14T22:17:43Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n>> > I find it a pity that my suggestion to ask about how comfortable\n>> > people are with the tone on the list did not make it into the\n>> > survey.\n>\n> Well, everybody knows who wanted to have that question in the\n> survey, and everybody knows why.\n\nAnd would it not be good to corroborate that \"who\" is alone with his\nopinion? The purpose of a survey is to get, not to push opinions. So\nwhy fear the question?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55788","messageId":"3a5d78af0710141523u4330a0fcnbc76a6b18354181e@mail.gmail.com","threadId":"10194","inReplyTo":"85k5ppjqfu.fsf@lola.goethe.zz","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Matthew Andrews","fromEmail":"matthew.andrews@gmail.com","sentAt":"2007-10-14T22:23:52Z","receivedAt":"2007-10-14T22:23:52Z","isPatch":false,"sender":{"key":"matthew.andrews@gmail.com","avatar":null},"body":"I'm trying to see this negative tone that apparently exists on the\nlist. As a long-time lurker, I only see a fairly standard open-source\nexpectation of basic knowledge and strong opinion. The list is fairly\ngood about point people to existing documentation. If you do something\nthat somebody thinks is stupid, they'll tell you so. They don't coddle\nyou here, but they are more than willing to help.\n\nOn 10/14/07, David Kastrup wrote:\n> \"Jakub Narebski\" writes:\n>\n> > On 10/13/07, David Kastrup wrote:\n> >\n> >> I find it a pity that my suggestion to ask about how comfortable\n> >> people are with the tone on the list did not make it into the survey.\n> >> Enough core developers make the tone sufficiently unconstructive to\n> >> make it quite understandable that people are unwilling to ask\n> >> questions here, in order to avoid getting their heads banged against a\n> >> wall, virtual or not.\n> >\n> > I think next to last question in the survey\n> >\n> > 61. Did you have problems getting GIT help on mailing list or on\n> > IRC channel? What were it? What could be improved?\n> >\n> > was the place to put complaints about git mailing list.\n>\n> What if there are no problems getting help once you submit to letting\n> your head get bashed in?\n>\n> The problem is not with getting help on the list: the list is\n> bristling with competent people. The problem is the price to pay in\n> self-esteem and comfort.\n>\n> --\n> David Kastrup, Kriemhildstr. 15, 44793 Bochum\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"55789","messageId":"853awdjpmu.fsf@lola.goethe.zz","threadId":"10194","inReplyTo":"3a5d78af0710141523u4330a0fcnbc76a6b18354181e@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-14T22:30:17Z","receivedAt":"2007-10-14T22:30:17Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Matthew Andrews\" writes:\n\n> I'm trying to see this negative tone that apparently exists on the\n> list. As a long-time lurker, I only see a fairly standard\n> open-source expectation of basic knowledge and strong opinion. The\n> list is fairly good about point people to existing documentation. If\n> you do something that somebody thinks is stupid, they'll tell you\n> so. They don't coddle you here, but they are more than willing to\n> help.\n\nI never said that this list was not competent or helpful.\n\nAnyway: if everybody had the same impression, we would not need a\nsurvey, right?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55921","messageId":"20071015232017.GS27899@spearce.org","threadId":"10194","inReplyTo":"alpine.LFD.0.9999.0710141542020.19446@xanadu.home","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-15T23:20:17Z","receivedAt":"2007-10-15T23:20:17Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> BTW I have patches here reworking the progress code for a more compact \n> display which should mitigate this issue quite a bit.\n\ngit-gui is scraping the output of the current progress meter using\na regex and then building a graphical progress bar from that output.\n\nAny change in how git produces the progress bar should still keep\nit in a form that git-gui can regex match and scrape, preferably\nwithout needing to know what version of git it is pulling that\noutput from. For example just teach git-gui to try two different\nregexps, new format and if that doesn't match then try the old\n(aka current) format.\n\n-- \nShawn.\n"},{"id":"55934","messageId":"alpine.LFD.0.9999.0710152245530.19446@xanadu.home","threadId":"10194","inReplyTo":"20071015232017.GS27899@spearce.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-16T02:48:54Z","receivedAt":"2007-10-16T02:48:54Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 15 Oct 2007, Shawn O. Pearce wrote:\n\n> Nicolas Pitre wrote:\n> > BTW I have patches here reworking the progress code for a more compact \n> > display which should mitigate this issue quite a bit.\n> \n> git-gui is scraping the output of the current progress meter using\n> a regex and then building a graphical progress bar from that output.\n\nErk!\n\n> Any change in how git produces the progress bar should still keep\n> it in a form that git-gui can regex match and scrape, preferably\n> without needing to know what version of git it is pulling that\n> output from. For example just teach git-gui to try two different\n> regexps, new format and if that doesn't match then try the old\n> (aka current) format.\n\nI think my new format might be easier for you as the \"title\" and the \nactual percentage and count is now on the same line.\n\n\nNicolas\n"},{"id":"56012","messageId":"Pine.LNX.4.64.0710161151030.25221@racer.site","threadId":"10194","inReplyTo":"alpine.LFD.0.9999.0710152245530.19446@xanadu.home","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T10:51:53Z","receivedAt":"2007-10-16T10:51:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Nicolas Pitre wrote:\n\n> On Mon, 15 Oct 2007, Shawn O. Pearce wrote:\n> \n> > Nicolas Pitre wrote:\n> > > BTW I have patches here reworking the progress code for a more compact \n> > > display which should mitigate this issue quite a bit.\n> > \n> > git-gui is scraping the output of the current progress meter using\n> > a regex and then building a graphical progress bar from that output.\n> \n> Erk!\n> \n> > Any change in how git produces the progress bar should still keep\n> > it in a form that git-gui can regex match and scrape, preferably\n> > without needing to know what version of git it is pulling that\n> > output from. For example just teach git-gui to try two different\n> > regexps, new format and if that doesn't match then try the old\n> > (aka current) format.\n> \n> I think my new format might be easier for you as the \"title\" and the \n> actual percentage and count is now on the same line.\n\nThat might have been an advantage if Shawn did not do the code already. \nAs it is, he'll have to maintain two different regexes, _and_ detect when \nto use which.\n\nCiao,\nDscho\n"},{"id":"56632","messageId":"1192827476.4522.93.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710130130380.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-19T20:57:56Z","receivedAt":"2007-10-19T20:57:56Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Sat, 2007-10-13 at 01:46 +0100, Johannes Schindelin wrote:\n\n> Jakub, thank you very much for doing this. It is a very tedious work, and \n> I deem it invaluable.\n\nSeconded! This survey is very valuable, Jakub!\n\n> > Figure out why people find git hard to learn and eliminate those\n> > barriers to entry. Make git more task-oriented rather than\n> > data-model-oriented the way it is now.\n> \n> Frankly, expectations like these make me want to bang somebody's head on \n> the wall. Why do people expect others to work for them for free? Hard?\n\nThe \"barriers to entry\" / \"data model\" comment came from me :)\n\n\"Find out why people find git hard to learn and eliminate those barriers\nto entry\" is what we do with usability tests e.g. in GNOME. You ask\npeople to use your software to accomplish well-defined tasks (\"send a\nmail to foo@bar.com\", \"using the word processor, copy this fancy printed\nlayout\"). Then, you see how they *expect* your software to work, you\nsee in which places it doesn't behave like that, and you fix it. This\nproduces very good results. For Git in particular this could be things\nlike, \"Import this project from SVN, fix a bug, commit the patch\", or\n\"You are a maintainer, merge in these two branches from two\ncontributors\".\n\n\"Make git more task-oriented rather than data-model-oriented\" is about\nmaking the tool adapt to what you usually want to do, instead of making\n*you* adapt to the way the tool wants to work. Many commands in Git\nhave documentation like\n\n \"option --foo updates the refs without modifying the index. Requires\n a clean working tree\"\n\nThis is gibberish for people who are not very familiar with Git's\ninternals. \"Git for computer scientists\" provides a *very nice*\nexplanation of the DAG and refs and tags, but unfortunately it doesn't\nexplain the index, why you would want to know about it, etc.\n\nGit introduces a lot of terminlogy: refs, index, working tree, remotes,\norigin, HEAD (which is not the same as CVS HEAD!), detached head,\nrebasing, porcelains, etc. Even the basic documentation is hard to read\nwhen you don't know all the terms yet.\n\nIt's nice that Git lets you manipulate the repository in all kinds of\nways, but presenting porcelains at the same level as plumbing makes\nthings hard for users to learn. I was just in our Beijing office,\nteaching people about development tools and Git in particular.\n\n Federico: \"get Git from this location\"\n\n Beijing hacker: tap tap tap, \"okay, it's installed now\"\n\n Federico \"Git commands all start with 'git'\"\n\n Beijing hacker: git\n \n Bash: Display all 150 possibilities?\n\n Beijing hacker: \"oh, shit...\"\n\nIt's hard to know where to begin :) Do I need \"git-cherry-pick\" or\n\"git-cherry\"? Why is the \"apply a patch\" command called \"git-am\"? Why\nis it different from \"git-apply\"? From \"git-applypatch\"? Etc.\n\n Federico\n"},{"id":"56643","messageId":"8fe92b430710191627k570d9acfh22255a3971f172ed@mail.gmail.com","threadId":"10194","inReplyTo":"1192827476.4522.93.camel@cacharro.xalalinux.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-19T23:27:54Z","receivedAt":"2007-10-19T23:27:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/19/07, Federico Mena Quintero wrote:\n\n> \"Make git more task-oriented rather than data-model-oriented\" is about\n> making the tool adapt to what you usually want to do, instead of making\n> *you* adapt to the way the tool wants to work. Many commands in Git\n> have documentation like\n>\n> \"option --foo updates the refs without modifying the index. Requires\n> a clean working tree\"\n>\n> This is gibberish for people who are not very familiar with Git's\n> internals. \"Git for computer scientists\" provides a *very nice*\n> explanation of the DAG and refs and tags, but unfortunately it doesn't\n> explain the index, why you would want to know about it, etc.\n\nThat is what \"Git User's Manual\" (and tutorials) is for. And there is\nglossary in documentation.\n\n[...]\n> It's nice that Git lets you manipulate the repository in all kinds of\n> ways, but presenting porcelains at the same level as plumbing makes\n> things hard for users to learn. I was just in our Beijing office,\n> teaching people about development tools and Git in particular.\n>\n> Federico: \"get Git from this location\"\n>\n> Beijing hacker: tap tap tap, \"okay, it's installed now\"\n>\n> Federico \"Git commands all start with 'git'\"\n>\n> Beijing hacker: git\n>\n> Bash: Display all 150 possibilities?\n>\n> Beijing hacker: \"oh, shit...\"\n\nIt is better to use bash (or zsh) completion, than rely on completion\nof commands names.\n\nBeijing hacker: git \n\n(that is, space after 'git') shows around 62 commands.\n\n> It's hard to know where to begin :) Do I need \"git-cherry-pick\" or\n> \"git-cherry\"? Why is the \"apply a patch\" command called \"git-am\"? Why\n> is it different from \"git-apply\"? From \"git-applypatch\"? Etc.\n\nI think git-cherry will soon be obsoleted and removed, such like\ngit-applymbox and it companion git-applypatch are being obsoleted by\ngit-am.\n\ngit-am applies series of patches _with description_ from messagebox,\ncreating commits if patch applies without conflicts. It requires git\nextended patch for sensible operation; it is best when patch is result\nof git-format-patch. git-apply is to apply GNU patch (optionally git\npatch) to working area, or working area and index, but do not create a\ncommit. It is improved version of GNU patch utility (it understands\ngit extended diff syntax), but it is not meant (alone) to work with\ncommits send by email.\n\n-- \nJakub Narebski\n"},{"id":"56644","messageId":"Pine.LNX.4.64.0710200035020.25221@racer.site","threadId":"10194","inReplyTo":"1192827476.4522.93.camel@cacharro.xalalinux.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-19T23:37:05Z","receivedAt":"2007-10-19T23:37:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Oct 2007, Federico Mena Quintero wrote:\n\n> Bash: Display all 150 possibilities?\n> \n> Beijing hacker: \"oh, shit...\"\n> \n> It's hard to know where to begin :) Do I need \"git-cherry-pick\" or \n> \"git-cherry\"? Why is the \"apply a patch\" command called \"git-am\"? Why \n> is it different from \"git-apply\"? From \"git-applypatch\"? Etc.\n\nYeah, I was arguing a bit about obsoleting the \"git-*\" programs. But it \nseems that we are not getting it anytime soon.\n\nFWIW try this:\n\n\tgit\n\nor even better:\n\n\tgit\n\nCiao,\nDscho\n"},{"id":"56678","messageId":"4719B655.90204@op5.se","threadId":"10194","inReplyTo":"1192827476.4522.93.camel@cacharro.xalalinux.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-20T08:03:33Z","receivedAt":"2007-10-20T08:03:33Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Federico Mena Quintero wrote:\n> \n> \"Find out why people find git hard to learn and eliminate those barriers\n> to entry\" is what we do with usability tests e.g. in GNOME.\n\nAnd what every major corporation who's serious about UI's do. Windows\nworks the way it does because that's how idiots expect it to work. Sad but\ntrue. If our aim is world domination, we need not cater to the morons, but\nwe must make it easier for them to start learning on their own.\n\n> You ask\n> people to use your software to accomplish well-defined tasks (\"send a\n> mail to foo@bar.com\", \"using the word processor, copy this fancy printed\n> layout\"). Then, you see how they *expect* your software to work, you\n> see in which places it doesn't behave like that, and you fix it. This\n> produces very good results. For Git in particular this could be things\n> like, \"Import this project from SVN, fix a bug, commit the patch\", or\n> \"You are a maintainer, merge in these two branches from two\n> contributors\".\n> \n\nI like it. So much so that I'll see if I can get a non-programmer at work\nto do these tasks. Now... to assemble that task-list. Suggestions welcome.\n\n> \n> It's hard to know where to begin :) Do I need \"git-cherry-pick\" or\n> \"git-cherry\"? Why is the \"apply a patch\" command called \"git-am\"? Why\n> is it different from \"git-apply\"? From \"git-applypatch\"? Etc.\n> \n\nI agree completely. It wouldn't be hard to make git-apply figure out if\nit's being fed something that 'am' would normally want, and if it's being\nfed it inside a git repo. If so, make it work just like 'am'.\ngit-applypatch was deprecated a long time ago and has already been removed.\n\nPersonally, I can't help but think that the numerous times I've heard \"oh\ngods, that's a lot of commands\" should finally mean something. I've started\ntaking a look at which of them one can bundle together. If we can drop the\nporcelainish commands down to ~30 or so, and hide the plumbing from git-\nlistings, the initial hurdle people have to jump would be significantly lower.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56684","messageId":"DE4FB702-24E8-421F-8447-04A5C7F7B5D2@zib.de","threadId":"10194","inReplyTo":"4719B655.90204@op5.se","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-20T10:19:45Z","receivedAt":"2007-10-20T10:19:45Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 20, 2007, at 10:03 AM, Andreas Ericsson wrote:\n\n>\n> Personally, I can't help but think that the numerous times I've \n> heard \"oh\n> gods, that's a lot of commands\" should finally mean something. I've \n> started\n> taking a look at which of them one can bundle together. If we can \n> drop the\n> porcelainish commands down to ~30 or so, and hide the plumbing from \n> git-\n> listings, the initial hurdle people have to jump would be \n> significantly lower.\n\nMaybe we could group commands into more categories?\n\nplumbing: should be hidden from the 'normal' user. Porcelain\n should be sufficient for every standard task.\n\ncore porcelain: this is what everyone needs who works in a\n pure git based workflow based on push/pull. You can't use\n git without these commands. But these commands are already\n sufficient to solve most of your tasks.\n\nmail porcelain: the list will probably hate me for this, but\n I think all commands needed to create and send patches per\n mail are not essential. I suspect that I'll _never_ ask\n my colleagues at work to send me a patch by mail. They'll\n always push it to a shared repo.\n\nimport/export: Many commands are only used for importing\n from or exporting to other version control systems. Examples\n are git-cvs*, git-svn*. They are not needed once you switched\n to git.\n\nadmin: Some commands are not used in a typical workflow. For\n example git-filter-branch or git-fsck have a more admin\n flavor.\n\nThere might be more categories. I am not sure because there\na quite a few commands that I _never_ used and have no clear\nidea about what they do.\n\n\nSo here are a few questions:\n\nCould we find a small set of core porcelain commands that\ncompletely cover a typical workflow? The core section of the\nmanual should only refer to those commands. Absolutely no\nplumbing should be needed to tweak things. In principle, a\ntypical user should be able to work if _all other_ commands\nexcept for core porcelain are hidden from his PATH.\n\nAnother section in the manual should describe a workflow based\non sending patches around. Obviously the mail porcelain is\nneeded for this.\n\n... and so forth.\n\nI don't know if we really want to hide the commands from PATH.\nBut maybe we should consider grouping them into subdirectories,\nor provide another way to for the user to focus on the core\nporcelain.\n\n\tSteffen\n"},{"id":"56691","messageId":"4719E69B.3020906@op5.se","threadId":"10194","inReplyTo":"DE4FB702-24E8-421F-8447-04A5C7F7B5D2@zib.de","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-20T11:29:31Z","receivedAt":"2007-10-20T11:29:31Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Steffen Prohaska wrote:\n> \n> On Oct 20, 2007, at 10:03 AM, Andreas Ericsson wrote:\n> \n>>\n>> Personally, I can't help but think that the numerous times I've heard \"oh\n>> gods, that's a lot of commands\" should finally mean something. I've \n>> started\n>> taking a look at which of them one can bundle together. If we can drop \n>> the\n>> porcelainish commands down to ~30 or so, and hide the plumbing from \n>> git-\n>> listings, the initial hurdle people have to jump would be \n>> significantly lower.\n> \n> Maybe we could group commands into more categories?\n> \n> plumbing: should be hidden from the 'normal' user. Porcelain\n> should be sufficient for every standard task.\n> \n\nAgreed. /usr/libexec/git/ seems to me to be the ideal spot for\nit.\n\n> core porcelain: this is what everyone needs who works in a\n> pure git based workflow based on push/pull. You can't use\n> git without these commands. But these commands are already\n> sufficient to solve most of your tasks.\n> \n\nAgreed.\n\n> mail porcelain: the list will probably hate me for this, but\n> I think all commands needed to create and send patches per\n> mail are not essential. I suspect that I'll _never_ ask\n> my colleagues at work to send me a patch by mail. They'll\n> always push it to a shared repo.\n> \n\nDisagreed, for obvious reasons. Many OSS projects are patch-centric\nand developed much like git. OTOH, having to run \"git format-patch\"\nrather than \"git-format-patch\" probably isn't so hampering that we\ncan't live with it.\n\n> import/export: Many commands are only used for importing\n> from or exporting to other version control systems. Examples\n> are git-cvs*, git-svn*. They are not needed once you switched\n> to git.\n> \n\nBut very nifty for incremental imports. I track several CVS repos\nthat I continuously import. They're also self-explanatory, so\nthey don't add much to the clutter. Same reasons as above though;\nthere's no real reason not to invoke them as \"git cvsimport\" rather\nthan \"git-cvsimport\".\n\n> admin: Some commands are not used in a typical workflow. For\n> example git-filter-branch or git-fsck have a more admin\n> flavor.\n> \n\ngit-filter-branch could definitely live its life hidden somewhere.\ngit-fsck probably should stay with the plumbing, as it's used by\nother porcelainish programs more often than run directly by the\nuser.\n\n> There might be more categories. I am not sure because there\n> a quite a few commands that I _never_ used and have no clear\n> idea about what they do.\n> \n> \n> So here are a few questions:\n> \n> Could we find a small set of core porcelain commands that\n> completely cover a typical workflow? The core section of the\n> manual should only refer to those commands. Absolutely no\n> plumbing should be needed to tweak things. In principle, a\n> typical user should be able to work if _all other_ commands\n> except for core porcelain are hidden from his PATH.\n> \n\nNote that this is already possible, using a libexec-dir and\npassing --exec-dir to the git wrapper. The only thing that isn't\ndone is deciding what's *definitely* plumbing. Once that's defined,\nthe makefile can install plumbing to a separate directory and\nthe /usr/bin/git- should shrink by roughly half.\n\n> Another section in the manual should describe a workflow based\n> on sending patches around. Obviously the mail porcelain is\n> needed for this.\n> \n> ... and so forth.\n> \n> I don't know if we really want to hide the commands from PATH.\n> But maybe we should consider grouping them into subdirectories,\n> or provide another way to for the user to focus on the core\n> porcelain.\n> \n\nHiding the really core plumbing and getting rid of redundant\nprograms (git-am, git-apply, git-applypatch, ...) would do wonders,\nmethinks.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56733","messageId":"8fe92b430710201606i47e85b24k17abd819bf0d353b@mail.gmail.com","threadId":"10194","inReplyTo":"DE4FB702-24E8-421F-8447-04A5C7F7B5D2@zib.de","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-20T23:06:17Z","receivedAt":"2007-10-20T23:06:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/20/07, Steffen Prohaska wrote:\n\n> Maybe we could group commands into more categories?\n>\n> plumbing: should be hidden from the 'normal' user. Porcelain\n> should be sufficient for every standard task.\n\nThe problem is division between what is porcelain and what is plumbing.\nSome commands are right on border (git-fsck, git-update-index, git-rev-parse\ncomes to mind).\n\nBut it should be fairly easy to:\n 1. put only porcelain in bash / zsh completion ('git ' shows\nonly porcelain\n 2. move plumbing out of PATH, but use exec-dir instead.\n\n[...]\n> mail porcelain: the list will probably hate me for this, but\n> I think all commands needed to create and send patches per\n> mail are not essential. I suspect that I'll _never_ ask\n> my colleagues at work to send me a patch by mail. They'll\n> always push it to a shared repo.\n\nUsually mail porcelain is in separate binary package, git-mail for\nRPMS packages for example. But iMVHO git-format-patch is as often used\nas other commands, and is certainly porcelain.\n\n> import/export: Many commands are only used for importing\n> from or exporting to other version control systems. Examples\n> are git-cvs*, git-svn*. They are not needed once you switched\n> to git.\n\nThose are also in separate packages.\n\n> admin: Some commands are not used in a typical workflow. For\n> example git-filter-branch or git-fsck have a more admin\n> flavor.\n\nThese are a few commands only. I'm not sure about how to separate\nthose from ordinary commands.\n\n[...]\n> So here are a few questions:\n>\n> Could we find a small set of core porcelain commands that\n> completely cover a typical workflow? The core section of the\n> manual should only refer to those commands. Absolutely no\n> plumbing should be needed to tweak things. In principle, a\n> typical user should be able to work if _all other_ commands\n> except for core porcelain are hidden from his PATH.\n\nThe problem here I suppose might lie with the same reason why\n(almost?) all Office Lite systems failed: because even if 80% of people\nuse only 20% of functaionality, it is not the _same_ 20%.\n\n-- \nJakub Narebski\n"},{"id":"56734","messageId":"Pine.LNX.4.64.0710210031130.25221@racer.site","threadId":"10194","inReplyTo":"8fe92b430710201606i47e85b24k17abd819bf0d353b@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-20T23:33:13Z","receivedAt":"2007-10-20T23:33:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Oct 2007, Jakub Narebski wrote:\n\n> On 10/20/07, Steffen Prohaska wrote:\n> \n> > Maybe we could group commands into more categories?\n> >\n> > plumbing: should be hidden from the 'normal' user. Porcelain\n> > should be sufficient for every standard task.\n> \n> The problem is division between what is porcelain and what is plumbing. \n> Some commands are right on border (git-fsck, git-update-index, \n> git-rev-parse comes to mind).\n\nSorry, but my impression from the latest mails was that the commands are \nfine. What is lacking is a nice, _small_ collection of recommended \nworkflows. And when we have agreed on such a set of workflows, we \noptimize the hell out of them. Only this time it is not performance, but \nuser-friendliness.\n\nHmm?\n\nCiao,\nDscho\n"},{"id":"56750","messageId":"20071021060813.GK20588@dpotapov.dyndns.org","threadId":"10194","inReplyTo":"4719E69B.3020906@op5.se","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2007-10-21T06:08:13Z","receivedAt":"2007-10-21T06:08:13Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, Oct 20, 2007 at 01:29:31PM +0200, Andreas Ericsson wrote:\n> Steffen Prohaska wrote:\n> >\n> >plumbing: should be hidden from the 'normal' user. Porcelain\n> > should be sufficient for every standard task.\n> >\n> \n> Agreed. /usr/libexec/git/ seems to me to be the ideal spot for\n> it.\n\n/usr/libexec is against the Filesystem Hierarchy Standard (FHS).\nIt is better to use /usr/lib/git/ for that.\n\nDmitry\n"},{"id":"56756","messageId":"471AFD07.4040606@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710210031130.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-21T07:17:27Z","receivedAt":"2007-10-21T07:17:27Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 21 Oct 2007, Jakub Narebski wrote:\n> \n>> On 10/20/07, Steffen Prohaska wrote:\n>>\n>>> Maybe we could group commands into more categories?\n>>>\n>>> plumbing: should be hidden from the 'normal' user. Porcelain\n>>> should be sufficient for every standard task.\n>> The problem is division between what is porcelain and what is plumbing. \n>> Some commands are right on border (git-fsck, git-update-index, \n>> git-rev-parse comes to mind).\n> \n> Sorry, but my impression from the latest mails was that the commands are \n> fine. What is lacking is a nice, _small_ collection of recommended \n> workflows. And when we have agreed on such a set of workflows, we \n> optimize the hell out of them. Only this time it is not performance, but \n> user-friendliness.\n> \n\nhttp://www.kernel.org/pub/software/scm/git/docs/everyday.html would be a\ngood starting point, I think.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56785","messageId":"20071021221255.GA18850@fieldses.org","threadId":"10194","inReplyTo":"DE4FB702-24E8-421F-8447-04A5C7F7B5D2@zib.de","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-21T22:12:55Z","receivedAt":"2007-10-21T22:12:55Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sat, Oct 20, 2007 at 12:19:45PM +0200, Steffen Prohaska wrote:\n> mail porcelain: the list will probably hate me for this, but\n> I think all commands needed to create and send patches per\n> mail are not essential. I suspect that I'll _never_ ask\n> my colleagues at work to send me a patch by mail. They'll\n> always push it to a shared repo.\n\nThat's not going to fly. There are too many projects for which email is\nthe preferred way to submit patches (especially for new or occasional\ndevelopers).\n\n--b.\n"},{"id":"56786","messageId":"Pine.LNX.4.64.0710212308540.25221@racer.site","threadId":"10194","inReplyTo":"471AFD07.4040606@op5.se","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-21T22:15:07Z","receivedAt":"2007-10-21T22:15:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Oct 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Sun, 21 Oct 2007, Jakub Narebski wrote:\n> > \n> > > On 10/20/07, Steffen Prohaska wrote:\n> > > \n> > > > Maybe we could group commands into more categories?\n> > > > \n> > > > plumbing: should be hidden from the 'normal' user. Porcelain\n> > > > should be sufficient for every standard task.\n> > >\n> > > The problem is division between what is porcelain and what is \n> > > plumbing. Some commands are right on border (git-fsck, \n> > > git-update-index, git-rev-parse comes to mind).\n> > \n> > Sorry, but my impression from the latest mails was that the commands \n> > are fine. What is lacking is a nice, _small_ collection of \n> > recommended workflows. And when we have agreed on such a set of \n> > workflows, we optimize the hell out of them. Only this time it is not \n> > performance, but user-friendliness.\n> \n> http://www.kernel.org/pub/software/scm/git/docs/everyday.html would be a \n> good starting point, I think.\n\nI don't think so. Way too few authors were involved in writing this \ndocument, so it is not \"typical\" in and of itself.\n\nI'd really like people to respond not so much with broad and general \nstatements to my mail (those statements tend to be rather useless to find \nhow to make git more suitable to newbies), but rather with concrete top \nten lists of what they do daily.\n\nMy top ten list:\n\n- git diff\n- git commit\n- git status\n- git fetch\n- git rebase\n- git pull\n- git cherry-pick\n- git bisect\n- git push\n- git add\n\nOf course, my list is somewhat skewed (because I am quite comfortable with \nthe commands git provided; otherwise I would have provided -- unlike \nothers, probably -- patches, and would have fought -- also unlike others \n-- to get them in, such as --color-words).\n\nSo again, I'd like people who did _not_ tweak git to their likings to tell \nthe most common steps they do. My hope is that we see things that are \ngood practices, but could use an easier user interface.\n\nCiao,\nDscho\n"},{"id":"56838","messageId":"471C586A.9030900@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710212308540.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-22T07:59:38Z","receivedAt":"2007-10-22T07:59:38Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 21 Oct 2007, Andreas Ericsson wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> On Sun, 21 Oct 2007, Jakub Narebski wrote:\n>>>\n>>>> On 10/20/07, Steffen Prohaska wrote:\n>>>>\n>>>>> Maybe we could group commands into more categories?\n>>>>>\n>>>>> plumbing: should be hidden from the 'normal' user. Porcelain\n>>>>> should be sufficient for every standard task.\n>>>> The problem is division between what is porcelain and what is \n>>>> plumbing. Some commands are right on border (git-fsck, \n>>>> git-update-index, git-rev-parse comes to mind).\n>>> Sorry, but my impression from the latest mails was that the commands \n>>> are fine. What is lacking is a nice, _small_ collection of \n>>> recommended workflows. And when we have agreed on such a set of \n>>> workflows, we optimize the hell out of them. Only this time it is not \n>>> performance, but user-friendliness.\n>> http://www.kernel.org/pub/software/scm/git/docs/everyday.html would be a \n>> good starting point, I think.\n> \n> I don't think so. Way too few authors were involved in writing this \n> document, so it is not \"typical\" in and of itself.\n> \n> I'd really like people to respond not so much with broad and general \n> statements to my mail (those statements tend to be rather useless to find \n> how to make git more suitable to newbies), but rather with concrete top \n> ten lists of what they do daily.\n> \n> My top ten list:\n> \n> - git diff\n> - git commit\n> - git status\n> - git fetch\n> - git rebase\n> - git pull\n> - git cherry-pick\n> - git bisect\n> - git push\n> - git add\n> \n> So again, I'd like people who did _not_ tweak git to their likings to tell \n> the most common steps they do. My hope is that we see things that are \n> good practices, but could use an easier user interface.\n> \n\nI'm not so sure we'd want to hide commands that git-gurus simply do not \nuse, such as git-blame. In my opinion, we should just locate the highest \nlevel available of UI tool that implements a particular feature and have \nthat listed in the git[- ] view.\n\nI doubt many people on this list regularly use git-blame but it's a \ncommand that's definitely non-trivial to script out using only the \n\"proper\" commands, and CVS/SVN users expect it to be there, so it's \nprobably worth listing anyhow.\n\nSimilarly, it might be helpful to have help topics the gdb way, like \n\"git help patches\". It's one of those things that people have come to \nexpect from a software tool, so perhaps we should humor them? Given gits \n\"every help topic is a man-page\" idiom, this shouldn't require any real \ntechnical effort.\n\nSuch topics should probably include\nmerge/merges/merging - overview of various ways of putting two lines of \ndevelopment back together\npatch/patches - how to create, send and apply\ntags/branches/refs - what they are, why they're good, link to merging\n\nI'm currently swanked with day-job work, but I'll see if I can get some \nprototype docs done later this week and check if it requires any code \nsupport. If anyone's well-versed in asciidoc HTML-indexing and wants to \nprovide pointers to what I should think about for generating those topic \nmenus as html docs, feel free to chuck me an email.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56855","messageId":"Pine.LNX.4.64.0710221156540.25221@racer.site","threadId":"10194","inReplyTo":"471C586A.9030900@op5.se","subject":"best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-22T11:04:31Z","receivedAt":"2007-10-22T11:04:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Oct 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > I'd really like people to respond not so much with broad and general \n> > statements to my mail (those statements tend to be rather useless to \n> > find how to make git more suitable to newbies), but rather with \n> > concrete top ten lists of what they do daily.\n> > \n> > My top ten list:\n> > \n> > - git diff\n> > - git commit\n> > - git status\n> > - git fetch\n> > - git rebase\n> > - git pull\n> > - git cherry-pick\n> > - git bisect\n> > - git push\n> > - git add\n> > \n> > So again, I'd like people who did _not_ tweak git to their likings to \n> > tell the most common steps they do. My hope is that we see things \n> > that are good practices, but could use an easier user interface.\n> \n> I'm not so sure we'd want to hide commands that git-gurus simply do not \n> use, such as git-blame.\n\nI was not talking about commands that git gurus simply do not use. I \nexplicitely avoided asking \"git gurus\" for what they use.\n\n> In my opinion, we should just locate the highest level available of UI \n> tool that implements a particular feature and have that listed in the \n> git[- ] view.\n\n>From the survey it is utterly clear that the available UI tools are still \nnot good enough.\n\nSo once again, what operations involving git do people use regularly?\n\nThere is a good chance that git is not optimised for most \npeople's daily workflows, as project maintainers seemed to be much more \nforthcoming with patches, and therefore maintainers' tasks are much more \noptimised than in other SCMs.\n\nCiao,\nDscho\n\nP.S.: If nobody replies with actual daily workflows to this mail, I'll \njust assume that this complaint in the user survey was just bullocks, and \nno change in git is needed.\n"},{"id":"56866","messageId":"8fe92b430710220526i65ecb862ie1037e9d94d93b83@mail.gmail.com","threadId":"10194","inReplyTo":"471C586A.9030900@op5.se","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-22T12:26:37Z","receivedAt":"2007-10-22T12:26:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/22/07, Andreas Ericsson wrote:\n[...]\n>>>>> On 10/20/07, Steffen Prohaska wrote:\n>>>>>\n>>>>>> Maybe we could group commands into more categories?\n\n> Similarly, it might be helpful to have help topics the gdb way, like\n> \"git help patches\". It's one of those things that people have come to\n> expect from a software tool, so perhaps we should humor them? Given gits\n> \"every help topic is a man-page\" idiom, this shouldn't require any real\n> technical effort.\n>\n> Such topics should probably include\n> merge/merges/merging - overview of various ways of putting two lines of\n> development back together\n> patch/patches - how to create, send and apply\n> tags/branches/refs - what they are, why they're good, link to merging\n\nVery good idea. It is definitely something that can be worked on.\n\nBy the way, what do you think about \"spying\" version of git, specially\nmarked release which gathers statistics of porcelain used, with\nfrequency of its use, and git-sendstats command added in this release?\n\n-- \nJakub Narebski\n"},{"id":"56867","messageId":"471C9B13.9080603@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221156540.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-22T12:44:03Z","receivedAt":"2007-10-22T12:44:03Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> So once again, what operations involving git do people use regularly?\n> \n\ndiff\nqgit\ncommit\nfetch\nrebase\nmerge\nstatus\npush\ncherry-pick\ngrep\nbisect\nadd\nshow-ref\n\nIf I were to suggest any improvements, it'd be to change the semantics \nof git-pull to always update the local branches set up to be merged with \nthe remote tracking branches when they, prior to fetching, pointed to \nthe same commit, such that when\n\n$ git show-ref master\nd4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\nd4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n\nrefs/heads/master gets set to refs/remotes/origin/master post-fetch.\n\nThis would save me from this command sequence, which I currently have to \ndo for git.\n\ngit fetch\ngit checkout next\ngit merge spearce/next\ngit checkout master\ngit merge spearce/master\ngit checkout maint\ngit merge spearce/maint\ngit checkout pu\ngit reset --hard spearce/pu\n\n\n\ngit could definitely help here. I want the local branches to be \nup-to-date with the remote ones, because I frequently run diffs against \nthe various branches to see if anything that I should be aware of has \nchanged, and just as frequently I forget to add that 'origin/' prefix, \nwhich means I *might* be looking at old code.\n\nI usually do that on internal projects, where we have \"master\", \"next\", \n\"testing\", and \"stable\" branches for pretty much every repo. We have 54 \ngit repos. The typing adds up. This is also one of the most frequent \ncauses of confusion for my (even) less git-savvy co-workers. The \nargument usually goes like this:\n\"Umm... Peter, why did you commit your fix on top of 7 weeks old code?\"\n\"Oh? I did git-pull first, just as you said, so it should have been the \nlatest, shouldn't it?\"\n\"Well, what branch were you on when you pulled?\"\n\"Err.. does that matter? I didn't have any local modifications on the \nbranch when I pulled, so it should have just updated it.\"\n\nWhat's happened prior to such an argument is usually this:\nnext or master is inevitably checked out. The user does git-pull to get \nup to date. They then change branch and get down to business with \nrebasing, merging and editing. When it's time to push, git tells them \n\"not a strict subset. use git-pull!\", and they do, and sometimes it \nfails, and I have a hard time explaining why since I really don't see a \nreason for *not* updating all \"to-merge\" branches when they point to the \nsame commit as their tracking-branch before the pull.\n\nPatch to follow (at some point), although it's likely to make git-pull a \nbuilt-in since I have no idea how to maintain coupled lists in shell.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56869","messageId":"ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221156540.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-22T13:17:19Z","receivedAt":"2007-10-22T13:17:19Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 22/10/2007, a las 13:04, Johannes Schindelin escribió:\n\n> So once again, what operations involving git do people use regularly?\n\nHere are my top ten commands, sorted by the number of times they \nappear in my ~/.bash_history:\n\n533 status\n342 diff\n252 commit\n234 add\n123 checkout\n116 log\n106 push\n97 config\n83 show\n83 branch\n\nNot very scientific, but it gives a rough idea of how one Git newbie \n(using it for several months) with a very basic workflow uses Git.\n\nCheers,\nWincent\n"},{"id":"56870","messageId":"ee77f5c20710220633j37673651p5862b82d5a7b82e8@mail.gmail.com","threadId":"10194","inReplyTo":"ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-10-22T13:33:21Z","receivedAt":"2007-10-22T13:33:21Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On 22/10/2007, Wincent Colaiuta wrote:\n> El 22/10/2007, a las 13:04, Johannes Schindelin escribió:\n>\n> > So once again, what operations involving git do people use regularly?\n>\n> Here are my top ten commands, sorted by the number of times they\n> appear in my ~/.bash_history:\n\nSounds like a good idea. Here's mine (my .bash_history is limited to\n500 commands, though):\n\n$ cat ~/.bash_history | grep ^git | cut -c5- | cut -d' ' -f1 | sort |\nuniq -c | sort -nr | head -10\n 64 status\n 37 diff\n 23 push\n 13 checkout\n 12 add\n 9 log\n 9 commit\n 8 rebase\n 8 branch\n 5 count-objects\n\n\nDave.\n"},{"id":"56871","messageId":"fcaeb9bf0710220636k40c14c40mdd8d7d0b77cf48fa@mail.gmail.com","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221156540.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-10-22T13:36:39Z","receivedAt":"2007-10-22T13:36:39Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/22/07, Johannes Schindelin wrote:\n> So once again, what operations involving git do people use regularly?\n\nAll operations in my laptop since May:\n\n 621 git log\n 614 git diff\n 510 git status\n 378 git grep\n 203 git checkout\n 166 git add\n 159 git commit\n 106 git fetch\n 87 git branch\n 61 git help\n 55 git am\n 49 git ls-files\n 48 git format-patch\n 46 git show\n 46 git reset\n 46 git clone\n 44 git cherry-pick\n 42 git merge\n 36 git apply\n 26 git cherry\n 25 git push\n 25 git describe\n 24 git rev-list\n 20 git rebase\n 18 git pull\n 17 gitview\n 16 git shortlog\n 15 git revert\n 15 git cat-file\n 12 git name-rev\n 11 git update-index\n 11 git ls-tree\n 11 git count-objects\n 10 git tag\n 9 git send-email\n 9 git rev-parse\n 7 git svn\n 7 git read-tree\n 6 git repack\n 6 git fsck\n 4 git init\n 4 git clean\n 3 git rm\n 3 git gc\n 2 git submodule\n 2 git prune\n 2 git ls\n 2 gitk\n 2 git gui\n 2 git config\n 1 git mailinfo\n 1 git lost-found\n-- \nDuy\n"},{"id":"56872","messageId":"Pine.LNX.4.64.0710221428390.25221@racer.site","threadId":"10194","inReplyTo":"ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-22T13:38:38Z","receivedAt":"2007-10-22T13:38:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Oct 2007, Wincent Colaiuta wrote:\n\n> El 22/10/2007, a las 13:04, Johannes Schindelin escribi?:\n> \n> > So once again, what operations involving git do people use regularly?\n> \n> Here are my top ten commands, sorted by the number of times they appear \n> in my ~/.bash_history:\n\nThanks. That's a really good idea. I did the same, and it turns out that \nmy list was wrong:\n\n 68 log\n 50 fetch\n 36 show\n 33 diff\n 19 grep\n 19 commit\n 14 ps (my alias which runs -p status)\n 10 config\n 8 rebase\n 8 push\n\nEverybody who wants to find out the same: this is how I did it:\n\ncat .bash_history |\n\ttr \";\" \"\\\\n\" |\n\tsed -n \"s/^ *git[- ]\\([^ ]*\\).*$/\\1/p\" |\n\tsort |\n\tuniq -c |\n\tsort -r -n\n\nOne thing that I realised by looking at my list: It probably makes more \nsense teaching people about \"fetch\" in the beginning, teach other parts \nabout git, and only then \"push\".\n\nWe tend to teach people about \"fetch\" and \"push\" at the same time, but \nthis is not consistent with any workflow.\n\nCiao,\nDscho\n"},{"id":"56874","messageId":"Pine.LNX.4.64.0710221444460.25221@racer.site","threadId":"10194","inReplyTo":"8fe92b430710220526i65ecb862ie1037e9d94d93b83@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-22T13:45:05Z","receivedAt":"2007-10-22T13:45:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Oct 2007, Jakub Narebski wrote:\n\n> On 10/22/07, Andreas Ericsson wrote:\n> [...]\n> >>>>> On 10/20/07, Steffen Prohaska wrote:\n> >>>>>\n> >>>>>> Maybe we could group commands into more categories?\n> \n> > Similarly, it might be helpful to have help topics the gdb way, like\n> > \"git help patches\". It's one of those things that people have come to\n> > expect from a software tool, so perhaps we should humor them? Given gits\n> > \"every help topic is a man-page\" idiom, this shouldn't require any real\n> > technical effort.\n> >\n> > Such topics should probably include\n> > merge/merges/merging - overview of various ways of putting two lines of\n> > development back together\n> > patch/patches - how to create, send and apply\n> > tags/branches/refs - what they are, why they're good, link to merging\n> \n> Very good idea. It is definitely something that can be worked on.\n> \n> By the way, what do you think about \"spying\" version of git, specially\n> marked release which gathers statistics of porcelain used, with\n> frequency of its use, and git-sendstats command added in this release?\n\nI like Wincent's approach, scanning .bash_history.\n\nCiao,\nDscho\n"},{"id":"56876","messageId":"Pine.LNX.4.64.0710221445170.25221@racer.site","threadId":"10194","inReplyTo":"471C9B13.9080603@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-22T13:48:20Z","receivedAt":"2007-10-22T13:48:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Oct 2007, Andreas Ericsson wrote:\n\n> If I were to suggest any improvements, it'd be to change the semantics of\n> git-pull to always update the local branches set up to be merged with the\n> remote tracking branches when they, prior to fetching, pointed to the same\n> commit, such that when\n> \n> $ git show-ref master\n> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n> \n> refs/heads/master gets set to refs/remotes/origin/master post-fetch.\n\nIn general, this should fail. Because you are expected to have local \nchanges in the local branches. What you describe suggests that you should \nnot use the branch name \"master\" at all, but \"origin/master\".\n\nThat said, there is a pretty simple way to achieve what you want (even if \nit does not help the confusion you create between local and remote \nbranches):\n\n\tgit config --add remote.origin.fetch master:master\n\nOf course, when you checkout \"master\" and pull then, you'll get even more \nproblems, _exactly_ because you muddled up the clear distinction between \nlocal and remote branches.\n\nCiao,\nDscho\n"},{"id":"56880","messageId":"1193063339.4522.134.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710200035020.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-22T14:28:59Z","receivedAt":"2007-10-22T14:28:59Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Sat, 2007-10-20 at 00:37 +0100, Johannes Schindelin wrote:\n\n> FWIW try this:\n> \n> \tgit\n> \n> or even better:\n> \n> \tgit\n\nHmm, this didn't work. I'm still using git 1.5.4.2 from the \nstock openSUSE 10.3 packages --- did this get added in a newer version?\n\n Federico\n"},{"id":"56881","messageId":"471CB3AE.7080802@op5.se","threadId":"10194","inReplyTo":"8fe92b430710220526i65ecb862ie1037e9d94d93b83@mail.gmail.com","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-22T14:29:02Z","receivedAt":"2007-10-22T14:29:02Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> On 10/22/07, Andreas Ericsson wrote:\n> [...]\n>>>>>> On 10/20/07, Steffen Prohaska wrote:\n>>>>>>\n>>>>>>> Maybe we could group commands into more categories?\n> \n>> Similarly, it might be helpful to have help topics the gdb way, like\n>> \"git help patches\". It's one of those things that people have come to\n>> expect from a software tool, so perhaps we should humor them? Given gits\n>> \"every help topic is a man-page\" idiom, this shouldn't require any real\n>> technical effort.\n>>\n>> Such topics should probably include\n>> merge/merges/merging - overview of various ways of putting two lines of\n>> development back together\n>> patch/patches - how to create, send and apply\n>> tags/branches/refs - what they are, why they're good, link to merging\n> \n> Very good idea. It is definitely something that can be worked on.\n> \n> By the way, what do you think about \"spying\" version of git, specially\n> marked release which gathers statistics of porcelain used, with\n> frequency of its use, and git-sendstats command added in this release?\n> \n\nI like it and I'd use it. What's more interesting is that I could \nprobably get my co-workers to do the same.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56883","messageId":"471CB443.9070606@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221445170.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-22T14:31:31Z","receivedAt":"2007-10-22T14:31:31Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n> \n>> If I were to suggest any improvements, it'd be to change the semantics of\n>> git-pull to always update the local branches set up to be merged with the\n>> remote tracking branches when they, prior to fetching, pointed to the same\n>> commit, such that when\n>>\n>> $ git show-ref master\n>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n>>\n>> refs/heads/master gets set to refs/remotes/origin/master post-fetch.\n> \n> In general, this should fail. Because you are expected to have local \n> changes in the local branches.\n\n\nBS argument. Git knows when I haven't got any changes on my local \nbranches, and it can be fairly safely assumed that when I feel like \nmaking any, I'd like to make them off as fresh a tip as possible unless \nI explicitly tell git otherwise.\n\nNice hint though. I'm working on a patch for it now but I've only looked \nat it 15 minutes over lunch today, so it'll probably be a few days.\n\n\n> What you describe suggests that you should \n> not use the branch name \"master\" at all, but \"origin/master\".\n> \n\nNo. I want the ability to commit locally without it affecting my \nupstream tracking branches, but I also want to make sure that when I \nwant to work on some branch I don't frequently touch, git will make sure \nit's kept up-to-speed with the branch I explicitly have told it to merge \nwith, without me having to remember if I was on that branch when I last \ndid git-pull (I might not have a network connection), and without having \nto remember what I decided to call my locally-modifiable branch.\n\n\n> That said, there is a pretty simple way to achieve what you want (even if \n> it does not help the confusion you create between local and remote \n> branches):\n> \n> \tgit config --add remote.origin.fetch master:master\n> \n> Of course, when you checkout \"master\" and pull then, you'll get even more \n> problems, _exactly_ because you muddled up the clear distinction between \n> local and remote branches.\n> \n\nThat's not what I want at all. I must have been unclear in my original \npost. I'm talking about git doing automatically what every single user \nI've ever talked to wants it to do, which is to maintain the state of \nsync that the \"local-and-modifiable\" branches had with the \n\"local-non-modifiable-aka-remote-tracking\" branches. Note that the state \nof sync is more important to users than git never ever touching the \nbranches that they *could* have (but don't have) changes on.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56886","messageId":"1193064780.4522.142.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"471C586A.9030900@op5.se","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-22T14:53:00Z","receivedAt":"2007-10-22T14:53:00Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Mon, 2007-10-22 at 09:59 +0200, Andreas Ericsson wrote:\n\n> I doubt many people on this list regularly use git-blame but it's a \n> command that's definitely non-trivial to script out using only the \n> \"proper\" commands, and CVS/SVN users expect it to be there, so it's \n> probably worth listing anyhow.\n\nHmmm, I don't really want to turn the \"summary\" thread into oodles of\nsub-threads, but here goes :)\n\nPersonally I find git-blame *EXTREMELY* useful. The workflow is:\n\n1. Bug #12345 for FooApp gets assigned to you.\n\n2. git-svn clone fooapp's repository\n\n3. git checkout -b my-bugfix-branch-for-12345\n\n4. debug debug debug\n\n5. \"WTF? Who wrote this crappy code?\"\n\n6. git blame culprit-file.c\n\n7. \"Oh, it was $person with $commit_id... what were they thinking at the\ntime?\"\n\n8. git show $commit_id\n\n9. \"Oh, I see their intentions now... what was going on at that time?\"\n\n10. git log \n\n11. etc.\n\nGit-blame is very nice for code archaeology (long explanation at\nhttp://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00238.html).\n\n> Similarly, it might be helpful to have help topics the gdb way, like \n> \"git help patches\".\n\nThis would be simply fantastic. If those help topics suggested\nworkflows, I'd be delighted :) Feel free to poke me if you write up\nsome text; I'd love to help on this.\n\n Federico\n"},{"id":"56887","messageId":"Pine.LNX.4.64.0710221558230.25221@racer.site","threadId":"10194","inReplyTo":"471CB443.9070606@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-22T15:00:34Z","receivedAt":"2007-10-22T15:00:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Oct 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n> > \n> > > If I were to suggest any improvements, it'd be to change the \n> > > semantics of git-pull to always update the local branches set up to \n> > > be merged with the remote tracking branches when they, prior to \n> > > fetching, pointed to the same commit, such that when\n> > > \n> > > $ git show-ref master\n> > > d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n> > > d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n> > > \n> > > refs/heads/master gets set to refs/remotes/origin/master post-fetch.\n> > \n> > In general, this should fail. Because you are expected to have local \n> > changes in the local branches.\n> \n> \n> BS argument.\n\nAha. So you want to make sure that the local branches are no longer \n\"purely\" local. And you want to stop updating them when unpushed changes \nare in the local branches.\n\nSeems I cannot help you.\n\nCiao,\nDscho\n"},{"id":"56888","messageId":"471CBEB1.2030008@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221558230.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-22T15:16:01Z","receivedAt":"2007-10-22T15:16:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n>>>\n>>>> If I were to suggest any improvements, it'd be to change the \n>>>> semantics of git-pull to always update the local branches set up to \n>>>> be merged with the remote tracking branches when they, prior to \n>>>> fetching, pointed to the same commit, such that when\n>>>>\n>>>> $ git show-ref master\n>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n>>>>\n>>>> refs/heads/master gets set to refs/remotes/origin/master post-fetch.\n>>> In general, this should fail. Because you are expected to have local \n>>> changes in the local branches.\n>>\n>> BS argument.\n> \n> Aha. So you want to make sure that the local branches are no longer \n> \"purely\" local. And you want to stop updating them when unpushed changes \n> are in the local branches.\n> \n\nTo me, it's more along the lines of \"let git help me not make the \nmistake of hacking on a six-week old codebase when I've explicitly asked \nit to merge these and those remote tracking branches into these and \nthose local branches\". Not updating those branches when there *are* \nchanges on them is something users can understand and will probably also \nappreciate, but the reason for not allowing even fast-forwards escape me.\n\n> Seems I cannot help you.\n> \n\nWell, I knew that much from the start so I didn't ask you to, and since \nyou seem to fail to grasp what I had in mind, I'm sure you'd botch the \nimplementation anyway. Thanks for not quite offering though ;-)\n\nI'm sure you'll review the patch though, and I'm equally sure I will \nappreciate your technical comments rather a lot more than this current \nbickering about a feature it seems I can't express clearly enough in words.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56890","messageId":"1193066660.4522.166.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221156540.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summarycontinued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-22T15:24:20Z","receivedAt":"2007-10-22T15:24:20Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Mon, 2007-10-22 at 12:04 +0100, Johannes Schindelin wrote:\n\n> There is a good chance that git is not optimised for most \n> people's daily workflows, as project maintainers seemed to be much more \n> forthcoming with patches, and therefore maintainers' tasks are much more \n> optimised than in other SCMs.\n\nThe following are workflows that would be very useful for my cow-orkers\nand project peers.\n\nEnd-user workflows:\n\n* Clone from another SCM (mostly svn). Make a local branch to implement\nsomething in various commits. Rebase to the \"latest upstream sources\"\nwhen you are done, and then do the equivalent to \"svn dcommit\" to upload\nyour final changes to the other SCM. The use case for this is to fix a\ncomplicated bug in GNOME, which uses SVN.\n\n* While you are doing that, produce a patchset that you can send to the\nmaintainers for review. I love \"git-format-patch -n --thread --stdout >\nfoo\", but it's pretty painful to have to 1. look up git-format-patch's\noptions in the man page (if you use --stdout, shouldn't -n and --thread\nbe turned on by default?); 2. import \"foo\" into Evolution to then be\nable to edit the zeroth mail, and then be able to use Evo's SMTP\nconfiguration to send out the mails while preserving the threading.\n\n* Clone a git repository which has several interesting branches. Figure\nout which branch you are interested in. Create a local branch based on\nthat; do your changes there. Keep your code up to date (rebase? when\nto fetch / pull / etc?).\n\n* You have a personal branch with a bunch of commits: a mess of \"real\nwork\", \"remove debugging printf\", \"fix typo\", etc. Reformat / reorder\nthose patches into something suitable for submission. [I just found out\nabout git rebase --interactive and it's *FANTASTIC* for this!]\n\nMaintainer workflows:\n\n* Start a personal project in git and publish it for others to clone.\nAssume several possible setups: dumb web server with no git installed,\ngit installed but no git-daemon, git installed with git-daemon running.\nI've found that publishing is not trivial at all; it's a rather\ncumbersome multi-step process.\n\n* Several of your contributors publish their own git repositories.\nIntegrate changes from them, or review them. This interesting because\nyou'll have to do a lot of navigation in repos with which you aren't\nfamiliar, you'll have to use the merging and conflict resolution tools,\nyou'll have to maintain the signoffs, etc.\n\n* Set up a public repository to which other people can push.\n\n* Publish just some of your branches. Do that often, say, because you\nhave new work to show in each of those branches.\n\n Federico\n"},{"id":"56900","messageId":"87AF88A8-93B2-448C-B100-10B8EFFB6627@zib.de","threadId":"10194","inReplyTo":"471CBEB1.2030008@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-22T15:42:48Z","receivedAt":"2007-10-22T15:42:48Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 22, 2007, at 5:16 PM, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n>> Hi,\n>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n>>> Johannes Schindelin wrote:\n>>>\n>>>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n>>>>\n>>>>> If I were to suggest any improvements, it'd be to change the \n>>>>> semantics of git-pull to always update the local branches set \n>>>>> up to be merged with the remote tracking branches when they, \n>>>>> prior to fetching, pointed to the same commit, such that when\n>>>>>\n>>>>> $ git show-ref master\n>>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n>>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/ \n>>>>> master\n>>>>>\n>>>>> refs/heads/master gets set to refs/remotes/origin/master post- \n>>>>> fetch.\n>>>> In general, this should fail. Because you are expected to have \n>>>> local changes in the local branches.\n>>>\n>>> BS argument.\n>> Aha. So you want to make sure that the local branches are no \n>> longer \"purely\" local. And you want to stop updating them when \n>> unpushed changes are in the local branches.\n>\n> To me, it's more along the lines of \"let git help me not make the \n> mistake of hacking on a six-week old codebase when I've explicitly \n> asked it to merge these and those remote tracking branches into \n> these and those local branches\". Not updating those branches when \n> there *are* changes on them is something users can understand and \n> will probably also appreciate, but the reason for not allowing even \n> fast-forwards escape me.\n\nHere's also an interesting asymmetry. By default, git push\nupdates all remote branches matching a local branch. But git\npull \"updates\" only the current local branch to the state of\nthe remote head (by updating all local copies of the remote\nbranches, but merging only a single of these heads).\n\nMaybe this asymmetry adds to the confusion. I see arguments\nfor both behaviours:\n1) In both cases, update only the branch you're on\nor\n2) in both cases update all matching branches.\n(btw, if I do not intend to merge at all, you can always use\n\"git fetch\".)\n\n\tSteffen\n"},{"id":"56901","messageId":"200710221948.53694.robin.rosenberg.lists@dewire.com","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221428390.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-10-22T17:48:53Z","receivedAt":"2007-10-22T17:48:53Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\nMy list\n\n 61 show\n 35 gitk\n 31 diff\n 23 fetch\n 12 reset\n 12 blame\n 11 clone\n 11 checkout\n 10 remote\n 10 rebase\n 9 status\n 5 commit\n 4 branch\n 3 clean\n 2 revert\n 2 merge\n 2 ls-remote\n 2 gui\n\n-- robin\n"},{"id":"56903","messageId":"Pine.LNX.4.64.0710221305230.32497@iabervon.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221445170.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-22T18:06:00Z","receivedAt":"2007-10-22T18:06:00Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 22 Oct 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n> \n> > If I were to suggest any improvements, it'd be to change the semantics of\n> > git-pull to always update the local branches set up to be merged with the\n> > remote tracking branches when they, prior to fetching, pointed to the same\n> > commit, such that when\n> > \n> > $ git show-ref master\n> > d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n> > d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n> > \n> > refs/heads/master gets set to refs/remotes/origin/master post-fetch.\n> \n> In general, this should fail. Because you are expected to have local \n> changes in the local branches. What you describe suggests that you should \n> not use the branch name \"master\" at all, but \"origin/master\".\n\nIf you push your changes to the origin soon after making them, you'll only \nhave local changes if somebody else changed something while you were \nworking on a change. You're expected to create local changes in the local \nbranches, but you shouldn't generally sit on them forever, and when you've \npushed them, you no longer have any difference in content between local \nand remote.\n\nIf the project has multiple branches in the central repository, and you \nmake changes for each of them at different times, but only one each day, \nthe normal case will be to have local changes sitting in at most one of \nthe branches, and, in particular, no local changes left in any branch \nother than HEAD.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"56908","messageId":"1193081785.4522.181.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"471CBEB1.2030008@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-22T19:36:25Z","receivedAt":"2007-10-22T19:36:25Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Mon, 2007-10-22 at 17:16 +0200, Andreas Ericsson wrote:\n\n> To me, it's more along the lines of \"let git help me not make the \n> mistake of hacking on a six-week old codebase when I've explicitly asked \n> it to merge these and those remote tracking branches into these and \n> those local branches\". Not updating those branches when there *are* \n> changes on them is something users can understand and will probably also \n> appreciate, but the reason for not allowing even fast-forwards escape me.\n\nI'd love this behavior, FWIW.\n\nThe \"branches should not track their origin by default\" seems suited\nonly to Linux kernel maintainers who frequently pull from many different\npeople, not to \"random hacker who wants to keep track of a project he\ndoesn't maintain\" :)\n\n Federico\n"},{"id":"56920","messageId":"471D2A07.7070201@midwinter.com","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710212308540.25221@racer.site","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-22T22:53:59Z","receivedAt":"2007-10-22T22:53:59Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> I'd really like people to respond not so much with broad and general \n> statements to my mail (those statements tend to be rather useless to find \n> how to make git more suitable to newbies), but rather with concrete top \n> ten lists of what they do daily.\n> \n\nMaybe not top 10 per se, but here are a couple of my common command \nsequences and some comments about how they could maybe be simplified. I \nmostly use git to talk to an svn repo, which in some sense is a corner \ncase but which I suspect is both (a) really common already, and (b) \npotentially even *more* common if we can make git an even easier way to \nwork with svn repositories.\n\nPulling updates from svn:\n\ngit stash\ngit svn rebase\ngit stash apply\n\nA \"git svn up\" command could do the above automatically (svn users are \naccustomed to doing \"svn up\" with dirty working copies.)\n\nCommitting my work:\n\ngit commit -a\n(ask someone for a code review, usually involves \"git diff\" or \"git show\")\ngit commit --amend (to indicate in my commit message who did the review)\ngit svn rebase\ngit svn dcommit\n\nThis isn't too bad as is. I could save myself the \"git commit --amend\" \nif there were an option to \"git svn dcommit\" to pop up a commit message \neditor (using the existing text as the default, of course) but it \ndoesn't bother me much.\n\nA more extreme possibility which I predict approximately 0 people on \nthis list will like: if the working copy is dirty but there is no local \ncommit, \"git svn dcommit\" could pop up an editor for a commit message, \nmake a local commit, then send it to svn. That would simplify the \ngit-based workflow even further for svn users who don't care about local \nversioning. I'm not sure *I* even like this idea, mind you, but it would \ncertainly address the \"Why this extra step I don't need in svn?\" \ncomplaint svn users sometimes raise.\n\nWorking in a topic branch:\n\ngit checkout whateverbranch\ngit svn rebase\ngit commit -a (a bunch of times)\ngit checkout -b temp trunk\ngit merge --squash whateverbranch\ngit commit\n(get code review)\ngit commit --amend\ngit svn dcommit\n\nThis could be shortened a bit with the above idea (edit commit message) \nplus an option to git-svn dcommit to squash everything into one svn commit.\n\nOf course, whether adding more options like that would make things more \nnewbie-friendly is a valid question in and of itself; a shorter workflow \nis not necessarily a more discoverable one.\n\n-Steve\n"},{"id":"56924","messageId":"Pine.LNX.4.64.0710230017120.25221@racer.site","threadId":"10194","inReplyTo":"1193081785.4522.181.camel@cacharro.xalalinux.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-22T23:21:03Z","receivedAt":"2007-10-22T23:21:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Oct 2007, Federico Mena Quintero wrote:\n\n> On Mon, 2007-10-22 at 17:16 +0200, Andreas Ericsson wrote:\n> \n> > To me, it's more along the lines of \"let git help me not make the \n> > mistake of hacking on a six-week old codebase when I've explicitly asked \n> > it to merge these and those remote tracking branches into these and \n> > those local branches\". Not updating those branches when there *are* \n> > changes on them is something users can understand and will probably also \n> > appreciate, but the reason for not allowing even fast-forwards escape me.\n> \n> I'd love this behavior, FWIW.\n> \n> The \"branches should not track their origin by default\" seems suited\n> only to Linux kernel maintainers who frequently pull from many different\n> people, not to \"random hacker who wants to keep track of a project he\n> doesn't maintain\" :)\n\nThe problem I see here is not that the kernel folks would suffer, but that \nthe behaviour would not be easy to explain. Which is a sure way to not \nonly give people rope, but put their heads in the noose.\n\nNot having clear semantics is prone to lead to misunderstandings, and \nmistakes.\n\nIOW while I trust you when you say it would make things easier for you, I \nam quite certain it would make things much harder for a substantial part \nof the rest of humanity.\n\nCiao,\nDscho\n"},{"id":"56925","messageId":"8fe92b430710221627p6d8a28a3oa0d6f747d99af0b6@mail.gmail.com","threadId":"10194","inReplyTo":"1193064780.4522.142.camel@cacharro.xalalinux.org","subject":"Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-22T23:27:07Z","receivedAt":"2007-10-22T23:27:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/22/07, Federico Mena Quintero wrote:\n> On Mon, 2007-10-22 at 09:59 +0200, Andreas Ericsson wrote:\n>\n>> I doubt many people on this list regularly use git-blame but it's a\n>> command that's definitely non-trivial to script out using only the\n>> \"proper\" commands, and CVS/SVN users expect it to be there, so it's\n>> probably worth listing anyhow.\n\n> Personally I find git-blame *EXTREMELY* useful. The workflow is:\n\n> 5. \"WTF? Who wrote this crappy code?\"\n>\n> 6. git blame culprit-file.c\n>\n> 7. \"Oh, it was $person with $commit_id... what were they thinking at the\n> time?\"\n>\n> 8. git show $commit_id\n\nYou don't need blame for that (by the way, as git-blame is slow, you\ncan try -L option to limit range of lines; it is a pity that 'git gui\nblame' does not support it yet). You can use 'pickaxe search', i.e.\n\"git log -S''\". Sometimes it is better than git-blame...\n\n-- \nJakub Narebski\n"},{"id":"56928","messageId":"8fe92b430710221635x752c561ejcee14e2526010cc9@mail.gmail.com","threadId":"10194","inReplyTo":"471CB443.9070606@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-22T23:35:41Z","receivedAt":"2007-10-22T23:35:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/22/07, Andreas Ericsson wrote:\n> Johannes Schindelin wrote:\n>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n>>\n>>> If I were to suggest any improvements, it'd be to change the semantics of\n>>> git-pull to always update the local branches set up to be merged with the\n>>> remote tracking branches when they, prior to fetching, pointed to the same\n>>> commit, such that when\n>>>\n>>> $ git show-ref master\n>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n>>>\n>>> refs/heads/master gets set to refs/remotes/origin/master post-fetch.\n>>\n>> In general, this should fail. Because you are expected to have local\n>> changes in the local branches.\n>\n>\n> BS argument. Git knows when I haven't got any changes on my local\n> branches, and it can be fairly safely assumed that when I feel like\n> making any, I'd like to make them off as fresh a tip as possible unless\n> I explicitly tell git otherwise.\n[cut]\n\nIt would be I think possible to make git behave as you want, although I'd rather\n(at least at first) have behaviour described above turned on by some option\nor config variable. I guess that it would be not that hard to make script to do\nwhat you ant (and probably it would be best if you tried your idea that way).\n\nThere are the following caveats.\n1. For each local branch that is to be updated on pull, this branch\nmust be marked as tracking some branch of some repository. This has to\nbe explicitely done; for example by creating those branches using\n--track option.\n2. Git can do a merge with conflicts _only_ if that branch is checked\nout. So for all local branches which you want to get updated using\n\"git pull --update-all \" (or something like that), the merge\nwith remote branch should be either fast-forward, trivial merge, or\nmerge without conflicts. \"git pull --update-all \" would return\nthen list of updated branches and list of branches which cannot be\nupdated.\n\nSo... are you going to try to implement that?\n-- \nJakub Narebski\n"},{"id":"56963","messageId":"92320AA3-6D23-4967-818D-F7FA3962E88D@zib.de","threadId":"10194","inReplyTo":"8fe92b430710221635x752c561ejcee14e2526010cc9@mail.gmail.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-23T05:38:23Z","receivedAt":"2007-10-23T05:38:23Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 23, 2007, at 1:35 AM, Jakub Narebski wrote:\n\n> On 10/22/07, Andreas Ericsson wrote:\n>> Johannes Schindelin wrote:\n>>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n>>>\n>>>> If I were to suggest any improvements, it'd be to change the \n>>>> semantics of\n>>>> git-pull to always update the local branches set up to be merged \n>>>> with the\n>>>> remote tracking branches when they, prior to fetching, pointed \n>>>> to the same\n>>>> commit, such that when\n>>>>\n>>>> $ git show-ref master\n>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n>>>>\n>>>> refs/heads/master gets set to refs/remotes/origin/master post- \n>>>> fetch.\n>>>\n>>> In general, this should fail. Because you are expected to have \n>>> local\n>>> changes in the local branches.\n>>\n>>\n>> BS argument. Git knows when I haven't got any changes on my local\n>> branches, and it can be fairly safely assumed that when I feel like\n>> making any, I'd like to make them off as fresh a tip as possible \n>> unless\n>> I explicitly tell git otherwise.\n> [cut]\n>\n> It would be I think possible to make git behave as you want, \n> although I'd rather\n> (at least at first) have behaviour described above turned on by \n> some option\n> or config variable. I guess that it would be not that hard to make \n> script to do\n> what you ant (and probably it would be best if you tried your idea \n> that way).\n>\n> There are the following caveats.\n> 1. For each local branch that is to be updated on pull, this branch\n> must be marked as tracking some branch of some repository. This has to\n> be explicitely done; for example by creating those branches using\n> --track option.\n\nTrue, and only the branches matching the remote currently pulled\nshould be considered. Tracking branches pointing to a different\nremote need to be skipped.\n\n\n> 2. Git can do a merge with conflicts _only_ if that branch is checked\n> out.\n\nAndreas' proposal contains an important requirement that\navoids this problem. His proposal states \"when they, prior\nto fetching, pointed to the same commit [the head in remotes\npointed to]\". That is only fast-forwards are needed, which\nnever have merge conflicts.\n\n\n> So for all local branches which you want to get updated using\n> \"git pull --update-all \" (or something like that), the merge\n> with remote branch should be either fast-forward, trivial merge, or\n> merge without conflicts. \"git pull --update-all \" would return\n> then list of updated branches and list of branches which cannot be\n> updated.\n\nMaybe Andreas' proposal could be extended as you describe.\nBut I don't think any merging should automatically be done. I'd\nonly support fast forwards. Merging always includes a risk\nof unexpected changes to the code; even if there are no merge\nconflicts detected by git. I think it is reasonable to leave\nall such cases to the user for manual resolution. Supporting\nfast-forward should be sufficient.\n\n\tSteffen\n"},{"id":"56987","messageId":"471DA1B8.4030400@op5.se","threadId":"10194","inReplyTo":"8fe92b430710221635x752c561ejcee14e2526010cc9@mail.gmail.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-23T07:24:40Z","receivedAt":"2007-10-23T07:24:40Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> On 10/22/07, Andreas Ericsson wrote:\n>> Johannes Schindelin wrote:\n>>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:\n>>>\n>>>> If I were to suggest any improvements, it'd be to change the semantics of\n>>>> git-pull to always update the local branches set up to be merged with the\n>>>> remote tracking branches when they, prior to fetching, pointed to the same\n>>>> commit, such that when\n>>>>\n>>>> $ git show-ref master\n>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master\n>>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master\n>>>>\n>>>> refs/heads/master gets set to refs/remotes/origin/master post-fetch.\n>>> In general, this should fail. Because you are expected to have local\n>>> changes in the local branches.\n>>\n>> BS argument. Git knows when I haven't got any changes on my local\n>> branches, and it can be fairly safely assumed that when I feel like\n>> making any, I'd like to make them off as fresh a tip as possible unless\n>> I explicitly tell git otherwise.\n> [cut]\n> \n> It would be I think possible to make git behave as you want, although I'd rather\n> (at least at first) have behaviour described above turned on by some option\n> or config variable. I guess that it would be not that hard to make script to do\n> what you ant (and probably it would be best if you tried your idea that way).\n> \n> There are the following caveats.\n> 1. For each local branch that is to be updated on pull, this branch\n> must be marked as tracking some branch of some repository. This has to\n> be explicitely done; for example by creating those branches using\n> --track option.\n> 2. Git can do a merge with conflicts _only_ if that branch is checked\n> out. So for all local branches which you want to get updated using\n> \"git pull --update-all \" (or something like that), the merge\n> with remote branch should be either fast-forward, trivial merge, or\n> merge without conflicts. \"git pull --update-all \" would return\n> then list of updated branches and list of branches which cannot be\n> updated.\n> \n> So... are you going to try to implement that?\n\nYes, but only for fast-forward cases. When there *are* local changes, \nthe user must decide when to merge those, since he/she may not be done \nwith them. It doesn't make sense to merge local canges on a not checked \nout branch automagically, because then we end up in the very unclear \nsemantics that Dscho (and myself) fear.\n\nAlso, as Steffen pointed out in his mail, this will make \"git pull\" \nlargely symmetrical with \"git push\", which *does* update all the remote \nbranches, but only if the update results in a fast-forward.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56994","messageId":"Pine.LNX.4.64.0710231155321.25221@racer.site","threadId":"10194","inReplyTo":"92320AA3-6D23-4967-818D-F7FA3962E88D@zib.de","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-23T10:58:58Z","receivedAt":"2007-10-23T10:58:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Oct 2007, Steffen Prohaska wrote:\n\n> \n> On Oct 23, 2007, at 1:35 AM, Jakub Narebski wrote:\n> \n> > 2. Git can do a merge with conflicts _only_ if that branch is checked \n> > out.\n> \n> Andreas' proposal contains an important requirement that avoids this \n> problem. His proposal states \"when they, prior to fetching, pointed to \n> the same commit [the head in remotes pointed to]\". That is only \n> fast-forwards are needed, which never have merge conflicts.\n\nYou know what I do not like with this proposal? The whole _point_ of this \ndiscussion is to make git _easier_. Go ahead, try to explain to a \ncomplete git newbie the proposed behaviour. I have a pound here which \nsays that there is _no_ _way_ that this newbie says \"well, that's easy\".\n\nSome people may not get this, but git has a reputation of being \ncomplicated, and my \"BS\" argument was, is, and will be, that we should \nkeep clear and simple semantics, because they are the _only_ way to battle \nthat reputation.\n\nCiao,\nDscho\n"},{"id":"57032","messageId":"20071023221358.GB729@steel.home","threadId":"10194","inReplyTo":"ED965042-27DE-450B-96CB-00D27000FAF6@wincent.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-23T22:13:59Z","receivedAt":"2007-10-23T22:13:59Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Wincent Colaiuta, Mon, Oct 22, 2007 15:17:19 +0200:\n>\n>> So once again, what operations involving git do people use regularly?\n>\n> Here are my top ten commands, sorted by the number of times they appear in \n> my ~/.bash_history:\n\nfrom my (short, 500) .bash_history:\n\n 26 am\n 22 gitk\n 21 fetch\n 15 reset\n 10 log\n 9 merge\n 8 cherry-pick\n 7 status\n 5 commit\n 4 svn\n 4 push\n 4 gc\n 4 diff\n 3 gui\n 3 format-patch\n 2 pull\n 2 clone\n 1 show\n 1 rebase\n 1 grep\n 1 cat-file\n 1 branch\n 1 apply\n\nbranch, cat-file and show are actually fairly common, the history just\nshorted and I lost them.\n"},{"id":"57050","messageId":"8fe92b430710231906l35606fe2j2b7c28ed6f4dd1a3@mail.gmail.com","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710221156540.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-24T02:06:38Z","receivedAt":"2007-10-24T02:06:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/22/07, Johannes Schindelin wrote:\n\n> So once again, what operations involving git do people use regularly?\n>\n> There is a good chance that git is not optimised for most\n> people's daily workflows, as project maintainers seemed to be much more\n> forthcoming with patches, and therefore maintainers' tasks are much more\n> optimised than in other SCMs.\n\nFor working on gitweb in git.git repository.\n1. Fetch (when I am on topic branch) or pull (in rare cases I am on master)\n2. \"stg rebase origin\"\n3. work, work, work, using StGIT to generate perfect patch series\n(going back and forth between patches, reordering patches, adding\npatch in the middle of series, concatenating two patches, etc.; for\nexample when I notice that something should be changed in previous\npatch, be it either bug noticed just now, or change in preparatory\npatch to better suit main one)\n4. fetch and rebase just between publishing\n5. git format-patch to generate patch series; use git-shortlog or\ngrepping for patches subjects and git-diff --stat to generate\nintroductory email. Unfortunately StGIT template for introductory\nemail does have neither shortlog nor diffstat fields to atomatically\nfill. Add comments to patches if needed.\n6. Either use KMail + attach inline (no word wrap), or git-send-mail\n(with sendmail configured to use gmail account; now I could use simply\ngit-send-mail configuration in user config) to send patches to git\nmailing list\n7. Push changes (if I don't forget) to repo.or.cz repository (jnareb-git.git).\n\n-- \nJakub Narebski\n"},{"id":"57070","messageId":"20071024102950.GA3908@diana.vm.bytemark.co.uk","threadId":"10194","inReplyTo":"8fe92b430710231906l35606fe2j2b7c28ed6f4dd1a3@mail.gmail.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-24T10:29:50Z","receivedAt":"2007-10-24T10:29:50Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-24 04:06:38 +0200, Jakub Narebski wrote:\n\n> 5. git format-patch to generate patch series; use git-shortlog or\n> grepping for patches subjects and git-diff --stat to generate\n> introductory email. Unfortunately StGIT template for introductory\n> email does have neither shortlog nor diffstat fields to atomatically\n> fill.\n\nIt does now! (I don't think it's in any released version yet, though.)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"57072","messageId":"8fe92b430710240404u202521d4g2275bc4886956807@mail.gmail.com","threadId":"10194","inReplyTo":"20071024102950.GA3908@diana.vm.bytemark.co.uk","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-24T11:04:01Z","receivedAt":"2007-10-24T11:04:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/24/07, Karl Hasselström wrote:\n> On 2007-10-24 04:06:38 +0200, Jakub Narebski wrote:\n>\n>> 5. git format-patch to generate patch series; use git-shortlog or\n>> grepping for patches subjects and git-diff --stat to generate\n>> introductory email. Unfortunately StGIT template for introductory\n>> email does have neither shortlog nor diffstat fields to atomatically\n>> fill.\n>\n> It does now! (I don't think it's in any released version yet, though.)\n\nThat is nice to hear.\n\nBy the way, there is SRPM for StGIT in\nhttp://homepage.ntlworld.com/cmarinas/stgit/\n(I need it because I have Python 2.4), but it is not listed on downloads page...\n\n-- \nJakub Narebski\n"},{"id":"57075","messageId":"20071024113123.GB6459@diana.vm.bytemark.co.uk","threadId":"10194","inReplyTo":"8fe92b430710240404u202521d4g2275bc4886956807@mail.gmail.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-24T11:31:23Z","receivedAt":"2007-10-24T11:31:23Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-24 13:04:01 +0200, Jakub Narebski wrote:\n\n> By the way, there is SRPM for StGIT in\n> http://homepage.ntlworld.com/cmarinas/stgit/ (I need it because I\n> have Python 2.4), but it is not listed on downloads page...\n\nI'll leave the webpage question to Catalin, but I'm curious about the\nPython version remark. What exactly is the problem?\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"57081","messageId":"1193231728.4671.13.camel@pc1117.cambridge.arm.com","threadId":"10194","inReplyTo":"8fe92b430710240404u202521d4g2275bc4886956807@mail.gmail.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2007-10-24T13:15:28Z","receivedAt":"2007-10-24T13:15:28Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"On Wed, 2007-10-24 at 13:04 +0200, Jakub Narebski wrote:\n> On 10/24/07, Karl Hasselström wrote:\n> > On 2007-10-24 04:06:38 +0200, Jakub Narebski wrote:\n> >\n> >> 5. git format-patch to generate patch series; use git-shortlog or\n> >> grepping for patches subjects and git-diff --stat to generate\n> >> introductory email. Unfortunately StGIT template for introductory\n> >> email does have neither shortlog nor diffstat fields to atomatically\n> >> fill.\n> >\n> > It does now! (I don't think it's in any released version yet, though.)\n> \n> That is nice to hear.\n> \n> By the way, there is SRPM for StGIT in\n> http://homepage.ntlworld.com/cmarinas/stgit/\n> (I need it because I have Python 2.4), but it is not listed on downloads page...\n\nI never thought anyone would need it. I find the .tar.gz better.\n\nBTW, what is the problem with Python 2.4? Was the RPM built for a\ndifferent version? The upcoming 0.14 release will be based on Python 2.5\nbut we keep the compatibility with 2.4 (we dropped 2.3).\n\n-- \nCatalin\n"},{"id":"57090","messageId":"90325C2E-9AF4-40FB-9EFB-70B6D0174409@zib.de","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710231155321.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-24T18:48:54Z","receivedAt":"2007-10-24T18:48:54Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 23, 2007, at 12:58 PM, Johannes Schindelin wrote:\n\n> On Tue, 23 Oct 2007, Steffen Prohaska wrote:\n>\n>>\n>> On Oct 23, 2007, at 1:35 AM, Jakub Narebski wrote:\n>>\n>>> 2. Git can do a merge with conflicts _only_ if that branch is \n>>> checked\n>>> out.\n>>\n>> Andreas' proposal contains an important requirement that avoids this\n>> problem. His proposal states \"when they, prior to fetching, \n>> pointed to\n>> the same commit [the head in remotes pointed to]\". That is only\n>> fast-forwards are needed, which never have merge conflicts.\n>\n> You know what I do not like with this proposal? The whole _point_ \n> of this\n> discussion is to make git _easier_. Go ahead, try to explain to a\n> complete git newbie the proposed behaviour. I have a pound here which\n> says that there is _no_ _way_ that this newbie says \"well, that's \n> easy\".\n>\n> Some people may not get this, but git has a reputation of being\n> complicated, and my \"BS\" argument was, is, and will be, that we should\n> keep clear and simple semantics, because they are the _only_ way to \n> battle\n> that reputation.\n\nI try to explain the workflow that I'd use the feature for.\nMaybe an easier setup could be used to achieve the same.\nAny suggestions for a simpler setup are welcome.\n\nThe workflow is used by a group of developers that all have\naccess to a shared repository. One major goal is to keep the\nsetup for most developers simple. They are new to git and\nas few commands as possible should be sufficient to start\nworking. Besides the typical stable branches (master, next)\nshared topic branches should be available that can be used\nto develop and review features before they are merged to the\nstable branches. Patches are not send by email.\n\nSo here's the setup:\n\nThe central shared repo is called project-shared.git and contains,\nfor example, the following branches:\n master\n next\n work/topicA\n work/topicB\n ...\n\n\nDevelopers clone the repo and check out the branches they are\ninterested in. For example a developer may want to track next\nand work on topicB:\n\n git clone ssh://central.example.com/project-shared.git project\n cd project\n git checkout -b next origin/next\n git checkout -b work/topicB origin/work/topicB\n\nThis is sufficient. No adding of remotes is needed. Neither\nis a private repository on a server required. After cloning,\ndevelopers have all they need.\n\nLater work/topicB has new commits and should be pushed:\n\n git push origin\n\nThe default behaviour of push is fine. Only matching branches\nare pushed.\n\n_But_, origin is a shared repository. Therefore branches may\nhave advanced and git push may report\n\nerror: remote 'refs/heads/next' is not a strict subset of local ref \n'refs/heads/next'. maybe you are not up-to-date and need to pull first?\n\nSo here's the problem. The developer didn't do anything wrong.\nBut git complaints with an error. Git also recommends to run\npull, so the developer runs \"git pull\". But this doesn't help,\nbecause it's only updating work/topicB and \"git push\" will\ncomplain with the very same error.\n\nWhat you need to do is\n\n git checkout \n git pull\n git checkout \n git pull\n ...\n\nfor every local branch.\n\nThis is absolutely stupid. Therefore the developer starts\nto hate git, or she just starts to ignore the errors because\nthey don't have a real meaning most of the times. And later,\nwhen the error could be helpful she would ignore it, too.\n\nThe problem described can only happen with a shared repository.\nIn a workflow that pulls from read-only repos and pushes to a\nprivate repo that is read-only for others, such a problem cannot\nhappen. Because in a non-shared repository the branches cannot\nbe advanced by others. But in a shared repository they can.\n\nI see two reasonable solutions:\n1) \"git push\" only pushes the current branch.\n2) \"git pull\" pulls all branches as proposed by Andreas.\n\nMaybe something that I don't see is fundamentally wrong with\nthe setup.\n\nJohannes, you mentioned that it is essential to distinguish\nremote branches from local branches. In general, I agree. The\nproblem described above is 'smaller' if you have less local\nbranches that you're not actively working on. But I believe\nit is reasonable to have more than one of them. The remotes\ntrack everything and your local branches are a subset of things\nyou're interested in although you're not working on each of\nthe branch every day. I don't think it's reasonable to delete\na local branch immediately each time you stopped working on it.\n\nI think root of the problem is that git is more focused on\npulling from read-only and pushing to non-shared repos. The\nsupport for shared repos needs to be improved before it\nis perfect.\n\n\tSteffen\n"},{"id":"57091","messageId":"20071024192058.GF29830@fieldses.org","threadId":"10194","inReplyTo":"90325C2E-9AF4-40FB-9EFB-70B6D0174409@zib.de","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-24T19:20:58Z","receivedAt":"2007-10-24T19:20:58Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote:\n> The central shared repo is called project-shared.git and contains,\n> for example, the following branches:\n> master\n> next\n> work/topicA\n> work/topicB\n> ...\n>\n>\n> Developers clone the repo and check out the branches they are\n> interested in. For example a developer may want to track next\n> and work on topicB:\n>\n> git clone ssh://central.example.com/project-shared.git project\n> cd project\n> git checkout -b next origin/next\n> git checkout -b work/topicB origin/work/topicB\n>\n> This is sufficient. No adding of remotes is needed. Neither\n> is a private repository on a server required. After cloning,\n> developers have all they need.\n>\n> Later work/topicB has new commits and should be pushed:\n>\n> git push origin\n>\n> The default behaviour of push is fine. Only matching branches\n> are pushed.\n>\n> _But_, origin is a shared repository. Therefore branches may\n> have advanced and git push may report\n>\n> error: remote 'refs/heads/next' is not a strict subset of local ref \n> 'refs/heads/next'. maybe you are not up-to-date and need to pull first?\n>\n> So here's the problem. The developer didn't do anything wrong.\n> But git complaints with an error. Git also recommends to run\n> pull, so the developer runs \"git pull\". But this doesn't help,\n> because it's only updating work/topicB and \"git push\" will\n> complain with the very same error.\n>\n> What you need to do is\n>\n> git checkout \n> git pull\n> git checkout \n> git pull\n> ...\n>\n> for every local branch.\n\nOr just\n\n\tgit push origin work/topicB\n\nsince that's all you really wanted to push anyway.\n\n> The problem described can only happen with a shared repository.\n> In a workflow that pulls from read-only repos and pushes to a\n> private repo that is read-only for others, such a problem cannot\n> happen. Because in a non-shared repository the branches cannot\n> be advanced by others. But in a shared repository they can.\n\nActually I push to my public repo from multiple working repositories\n(because usually I work on my laptop, but sometimes I do work from a\ndifferent machine), so the above can still happen.\n\n--b.\n"},{"id":"57093","messageId":"471F9FD1.6080002@op5.se","threadId":"10194","inReplyTo":"20071024192058.GF29830@fieldses.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-24T19:41:05Z","receivedAt":"2007-10-24T19:41:05Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"J. Bruce Fields wrote:\n> On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote:\n>> The central shared repo is called project-shared.git and contains,\n>> for example, the following branches:\n>> master\n>> next\n>> work/topicA\n>> work/topicB\n>> ...\n>>\n>>\n>> Developers clone the repo and check out the branches they are\n>> interested in. For example a developer may want to track next\n>> and work on topicB:\n>>\n>> git clone ssh://central.example.com/project-shared.git project\n>> cd project\n>> git checkout -b next origin/next\n>> git checkout -b work/topicB origin/work/topicB\n>>\n>> This is sufficient. No adding of remotes is needed. Neither\n>> is a private repository on a server required. After cloning,\n>> developers have all they need.\n>>\n>> Later work/topicB has new commits and should be pushed:\n>>\n>> git push origin\n>>\n>> The default behaviour of push is fine. Only matching branches\n>> are pushed.\n>>\n>> _But_, origin is a shared repository. Therefore branches may\n>> have advanced and git push may report\n>>\n>> error: remote 'refs/heads/next' is not a strict subset of local ref \n>> 'refs/heads/next'. maybe you are not up-to-date and need to pull first?\n>>\n>> So here's the problem. The developer didn't do anything wrong.\n>> But git complaints with an error. Git also recommends to run\n>> pull, so the developer runs \"git pull\". But this doesn't help,\n>> because it's only updating work/topicB and \"git push\" will\n>> complain with the very same error.\n>>\n>> What you need to do is\n>>\n>> git checkout \n>> git pull\n>> git checkout \n>> git pull\n>> ...\n>>\n>> for every local branch.\n> \n> Or just\n> \n> \tgit push origin work/topicB\n> \n> since that's all you really wanted to push anyway.\n> \n\ngit pull. Not git push. git pull operates on one working branch\nat a time (by default), whereas git push uploads and fast-forwards\nall the common branches (by default). I want git pull to work like\ngit push.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57094","messageId":"20071024194849.GH29830@fieldses.org","threadId":"10194","inReplyTo":"471F9FD1.6080002@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-24T19:48:49Z","receivedAt":"2007-10-24T19:48:49Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Oct 24, 2007 at 09:41:05PM +0200, Andreas Ericsson wrote:\n> J. Bruce Fields wrote:\n>> On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote:\n>>> The central shared repo is called project-shared.git and contains,\n>>> for example, the following branches:\n>>> master\n>>> next\n>>> work/topicA\n>>> work/topicB\n>>> ...\n>>>\n>>>\n>>> Developers clone the repo and check out the branches they are\n>>> interested in. For example a developer may want to track next\n>>> and work on topicB:\n>>>\n>>> git clone ssh://central.example.com/project-shared.git project\n>>> cd project\n>>> git checkout -b next origin/next\n>>> git checkout -b work/topicB origin/work/topicB\n>>>\n>>> This is sufficient. No adding of remotes is needed. Neither\n>>> is a private repository on a server required. After cloning,\n>>> developers have all they need.\n>>>\n>>> Later work/topicB has new commits and should be pushed:\n>>>\n>>> git push origin\n>>>\n>>> The default behaviour of push is fine. Only matching branches\n>>> are pushed.\n>>>\n>>> _But_, origin is a shared repository. Therefore branches may\n>>> have advanced and git push may report\n>>>\n>>> error: remote 'refs/heads/next' is not a strict subset of local ref \n>>> 'refs/heads/next'. maybe you are not up-to-date and need to pull first?\n>>>\n>>> So here's the problem. The developer didn't do anything wrong.\n>>> But git complaints with an error. Git also recommends to run\n>>> pull, so the developer runs \"git pull\". But this doesn't help,\n>>> because it's only updating work/topicB and \"git push\" will\n>>> complain with the very same error.\n>>>\n>>> What you need to do is\n>>>\n>>> git checkout \n>>> git pull\n>>> git checkout \n>>> git pull\n>>> ...\n>>>\n>>> for every local branch.\n>> Or just\n>> \tgit push origin work/topicB\n>> since that's all you really wanted to push anyway.\n>\n> git pull. Not git push. git pull operates on one working branch\n> at a time (by default), whereas git push uploads and fast-forwards\n> all the common branches (by default).\n\nI understand. I was just suggesting that if the goal was to avoid the\nerror message on push, then specifying the branch to push explicitly\nwould be a solution.\n\n> I want git pull to work like git push.\n\nThat strikes me as a less complete solution, since it only helps in the\ncase where the other branches all happen to be unmodified locally (hence\ncan be fast-forwarded). In other cases the \"git push\" will still emit a\nspurious error.\n\n--b.\n"},{"id":"57096","messageId":"86784BB7-076F-4504-BCE6-4580A7C68AAC@zib.de","threadId":"10194","inReplyTo":"20071024194849.GH29830@fieldses.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-24T20:12:29Z","receivedAt":"2007-10-24T20:12:29Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n\n>\n>> I want git pull to work like git push.\n>\n> That strikes me as a less complete solution, since it only helps in \n> the\n> case where the other branches all happen to be unmodified locally \n> (hence\n> can be fast-forwarded). In other cases the \"git push\" will still \n> emit a\n> spurious error.\n\nWell, but then there's something you should really think\nabout. Then you _have_ local changes that are not at the remote.\nYou need to handle them somehow. Maybe you forgot to push\nearlier and now the remote advanced.\n\nBtw, the 'new' git pull should already have reported a warning\nthat it failed to fast forward the local branch. git pull\nshould have suggested to explicitly merge the branch with\nlocal changes.\n\n\tSteffen\n"},{"id":"57097","messageId":"471FA751.4000603@op5.se","threadId":"10194","inReplyTo":"20071024194849.GH29830@fieldses.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-24T20:13:05Z","receivedAt":"2007-10-24T20:13:05Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"J. Bruce Fields wrote:\n> On Wed, Oct 24, 2007 at 09:41:05PM +0200, Andreas Ericsson wrote:\n>> J. Bruce Fields wrote:\n>>> On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote:\n>>>> The central shared repo is called project-shared.git and contains,\n>>>> for example, the following branches:\n>>>> master\n>>>> next\n>>>> work/topicA\n>>>> work/topicB\n>>>> ...\n>>>>\n>>>>\n>>>> Developers clone the repo and check out the branches they are\n>>>> interested in. For example a developer may want to track next\n>>>> and work on topicB:\n>>>>\n>>>> git clone ssh://central.example.com/project-shared.git project\n>>>> cd project\n>>>> git checkout -b next origin/next\n>>>> git checkout -b work/topicB origin/work/topicB\n>>>>\n>>>> This is sufficient. No adding of remotes is needed. Neither\n>>>> is a private repository on a server required. After cloning,\n>>>> developers have all they need.\n>>>>\n>>>> Later work/topicB has new commits and should be pushed:\n>>>>\n>>>> git push origin\n>>>>\n>>>> The default behaviour of push is fine. Only matching branches\n>>>> are pushed.\n>>>>\n>>>> _But_, origin is a shared repository. Therefore branches may\n>>>> have advanced and git push may report\n>>>>\n>>>> error: remote 'refs/heads/next' is not a strict subset of local ref \n>>>> 'refs/heads/next'. maybe you are not up-to-date and need to pull first?\n>>>>\n>>>> So here's the problem. The developer didn't do anything wrong.\n>>>> But git complaints with an error. Git also recommends to run\n>>>> pull, so the developer runs \"git pull\". But this doesn't help,\n>>>> because it's only updating work/topicB and \"git push\" will\n>>>> complain with the very same error.\n>>>>\n>>>> What you need to do is\n>>>>\n>>>> git checkout \n>>>> git pull\n>>>> git checkout \n>>>> git pull\n>>>> ...\n>>>>\n>>>> for every local branch.\n>>> Or just\n>>> \tgit push origin work/topicB\n>>> since that's all you really wanted to push anyway.\n>> git pull. Not git push. git pull operates on one working branch\n>> at a time (by default), whereas git push uploads and fast-forwards\n>> all the common branches (by default).\n> \n> I understand. I was just suggesting that if the goal was to avoid the\n> error message on push, then specifying the branch to push explicitly\n> would be a solution.\n> \n\nA better way to avoid that error message is ofcourse to make sure one\nalways starts development off of the latest version of the particular\nbranch one wants to work on.\n\n>> I want git pull to work like git push.\n> \n> That strikes me as a less complete solution, since it only helps in the\n> case where the other branches all happen to be unmodified locally (hence\n> can be fast-forwarded).\n\nFor a corporate environment with multiple modules, the scenario where the\nupstream is modified and the local branches aren't is more common than\nanything else. The failure on push happens because developers do\n\ngit pull; # Yup, gotta do that to get the latest changes\ngit checkout whatever; # Here's where I want to work\nwork work work\ngit push; # ach crivens! bloody stupid git of a tool to ALWAYS BREAK!\n\n> In other cases the \"git push\" will still emit a\n> spurious error.\n> \n\nIf the tool can make it happen as few times as possible, that's good\nenough for me. It's a lot easier to explain to my co-workers that\ntheir push failed because someone else worked on it simultaneously\nand pushed before they did, rather than telling them that they did\nthe pull/checkout sequence in the wrong order.\n\nIn the one scenario, it's \"oh, I see\". In the other, it's \"god damn\npiece of shit tool\". Simple as that.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57100","messageId":"20071024203335.GJ29830@fieldses.org","threadId":"10194","inReplyTo":"86784BB7-076F-4504-BCE6-4580A7C68AAC@zib.de","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-24T20:33:35Z","receivedAt":"2007-10-24T20:33:35Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:\n> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n>\n>>\n>>> I want git pull to work like git push.\n>>\n>> That strikes me as a less complete solution, since it only helps in the\n>> case where the other branches all happen to be unmodified locally (hence\n>> can be fast-forwarded). In other cases the \"git push\" will still emit a\n>> spurious error.\n>\n> Well, but then there's something you should really think\n> about.\n\nPerhaps, but not necessarily; you may have some branches with local\nchanges that you're content to leave unpushed (and un-updated).\n\nSo the case where this proposal helps is the case where:\n\t- the user hasn't learned how to name individual branches on the\n\t push commandline, or has learned to do so, but wants less\n\t typing, and\n\t- the user has one or more unmodified copies of remote branches\n\t lying around, and\n\t- the user minds being reminded that those copies are out of\n\t date, and\n\t- the user either has no *modified* copies of local branches, or\n\t has some but doesn't mind being reminded that they're out of\n\t date on each push.\n\n--b.\n"},{"id":"57103","messageId":"471FB3D0.4040800@op5.se","threadId":"10194","inReplyTo":"20071024203335.GJ29830@fieldses.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-24T21:06:24Z","receivedAt":"2007-10-24T21:06:24Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"J. Bruce Fields wrote:\n> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:\n>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n>>\n>>>> I want git pull to work like git push.\n>>> That strikes me as a less complete solution, since it only helps in the\n>>> case where the other branches all happen to be unmodified locally (hence\n>>> can be fast-forwarded). In other cases the \"git push\" will still emit a\n>>> spurious error.\n>> Well, but then there's something you should really think\n>> about.\n> \n> Perhaps, but not necessarily; you may have some branches with local\n> changes that you're content to leave unpushed (and un-updated).\n> \n\nSure, but that won't change. The only thing I'm proposing is that\nlocal copies of remote branches are automatically fast-forwarded\non every pull, but only if\n\n* the branch has no modifications what so ever\n* the branch is set up to auto-merge with the particular branch\nfetched from the particular remote\n\nI really don't see any downsides what so ever with this. Those\nof you who do, please enlighten me.\n\n> \t- the user has one or more unmodified copies of remote branches\n> \t lying around, and\n\nExtremely common case for a large group of users. The worst part is\nthat this problem can get extremely annoying pretty quickly, with a\nlarge number of repos and a large number of branches, whereas the\none dev per repo folks will never have big worries about it.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57104","messageId":"AF6B550F-99FB-4F65-BA07-662AD590D070@zib.de","threadId":"10194","inReplyTo":"20071024203335.GJ29830@fieldses.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-24T21:16:26Z","receivedAt":"2007-10-24T21:16:26Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 24, 2007, at 10:33 PM, J. Bruce Fields wrote:\n\n> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:\n>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n>>\n>>>\n>>>> I want git pull to work like git push.\n>>>\n>>> That strikes me as a less complete solution, since it only helps \n>>> in the\n>>> case where the other branches all happen to be unmodified locally \n>>> (hence\n>>> can be fast-forwarded). In other cases the \"git push\" will still \n>>> emit a\n>>> spurious error.\n>>\n>> Well, but then there's something you should really think\n>> about.\n>\n> Perhaps, but not necessarily; you may have some branches with local\n> changes that you're content to leave unpushed (and un-updated).\n\nPersonally, I don't dare to work that way. But if you do want\nto keep local changes on branches that would normally be pushed\nbut you do not want to push them now, you must not call \"git\npush\" without arguments in the first place. Then you'll never\nsee the error emitted by push.\n\nI put local changes that I do not intend to change right away\non a special branch for/. I only merge them to \nif I decided to push them, and then I push them soon (maybe\nafter I prepared more branches and then push all at once).\n\n\n> So the case where this proposal helps is the case where:\n> \t- the user hasn't learned how to name individual branches on the\n> \t push commandline, or has learned to do so, but wants less\n> \t typing, and\n\nWell, as I wrote above \"git push\" is a too sharp knife for\nme. I _never_ have local changes that I don't intend to push.\nSo \"git push\" always does the right thing for me.\n\n\n> \t- the user has one or more unmodified copies of remote branches\n> \t lying around, and\n> \t- the user minds being reminded that those copies are out of\n> \t date, and\n> \t- the user either has no *modified* copies of local branches, or\n> \t has some but doesn't mind being reminded that they're out of\n> \t date on each push.\n\nI see your point. These are may requirements to make the\nproposed behaviour of \"git pull\" useful. But I'd recommend to\nuse git exactly as you described when working with a shared\nrepository:\n\nJust use \"git pull\" and \"git push\" and everything will be fine\nif you work as follows:\n- Use the same branch names that are used on the origin.\n- Only check out branches locally that you are especially interested in.\n- Only put changes on those branches if you intend to push them.\n- Use \"git pull\" before you start to prepare branches for\n \"git push\".\n- Keep you privat work on branches that are named differently\n from branches in the shared repository.\n\n\tSteffen\n"},{"id":"57106","messageId":"20071024212025.GM29830@fieldses.org","threadId":"10194","inReplyTo":"471FB3D0.4040800@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-24T21:20:25Z","receivedAt":"2007-10-24T21:20:25Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:\n> J. Bruce Fields wrote:\n>> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:\n>>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n>>>\n>>>>> I want git pull to work like git push.\n>>>> That strikes me as a less complete solution, since it only helps in the\n>>>> case where the other branches all happen to be unmodified locally (hence\n>>>> can be fast-forwarded). In other cases the \"git push\" will still emit a\n>>>> spurious error.\n>>> Well, but then there's something you should really think\n>>> about.\n>> Perhaps, but not necessarily; you may have some branches with local\n>> changes that you're content to leave unpushed (and un-updated).\n>\n> Sure, but that won't change. The only thing I'm proposing is that\n> local copies of remote branches are automatically fast-forwarded\n> on every pull, but only if\n>\n> * the branch has no modifications what so ever\n> * the branch is set up to auto-merge with the particular branch\n> fetched from the particular remote\n>\n> I really don't see any downsides what so ever with this. Those\n> of you who do, please enlighten me.\n\nThe downsides are that it makes the behavior of pull slightly more\ncomplicated, and that it changes long-established default behavior of a\nmajor subcommand. (Those aren't huge disadvantages, but they are\ndisadvantages.)\n\n>\n>> \t- the user has one or more unmodified copies of remote branches\n>> \t lying around, and\n>\n> Extremely common case for a large group of users.\n\nOK, but that was one part of a four-\"and\" clause. I don't see any\nabsolute clincher here, but on balance I think the disadvantages win\nout.\n\n--b.\n"},{"id":"57107","messageId":"20071024212854.GB6069@xp.machine.xx","threadId":"10194","inReplyTo":"471FB3D0.4040800@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-10-24T21:28:54Z","receivedAt":"2007-10-24T21:28:54Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:\n> J. Bruce Fields wrote:\n>> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:\n>>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n>>>\n>>>>> I want git pull to work like git push.\n>>>> That strikes me as a less complete solution, since it only helps in the\n>>>> case where the other branches all happen to be unmodified locally (hence\n>>>> can be fast-forwarded). In other cases the \"git push\" will still emit a\n>>>> spurious error.\n>>> Well, but then there's something you should really think\n>>> about.\n>> Perhaps, but not necessarily; you may have some branches with local\n>> changes that you're content to leave unpushed (and un-updated).\n>\n> Sure, but that won't change. The only thing I'm proposing is that\n> local copies of remote branches are automatically fast-forwarded\n> on every pull, but only if\n>\n> * the branch has no modifications what so ever\n> * the branch is set up to auto-merge with the particular branch\n> fetched from the particular remote\n>\n> I really don't see any downsides what so ever with this. Those\n> of you who do, please enlighten me.\n>\n\nYou can't check what got added in your pull, e.g you can't review the new\ncode with something like\n\n\tgitk next..origin/next\n\nI often do something like this, just to see what got changed. So at least\nin my opinion you have to add a third point:\n\n * the branch has no modifications what so ever\n * the branch is set up to auto-merge with the particular branch\n fetched from the particular remote\n\t\t\t\tAND\n * the user set a config option to always autofastfoward if the above\n conditions are true! This could be implemented as a global option with\n a per branch overwrite.\n\nOnly if this option is added so a user can mark a branch to never\nautofastforward (but it is still possible to have an auto-merge config) you won't\nloose valuable information.\n\n-Peter\n"},{"id":"57108","messageId":"05B279A2-98A3-45F1-9661-AB361F7CAA37@zib.de","threadId":"10194","inReplyTo":"20071024212854.GB6069@xp.machine.xx","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-24T21:47:13Z","receivedAt":"2007-10-24T21:47:13Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 24, 2007, at 11:28 PM, Peter Baumann wrote:\n\n> On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:\n>> J. Bruce Fields wrote:\n>>> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:\n>>>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n>>>>\n>>>>>> I want git pull to work like git push.\n>>>>> That strikes me as a less complete solution, since it only \n>>>>> helps in the\n>>>>> case where the other branches all happen to be unmodified \n>>>>> locally (hence\n>>>>> can be fast-forwarded). In other cases the \"git push\" will \n>>>>> still emit a\n>>>>> spurious error.\n>>>> Well, but then there's something you should really think\n>>>> about.\n>>> Perhaps, but not necessarily; you may have some branches with local\n>>> changes that you're content to leave unpushed (and un-updated).\n>>\n>> Sure, but that won't change. The only thing I'm proposing is that\n>> local copies of remote branches are automatically fast-forwarded\n>> on every pull, but only if\n>>\n>> * the branch has no modifications what so ever\n>> * the branch is set up to auto-merge with the particular branch\n>> fetched from the particular remote\n>>\n>> I really don't see any downsides what so ever with this. Those\n>> of you who do, please enlighten me.\n>>\n>\n> You can't check what got added in your pull, e.g you can't review \n> the new\n> code with something like\n>\n> \tgitk next..origin/next\n\nYou're not forced to pull. Just use \"git fetch\" if you\nwant to do this. Or is something missing if you'd be\nlimited to \"git fetch\"?\n\n\n> I often do something like this, just to see what got changed. So at \n> least\n> in my opinion you have to add a third point:\n>\n> * the branch has no modifications what so ever\n> * the branch is set up to auto-merge with the particular branch\n> fetched from the particular remote\n> \t\t\t\tAND\n> * the user set a config option to always autofastfoward if the above\n> conditions are true! This could be implemented as a global \n> option with\n> a per branch overwrite.\n\nI (and, as I understood, Andreas, too) want to change the\ndefault. Because we believe that git would be easier to use\nin workflows based on a shared repository.\n\nBut if we fail to convince the list, maybe a global\nconfiguration variable that configures \"git pull\" to autoforward\nbranches as propose would be a nearly equally good solution.\n\nHowever, I think it is dangerous to introduce many of such\nconfiguration options. Explaining the behaviour of git will\nbecome harder. The behaviour will become dependent on the\nlocal configuration and eventually the first question before\nanswering a question will be \"send me the output of 'git config\n--list'. I need to see how your git is configured.\"\n\n\tSteffen\n"},{"id":"57109","messageId":"471FBF29.8030802@op5.se","threadId":"10194","inReplyTo":"20071024212854.GB6069@xp.machine.xx","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-24T21:54:49Z","receivedAt":"2007-10-24T21:54:49Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Peter Baumann wrote:\n> On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:\n>> J. Bruce Fields wrote:\n>>> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:\n>>>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n>>>>\n>>>>>> I want git pull to work like git push.\n>>>>> That strikes me as a less complete solution, since it only helps in the\n>>>>> case where the other branches all happen to be unmodified locally (hence\n>>>>> can be fast-forwarded). In other cases the \"git push\" will still emit a\n>>>>> spurious error.\n>>>> Well, but then there's something you should really think\n>>>> about.\n>>> Perhaps, but not necessarily; you may have some branches with local\n>>> changes that you're content to leave unpushed (and un-updated).\n>> Sure, but that won't change. The only thing I'm proposing is that\n>> local copies of remote branches are automatically fast-forwarded\n>> on every pull, but only if\n>>\n>> * the branch has no modifications what so ever\n>> * the branch is set up to auto-merge with the particular branch\n>> fetched from the particular remote\n>>\n>> I really don't see any downsides what so ever with this. Those\n>> of you who do, please enlighten me.\n>>\n> \n> You can't check what got added in your pull, e.g you can't review the new\n> code with something like\n> \n> \tgitk next..origin/next\n> \n\nThat's what git-fetch is for.\n\n> I often do something like this, just to see what got changed. So at least\n> in my opinion you have to add a third point:\n> \n> * the branch has no modifications what so ever\n> * the branch is set up to auto-merge with the particular branch\n> fetched from the particular remote\n> \t\t\t\tAND\n> * the user set a config option to always autofastfoward if the above\n> conditions are true! This could be implemented as a global option with\n> a per branch overwrite.\n> \n\nI'd be fine with that, except I think it's fairly dangerous to have\ndifferent defaults. The two first points are sort of the core of the\ncase I've been arguing all along.\n\n> Only if this option is added so a user can mark a branch to never\n> autofastforward (but it is still possible to have an auto-merge config) you won't\n> loose valuable information.\n> \n\nSure. I was thinking something along these lines:\n\n[branch \"foo\"]\n\tremote = bar\n\tmerge = some-branch\n\tautofastforward = false\n\n\nOr use git-fetch. git-pull is \"fetch + merge\". Conceptually, I don't\nthink it'll be any problem what so ever telling anyone that the branches\nthat aren't currently checked out get merged automatically only if they\nresult in a fast-forward.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57111","messageId":"Pine.LNX.4.64.0710242258201.25221@racer.site","threadId":"10194","inReplyTo":"05B279A2-98A3-45F1-9661-AB361F7CAA37@zib.de","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-24T22:14:25Z","receivedAt":"2007-10-24T22:14:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 24 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 24, 2007, at 11:28 PM, Peter Baumann wrote:\n> \n> > You can't check what got added in your pull, e.g you can't review the \n> > new code with something like\n> > \n> > \tgitk next..origin/next\n> \n> You're not forced to pull. Just use \"git fetch\" if you want to do this. \n> Or is something missing if you'd be limited to \"git fetch\"?\n\nI am more concerned about having very fuzzy meanings of our nomenclature. \nAs of now, \"pull = fetch + merge\". You want to change that, and I am sure \nthat it is harder to explain, Andreas' insistence on my being wrong \nnotwithstanding.\n\nWhenever I told people \"pull = fetch + merge\", they got it. Often I would \nstart a talk about git by introducing distributed development. By stating \nthat working in a working directory is already forking, only without \ncommiting. Then I'd go into details, by saying that there are multiple \nrepositories, and that you can update local copies of the remote branches \nby \"git fetch\". And you can merge by \"git merge\". And then I would write \ndown on the blackboard -- the first written thing in my talk! -- pull = \nfetch + merge.\n\nMy \"pupils\" _always_ liked the preciseness of the nomenclature. And they \nmade many less mistakes because they had a clear mental model of what is \nremote, and what is local. And that local branches are always forks.\n\n> > I often do something like this, just to see what got changed. So at \n> > least in my opinion you have to add a third point:\n> > \n> > * the branch has no modifications what so ever\n> > * the branch is set up to auto-merge with the particular branch\n> > fetched from the particular remote\n> > \t\t\t\tAND\n> > * the user set a config option to always autofastfoward if the above\n> > conditions are true! This could be implemented as a global option with\n> > a per branch overwrite.\n> \n> I (and, as I understood, Andreas, too) want to change the default. \n> Because we believe that git would be easier to use in workflows based on \n> a shared repository.\n\nAnd here I have to disagree strongly. In a workflow based on a shared \nrepository, you do not want to merge. You want to rebase. First thing \nyou do when switching to another branch is fetch + rebase (that's why I \nwant an option to \"pull --rebase\" other branches).\n\nBut _even if_ you merge instead of rebase, I fail to see how the current \nsituation is different from CVS (which many people maintain is _easier_ \nthan gi), where first thing you do is to \"cvs update\". Just for git it is \n\"git pull\".\n\nBut I think I have to drive my message home again: if what you desire \nbecomes reality, you take away the clear distinction between local \nand remote branches. In fact, those branches are neither local (because \nthe next pull will automatically update them with remote changes, but \n_only_ if they fast-forward) nor remote (because you plan to work on them \nlocally).\n\nBut here is a proposal which should make you and your developers happy, \n_and_ should be even easier to explain:\n\nWork with topic branches. And when you're done, delete them.\n\nSo the beginning of the day could look like this:\n\n\tgit fetch\n\tgit checkout -b todays-topic origin/master\n\n\t[hack hack hack]\n\t[test test test]\n\t[debug debug debug]\n\t[occasionally commit]\n\t[occasionally git rebase -i origin/master]\n\nand the end of the topic\n\n\tgit branch -M master\n\tgit push origin master\n\nIf you should not be ready to push by the end of the day, no need to \nworry. Just stay on that topic branch, and before pushing, do\n\n\tgit fetch\n\tgit rebase origin/master\n\nIn _every_ case where I explained git, I found that people appreciated the \ntwo-step procedures (like you will find in the examples I showed you \nabove): one git command to work locally, and one to push/fetch to/from \norigin.\n\nCiao,\nDscho\n"},{"id":"57112","messageId":"Pine.LNX.4.64.0710242315310.25221@racer.site","threadId":"10194","inReplyTo":"471FBF29.8030802@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-24T22:17:08Z","receivedAt":"2007-10-24T22:17:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 24 Oct 2007, Andreas Ericsson wrote:\n\n> Conceptually, I don't think it'll be any problem what so ever telling \n> anyone that the branches that aren't currently checked out get merged \n> automatically only if they result in a fast-forward.\n\nIt would be a matter of seconds until someone asks \"why only \nfast-forwards? Would it not be _much_ better to merge _always_? Stupid \ngit.\"\n\nAnd all because the concept of \"local\" vs \"remote\" was blurred.\n\nCiao,\nDscho\n"},{"id":"57113","messageId":"008A7EF9-6F58-47AE-9AA0-B466797F6B1D@zib.de","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710242258201.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-24T22:33:37Z","receivedAt":"2007-10-24T22:33:37Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n\n> And here I have to disagree strongly. In a workflow based on a shared\n> repository, you do not want to merge. You want to rebase. First \n> thing\n> you do when switching to another branch is fetch + rebase (that's \n> why I\n> want an option to \"pull --rebase\" other branches).\n>\n> But _even if_ you merge instead of rebase, I fail to see how the \n> current\n> situation is different from CVS (which many people maintain is \n> _easier_\n> than gi), where first thing you do is to \"cvs update\". Just for \n> git it is\n> \"git pull\".\n>\n> But I think I have to drive my message home again: if what you desire\n> becomes reality, you take away the clear distinction between local\n> and remote branches. In fact, those branches are neither local \n> (because\n> the next pull will automatically update them with remote changes, but\n> _only_ if they fast-forward) nor remote (because you plan to work \n> on them\n> locally).\n\nExactly, because I do not work on those branches alone. These\nare _shared_ branches. I can work on such a branch with a\ngroup of developers. I'm willing to accept this bit of chaos.\n\nYour rebase workflow is not possible if more than one dev wants\nto work on the topic branch together.\n\nEventually you can linearize such a topic branch using rebase.\nBut you need to agree first that everyone else needs to delete\nthe branch.\n\n\n\n> But here is a proposal which should make you and your developers \n> happy,\n> _and_ should be even easier to explain:\n>\n> Work with topic branches. And when you're done, delete them.\n\nAgain, if you want to share the topic branch the situation gets\nmore complex.\n\nI absolutely agree that for purely local work topic branches that\nare deleted before pushing are a good solution.\n\n\n> So the beginning of the day could look like this:\n>\n> \tgit fetch\n> \tgit checkout -b todays-topic origin/master\n>\n> \t[hack hack hack]\n> \t[test test test]\n> \t[debug debug debug]\n> \t[occasionally commit]\n> \t[occasionally git rebase -i origin/master]\n>\n> and the end of the topic\n>\n> \tgit branch -M master\n> \tgit push origin master\n>\n> If you should not be ready to push by the end of the day, no need to\n> worry. Just stay on that topic branch, and before pushing, do\n>\n> \tgit fetch\n> \tgit rebase origin/master\n>\n> In _every_ case where I explained git, I found that people \n> appreciated the\n> two-step procedures (like you will find in the examples I showed you\n> above): one git command to work locally, and one to push/fetch to/from\n> origin.\n\nMaybe. I know git quite well now and in a shared workflow \"git pull\"\nwith auto-fast-forward would help me. I often need to run \"for each\nlocal branch: git checkout ; git merge\" to get rid of the errors\nreported by \"git push\".\n\n\tSteffen\n"},{"id":"57114","messageId":"20071024223815.GN29830@fieldses.org","threadId":"10194","inReplyTo":"008A7EF9-6F58-47AE-9AA0-B466797F6B1D@zib.de","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-24T22:38:15Z","receivedAt":"2007-10-24T22:38:15Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Oct 25, 2007 at 12:33:37AM +0200, Steffen Prohaska wrote:\n> Maybe. I know git quite well now and in a shared workflow \"git pull\"\n> with auto-fast-forward would help me. I often need to run \"for each\n> local branch: git checkout ; git merge\" to get rid of the errors\n> reported by \"git push\".\n\nHm. There's gotta be more efficient ways to do that. Maybe \"git push .\norigin/branch:branch\" for each local \"branch\"?\n\nBut I'm still a little confused why you don't just want to \"git push\nname-of-branch\" and avoid the whole problem.\n\n--b.\n"},{"id":"57115","messageId":"B3A195E0-84E7-4844-B939-98BC352C91A1@zib.de","threadId":"10194","inReplyTo":"20071024223815.GN29830@fieldses.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-24T22:51:09Z","receivedAt":"2007-10-24T22:51:09Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 25, 2007, at 12:38 AM, J. Bruce Fields wrote:\n\n> On Thu, Oct 25, 2007 at 12:33:37AM +0200, Steffen Prohaska wrote:\n>> Maybe. I know git quite well now and in a shared workflow \"git pull\"\n>> with auto-fast-forward would help me. I often need to run \"for each\n>> local branch: git checkout ; git merge\" to get rid of the errors\n>> reported by \"git push\".\n>\n> Hm. There's gotta be more efficient ways to do that. Maybe \"git \n> push .\n> origin/branch:branch\" for each local \"branch\"?\n>\n> But I'm still a little confused why you don't just want to \"git push\n> name-of-branch\" and avoid the whole problem.\n\nThere are two points:\n\n- The current implementation of \"git push\" creates a remote branch\n if it does not yet exist. I want a safety net: \"git push\" only pushes\n if the remote branch already exists. In a sense \"git push\" is safer\n than \"git push branch-with-typo\". I use \"git push branchname\"\n exclusively for _creating_ new branches on the remote.\n\n- Sometimes I updated two local branches and want to push. \"git push\"\n just works.\n\nI started to believe that \"git push\" should always do the right\nthing. Maybe it is not possible, but actually \"git push\" always\ndoes the right thing for me if I ignore the error messages\nabout local branches that need merging. I tend to merge all\nsuch branches right away, although it is a bit of a hassel.\nOtherwise, there will be a day I'll miss an important error.\n\nWhat concerns me more is how to explain the behaviour to others.\nRight now, I can't tell them that \"git push\" just works but need\nto go into a lot of details.\n\n\tSteffen\n"},{"id":"57116","messageId":"8fe92b430710241627v3ec51b20qf0b4e60356336363@mail.gmail.com","threadId":"10194","inReplyTo":"20071024113123.GB6459@diana.vm.bytemark.co.uk","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-24T23:27:10Z","receivedAt":"2007-10-24T23:27:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/24/07, Karl Hasselström wrote:\n> On 2007-10-24 13:04:01 +0200, Jakub Narebski wrote:\n>\n>> By the way, there is SRPM for StGIT in\n>> http://homepage.ntlworld.com/cmarinas/stgit/ (I need it because I\n>> have Python 2.4), but it is not listed on downloads page...\n>\n> I'll leave the webpage question to Catalin, but I'm curious about the\n> Python version remark. What exactly is the problem?\n\nIf I remember correctly the StGIT RPM requires python 2.5\n(and is build using python 2.5, so install with --force doesn't work).\n\nBTW. SRPM is better than tar.gz because I can simply do \"rpmbuild\n--rebuild\" to get binary RPM to install.\n\n-- \nJakub Narebski\n"},{"id":"57117","messageId":"Pine.LNX.4.64.0710250021430.25221@racer.site","threadId":"10194","inReplyTo":"008A7EF9-6F58-47AE-9AA0-B466797F6B1D@zib.de","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-24T23:28:39Z","receivedAt":"2007-10-24T23:28:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n> \n> > But I think I have to drive my message home again: if what you desire \n> > becomes reality, you take away the clear distinction between local and \n> > remote branches. In fact, those branches are neither local (because \n> > the next pull will automatically update them with remote changes, but \n> > _only_ if they fast-forward) nor remote (because you plan to work on \n> > them locally).\n> \n> Exactly, because I do not work on those branches alone. These are \n> _shared_ branches. I can work on such a branch with a group of \n> developers. I'm willing to accept this bit of chaos.\n\nIt is not just a chaos. I see a serious problem here. On _your_ \ncomputer, you do _not_ have a shared branch. Which is visible _even_ in \nyour modified work flow when you have unpushed changes.\n\nSo your desired illusion that your local branches are anything but local \nbranches will never be perfect enough.\n\n> Your rebase workflow is not possible if more than one dev wants to work \n> on the topic branch together.\n\nWhy not? I do it all the time. CVS users do it all the time, for that \nmatter.\n\n> Eventually you can linearize such a topic branch using rebase. But you \n> need to agree first that everyone else needs to delete the branch.\n\nNo, you can linearize your branch already while cleaning up your local \nbranch before continuing to work on the topic.\n\n> > But here is a proposal which should make you and your developers \n> > happy, _and_ should be even easier to explain:\n> > \n> > Work with topic branches. And when you're done, delete them.\n> \n> Again, if you want to share the topic branch the situation gets\n> more complex.\n\nHardly so. In my proposed solution to your problem, there is nothing \nwhich prevents you from working off of another branch than \"master\".\n\n> > So the beginning of the day could look like this:\n> > \n> > \tgit fetch\n> > \tgit checkout -b todays-topic origin/master\n> > \n> > \t[hack hack hack]\n> > \t[test test test]\n> > \t[debug debug debug]\n> > \t[occasionally commit]\n> > \t[occasionally git rebase -i origin/master]\n> > \n> > and the end of the topic\n> > \n> > \tgit branch -M master\n> > \tgit push origin master\n> > \n> > If you should not be ready to push by the end of the day, no need to\n> > worry. Just stay on that topic branch, and before pushing, do\n> > \n> > \tgit fetch\n> > \tgit rebase origin/master\n> > \n> > In _every_ case where I explained git, I found that people appreciated the\n> > two-step procedures (like you will find in the examples I showed you\n> > above): one git command to work locally, and one to push/fetch to/from\n> > origin.\n> \n> Maybe. I know git quite well now and in a shared workflow \"git pull\"\n> with auto-fast-forward would help me. I often need to run \"for each\n> local branch: git checkout ; git merge\" to get rid of the errors\n> reported by \"git push\".\n\nThe problem I see here: you know git quite well. Others don't, and will \nbe mightily confused why pull updates local branches sometimes, and \nsometimes not.\n\nCiao,\nDscho\n"},{"id":"57119","messageId":"8fe92b430710241648j609d4d00x121836001a69d1e6@mail.gmail.com","threadId":"10194","inReplyTo":"471F9FD1.6080002@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-10-24T23:48:12Z","receivedAt":"2007-10-24T23:48:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On 10/24/07, Andreas Ericsson wrote:\n\n> git pull. Not git push. git pull operates on one working branch\n> at a time (by default), whereas git push uploads and fast-forwards\n> all the common branches (by default). I want git pull to work like\n> git push.\n\ngit push is opposite (almost) to git fetch, not to git pull.\n\n-- \nJakub Narebski\n"},{"id":"57140","messageId":"79366145-3C91-4417-B62C-FFF9EC452076@zib.de","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710250021430.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-25T06:02:57Z","receivedAt":"2007-10-25T06:02:57Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote:\n\n> On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n>\n>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n>>\n>>> But I think I have to drive my message home again: if what you \n>>> desire\n>>> becomes reality, you take away the clear distinction between \n>>> local and\n>>> remote branches. In fact, those branches are neither local (because\n>>> the next pull will automatically update them with remote changes, \n>>> but\n>>> _only_ if they fast-forward) nor remote (because you plan to work on\n>>> them locally).\n>>\n>> Exactly, because I do not work on those branches alone. These are\n>> _shared_ branches. I can work on such a branch with a group of\n>> developers. I'm willing to accept this bit of chaos.\n>\n> It is not just a chaos. I see a serious problem here. On _your_\n> computer, you do _not_ have a shared branch. Which is visible \n> _even_ in\n> your modified work flow when you have unpushed changes.\n>\n> So your desired illusion that your local branches are anything but \n> local\n> branches will never be perfect enough.\n\nOk, there is not a fundamental difference between local branches\nthat automatically merge from remotes and local branches that\nare purely local and _never_ merge anything automatically. Both\nare only local branches.\n\nBut these two types of branches already behave differently when\nI call \"git pull\". There is already some kind of \"illusion\"\nthat some local branches are more tightly connected to remote\nbranches than others.\n\n\"git pull\" could help to make the illusion even better. The\nillusion would be better if it was easier to keep the heads\nof the local branches near to the heads of branches they\nautomatically merge from, as long as this is easily possible.\n\n\n>> Your rebase workflow is not possible if more than one dev wants to \n>> work\n>> on the topic branch together.\n>\n> Why not? I do it all the time. CVS users do it all the time, for \n> that\n> matter.\n\nYou're right. You can rebase your local changes on top of the new\nshared remote head. And this is probably the best thing you can do\nto get a clean history. Maybe it should be easier.\n\nSo, do I understand correctly, what you propose is:\n- never merge but only rebase\n- Due to lacking support for this in \"git pull\", never use\n git pull when working with shared branches but instead _always_ use\n \"git fetch; git rebase origin/\".\n\nSo you say that one of the first messages in \"git for CVS users\",\n\"The equivalent of cvs update is git pull origin\" [1], is wrong.\nI don't think I'm able to sell your proposed workflow with the current\ndocumentation. But maybe I try if I'm absolutely convinced that it\nis superior.\n\n[1] http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html\n\n\n>>> But here is a proposal which should make you and your developers\n>>> happy, _and_ should be even easier to explain:\n>>>\n>>> Work with topic branches. And when you're done, delete them.\n>>\n>> Again, if you want to share the topic branch the situation gets\n>> more complex.\n>\n> Hardly so. In my proposed solution to your problem, there is nothing\n> which prevents you from working off of another branch than \"master\".\n\nWell if you have several local branches checked out that are\nshared with others you run into the \"git push\" problem again ...\n(see below at git push origin master).\n\n\n>>> So the beginning of the day could look like this:\n>>>\n>>> \tgit fetch\n>>> \tgit checkout -b todays-topic origin/master\n>>>\n>>> \t[hack hack hack]\n>>> \t[test test test]\n>>> \t[debug debug debug]\n>>> \t[occasionally commit]\n>>> \t[occasionally git rebase -i origin/master]\n>>>\n>>> and the end of the topic\n>>>\n>>> \tgit branch -M master\n\nIsn't this a bit dangerous? It forces to overwrite master\nno matter what's on it. You don't see diffstats nor a fast\nforward message that confirms what you're doing.\n\n\n>>> \tgit push origin master\n\nI'd like to see \"git push\" here. But to make this work without\nerror you'd need to _delete_ master after you pushed. Otherwise\nit could happen that you later work on a different shared\nbranch and \"git push\" would complain about master. \"git push\"\nwould recommend to do a \"git pull\" and we're back where the\ndiscussion started.\n\nOr do you propose to delete master at this point? That is do\nyou propose to _never_ have remote branches checked out locally.\nExcept for a very short period when you do\n\n git branch -m \n git push origin \n git checkout do-not-work-here\n git branch -D \n\n\n>>> If you should not be ready to push by the end of the day, no need to\n>>> worry. Just stay on that topic branch, and before pushing, do\n>>>\n>>> \tgit fetch\n>>> \tgit rebase origin/master\n>>>\n>>> In _every_ case where I explained git, I found that people \n>>> appreciated the\n>>> two-step procedures (like you will find in the examples I showed you\n>>> above): one git command to work locally, and one to push/fetch to/ \n>>> from\n>>> origin.\n>>\n>> Maybe. I know git quite well now and in a shared workflow \"git pull\"\n>> with auto-fast-forward would help me. I often need to run \"for each\n>> local branch: git checkout ; git merge\" to get rid of the errors\n>> reported by \"git push\".\n>\n> The problem I see here: you know git quite well. Others don't, and \n> will\n> be mightily confused why pull updates local branches sometimes, and\n> sometimes not.\n\nBut it already happens now. \"git pull\" sometimes merges a\nremote branch (--track) and sometimes it reports an error that\nis fails to do so (--no-track). It would only do more work\nautomatically in the future and report appropriate warnings\nor errors if it runs into a problem.\n\n\tSteffen\n"},{"id":"57141","messageId":"20071025061054.GA23052@diana.vm.bytemark.co.uk","threadId":"10194","inReplyTo":"8fe92b430710241627v3ec51b20qf0b4e60356336363@mail.gmail.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-25T06:10:54Z","receivedAt":"2007-10-25T06:10:54Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-25 01:27:10 +0200, Jakub Narebski wrote:\n\n> On 10/24/07, Karl Hasselström wrote:\n>\n> > On 2007-10-24 13:04:01 +0200, Jakub Narebski wrote:\n> >\n> > > By the way, there is SRPM for StGIT in\n> > > http://homepage.ntlworld.com/cmarinas/stgit/ (I need it because\n> > > I have Python 2.4), but it is not listed on downloads page...\n> >\n> > I'll leave the webpage question to Catalin, but I'm curious about\n> > the Python version remark. What exactly is the problem?\n>\n> If I remember correctly the StGIT RPM requires python 2.5 (and is\n> build using python 2.5, so install with --force doesn't work).\n\nHmm. That's overkill, considering that only 2.4 is actually required\n(and until recently, we tried to be careful to only require 2.3).\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"57145","messageId":"47204297.5050109@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710250021430.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T07:15:35Z","receivedAt":"2007-10-25T07:15:35Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n> \n>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n>>\n>>> But I think I have to drive my message home again: if what you desire \n>>> becomes reality, you take away the clear distinction between local and \n>>> remote branches. In fact, those branches are neither local (because \n>>> the next pull will automatically update them with remote changes, but \n>>> _only_ if they fast-forward) nor remote (because you plan to work on \n>>> them locally).\n>> Exactly, because I do not work on those branches alone. These are \n>> _shared_ branches. I can work on such a branch with a group of \n>> developers. I'm willing to accept this bit of chaos.\n> \n> It is not just a chaos. I see a serious problem here. On _your_ \n> computer, you do _not_ have a shared branch. Which is visible _even_ in \n> your modified work flow when you have unpushed changes.\n> \n\nOfcourse it is. People might pull from it. That's the whole point of a\ndistributed model.\n\n> So your desired illusion that your local branches are anything but local \n> branches will never be perfect enough.\n> \n>> Your rebase workflow is not possible if more than one dev wants to work \n>> on the topic branch together.\n> \n> Why not? I do it all the time. CVS users do it all the time, for that \n> matter.\n> \n\nFor 200 branches at a time, where any of them might have changed? Do they\n*really* go into all those branches and make really, really sure they run\ngit pull before they ever do anything? Isn't there a teensy weensy risk of\nthem forgetting that sometime when they really meant to do it?\n\nOn the other hand, if they absolutely *must* fork a branch at a specific\npoint in history (rather than \"the latest published work this branch has\"),\nwon't they run gitk/qgit/git-log/whatever, regardless of where their branch\nhead is?\n\n> \n> The problem I see here: you know git quite well. Others don't, and will \n> be mightily confused why pull updates local branches sometimes, and \n> sometimes not.\n\nDo you know this, or are you just guessing? I'm getting the exact same\nconfusion with the current behaviour. \"Why the hell doesn't git update\nall the branches I told the damn stupid tool to auto-merge when I pull?\"\nfrequently echoes around the office. My co-workers aren't interested in\nlearning about git internals, or its reasons for doing what it does.\nThey don't give a damn about local vs remote namespaces for their branches.\nThey want to get some work done the smoothest way possible, but with our\nsmall forest of repositories and the bushel of branches in each repo\nmakes life difficult for them, because they just can't imagine that\ngit doesn't do what they told it to, which is \"this branch tracks that\".\nThey may work on \"this\", but still want it to track \"that\" so they don't\nhave to run \"git-update-all.sh\", or \"git-walk-everything.sh\" or any other\nof a dozen small and near-identical scripts floating around the office.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57146","messageId":"20071025072635.GC6069@xp.machine.xx","threadId":"10194","inReplyTo":"471FBF29.8030802@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-10-25T07:26:35Z","receivedAt":"2007-10-25T07:26:35Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Oct 24, 2007 at 11:54:49PM +0200, Andreas Ericsson wrote:\n> Peter Baumann wrote:\n>> On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:\n>>> J. Bruce Fields wrote:\n>>>> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:\n>>>>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:\n>>>>>\n>>>>>>> I want git pull to work like git push.\n>>>>>> That strikes me as a less complete solution, since it only helps in \n>>>>>> the\n>>>>>> case where the other branches all happen to be unmodified locally \n>>>>>> (hence\n>>>>>> can be fast-forwarded). In other cases the \"git push\" will still emit \n>>>>>> a\n>>>>>> spurious error.\n>>>>> Well, but then there's something you should really think\n>>>>> about.\n>>>> Perhaps, but not necessarily; you may have some branches with local\n>>>> changes that you're content to leave unpushed (and un-updated).\n>>> Sure, but that won't change. The only thing I'm proposing is that\n>>> local copies of remote branches are automatically fast-forwarded\n>>> on every pull, but only if\n>>>\n>>> * the branch has no modifications what so ever\n>>> * the branch is set up to auto-merge with the particular branch\n>>> fetched from the particular remote\n>>>\n>>> I really don't see any downsides what so ever with this. Those\n>>> of you who do, please enlighten me.\n>>>\n>> You can't check what got added in your pull, e.g you can't review the new\n>> code with something like\n>> \tgitk next..origin/next\n>\n> That's what git-fetch is for.\n>\n\nIf I run git pull and have a auto-merge setup, I would merge the\nremote side into my local branch. Then doing\n\n\tgitk ORIG_HEAD..\n\ndoes the trick for to review what got added _and_ merged into my local\nbranch. I can't use this for other local branches not checked out. And as\nI normally want to merge, your suggested behaviour is fine with me *IFF*\nit is configurable _per_ branch.\n\n>> I often do something like this, just to see what got changed. So at least\n>> in my opinion you have to add a third point:\n>> * the branch has no modifications what so ever\n>> * the branch is set up to auto-merge with the particular branch\n>> fetched from the particular remote\n>> \t\t\t\tAND\n>> * the user set a config option to always autofastfoward if the above\n>> conditions are true! This could be implemented as a global option with\n>> a per branch overwrite.\n>\n> I'd be fine with that, except I think it's fairly dangerous to have\n> different defaults. The two first points are sort of the core of the\n> case I've been arguing all along.\n>\n\nI aggree. And thats why I think your autofastforward should be set to\n\"false\" per default, so that the distinction between local and remote\nbranches would still be clearly defined. Changing this would confuse new\nusers a lot more, me thinks.\n\nBut having the option for power users sounds fine!\n\n>> Only if this option is added so a user can mark a branch to never\n>> autofastforward (but it is still possible to have an auto-merge config) \n>> you won't\n>> loose valuable information.\n>\n> Sure. I was thinking something along these lines:\n>\n> [branch \"foo\"]\n> \tremote = bar\n> \tmerge = some-branch\n> \tautofastforward = false\n>\n\nThats exactlcy what I had in mind. Maybe and a\n\n[core]\n\tglobal_autofastforward = true\n\nso you could have a sane default for every branch which is missing the\nautofastforward statement. (or make it per [remote \"foo\"] ?)\n\n> Or use git-fetch. git-pull is \"fetch + merge\". Conceptually, I don't\n> think it'll be any problem what so ever telling anyone that the branches\n> that aren't currently checked out get merged automatically only if they\n> result in a fast-forward.\n>\n\nI'm not so sure about that.\n\n-Peter\n"},{"id":"57147","messageId":"20071025073102.GD6069@xp.machine.xx","threadId":"10194","inReplyTo":"47204297.5050109@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-10-25T07:31:02Z","receivedAt":"2007-10-25T07:31:02Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Thu, Oct 25, 2007 at 09:15:35AM +0200, Andreas Ericsson wrote:\n> Johannes Schindelin wrote:\n>> Hi,\n>> On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n>>>\n>>>> But I think I have to drive my message home again: if what you desire \n>>>> becomes reality, you take away the clear distinction between local and \n>>>> remote branches. In fact, those branches are neither local (because the \n>>>> next pull will automatically update them with remote changes, but _only_ \n>>>> if they fast-forward) nor remote (because you plan to work on them \n>>>> locally).\n>>> Exactly, because I do not work on those branches alone. These are \n>>> _shared_ branches. I can work on such a branch with a group of \n>>> developers. I'm willing to accept this bit of chaos.\n>> It is not just a chaos. I see a serious problem here. On _your_ \n>> computer, you do _not_ have a shared branch. Which is visible _even_ in \n>> your modified work flow when you have unpushed changes.\n>\n> Ofcourse it is. People might pull from it. That's the whole point of a\n> distributed model.\n>\n>> So your desired illusion that your local branches are anything but local \n>> branches will never be perfect enough.\n>>> Your rebase workflow is not possible if more than one dev wants to work \n>>> on the topic branch together.\n>> Why not? I do it all the time. CVS users do it all the time, for that \n>> matter.\n>\n> For 200 branches at a time, where any of them might have changed? Do they\n> *really* go into all those branches and make really, really sure they run\n> git pull before they ever do anything? Isn't there a teensy weensy risk of\n> them forgetting that sometime when they really meant to do it?\n>\n> On the other hand, if they absolutely *must* fork a branch at a specific\n> point in history (rather than \"the latest published work this branch has\"),\n> won't they run gitk/qgit/git-log/whatever, regardless of where their branch\n> head is?\n>\n>> The problem I see here: you know git quite well. Others don't, and will \n>> be mightily confused why pull updates local branches sometimes, and \n>> sometimes not.\n>\n> Do you know this, or are you just guessing? I'm getting the exact same\n> confusion with the current behaviour. \"Why the hell doesn't git update\n> all the branches I told the damn stupid tool to auto-merge when I pull?\"\n> frequently echoes around the office. My co-workers aren't interested in\n> learning about git internals, or its reasons for doing what it does.\n> They don't give a damn about local vs remote namespaces for their branches.\n> They want to get some work done the smoothest way possible, but with our\n> small forest of repositories and the bushel of branches in each repo\n> makes life difficult for them, because they just can't imagine that\n> git doesn't do what they told it to, which is \"this branch tracks that\".\n> They may work on \"this\", but still want it to track \"that\" so they don't\n> have to run \"git-update-all.sh\", or \"git-walk-everything.sh\" or any other\n> of a dozen small and near-identical scripts floating around the office.\n>\n\nWhat actually wonders me why you guys do have 200 local branches. I\nusually just create a local branch from the remote IFF I'd like to do some\nwork on it. And for inspecting a remote branch, a detached HEAD works just as\nfine ...\n\n-Peter\n"},{"id":"57148","messageId":"472048EB.1000707@op5.se","threadId":"10194","inReplyTo":"8fe92b430710241648j609d4d00x121836001a69d1e6@mail.gmail.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T07:42:35Z","receivedAt":"2007-10-25T07:42:35Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> On 10/24/07, Andreas Ericsson wrote:\n> \n>> git pull. Not git push. git pull operates on one working branch\n>> at a time (by default), whereas git push uploads and fast-forwards\n>> all the common branches (by default). I want git pull to work like\n>> git push.\n> \n> git push is opposite (almost) to git fetch, not to git pull.\n> \n\nNot to an end user that has no idea or desire to learn about git remotes\nor anything else. They see \"ok, push updates all the remote branches, but\nonly if it's a fast-forward\". They also see \"righto, git pull updates all\nthe local branches, and even merges and does other funny things\", but they\n*don't* understand why git-pull (in their eyes) only update ONE branch that\nthey can actually check out. From a technical standpoint, fetch and push\nare the same, but from the user perspective, push and pull seem much more\nalike.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57149","messageId":"47204C6D.3020900@op5.se","threadId":"10194","inReplyTo":"20071025073102.GD6069@xp.machine.xx","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T07:57:33Z","receivedAt":"2007-10-25T07:57:33Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Peter Baumann wrote:\n> On Thu, Oct 25, 2007 at 09:15:35AM +0200, Andreas Ericsson wrote:\n>> Johannes Schindelin wrote:\n>>> Hi,\n>>> On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n>>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n>>>>\n>>>>> But I think I have to drive my message home again: if what you desire \n>>>>> becomes reality, you take away the clear distinction between local and \n>>>>> remote branches. In fact, those branches are neither local (because the \n>>>>> next pull will automatically update them with remote changes, but _only_ \n>>>>> if they fast-forward) nor remote (because you plan to work on them \n>>>>> locally).\n>>>> Exactly, because I do not work on those branches alone. These are \n>>>> _shared_ branches. I can work on such a branch with a group of \n>>>> developers. I'm willing to accept this bit of chaos.\n>>> It is not just a chaos. I see a serious problem here. On _your_ \n>>> computer, you do _not_ have a shared branch. Which is visible _even_ in \n>>> your modified work flow when you have unpushed changes.\n>> Ofcourse it is. People might pull from it. That's the whole point of a\n>> distributed model.\n>>\n>>> So your desired illusion that your local branches are anything but local \n>>> branches will never be perfect enough.\n>>>> Your rebase workflow is not possible if more than one dev wants to work \n>>>> on the topic branch together.\n>>> Why not? I do it all the time. CVS users do it all the time, for that \n>>> matter.\n>> For 200 branches at a time, where any of them might have changed? Do they\n>> *really* go into all those branches and make really, really sure they run\n>> git pull before they ever do anything? Isn't there a teensy weensy risk of\n>> them forgetting that sometime when they really meant to do it?\n>>\n>> On the other hand, if they absolutely *must* fork a branch at a specific\n>> point in history (rather than \"the latest published work this branch has\"),\n>> won't they run gitk/qgit/git-log/whatever, regardless of where their branch\n>> head is?\n>>\n>>> The problem I see here: you know git quite well. Others don't, and will \n>>> be mightily confused why pull updates local branches sometimes, and \n>>> sometimes not.\n>> Do you know this, or are you just guessing? I'm getting the exact same\n>> confusion with the current behaviour. \"Why the hell doesn't git update\n>> all the branches I told the damn stupid tool to auto-merge when I pull?\"\n>> frequently echoes around the office. My co-workers aren't interested in\n>> learning about git internals, or its reasons for doing what it does.\n>> They don't give a damn about local vs remote namespaces for their branches.\n>> They want to get some work done the smoothest way possible, but with our\n>> small forest of repositories and the bushel of branches in each repo\n>> makes life difficult for them, because they just can't imagine that\n>> git doesn't do what they told it to, which is \"this branch tracks that\".\n>> They may work on \"this\", but still want it to track \"that\" so they don't\n>> have to run \"git-update-all.sh\", or \"git-walk-everything.sh\" or any other\n>> of a dozen small and near-identical scripts floating around the office.\n>>\n> \n> What actually wonders me why you guys do have 200 local branches. I\n> usually just create a local branch from the remote IFF I'd like to do some\n> work on it. And for inspecting a remote branch, a detached HEAD works just as\n> fine ...\n> \n\n50+ repositories, with stable, testing and maint branches. Some repos have more\nthan that, so it amounts to roughly 200 branches. Each branch can be modified by\nanyone (we're a small company - everyone still works everywhere), but all changes\nshould be done to the tip of the upstream branch. Especially for maint this is a\nbit of a problem, since we frequently have consultants out and about, and they\nsometimes find a bug that they commit locally to their own repo. They're in a\nhurry though, and have no connection to the mothership repo so they can't git-pull\nto get up to date. They aren't exactly developers, but savvy enough to fix a few\nsimple bugs, but the concept of the locally-modifiable branches not being updated\nto their remote-tracking counterparts with each git-pull is just incomprehensible\nto them. To me, that suggests that we're doing something wrong.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57150","messageId":"47204ECA.7040309@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710242315310.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T08:07:38Z","receivedAt":"2007-10-25T08:07:38Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 24 Oct 2007, Andreas Ericsson wrote:\n> \n>> Conceptually, I don't think it'll be any problem what so ever telling \n>> anyone that the branches that aren't currently checked out get merged \n>> automatically only if they result in a fast-forward.\n> \n> It would be a matter of seconds until someone asks \"why only \n> fast-forwards? Would it not be _much_ better to merge _always_? Stupid \n> git.\"\n> \n> And all because the concept of \"local\" vs \"remote\" was blurred.\n> \n\nIt's already blurred, since we have git-pull instead of just git-fetch.\npull is the dwim version of fetch for anyone who isn't frequently pulling\nfrom multiple repos that aren't configured as remotes (99% of git's users).\nIt really is. You configure it to merge this and that branch to those and\nthese branches. Sometimes it does and sometimes it doesn't, and the decision\nis based on what branch you're currently on.\n\nOnly git-fetch has the clear local vs remote distinction, because it *never*\nmerges anything.\n\nOn a side-note, I'm starting to see why hg has gotten such a user-base.\nTheir docs focus on one repo per branch, which doesn't have this problem at\nall.\n\nSo in short, letting \"git-pull\" fast-forward (or rebase; I like that idea)\nthe local copies of the remote tracking branches onto those remote tracking\nbranches will make life easier for:\n* People who collaborate with others in a shared environment, where branch\n heads frequently change in the mothership repo but all development is\n supposed to be done at the tip of those mothership branches anyway.\n Nearly all corporate users fall into this category.\n* People who just want to track and test the latest and greatest version of\n software X. Sometimes trying latest stable, and sometimes going with the\n freshest beta. They won't want to do \"git merge beta origin/beta\" after\n having done \"git checkout beta\", but they sure as hell don't want to run\n anything but the latest either. They may contribute once in a while, but\n generally just want to make sure they've got the bleeding edge.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57151","messageId":"4E5890F8-2184-4555-8FBE-6B92FE2590E9@zib.de","threadId":"10194","inReplyTo":"47204C6D.3020900@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-25T08:25:16Z","receivedAt":"2007-10-25T08:25:16Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 25, 2007, at 9:57 AM, Andreas Ericsson wrote:\n\n> 50+ repositories, with stable, testing and maint branches. Some \n> repos have more\n> than that, so it amounts to roughly 200 branches. Each branch can \n> be modified by\n> anyone (we're a small company - everyone still works everywhere), \n> but all changes\n> should be done to the tip of the upstream branch. Especially for \n> maint this is a\n> bit of a problem, since we frequently have consultants out and \n> about, and they\n> sometimes find a bug that they commit locally to their own repo. \n> They're in a\n> hurry though, and have no connection to the mothership repo so they \n> can't git-pull\n> to get up to date. They aren't exactly developers, but savvy enough \n> to fix a few\n> simple bugs, but the concept of the locally-modifiable branches not \n> being updated\n> to their remote-tracking counterparts with each git-pull is just \n> incomprehensible\n> to them. To me, that suggests that we're doing something wrong.\n\nJohannes described a workflow using rebase. It would create\na very clean history avoiding long \"parallel roads\" and it\nmimics what experience git users would probably do: Just work\nif you have no connection but cleanup your work by using rebase\nbefore pushing it.\n\nJohannes, and Peter, too, propose to delete local branches\nasap to avoid the third copy besides the copy on the server\nand the copy in remotes. They suggest that local branches\nshould be absolutely reserved for local work.\n\nHowever, my feeling is that the current tools make it too hard\nto work the way described. Therefore it's hard to sell such a\nworkflow to an unexperienced developer. For example checking\nout a remote branch for doing some local work, pushing this\nwork, and cleaning up requires\n\n git checkout -b origin/\n # work work ...\n git push origin \n git checkout \n git branch -D \n\nThese are a lot of commands and some of them look quite\nredundant. Nearly every command contains . Why isn't is\nsufficient to tell the name of the branch I'm working on once.\nAnd '-D' looks even dangerous to me because it overrides all\nsafety checks. This should not be needed in daily work.\n\nHere are some questions:\nDo you think a workflow using rebase is feasible for\nunexperienced git users?\nWhat would be needed to bring such a workflow down to a few,\nsimple and reliable commands?\n\nI think the general question is what I described in a previous\nmail: You have a shared repository containing stable and topic\nbranches. Provide a workflow that is as simple as possible\nfor as many as possible developers. The average developer\nshould need nothing more than equivalents of \"cvs update\",\n\"cvs commit\" for daily work if there are no conflicts. Note,\nthere are no redundant branch names allowed in the commands.\nIf a developer doesn't switch branches there's no need to\ntell the branch name. \"git pull ; ... ; git push\" is simple\nbut it has the problem of reporting errors that average devs\ndon't understand.\n\n\tSteffen\n"},{"id":"57155","messageId":"Pine.LNX.4.64.0710251106110.25221@racer.site","threadId":"10194","inReplyTo":"472048EB.1000707@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-25T10:07:33Z","receivedAt":"2007-10-25T10:07:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Andreas Ericsson wrote:\n\n> Jakub Narebski wrote:\n> > On 10/24/07, Andreas Ericsson wrote:\n> > \n> > > git pull. Not git push. git pull operates on one working branch at a \n> > > time (by default), whereas git push uploads and fast-forwards all \n> > > the common branches (by default). I want git pull to work like git \n> > > push.\n> > \n> > git push is opposite (almost) to git fetch, not to git pull.\n> \n> Not to an end user that has no idea or desire to learn about git remotes \n> or anything else.\n\nAt some point you _have_ to expect your users to learn something. In the \ngit documentation, we never pretend that pull is anything else than \"fetch \n+ merge\".\n\nSo this assumption of your end user is a lack of training, really.\n\nCiao,\nDscho\n"},{"id":"57156","messageId":"Pine.LNX.4.64.0710251108330.25221@racer.site","threadId":"10194","inReplyTo":"47204ECA.7040309@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-25T10:12:19Z","receivedAt":"2007-10-25T10:12:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Wed, 24 Oct 2007, Andreas Ericsson wrote:\n> > \n> > > Conceptually, I don't think it'll be any problem what so ever \n> > > telling anyone that the branches that aren't currently checked out \n> > > get merged automatically only if they result in a fast-forward.\n> > \n> > It would be a matter of seconds until someone asks \"why only \n> > fast-forwards? Would it not be _much_ better to merge _always_? \n> > Stupid git.\"\n> > \n> > And all because the concept of \"local\" vs \"remote\" was blurred.\n> \n> It's already blurred, since we have git-pull instead of just git-fetch.\n\nHuh? How is \"I ask git pull to fetch the remote branch, and merge it into \nmy local branch\" a blurring of local vs remote branch?\n\nThe local branch is still the local branch where it is _my_ responsibility \nto update or change anything. The remote branch is not. If at all, I can \npush -- iff it fast-forwards.\n\nThe fact that you can set up local mirroring branches (with \"git remote \nadd\") which are only updated via \"git fetch\" is _no_ blurring of the \nconcepts: we make it quite explicit that you cannot check them out. They \nare not local branches.\n\nHth,\nDscho\n"},{"id":"57157","messageId":"Pine.LNX.4.64.0710251112390.25221@racer.site","threadId":"10194","inReplyTo":"47204297.5050109@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-25T10:17:25Z","receivedAt":"2007-10-25T10:17:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n> > \n> > > On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n> > > \n> > > > But I think I have to drive my message home again: if what you \n> > > > desire becomes reality, you take away the clear distinction \n> > > > between local and remote branches. In fact, those branches are \n> > > > neither local (because the next pull will automatically update \n> > > > them with remote changes, but _only_ if they fast-forward) nor \n> > > > remote (because you plan to work on them locally).\n> > >\n> > > Exactly, because I do not work on those branches alone. These are \n> > > _shared_ branches. I can work on such a branch with a group of \n> > > developers. I'm willing to accept this bit of chaos.\n> > \n> > It is not just a chaos. I see a serious problem here. On _your_ \n> > computer, you do _not_ have a shared branch. Which is visible _even_ \n> > in your modified work flow when you have unpushed changes.\n> \n> Ofcourse it is. People might pull from it. That's the whole point of a \n> distributed model.\n\nBy that reasoning, left is right. Because your \"left\" is my \"right\".\n\n> > So your desired illusion that your local branches are anything but \n> > local branches will never be perfect enough.\n> > \n> > > Your rebase workflow is not possible if more than one dev wants to \n> > > work on the topic branch together.\n> > \n> > Why not? I do it all the time. CVS users do it all the time, for \n> > that matter.\n> \n> For 200 branches at a time, where any of them might have changed?\n\nI slowly start to understand why your users are confused. _Nobody_ works \non 200 branches at the same time. (No, maintainers don't count: they do \nnot work _on_ the branches, but _with_; they merge them.)\n\nWhen you're done with a topic, why do you leave it around? Cluttering up \nyour \"git branch\" output?\n\n> > The problem I see here: you know git quite well. Others don't, and \n> > will be mightily confused why pull updates local branches sometimes, \n> > and sometimes not.\n> \n> Do you know this, or are you just guessing? I'm getting the exact same\n> confusion with the current behaviour. \"Why the hell doesn't git update\n> all the branches I told the damn stupid tool to auto-merge when I pull?\"\n\nThat's easy. A merge can have conflicts. Conflicts need a working \ndirectory. You cannot have multiple working directories. (Actually, you \ncan, with git-new-workdir, which would break down _horribly_ with your \ndesired change.)\n\nOh? You don't have local changes? Then why _on earth_ do you have a \nlocal branch?\n\nCiao,\nDscho\n"},{"id":"57158","messageId":"47206EC3.5000002@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710251108330.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T10:24:03Z","receivedAt":"2007-10-25T10:24:03Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 25 Oct 2007, Andreas Ericsson wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> On Wed, 24 Oct 2007, Andreas Ericsson wrote:\n>>>\n>>>> Conceptually, I don't think it'll be any problem what so ever \n>>>> telling anyone that the branches that aren't currently checked out \n>>>> get merged automatically only if they result in a fast-forward.\n>>> It would be a matter of seconds until someone asks \"why only \n>>> fast-forwards? Would it not be _much_ better to merge _always_? \n>>> Stupid git.\"\n>>>\n>>> And all because the concept of \"local\" vs \"remote\" was blurred.\n>> It's already blurred, since we have git-pull instead of just git-fetch.\n> \n> Huh? How is \"I ask git pull to fetch the remote branch, and merge it into \n> my local branch\" a blurring of local vs remote branch?\n> \n> The local branch is still the local branch where it is _my_ responsibility \n> to update or change anything.\n\nTrue. So git pull saves you exactly one command. The various fetch-all-git-\nrepos-and-update-all-fast-forward-branches in circulation at the office\nsave us ~500 commands each time they're run. Or rather, they *could* do\nthat, but you can't know until you've run it.\n\nSo what should I do to make what I want possible, without having git-pull\nmuddy the waters of local vs remote? There's clearly a user desire for it,\nbesides that of my eight co-workers and myself. Introduce git-?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57169","messageId":"Pine.LNX.4.64.0710251117310.25221@racer.site","threadId":"10194","inReplyTo":"79366145-3C91-4417-B62C-FFF9EC452076@zib.de","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-25T10:27:56Z","receivedAt":"2007-10-25T10:27:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote:\n> \n> > On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n> > \n> > > On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n> > > \n> > > > But I think I have to drive my message home again: if what you \n> > > > desire becomes reality, you take away the clear distinction \n> > > > between local and remote branches. In fact, those branches are \n> > > > neither local (because the next pull will automatically update \n> > > > them with remote changes, but _only_ if they fast-forward) nor \n> > > > remote (because you plan to work on them locally).\n> > > \n> > > Exactly, because I do not work on those branches alone. These are \n> > > _shared_ branches. I can work on such a branch with a group of \n> > > developers. I'm willing to accept this bit of chaos.\n> > \n> > It is not just a chaos. I see a serious problem here. On _your_ \n> > computer, you do _not_ have a shared branch. Which is visible _even_ \n> > in your modified work flow when you have unpushed changes.\n> > \n> > So your desired illusion that your local branches are anything but \n> > local branches will never be perfect enough.\n> \n> Ok, there is not a fundamental difference between local branches\n> that automatically merge from remotes and local branches that\n> are purely local and _never_ merge anything automatically. Both\n> are only local branches.\n\nActually, not really. For refs/remotes/* you expect them to change \npossibly at the same time. For your local branches, I'd expect them only \nto change when I am actually working on them (and yes, that includes a \npull into the current branch).\n\n> > > Your rebase workflow is not possible if more than one dev wants to \n> > > work on the topic branch together.\n> > \n> > Why not? I do it all the time. CVS users do it all the time, for \n> > that matter.\n> \n> You're right. You can rebase your local changes on top of the new shared \n> remote head. And this is probably the best thing you can do to get a \n> clean history. Maybe it should be easier.\n\nIt should. Thus my question about best practices (which is technically in \nthis thread, but we are in a subthread which permuted into \"I want git \npull to behave differently\")\n\nI _want_ this to be easier.\n\n> So, do I understand correctly, what you propose is:\n> - never merge but only rebase\n> - Due to lacking support for this in \"git pull\", never use\n> git pull when working with shared branches but instead _always_ use\n> \"git fetch; git rebase origin/\".\n> \n> So you say that one of the first messages in \"git for CVS users\", \"The \n> equivalent of cvs update is git pull origin\" [1], is wrong. I don't \n> think I'm able to sell your proposed workflow with the current \n> documentation. But maybe I try if I'm absolutely convinced that it is \n> superior.\n\nHehe. You just experienced the tremendous speed at which git moves. In \nthe beginning, we really thought that \"git pull\" is all you'll ever want \nto have.\n\nBut in the meantime, one of the biggest Enemies of the Rebase (yours \ntruly) converted to an avid fan of it, because it really helps \ndevelopment. It also makes for clean history, which is always good.\n\n> > > > But here is a proposal which should make you and your developers \n> > > > happy, _and_ should be even easier to explain:\n> > > > \n> > > > Work with topic branches. And when you're done, delete them.\n> > > \n> > > Again, if you want to share the topic branch the situation gets more \n> > > complex.\n> > \n> > Hardly so. In my proposed solution to your problem, there is nothing \n> > which prevents you from working off of another branch than \"master\".\n> \n> Well if you have several local branches checked out that are\n> shared with others you run into the \"git push\" problem again ...\n> (see below at git push origin master).\n\nDo the same as I, always say \"git push origin master\" (of course, you \nshould exchange \"master\" with whatever branch you want to push). Be \nprecise.\n\n> > > > So the beginning of the day could look like this:\n> > > > \n> > > > \tgit fetch\n> > > > \tgit checkout -b todays-topic origin/master\n> > > > \n> > > > \t[hack hack hack]\n> > > > \t[test test test]\n> > > > \t[debug debug debug]\n> > > > \t[occasionally commit]\n> > > > \t[occasionally git rebase -i origin/master]\n> > > > \n> > > > and the end of the topic\n> > > > \n> > > > \tgit branch -M master\n> \n> Isn't this a bit dangerous? It forces to overwrite master no matter \n> what's on it. You don't see diffstats nor a fast forward message that \n> confirms what you're doing.\n\nYeah, I should have said something like \"git branch -m master\" \n(implicitely assuming that you have no current \"master\" branch).\n\n> > > > \tgit push origin master\n> \n> I'd like to see \"git push\" here.\n\nI think it is not asking too much for the user to be a bit more precise. \nIf you really do not trust your developers to be capable of that, point \nthem to git gui.\n\n> git branch -m \n> git push origin \n> git checkout do-not-work-here\n> git branch -D \n\nActually, the last two commands would better be\n\n\tgit checkout HEAD^{commit}\n\tgit branch -d \n\n> > The problem I see here: you know git quite well. Others don't, and \n> > will be mightily confused why pull updates local branches sometimes, \n> > and sometimes not.\n> \n> But it already happens now. \"git pull\" sometimes merges a remote branch \n> (--track) and sometimes it reports an error that is fails to do so \n> (--no-track).\n\nIf there really is an inconsistent behaviour, then we'll have to fix that. \nWe should not introduce inconsistent behaviour on top of that.\n\nCiao,\nDscho\n"},{"id":"57170","messageId":"472070E5.4090303@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710251112390.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T10:33:09Z","receivedAt":"2007-10-25T10:33:09Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 25 Oct 2007, Andreas Ericsson wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n>>>\n>>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n>>>>\n>>>>> But I think I have to drive my message home again: if what you \n>>>>> desire becomes reality, you take away the clear distinction \n>>>>> between local and remote branches. In fact, those branches are \n>>>>> neither local (because the next pull will automatically update \n>>>>> them with remote changes, but _only_ if they fast-forward) nor \n>>>>> remote (because you plan to work on them locally).\n>>>> Exactly, because I do not work on those branches alone. These are \n>>>> _shared_ branches. I can work on such a branch with a group of \n>>>> developers. I'm willing to accept this bit of chaos.\n>>> It is not just a chaos. I see a serious problem here. On _your_ \n>>> computer, you do _not_ have a shared branch. Which is visible _even_ \n>>> in your modified work flow when you have unpushed changes.\n>> Ofcourse it is. People might pull from it. That's the whole point of a \n>> distributed model.\n> \n> By that reasoning, left is right. Because your \"left\" is my \"right\".\n> \n>>> So your desired illusion that your local branches are anything but \n>>> local branches will never be perfect enough.\n>>>\n>>>> Your rebase workflow is not possible if more than one dev wants to \n>>>> work on the topic branch together.\n>>> Why not? I do it all the time. CVS users do it all the time, for \n>>> that matter.\n>> For 200 branches at a time, where any of them might have changed?\n> \n> I slowly start to understand why your users are confused. _Nobody_ works \n> on 200 branches at the same time. (No, maintainers don't count: they do \n> not work _on_ the branches, but _with_; they merge them.)\n> \n> When you're done with a topic, why do you leave it around? Cluttering up \n> your \"git branch\" output?\n> \n\nWe have 91 repositories at work. Roughly 60 of those are in active use.\nThe active repos are organized pretty much like the git repo with\n'master', 'next' and 'maint'. We *do* work on all branches, but not\nevery day, ofcourse. They're NOT topic branches. We implement features\non topic-branches that we DO throw away, but those branches HAVE to be\nthere for us to be able to handle supporting of old versions as well as\nimplementing new features in a sane way. Throwing them away locally would\nmean having to re-create them very frequently, and since they have to\nexist in the upstream repo, \"git fetch\" would fetch and re-create them\nevery single time anyway.\n\nSo please, pretty please just drop the entire \"use topic branches\" argument.\nWe do that, but still have this problem, and it *is* a problem.\n\n>>> The problem I see here: you know git quite well. Others don't, and \n>>> will be mightily confused why pull updates local branches sometimes, \n>>> and sometimes not.\n>> Do you know this, or are you just guessing? I'm getting the exact same\n>> confusion with the current behaviour. \"Why the hell doesn't git update\n>> all the branches I told the damn stupid tool to auto-merge when I pull?\"\n> \n> That's easy. A merge can have conflicts. Conflicts need a working \n> directory. You cannot have multiple working directories. (Actually, you \n> can, with git-new-workdir, which would break down _horribly_ with your \n> desired change.)\n> \n> Oh? You don't have local changes? Then why _on earth_ do you have a \n> local branch?\n> \n\nBecause it's convenient, ofcourse. Don't you have 'maint', 'next' and 'master'\nin your clone of git.git? I'm guessing at least 99% of the people on this\nlist have those branches lying around in their clones, even if they only\never use 'next' and/or 'master'.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57171","messageId":"6AE2F79A-24EF-4F00-9D3E-742A47865FD1@zib.de","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710251106110.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-25T10:39:06Z","receivedAt":"2007-10-25T10:39:06Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 25, 2007, at 12:07 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Thu, 25 Oct 2007, Andreas Ericsson wrote:\n>\n>> Jakub Narebski wrote:\n>>> On 10/24/07, Andreas Ericsson wrote:\n>>>\n>>>> git pull. Not git push. git pull operates on one working branch \n>>>> at a\n>>>> time (by default), whereas git push uploads and fast-forwards all\n>>>> the common branches (by default). I want git pull to work like git\n>>>> push.\n>>>\n>>> git push is opposite (almost) to git fetch, not to git pull.\n>>\n>> Not to an end user that has no idea or desire to learn about git \n>> remotes\n>> or anything else.\n>\n> At some point you _have_ to expect your users to learn something. \n> In the\n> git documentation, we never pretend that pull is anything else than \n> \"fetch\n> + merge\".\n>\n> So this assumption of your end user is a lack of training, really.\n\nI typically describe in detail every step they need to get\nthere work done. I expect that a few, simple commands that can\nbe used per copy & paste should solve 90% of the cases.\n\nSome users will learn more, some will refuse to learn\nmore. Users from the second group will typically consult a\nmore experienced user if they hit a problem. At at that point\nthey are forced to learn.\n\nI don't expect that all users know all details and the users\nexpect that their daily workflow is well supported with a\nfew commands.\n\n\tSteffen\n"},{"id":"57174","messageId":"Pine.LNX.4.64.0710251232370.25221@racer.site","threadId":"10194","inReplyTo":"47206EC3.5000002@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-25T11:39:17Z","receivedAt":"2007-10-25T11:39:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Thu, 25 Oct 2007, Andreas Ericsson wrote:\n> > \n> > > Johannes Schindelin wrote:\n> > > \n> > > > On Wed, 24 Oct 2007, Andreas Ericsson wrote:\n> > > > \n> > > > > Conceptually, I don't think it'll be any problem what so ever \n> > > > > telling anyone that the branches that aren't currently checked \n> > > > > out get merged automatically only if they result in a \n> > > > > fast-forward.\n> > > >\n> > > > It would be a matter of seconds until someone asks \"why only \n> > > > fast-forwards? Would it not be _much_ better to merge _always_? \n> > > > Stupid git.\"\n> > > > \n> > > > And all because the concept of \"local\" vs \"remote\" was blurred.\n> > >\n> > > It's already blurred, since we have git-pull instead of just \n> > > git-fetch.\n> > \n> > Huh? How is \"I ask git pull to fetch the remote branch, and merge it \n> > into my local branch\" a blurring of local vs remote branch?\n> > \n> > The local branch is still the local branch where it is _my_ \n> > responsibility to update or change anything.\n> \n> True. So git pull saves you exactly one command. The various \n> fetch-all-git- repos-and-update-all-fast-forward-branches in circulation \n> at the office save us ~500 commands each time they're run. Or rather, \n> they *could* do that, but you can't know until you've run it.\n\nAs I pointed out, there is no way to sensibly have 500 _local_ branches \nlying around.\n\nIt is ridiculous to assume that you have to have local branches for all \nthe stable, maintenance, whatever branches.\n\nWhen you have to change something, you branch, hack, develop, commit, \npush, and then _clean up_ after yourself. No need to clutter your \nlocal branch space with unused branches.\n\n> So what should I do to make what I want possible, without having \n> git-pull muddy the waters of local vs remote? There's clearly a user \n> desire for it, besides that of my eight co-workers and myself. Introduce \n> git-?\n\nIf you _insist_ on your workflow, hey, git is a free program, and you can \ndo what you want to do with an alias easily enough. You can even make \nthat alias part of the templates, so you can force your desires down the \nthroat of every of your coworkers.\n\nHowever, that does not mean that you can insist on support for your \nworkflow in upstream git.\n\nCiao,\nDscho\n"},{"id":"57175","messageId":"8C2ADF84-2E35-46D3-B894-68341CF26A81@zib.de","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710251117310.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-25T12:04:40Z","receivedAt":"2007-10-25T12:04:40Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 25, 2007, at 12:27 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n>\n>> On Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote:\n>>\n>>> On Thu, 25 Oct 2007, Steffen Prohaska wrote:\n>>>\n>>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:\n\n[...]\n\n>>>>> But here is a proposal which should make you and your developers\n>>>>> happy, _and_ should be even easier to explain:\n>>>>>\n>>>>> Work with topic branches. And when you're done, delete them.\n>>>>\n>>>> Again, if you want to share the topic branch the situation gets \n>>>> more\n>>>> complex.\n>>>\n>>> Hardly so. In my proposed solution to your problem, there is \n>>> nothing\n>>> which prevents you from working off of another branch than \"master\".\n>>\n>> Well if you have several local branches checked out that are\n>> shared with others you run into the \"git push\" problem again ...\n>> (see below at git push origin master).\n>\n> Do the same as I, always say \"git push origin master\" (of course, you\n> should exchange \"master\" with whatever branch you want to push). Be\n> precise.\n\nWell, I'm lazy. git already knows everything. It knows that\nthe current branch is associated with a specific remote and it\npushes matching branches by default. And I took care to not\npollute the namespace. All my branches are named identical\nin all repositories I'm dealing with. It's reasonable to want\n\"git push\" to do the right thing.\n\n\n\n>>>>> So the beginning of the day could look like this:\n>>>>>\n>>>>> \tgit fetch\n>>>>> \tgit checkout -b todays-topic origin/master\n>>>>>\n>>>>> \t[hack hack hack]\n>>>>> \t[test test test]\n>>>>> \t[debug debug debug]\n>>>>> \t[occasionally commit]\n>>>>> \t[occasionally git rebase -i origin/master]\n>>>>>\n>>>>> and the end of the topic\n>>>>>\n>>>>> \tgit branch -M master\n>>\n>> Isn't this a bit dangerous? It forces to overwrite master no matter\n>> what's on it. You don't see diffstats nor a fast forward message that\n>> confirms what you're doing.\n>\n> Yeah, I should have said something like \"git branch -m master\"\n> (implicitely assuming that you have no current \"master\" branch).\n>\n>>>>> \tgit push origin master\n>>\n>> I'd like to see \"git push\" here.\n>\n> I think it is not asking too much for the user to be a bit more \n> precise.\n> If you really do not trust your developers to be capable of that, \n> point\n> them to git gui.\n\nWell I was more precise and got lazy over time. Now the most I do\nis \"git push --dry-run\" and if it looks good I do \"git push\".\nMost of the time I just say \"git push\".\n\nAs I pointed out earlier, \"git push origin \" can create\na new branch on the remote. \"git push\" never creates a new branch.\nI believe \"git push\" is safer.\n\n\n>> git branch -m \n>> git push origin \n>> git checkout do-not-work-here\n>> git branch -D \n>\n> Actually, the last two commands would better be\n>\n> \tgit checkout HEAD^{commit}\n> \tgit branch -d \n\nWow, looks weird (not too me but to someone who doesn't know git).\n\n\n>>> The problem I see here: you know git quite well. Others don't, and\n>>> will be mightily confused why pull updates local branches sometimes,\n>>> and sometimes not.\n>>\n>> But it already happens now. \"git pull\" sometimes merges a remote \n>> branch\n>> (--track) and sometimes it reports an error that is fails to do so\n>> (--no-track).\n>\n> If there really is an inconsistent behaviour, then we'll have to \n> fix that.\n> We should not introduce inconsistent behaviour on top of that.\n\nIt's not inconsistent. It's an option of a branch. Git supports two\nflavours of local branches. Some branches automatically merge and other\ndon't.\n\n\tSteffen\n"},{"id":"57176","messageId":"D94E760B-0DFC-4735-AB8D-3E7B4E47950A@zib.de","threadId":"10194","inReplyTo":"472070E5.4090303@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-25T12:09:01Z","receivedAt":"2007-10-25T12:09:01Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 25, 2007, at 12:33 PM, Andreas Ericsson wrote:\n\n>> I slowly start to understand why your users are confused. \n>> _Nobody_ works on 200 branches at the same time. (No, maintainers \n>> don't count: they do not work _on_ the branches, but _with_; they \n>> merge them.)\n>> When you're done with a topic, why do you leave it around? \n>> Cluttering up your \"git branch\" output?\n>\n> We have 91 repositories at work. Roughly 60 of those are in active \n> use.\n> The active repos are organized pretty much like the git repo with\n> 'master', 'next' and 'maint'. We *do* work on all branches, but not\n> every day, ofcourse. They're NOT topic branches. We implement features\n> on topic-branches that we DO throw away, but those branches HAVE to be\n> there for us to be able to handle supporting of old versions as \n> well as\n> implementing new features in a sane way. Throwing them away locally \n> would\n> mean having to re-create them very frequently, and since they have to\n> exist in the upstream repo, \"git fetch\" would fetch and re-create them\n> every single time anyway.\n>\n> So please, pretty please just drop the entire \"use topic branches\" \n> argument.\n> We do that, but still have this problem, and it *is* a problem.\n\nThis is an interesting situation. If we find a good solution\nthat is accepted by the average developer in daily work. We\ncan probably learn a lot.\n\n\tSteffen\n"},{"id":"57178","messageId":"4720903E.1070103@op5.se","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710251232370.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T12:46:54Z","receivedAt":"2007-10-25T12:46:54Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 25 Oct 2007, Andreas Ericsson wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> On Thu, 25 Oct 2007, Andreas Ericsson wrote:\n>>>\n>>>> Johannes Schindelin wrote:\n>>>>\n>>>>> On Wed, 24 Oct 2007, Andreas Ericsson wrote:\n>>>>>\n>>>>>> Conceptually, I don't think it'll be any problem what so ever \n>>>>>> telling anyone that the branches that aren't currently checked \n>>>>>> out get merged automatically only if they result in a \n>>>>>> fast-forward.\n>>>>> It would be a matter of seconds until someone asks \"why only \n>>>>> fast-forwards? Would it not be _much_ better to merge _always_? \n>>>>> Stupid git.\"\n>>>>>\n>>>>> And all because the concept of \"local\" vs \"remote\" was blurred.\n>>>> It's already blurred, since we have git-pull instead of just \n>>>> git-fetch.\n>>> Huh? How is \"I ask git pull to fetch the remote branch, and merge it \n>>> into my local branch\" a blurring of local vs remote branch?\n>>>\n>>> The local branch is still the local branch where it is _my_ \n>>> responsibility to update or change anything.\n>> True. So git pull saves you exactly one command. The various \n>> fetch-all-git- repos-and-update-all-fast-forward-branches in circulation \n>> at the office save us ~500 commands each time they're run. Or rather, \n>> they *could* do that, but you can't know until you've run it.\n> \n> As I pointed out, there is no way to sensibly have 500 _local_ branches \n> lying around.\n> \n> It is ridiculous to assume that you have to have local branches for all \n> the stable, maintenance, whatever branches.\n> \n> When you have to change something, you branch, hack, develop, commit, \n> push, and then _clean up_ after yourself. No need to clutter your \n> local branch space with unused branches.\n> \n\nerror: The branch 'next' is not a strict subset of your current HEAD.\nIf you are sure you want to delete it, run 'git branch -D next'.\n\nSo you want me to tell all the developers they should use \"git branch\n-D maint\" instead, so they can bypass the built-in security checks? No\nthanks.\n\n>> So what should I do to make what I want possible, without having \n>> git-pull muddy the waters of local vs remote? There's clearly a user \n>> desire for it, besides that of my eight co-workers and myself. Introduce \n>> git-?\n> \n> If you _insist_ on your workflow, hey, git is a free program, and you can \n> do what you want to do with an alias easily enough.\n\nWith a git alias? No. There aren't even any switches in git to make it do\nwhat I want. With a shell alias? Sure, it's doable, but cumbersome. With a\nshell-script I can get it done, but it's ugly, inefficient and has to parse\neverything twice. It's also a time-sink, and time is something I don't have\nvery much of right now.\n\n> You can even make \n> that alias part of the templates, so you can force your desires down the \n> throat of every of your coworkers.\n> \n\nThey're the ones that requested I hack it into git, but the result would\nremain the same, ofcourse.\n\n> However, that does not mean that you can insist on support for your \n> workflow in upstream git.\n> \n\nI'm not. We're currently discussing the pros and the cons, and I'm spending\nmy free 20 minutes every night working on a patch-series to make git-pull\na built-in and then implementing the switch/config-option/whatever that\nmakes it do what I want it to do. Apart from Junio, that's how everyone\nthat wants a feature implemented has to do it, so I'd hardly call that\ninsisting. If Junio decides the patch does something evil, I'll have to\nsettle for cherry-picking it into whatever branch I want to build from.\n\nOn a side note; I'd *love* for it to have a rebase option as well. Perhaps\nI'll do that next. In the mean-time, I'd settle for just updating locally\nmodifiable copies of tracking branches that I've already configured git to\nmerge with a tracking branch when it happens to be a fast-forward.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57179","messageId":"Pine.LNX.4.64.0710251239590.25221@racer.site","threadId":"10194","inReplyTo":"472070E5.4090303@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-25T12:58:53Z","receivedAt":"2007-10-25T12:58:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 25 Oct 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > When you're done with a topic, why do you leave it around? \n> > Cluttering up your \"git branch\" output?\n> \n> We have 91 repositories at work. Roughly 60 of those are in active use.\n> The active repos are organized pretty much like the git repo with\n> 'master', 'next' and 'maint'. We *do* work on all branches, but not\n> every day, ofcourse. They're NOT topic branches.\n\nI already explained in another mail (wasn't it even the one you replied \nto?) how this can be done more efficiently.\n\nCiao,\nDscho\n"},{"id":"57183","messageId":"20071025132401.GA22103@thunk.org","threadId":"10194","inReplyTo":"472070E5.4090303@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-25T13:24:01Z","receivedAt":"2007-10-25T13:24:01Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Oct 25, 2007 at 12:33:09PM +0200, Andreas Ericsson wrote:\n> Because it's convenient, ofcourse. Don't you have 'maint', 'next'\n> and 'master' in your clone of git.git? I'm guessing at least 99% of\n> the people on this list have those branches lying around in their\n> clones, even if they only ever use 'next' and/or 'master'.\n\nI find it just as easy to say: \"git checkout origin/maint\" or \"git\ncheckout origin/next\" when I want to examine some other branch.\n\nIf I want to make a change against maint, then I follow up \"git\ncheckout origin/maint\" with a \"git checkout -b \". Part of\nthe reason though, why I *want* to keep the topic branch around is\nprecisely because I don't get to push to the central repository. So I\nwant to keep it around so either (a) the central maintainer can pull\nfrom me, and I delete it only after he's done the pull, or (b) so I\ncan use git-chery so I can see when patches that I created and sent\nvia git-format-patch and git-send-email have been accepted.\n\nYou're using a diferent workflow, and with users who aren't interested\nin learning the fine points of git. But main issue is that git isn't\noptimized for what you want to do. So I can suggest a couple of\ndifferent approaches. One is to simply do things the 'hg' way.\nExplicitly set up different repos for the different branches. It's\nmore inefficient, but it does work. And if the bulk of your users\nare, ah, \"aggressive ignorant\" about git --- and many developers don't\ncare about learning the fine points of their tools, and a successful\nsoftware company needs to learn how to leverage the skills of such\nmid-level engineers (only at a startup or if you are at Google can you\ninsist only only hiring the best and brightest) --- then it might be\nthat the 'hg' approach is easier. Certainly that was the approach\nLarry McVoy has always used with BitKeeper, and he is focused on\nmeeting the needs of his corporate customers.\n\nAnother would be to set up a wrapper script for \"git-clone\" that\ncreates a separate local working directory for each branch. So for\nexample, it might do something like this:\n\n#!/bin/sh\n# Usage: get-repo [dir]\nURL=$1\ndir=$2\nbranches=`git-ls-remote --heads $URL | sed -e 's;.*/;;'`\nif [ \"$dir\"x = \"x\" ]; then dir=`basename $URL`; fi\ngit clone $URL .temp-repo\nmkdir $dir\ncd $dir\nfor i in $branches; do\n mkdir $i\n cd $i\n git init\n git remote add -t $i origin $URL\n echo ref: refs/heads/$i > .git/HEAD\n git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i\n # do it a second time to get the tags (bug in fetch?)\n git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i\n git merge origin/$i\n git config remote.origin.push $i:$i\n cd ..\ndone\ncd ..\nrm -rf .temp-repo\n\nFor bonus points, this script could be made smarter so that each of\nthe branches shared a common git object database, and some error\nchecking would be nice, but hopefully this gets the basic idea across.\n\nThis way, the \"basic git users\" get a separate working directory for\neach branch, where \"git pull\" updates that particular branch, and \"git\npush\" updates changes to the remote branch. \n\nDoes this do what you want?\n\n\t\t\t\t\t\t\t- Ted\n\nP.S. Note by the way that if you are having everyone own access to\npush into a single central repository, having a \"next\" branch probably\ndoesn't make seense. You're probably way better off just simply\nhaving \"master\" (which would be your devel branch), and \"maint\" for\nbug fixes.\n"},{"id":"57186","messageId":"20071025145132.GA31196@diana.vm.bytemark.co.uk","threadId":"10194","inReplyTo":"4720903E.1070103@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-25T14:51:32Z","receivedAt":"2007-10-25T14:51:32Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-25 14:46:54 +0200, Andreas Ericsson wrote:\n\n> error: The branch 'next' is not a strict subset of your current\n> HEAD. If you are sure you want to delete it, run 'git branch -D\n> next'.\n>\n> So you want me to tell all the developers they should use \"git\n> branch -D maint\" instead, so they can bypass the built-in security\n> checks? No thanks.\n\nMaybe the solution here is to let \"git branch -d\" succeed if the\nbranch is a subset of HEAD or the branch it is tracking? That way,\ndeleting would succeed if upstream has all your commits.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"57187","messageId":"4720AF05.3050308@op5.se","threadId":"10194","inReplyTo":"20071025132401.GA22103@thunk.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T14:58:13Z","receivedAt":"2007-10-25T14:58:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Theodore Tso wrote:\n> On Thu, Oct 25, 2007 at 12:33:09PM +0200, Andreas Ericsson wrote:\n>> Because it's convenient, ofcourse. Don't you have 'maint', 'next'\n>> and 'master' in your clone of git.git? I'm guessing at least 99% of\n>> the people on this list have those branches lying around in their\n>> clones, even if they only ever use 'next' and/or 'master'.\n> \n> I find it just as easy to say: \"git checkout origin/maint\" or \"git\n> checkout origin/next\" when I want to examine some other branch.\n> \n> If I want to make a change against maint, then I follow up \"git\n> checkout origin/maint\" with a \"git checkout -b \". Part of\n\nExcept that in this case will always be maint, since\nonly small bugfixes go on that branch. We tried using different-named\nbranches earlier, but the \"git push \" behaviour was\nmuch too common, and we ended up with far too many randomly named\nbranches on the mothership repository.\n\n> \n> You're using a diferent workflow, and with users who aren't interested\n> in learning the fine points of git. But main issue is that git isn't\n> optimized for what you want to do.\n\nCorrect. I'm working on optimizing it right now though :)\n\n> So I can suggest a couple of\n> different approaches. One is to simply do things the 'hg' way.\n> Explicitly set up different repos for the different branches. It's\n> more inefficient, but it does work.\n\nThat makes diffing harder to do, and for those few long-living topics\nthat get pushed to mothership, there's no logical way for the user to\nget only that branch. With the *:refs/remotes/foo/* config thing, this\nworks seemlessly today.\n\n> \n> Another would be to set up a wrapper script for \"git-clone\" that\n> creates a separate local working directory for each branch. So for\n> example, it might do something like this:\n> \n> #!/bin/sh\n> # Usage: get-repo [dir]\n> URL=$1\n> dir=$2\n> branches=`git-ls-remote --heads $URL | sed -e 's;.*/;;'`\n> if [ \"$dir\"x = \"x\" ]; then dir=`basename $URL`; fi\n> git clone $URL .temp-repo\n> mkdir $dir\n> cd $dir\n> for i in $branches; do\n> mkdir $i\n> cd $i\n> git init\n> git remote add -t $i origin $URL\n> echo ref: refs/heads/$i > .git/HEAD\n> git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i\n> # do it a second time to get the tags (bug in fetch?)\n> git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i\n> git merge origin/$i\n> git config remote.origin.push $i:$i\n> cd ..\n> done\n> cd ..\n> rm -rf .temp-repo\n> \n> For bonus points, this script could be made smarter so that each of\n> the branches shared a common git object database, and some error\n> checking would be nice, but hopefully this gets the basic idea across.\n> \n> This way, the \"basic git users\" get a separate working directory for\n> each branch, where \"git pull\" updates that particular branch, and \"git\n> push\" updates changes to the remote branch. \n> \n> Does this do what you want?\n> \n\nNot really, I'm afraid. Apart from missing out on the auto-download of\nnew repos you get with \"fetch = refs/heads/*:refs/remotes/origin/*\",\nit seems inelegant.\n\n> \t\t\t\t\t\t\t- Ted\n> \n> P.S. Note by the way that if you are having everyone own access to\n> push into a single central repository, having a \"next\" branch probably\n> doesn't make seense. You're probably way better off just simply\n> having \"master\" (which would be your devel branch), and \"maint\" for\n> bug fixes.\n> \n\nWe have\nmaint = maintenance code. some repos have several maint-branches\nmaster = integration-tested code that will end up in next release\ntesting = unit-tested features, ready for integration testing\n\nWe can't really do without them, but perhaps I can do what Dscho\nsuggested in another email and force everyone to delete their\nlocally-modifiable branches once they're done making changes to\nthem. It'll end up being more commands to run for a single fix,\nbut at least it's not error-prone.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57189","messageId":"20071025152159.GB22103@thunk.org","threadId":"10194","inReplyTo":"4720AF05.3050308@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-25T15:21:59Z","receivedAt":"2007-10-25T15:21:59Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Oct 25, 2007 at 04:58:13PM +0200, Andreas Ericsson wrote:\n>\n> Correct. I'm working on optimizing it right now though :)\n\nWe await your patches. :-)\n\n>> Another would be to set up a wrapper script for \"git-clone\" that\n>> creates a separate local working directory for each branch. So for\n>> example, it might do something like this:\n>>\n>> #!/bin/sh\n>> # Usage: get-repo [dir]\n>> ...\n\n> Not really, I'm afraid. Apart from missing out on the auto-download of\n> new repos you get with \"fetch = refs/heads/*:refs/remotes/origin/*\",\n> it seems inelegant.\n\nYou mean new branches, right?\n\nAnd of course it's inelegant. You just told us we were dealing with\nCVS-brain-damaged corporate developers who can't be bothered to learn\nabout the fine points of using things the git way. And I thought you\nsaid there were only a few branches, \"master\", maint\", etc. and all\nthe developers worked on were the tips of the branches of the\ncorporate mothership repository. \n\nIt's like complaining that a car with manual transmission is too hard\nto drive, and then when someone points out how this could be done with\nan automatic transmission, and then complaining that that you don't\nhave the fine control of a manual transmission. Well, of course you\ndon't! Having that fine control requires that you *learn* how to use\nthat fine control correctly.\n\nThe solution I presented is more elegant than what hg does with\nseparate repositories, but sure, it does require disk space. But this\ndisk space is cheap, even when compared with the salary costs of\nCVS-damanged developers. :-)\n\n\t\t\t\t\t\t- Ted\n"},{"id":"57195","messageId":"1193328386.4522.352.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710242258201.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-25T16:06:26Z","receivedAt":"2007-10-25T16:06:26Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Wed, 2007-10-24 at 23:14 +0100, Johannes Schindelin wrote:\n\n> Whenever I told people \"pull = fetch + merge\", they got it.\n[snip]\n> My \"pupils\" _always_ liked the preciseness of the nomenclature. And they \n> made many less mistakes because they had a clear mental model of what is \n> remote, and what is local. And that local branches are always forks.\n\nThis is a *very* powerful concept. Unfortunately, it is not 100% clear\nin the documentation, at least not when you are reading about\nfetch/merge/pull initially.\n\nAfter reading the user's manual, I just could not understand what\n\"fetch\" does, and therefore \"merge\" and \"pull\" did not make sense. I\ncould not understand where Git stored the new changes from upstream\nwhile also keeping my working directory in the same state it was. After\n10 years of using CVS/SVN, the assumption you have is, \"whenever I get\nchanges from the remote repository, they will be visible in my working\ncopy (and merge conflicts are a fact of life)\".\n\nSome time later, I ran into \"Git for computer scientists\" and then\nfinally I got it, thanks to the nice diagrams and explanation. I\nrealized how powerful a concept \"fetch\" is: THIS is the right way to\nexamine what upstream worked on while you did your own local work.\n\nOnce you understand what's going on, however, it is not obvious how to\n*visualize* the state of things after you do \"git fetch\". Probably\n\"gitk --all\" is the correct way to do it, but the presentation is not\nideal --- you have to hunt down the list of commits until you find your\nown \"master\" (or whatever branch), and *there* is where you can say,\n\"oh, this is where we diverged; now let's see what I'll get when I\nrebase later\".\n\nSo, a few problems so far, with possible solutions:\n\n* The docs do not make it easy to understand what git-fetch does. Can\nwe just cut&paste most of \"Git for computer scientists\" into the Git\nuser's manual?).\n\n* It's not obvious how to visualize the state after git-fetch, i.e.\n\"gitk --all\" is not the first thing that occurs to you. Maybe git-fetch\nshould suggest you to run \"gitk --all\" when your remotes get changes, so\nthat you can see what's going on?\n\n* It's hard to find the \"divergence point\" in gitk's display, since you\nhave to scroll down the reverse-chronological list of commits until you\nfind your local refs and where they started diverging. Would there be a\nway to \"flatten\" the display a bit, so your local stuff is always easy\nto find, and yet it's easy to see what the remote changes were?\n\n> And here I have to disagree strongly. In a workflow based on a\n> shared \n> repository, you do not want to merge. You want to rebase.\n\n.. And after I understood what \"fetch\" does, \"rebase\" became obvious,\nand *this* is where I started loving Git. I understood that in the past\nall I had been doing with CVS was to rebase by hand; that is where I\nsaid \"Git is such a powerful tool\".\n\n> But _even if_ you merge instead of rebase, I fail to see how the current \n> situation is different from CVS (which many people maintain is _easier_ \n> than gi), where first thing you do is to \"cvs update\". Just for git it is \n> \"git pull\".\n\nIt's a matter of perception. CVS requires *less* steps, even if you do\nmore manual work. To commit something, you need to\n\n cvs update\n \n cvs commit\n\nWhereas with Git you need\n\n git fetch\n git rebase \n \n git commit\n git push\n\n[Maybe that's not 100% the right sequence, but you know what I mean.]\n\nSo your perception is that you have to fiddle more with Git (look up the\nremote branch name, invoke more git commands), even if Git saved you a\nlot of work when rebasing.\n\nWhen you start using a complex tool like CVS or Git, you do it by\nvoodoo: you learn sequences of commands, but you don't really\nunderstand what they do. If one tool makes you use less comands, it is\nperceived as simpler and more powerful (\"because the other one needs\nmore babysitting\").\n\nSo, Git needs to make it very clear from the beginning (in the user's\nmanual or the distilled tutorials) that it has *very powerful* concepts\nat your disposal. It needs to *teach you* how it will save you a lot of\nwork when compared to traditional tools like CVS.\n\n Federico\n"},{"id":"57197","messageId":"1193328964.4522.361.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"8fe92b430710241648j609d4d00x121836001a69d1e6@mail.gmail.com","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-25T16:16:04Z","receivedAt":"2007-10-25T16:16:04Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Thu, 2007-10-25 at 01:48 +0200, Jakub Narebski wrote:\n\n> git push is opposite (almost) to git fetch, not to git pull.\n\nThis asymmetry is also part of what makes Git hard to learn at first.\n\nThere is a lot of new terminology to learn:\n\n refs\n remotes\n fast-forwarding\n rebasing\n origin\n master\n HEAD (which is not quite the same as good old CVS's HEAD)\n etc.\n\nThe solution is not, \"have a good glossary\" (which is needed, anyway),\nbut to make the documentation introduce those concepts at the right\ntime, instead of being chock-full of them from the beginning :)\n\nCarl Worth's git-ification of the Mercurial book chapter is very nice in\nthis regard; it doesn't dump all the terminology on you, but rather\ntakes its time to introduce each concept when you are ready to know\nabout it [1].\n\nIt's kind of sad that the first thing \"man git-push\" tells you is this:\n\n git-push - Update remote refs along with associated objects\n\nSo you go, \"refs? associated objects? whaaaaaat?\" :)\n\nImagine someone learning the GIMP a few versions ago. \"I want to make\nthis photo sharper\". You go to the Filters/Enhance menu and you see\n\n Laplace\n Sobel\n Sharpen\n Unsharp mask\n\nAll of those sharpen the image. Which one do you pick?\n\n[1] http://cworth.org/hgbook-git/\n\n Federico\n"},{"id":"57198","messageId":"20071025163835.GB31888@fieldses.org","threadId":"10194","inReplyTo":"1193328386.4522.352.camel@cacharro.xalalinux.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-25T16:38:35Z","receivedAt":"2007-10-25T16:38:35Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Oct 25, 2007 at 11:06:26AM -0500, Federico Mena Quintero wrote:\n> So, a few problems so far, with possible solutions:\n> \n> * The docs do not make it easy to understand what git-fetch does. Can\n> we just cut&paste most of \"Git for computer scientists\" into the Git\n> user's manual?).\n\nIt's definitely not a simple cut-and-paste--even with permission from\nthe author of \"Git for computer scientists\", fitting this in would\nrequire rethinking the ordering of topics in the manual. Also, there's\nthe restriction that we'd like to keep it looking good in plain ascii,\nso diagrams have to be done in ascii somehow.\n\nBut as for using ideas from \"Git for computer scientists\", and/or\nrethinking the ordering of the user's manual to make it more helpful.\nYes, that would be great! Let me know what I can do to help.\n\n--b.\n"},{"id":"57200","messageId":"4720CCE0.2090007@op5.se","threadId":"10194","inReplyTo":"20071025152159.GB22103@thunk.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T17:05:36Z","receivedAt":"2007-10-25T17:05:36Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Theodore Tso wrote:\n> On Thu, Oct 25, 2007 at 04:58:13PM +0200, Andreas Ericsson wrote:\n>> Correct. I'm working on optimizing it right now though :)\n> \n> We await your patches. :-)\n> \n>>> Another would be to set up a wrapper script for \"git-clone\" that\n>>> creates a separate local working directory for each branch. So for\n>>> example, it might do something like this:\n>>>\n>>> #!/bin/sh\n>>> # Usage: get-repo [dir]\n>>> ...\n> \n>> Not really, I'm afraid. Apart from missing out on the auto-download of\n>> new repos you get with \"fetch = refs/heads/*:refs/remotes/origin/*\",\n>> it seems inelegant.\n> \n> You mean new branches, right?\n> \n\nYes. The few topic-branches that require input from several people are\ndistributed this way for peer review and trouble-shooting. It's nifty\nif they're automatically downloaded, but not so much of an issue that\nit matters.\n\n\n> And of course it's inelegant. You just told us we were dealing with\n> CVS-brain-damaged corporate developers who can't be bothered to learn\n> about the fine points of using things the git way.\n\nNo, they're just surprised that what they thought would be automatic\nisn't, and the curse about it when they put themselves in trouble by\nforgetting about it. I've done it myself, and I've been using git since\nmay 2005.\n\n> And I thought you\n> said there were only a few branches, \"master\", maint\", etc. and all\n> the developers worked on were the tips of the branches of the\n> corporate mothership repository. \n> \n\nIt depends. For small bugfixes we sometimes commit directly on the\nchecked out branch. For larger issues we usually create a topic branch\nand hack away, creating nicely ordered patch-series and such, but those\ntopic branches must be created from the tip of the upstream tracking\nbranch. What Dscho suggested would definitely work, but that would\nmean I'd have to tell my co-workers to use 'git branch -D', which I'm\nquite reluctant to do. One solution to that particular problem is\nofcourse to hack the delete-command of git-branch to honor remote\ntracking branches when calculating dependencies, so the local branches\ncan safely be removed when they're done with them.\n\nHowever, there's still this issue:\n$ git checkout -b foo origin/pu\nBranch foo set up to track remote branch refs/remotes/origin/pu.\nSwitched to a new branch \"foo\"\n\ngit checkout will say that every time a branch is created from a\ntracking branch, unless one tells it --no-track (which people don't\nlearn about unless they're really into git), so it's quite natural\nthat people think git will actually make sure, within reasonable\nlimits, that 'foo' is kept in sync with refs/remotes/origin/pu.\nThat's not the case, however.\n\nSo we could either change the message to be:\n\"Branch foo set up to track remote branch refs/remotes/origin/pu,\nprovided you only ever issue git-pull while having branch foo\nchecked out.\"\n\nOr we could make 'git checkout -b' default to --no-track, perhaps\ngiving annoying messages everytime someone \"git-checkout -b\"'s a\nremote tracking branch.\nOr we could make git-pull keep git checkout's promises.\n\nI'm opting for the latter, since that's the one that makes a piece\nof machinery do some work for me. I'd happily call the command\n\"git-update-all-local-branches-tracking-remote-tracking-branches\"\nand only ever make it actually do any work if I pass it the option\n\"--I-bask-in-the-glory-of-local-vs-remote-confusion\", but I need\nsome sort of solution that\na) Doesn't normally present error messages.\nb) Doesn't involve routinely using \"git branch -D\"\nc) Doesn't require more than one or two commands per repo to get\nthe locally checked out copies of the remote tracking branches\n(the ones git has \"set up to track remote branch remotes/x/branch\")\nup to date with their remote counterpart.\n\n\n> It's like complaining that a car with manual transmission is too hard\n> to drive, and then when someone points out how this could be done with\n> an automatic transmission, and then complaining that that you don't\n> have the fine control of a manual transmission. Well, of course you\n> don't! Having that fine control requires that you *learn* how to use\n> that fine control correctly.\n> \n\nOr invent the sensatronic transmission system and get the best of both\nworlds. Engineering solutions so they fit humans? Good gods, that's a\nnovel idea! ;-)\n\n> The solution I presented is more elegant than what hg does with\n> separate repositories, but sure, it does require disk space. But this\n> disk space is cheap, even when compared with the salary costs of\n> CVS-damanged developers. :-)\n> \n\nIt's not so much CVS-damaged developers as it's conflicting messages.\nI'm quite confused about it myself at times, but for me there's\nnobody to harrass since I was the one vetoing in git as the scm to\nuse for all our corporate needs.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57201","messageId":"4720CE1F.3030902@op5.se","threadId":"10194","inReplyTo":"20071025145132.GA31196@diana.vm.bytemark.co.uk","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T17:10:55Z","receivedAt":"2007-10-25T17:10:55Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Karl Hasselström wrote:\n> On 2007-10-25 14:46:54 +0200, Andreas Ericsson wrote:\n> \n>> error: The branch 'next' is not a strict subset of your current\n>> HEAD. If you are sure you want to delete it, run 'git branch -D\n>> next'.\n>>\n>> So you want me to tell all the developers they should use \"git\n>> branch -D maint\" instead, so they can bypass the built-in security\n>> checks? No thanks.\n> \n> Maybe the solution here is to let \"git branch -d\" succeed if the\n> branch is a subset of HEAD or the branch it is tracking? That way,\n> deleting would succeed if upstream has all your commits.\n> \n\nDeleting branches sitting on a ref reachable from any other locally\nchecked out branch certainly works. Since this is done to protect\ncommits from being pruned, and prune honors remote tracking branches\nwhen deciding which commits are unreachable, I see no harm in letting\nbranches pointing to commits reachable from any remote tracking branch\nbe deleted.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57203","messageId":"1193335339.4522.398.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"20071025152159.GB22103@thunk.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-25T18:02:19Z","receivedAt":"2007-10-25T18:02:19Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:\n\n> And of course it's inelegant. You just told us we were dealing with\n> CVS-brain-damaged corporate developers who can't be bothered to learn\n> about the fine points of using things the git way.\n\nIgnore the corporate developers who use SCMs only because their company\nrequires them to. Git is not the right thing for them; some\nEclipse-based monstrosity probably is. It's like the horrendous\nOracle-based expense-reporting thing we have to use at Novell; I use it\nbecause they make me, not because I'm particularly excited about\nreporting expenses :)\n\nHowever, *do think* of the free software developers who have been using\nCVS forever. You won't make friends among them if you keep saying, \"you\nuse CVS? You are brain-damaged, then.\" CVS has been as good/bad to\nthem as to anyone else, and they are probably delighted to get a better\nsolution. That solution needs to take into account the concepts to\nwhich they have been exposed for the past N years. Just because your\nnew concepts are better, doesn't mean that their old ones were wrong in\ntheir time.\n\nYou don't find quantum physicists saying, \"... yeah, like Newton's\nbrain-damaged followers\" :)\n\n Federico\n"},{"id":"57207","messageId":"20071025180451.GA6349@glandium.org","threadId":"10194","inReplyTo":"1193335339.4522.398.camel@cacharro.xalalinux.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-10-25T18:04:51Z","receivedAt":"2007-10-25T18:04:51Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Oct 25, 2007 at 01:02:19PM -0500, Federico Mena Quintero wrote:\n> On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:\n> \n> > And of course it's inelegant. You just told us we were dealing with\n> > CVS-brain-damaged corporate developers who can't be bothered to learn\n> > about the fine points of using things the git way.\n> \n> Ignore the corporate developers who use SCMs only because their company\n> requires them to. Git is not the right thing for them; some\n> Eclipse-based monstrosity probably is. It's like the horrendous\n> Oracle-based expense-reporting thing we have to use at Novell; I use it\n> because they make me, not because I'm particularly excited about\n> reporting expenses :)\n> \n> However, *do think* of the free software developers who have been using\n> CVS forever. You won't make friends among them if you keep saying, \"you\n> use CVS? You are brain-damaged, then.\" CVS has been as good/bad to\n> them as to anyone else, and they are probably delighted to get a better\n> solution. That solution needs to take into account the concepts to\n> which they have been exposed for the past N years. Just because your\n> new concepts are better, doesn't mean that their old ones were wrong in\n> their time.\n\nIt's probably just a matter of writing a \"git for CVS users\" document.\n\nMike\n"},{"id":"57204","messageId":"1193335562.4522.403.camel@cacharro.xalalinux.org","threadId":"10194","inReplyTo":"20071025163835.GB31888@fieldses.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"Federico Mena Quintero","fromEmail":"federico@novell.com","sentAt":"2007-10-25T18:06:02Z","receivedAt":"2007-10-25T18:06:02Z","isPatch":false,"sender":{"key":"federico@novell.com","avatar":null},"body":"On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:\n\n> It's definitely not a simple cut-and-paste--even with permission from\n> the author of \"Git for computer scientists\", fitting this in would\n> require rethinking the ordering of topics in the manual.\n\nOh, that can be done. It's easier to move text around than to\nrearchitect code :)\n\n> Also, there's\n> the restriction that we'd like to keep it looking good in plain ascii,\n> so diagrams have to be done in ascii somehow.\n\nHmm, what's the rationale for this? I'd assume that most people read\nthe user's manual as a web page (or as bedside reading if they can print\na PDF thereof), where diagrams can be pretty.\n\n Federico\n"},{"id":"57208","messageId":"20071025181642.GC31888@fieldses.org","threadId":"10194","inReplyTo":"1193335562.4522.403.camel@cacharro.xalalinux.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-25T18:16:42Z","receivedAt":"2007-10-25T18:16:42Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Oct 25, 2007 at 01:06:02PM -0500, Federico Mena Quintero wrote:\n> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:\n> \n> > It's definitely not a simple cut-and-paste--even with permission from\n> > the author of \"Git for computer scientists\", fitting this in would\n> > require rethinking the ordering of topics in the manual.\n> \n> Oh, that can be done. It's easier to move text around than to\n> rearchitect code :)\n\nOK! I'm happy to help review patches, etc.\n\n> > Also, there's\n> > the restriction that we'd like to keep it looking good in plain ascii,\n> > so diagrams have to be done in ascii somehow.\n> \n> Hmm, what's the rationale for this?\n\nThere have always been a lot of complaints about the difficulty of\nbuilding the documentation. (I don't know why; at least on Debian all\nyou need is an \"apt-get build-dep git-core\".) And our response has been\n\"no problem, you can just read the source.\" That's a big reason why\nasciidoc was chosen.\n\n> I'd assume that most people read the user's manual as a web page (or\n> as bedside reading if they can print a PDF thereof), where diagrams\n> can be pretty.\n\nYeah. Heck, I just read it by pointing my web browser at kernel.org's\nhtml copy....\n\nSo you might get some sympathy for a request for fancier diagrams, I\ndon't know. It would require some more discussion, so I'd rather not\nhave other improvements blocked by this.\n\n--b.\n"},{"id":"57210","messageId":"20071025181817.GD31888@fieldses.org","threadId":"10194","inReplyTo":"20071025180451.GA6349@glandium.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-25T18:18:17Z","receivedAt":"2007-10-25T18:18:17Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Oct 25, 2007 at 08:04:51PM +0200, Mike Hommey wrote:\n> On Thu, Oct 25, 2007 at 01:02:19PM -0500, Federico Mena Quintero wrote:\n> > On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:\n> > \n> > > And of course it's inelegant. You just told us we were dealing with\n> > > CVS-brain-damaged corporate developers who can't be bothered to learn\n> > > about the fine points of using things the git way.\n> > \n> > Ignore the corporate developers who use SCMs only because their company\n> > requires them to. Git is not the right thing for them; some\n> > Eclipse-based monstrosity probably is. It's like the horrendous\n> > Oracle-based expense-reporting thing we have to use at Novell; I use it\n> > because they make me, not because I'm particularly excited about\n> > reporting expenses :)\n> > \n> > However, *do think* of the free software developers who have been using\n> > CVS forever. You won't make friends among them if you keep saying, \"you\n> > use CVS? You are brain-damaged, then.\" CVS has been as good/bad to\n> > them as to anyone else, and they are probably delighted to get a better\n> > solution. That solution needs to take into account the concepts to\n> > which they have been exposed for the past N years. Just because your\n> > new concepts are better, doesn't mean that their old ones were wrong in\n> > their time.\n> \n> It's probably just a matter of writing a \"git for CVS users\" document.\n\nFirst google hit for \"git for CVS users\":\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html\n\npatches welcomed....\n\n--b.\n"},{"id":"57214","messageId":"20071025182358.GA10664@thunk.org","threadId":"10194","inReplyTo":"1193335339.4522.398.camel@cacharro.xalalinux.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-10-25T18:23:58Z","receivedAt":"2007-10-25T18:23:58Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Oct 25, 2007 at 01:02:19PM -0500, Federico Mena Quintero wrote:\n> On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:\n> \n> > And of course it's inelegant. You just told us we were dealing with\n> > CVS-brain-damaged corporate developers who can't be bothered to learn\n> > about the fine points of using things the git way.\n> \n> Ignore the corporate developers who use SCMs only because their company\n> requires them to. Git is not the right thing for them; some\n> Eclipse-based monstrosity probably is. It's like the horrendous\n> Oracle-based expense-reporting thing we have to use at Novell; I use it\n> because they make me, not because I'm particularly excited about\n> reporting expenses :)\n\nI think I misunderstand Andreas' problem statement. What I proposed\nis useful for corporate developers who are deeply confused by\nbranches, especially when a single working directory is constantly\njumping back and forth between several branches. (Having the current\nbranch in your bash prompt is a *big* help here, but we can't count on\nthem having it.)\n\nSo setting up a solution where each branch gets its own working\ndirectory is a great solution where you have some number of newbie\ndevelopers in a company that get easily confused, while still\nproviding advanced users the ability to use the full power of git, and\ngiving both the newbie and advanced users the advantages of\ndisconnected operations. And, of course, hopefully some day the\nnewbie users will grow up to become advanced users.\n\nRight now I suspect a number of projects who have picked hg or bzr do\nso because the traditional git model is too confusing to newbie users.\nSo for those people, creating the model where branch == a separate\ndirectory may make life easier for them. That's probably the one\nthing that bzr does much better than git; it has a number of modes\nwhich act as training wheels for the easily confused user. For\nexample, the bzr's \"bound branch\" requires you to have network access,\nsince anything that modifies the local repository requires hitting the\nremote server as well. Horrible! Gives you all of the downsides of\nCVS! But it allows some users to use the SCM is CVS-style mode, while\nallowing more advanced users to use it in a more distributed mode.\n\nSo I think it *is* useful to help the corporate developers, because\nthat means there are more git users --- and someday some of us on this\nlist might have to work at such a company, and better that they use\ngit than something like perforce or Clearcase, right? :-)\n\n> However, *do think* of the free software developers who have been using\n> CVS forever. You won't make friends among them if you keep saying, \"you\n> use CVS? You are brain-damaged, then.\" \n\nFair enough. I used the term somewhat toungue-in-cheek, and I\nprobably should have said \"newbie user\" instead.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"57219","messageId":"7vejfj11tk.fsf@gitster.siamese.dyndns.org","threadId":"10194","inReplyTo":"4720CCE0.2090007@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-25T18:33:43Z","receivedAt":"2007-10-25T18:33:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> However, there's still this issue:\n> $ git checkout -b foo origin/pu\n> Branch foo set up to track remote branch refs/remotes/origin/pu.\n> Switched to a new branch \"foo\"\n>\n> git checkout will say that every time a branch is created from a\n> tracking branch, unless one tells it --no-track (which people don't\n> learn about unless they're really into git), so it's quite natural\n> that people think git will actually make sure, within reasonable\n> limits, that 'foo' is kept in sync with refs/remotes/origin/pu.\n> That's not the case, however.\n>\n> So we could either change the message to be:\n> \"Branch foo set up to track remote branch refs/remotes/origin/pu,\n> provided you only ever issue git-pull while having branch foo\n> checked out.\"\n>\n> Or we could make 'git checkout -b' default to --no-track, perhaps\n> giving annoying messages everytime someone \"git-checkout -b\"'s a\n> remote tracking branch.\n> Or we could make git-pull keep git checkout's promises.\n\nThe thing is, if you have 200 local branches (because you\ninteract with 50 repositories with 4 primary branches each), you\ndo not constantly check all of them out anyway. And the only\nplace that staleness of the local tracking fork matters is when\nyou check it out (that is, as long as you train your users that\nthe way to check differences with the upstream 'pu' in your case\nis by doing operations with 'origin/pu' not with your local\n'foo').\n\nWith that in mind, how about making \"git checkout foo\", after\nfoo is set up thusly, to show:\n\n\tgit log --pretty=oneline --left-right origin/pu...foo\n\nif (and only if) they have diverged? Then you can deal with the\nstaleness of local tracking fork 'foo' in any way you want.\n\nYou could even go one step further and make this \"checkout foo\",\nin addition to or instead of showing the above left-right log,\n\n - automatically run \"git merge origin/pu\" if it is a\n fast-forward, and say it did _not_ run that merge if it is\n not a fast-forward;\n\n - automatically run \"git merge origin/pu\" always, even if it is\n not a fast-forward;\n\n - automatically run \"git rebase origin/pu\" always;\n\nWould that make your life easier?\n"},{"id":"57221","messageId":"87r6jjrp6k.wl%cworth@cworth.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710230017120.25221@racer.site","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-10-25T19:04:35Z","receivedAt":"2007-10-25T19:04:35Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 23 Oct 2007 00:21:03 +0100 (BST), Johannes Schindelin wrote:\n> On Mon, 22 Oct 2007, Federico Mena Quintero wrote:\n> >\n> > The \"branches should not track their origin by default\"\n\n\nDid this change recently? I just wrote a long message arguing for the\n\"autosetupmerge = 1\" behavior by default, but when I tested with\n1.5.3.4 it seems to be there already.\n\nAm I seeing that correctly?\n\nIf so, thank you and congratulations! Not having to pass --track nor\nmanually configure autosetupmerge to get this very useful behavior is\na very nice change!\n\nA nice followup would be to improve the documentation for \"git pull\"\nto better indicate some of the smarts that are now inherent in it.\n\nI'll take a whack at that, (just as soon as I finish reading the rest\nof this giant thread...).\n\n-Carl\n"},{"id":"57228","messageId":"4720F7AE.7020603@op5.se","threadId":"10194","inReplyTo":"1193335339.4522.398.camel@cacharro.xalalinux.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T20:08:14Z","receivedAt":"2007-10-25T20:08:14Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Federico Mena Quintero wrote:\n> On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:\n> \n>> And of course it's inelegant. You just told us we were dealing with\n>> CVS-brain-damaged corporate developers who can't be bothered to learn\n>> about the fine points of using things the git way.\n> \n> Ignore the corporate developers who use SCMs only because their company\n> requires them to. Git is not the right thing for them;\n\nQuite contrary to what I think, and quite contrary to what Linus said in\nhis google speach. The problem with using a chainsaw instead of a tooth-\npick is that it's much easier to hurt yourself with a chainsaw. It's a\nlot easier to get real work done though.\n\n> some\n> Eclipse-based monstrosity probably is. It's like the horrendous\n> Oracle-based expense-reporting thing we have to use at Novell; I use it\n> because they make me, not because I'm particularly excited about\n> reporting expenses :)\n> \n\nNobody's particularly excited about reporting expenses. That's why there\nare so few OSS solutions for it, and the ones that exist suck horribly\nbecause whoever got the job of making the system knew his users would\nsimply hate it, no matter how perfect it was. It's one of those things ;-)\n\n> However, *do think* of the free software developers who have been using\n> CVS forever. You won't make friends among them if you keep saying, \"you\n> use CVS? You are brain-damaged, then.\" CVS has been as good/bad to\n> them as to anyone else, and they are probably delighted to get a better\n> solution. That solution needs to take into account the concepts to\n> which they have been exposed for the past N years. Just because your\n> new concepts are better, doesn't mean that their old ones were wrong in\n> their time.\n> \n\nWell, perhaps they were. CVS was a fairly important learning phase, much\nlike Thomas Edison who first discovered 2000 ways of not making a light-\nbulb. It doesn't make them less valuable though, and the reason to keep\ngoing until perfection is reached is that machines are made for work, and\nhumans are made for fun.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57230","messageId":"4720FA00.1050805@op5.se","threadId":"10194","inReplyTo":"7vejfj11tk.fsf@gitster.siamese.dyndns.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T20:18:08Z","receivedAt":"2007-10-25T20:18:08Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson writes:\n> \n>> However, there's still this issue:\n>> $ git checkout -b foo origin/pu\n>> Branch foo set up to track remote branch refs/remotes/origin/pu.\n>> Switched to a new branch \"foo\"\n>>\n>> git checkout will say that every time a branch is created from a\n>> tracking branch, unless one tells it --no-track (which people don't\n>> learn about unless they're really into git), so it's quite natural\n>> that people think git will actually make sure, within reasonable\n>> limits, that 'foo' is kept in sync with refs/remotes/origin/pu.\n>> That's not the case, however.\n>>\n>> So we could either change the message to be:\n>> \"Branch foo set up to track remote branch refs/remotes/origin/pu,\n>> provided you only ever issue git-pull while having branch foo\n>> checked out.\"\n>>\n>> Or we could make 'git checkout -b' default to --no-track, perhaps\n>> giving annoying messages everytime someone \"git-checkout -b\"'s a\n>> remote tracking branch.\n>> Or we could make git-pull keep git checkout's promises.\n> \n> The thing is, if you have 200 local branches (because you\n> interact with 50 repositories with 4 primary branches each), you\n> do not constantly check all of them out anyway. And the only\n> place that staleness of the local tracking fork matters is when\n> you check it out (that is, as long as you train your users that\n> the way to check differences with the upstream 'pu' in your case\n> is by doing operations with 'origin/pu' not with your local\n> 'foo').\n> \n\nProbably, although I think the confusion of 'foo' being something\nelse than 'origin/pu' after it's been checked out would be hard\nto explain. I'll see how the patch turns out. If it all goes tits\nup, I'll see if a post-checkout hook can solve it.\n\n> With that in mind, how about making \"git checkout foo\", after\n> foo is set up thusly, to show:\n> \n> \tgit log --pretty=oneline --left-right origin/pu...foo\n> \n> if (and only if) they have diverged? Then you can deal with the\n> staleness of local tracking fork 'foo' in any way you want.\n> \n> You could even go one step further and make this \"checkout foo\",\n> in addition to or instead of showing the above left-right log,\n> \n> - automatically run \"git merge origin/pu\" if it is a\n> fast-forward, and say it did _not_ run that merge if it is\n> not a fast-forward;\n> \n> - automatically run \"git merge origin/pu\" always, even if it is\n> not a fast-forward;\n> \n> - automatically run \"git rebase origin/pu\" always;\n> \n> Would that make your life easier?\n\nThat it would, except the confusion would then be that it's automatically\nrebased for the branches one currently hasn't got checked out while pulling,\nand the branch that *is* checked out gets merged (crazy, yes), so those\nwho prefer the rebase would get what they want by doing something completely\nbonkers, such as:\n\ngit checkout -b just-gonna-pull HEAD^\ngit pull\ngit checkout whatever-other-branch-they-were-on\n\n(yes, \"aggresively ignorant\", I think Ted said in an earlier mail)\n\nIt'd probably be better to go with Dscho's suggestion, although I'm not quite\nsure what that was any more. It involved automagical rebasing on fetch or pull\nthough.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57231","messageId":"4720FA6E.9040805@op5.se","threadId":"10194","inReplyTo":"1193335562.4522.403.camel@cacharro.xalalinux.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-25T20:19:58Z","receivedAt":"2007-10-25T20:19:58Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Federico Mena Quintero wrote:\n> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:\n> \n>> It's definitely not a simple cut-and-paste--even with permission from\n>> the author of \"Git for computer scientists\", fitting this in would\n>> require rethinking the ordering of topics in the manual.\n> \n> Oh, that can be done. It's easier to move text around than to\n> rearchitect code :)\n> \n\nIt misses the point though. Machines should work while humans are\nlounging. If the humans have to read a lot to get the machines to\nwork, there's less time for lounging ;-)\n\n>> Also, there's\n>> the restriction that we'd like to keep it looking good in plain ascii,\n>> so diagrams have to be done in ascii somehow.\n> \n> Hmm, what's the rationale for this? I'd assume that most people read\n> the user's manual as a web page (or as bedside reading if they can print\n> a PDF thereof), where diagrams can be pretty.\n> \n\nman pages.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57235","messageId":"20071025202744.GE31888@fieldses.org","threadId":"10194","inReplyTo":"4720FA6E.9040805@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-10-25T20:27:44Z","receivedAt":"2007-10-25T20:27:44Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Oct 25, 2007 at 10:19:58PM +0200, Andreas Ericsson wrote:\n> Federico Mena Quintero wrote:\n>> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:\n>>> Also, there's\n>>> the restriction that we'd like to keep it looking good in plain ascii,\n>>> so diagrams have to be done in ascii somehow.\n>> Hmm, what's the rationale for this? I'd assume that most people read\n>> the user's manual as a web page (or as bedside reading if they can print\n>> a PDF thereof), where diagrams can be pretty.\n>\n> man pages.\n\nI think he's talking about Documentation/user-manual.txt, which isn't\nturned into man pages. (Might be nice if it could be though, I\nsuppose.)\n\n--b.\n"},{"id":"57256","messageId":"1193373682-3608-1-git-send-email-stevenrwalter@gmail.com","threadId":"10194","inReplyTo":"1193328386.4522.352.camel@cacharro.xalalinux.org","subject":"[PATCH] Make rebase smarter","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2007-10-26T04:41:22Z","receivedAt":"2007-10-26T04:41:22Z","isPatch":true,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"It is a common workflow to run \"git fetch; git rebase origin/\" Where\nfoo is the remote tracking branch. git-rebase should default to using\nthe remote tracking branch if no other ref is given.\n\nSigned-off-by: Steven Walter \n---\n git-rebase.sh | 13 ++++++++++++-\n 1 files changed, 12 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 058fcac..1a2b51b 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -261,8 +261,19 @@ case \"$diff\" in\n \t;;\n esac\n \n-# The upstream head must be given. Make sure it is valid.\n upstream_name=\"$1\"\n+# Default to the remote tracking branch if we have one\n+if [ -z \"$upstream_name\" ]\n+then\n+\tcurr_branch=$(git symbolic-ref -q HEAD)\n+\tcurr_branch=${curr_branch//refs\\/heads\\//}\n+\tmerge=$(git config branch.$curr_branch.merge)\n+\tremote=$(git config branch.$curr_branch.remote)\n+\tfetch=$(git config remote.$remote.fetch)\n+\n+\texpanded=$(git fetch--tool expand-refs-wildcard \"0000000000000000000000000000000000000000 $merge\" \"$remote\" \"$fetch\")\n+\tupstream_name=${expanded/#*:/}\n+fi\n upstream=`git rev-parse --verify \"${upstream_name}^0\"` ||\n die \"invalid upstream $upstream_name\"\n \n-- \n1.5.3.4.1.gb4ad62-dirty\n"},{"id":"57257","messageId":"D38E4717-CF67-4897-983E-2B45CA217C11@zib.de","threadId":"10194","inReplyTo":"4720FA00.1050805@op5.se","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-26T06:18:27Z","receivedAt":"2007-10-26T06:18:27Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 25, 2007, at 10:18 PM, Andreas Ericsson wrote:\n\n> Junio C Hamano wrote:\n>> Andreas Ericsson writes:\n>\n>> With that in mind, how about making \"git checkout foo\", after\n>> foo is set up thusly, to show:\n>> \tgit log --pretty=oneline --left-right origin/pu...foo\n>> if (and only if) they have diverged? Then you can deal with the\n>> staleness of local tracking fork 'foo' in any way you want.\n>> You could even go one step further and make this \"checkout foo\",\n>> in addition to or instead of showing the above left-right log,\n>> - automatically run \"git merge origin/pu\" if it is a\n>> fast-forward, and say it did _not_ run that merge if it is\n>> not a fast-forward;\n>> - automatically run \"git merge origin/pu\" always, even if it is\n>> not a fast-forward;\n>> - automatically run \"git rebase origin/pu\" always;\n>> Would that make your life easier?\n>\n> That it would, except the confusion would then be that it's \n> automatically\n> rebased for the branches one currently hasn't got checked out while \n> pulling,\n> and the branch that *is* checked out gets merged (crazy, yes), so \n> those\n> who prefer the rebase would get what they want by doing something \n> completely\n> bonkers, such as:\n>\n> git checkout -b just-gonna-pull HEAD^\n> git pull\n> git checkout whatever-other-branch-they-were-on\n>\n> (yes, \"aggresively ignorant\", I think Ted said in an earlier mail)\n>\n> It'd probably be better to go with Dscho's suggestion, although I'm \n> not quite\n> sure what that was any more. It involved automagical rebasing on \n> fetch or pull\n> though.\n\ngit pull's automagic and the automatic behaviour of git checkout\nproposed by Junio should always do the same. git pull should\nbe changed to act a if your three commands were fused into it\n(but obviously implemented differently).\n\nI think teaching \"git checkout\" a dwim mode is quite\ninteresting. The required work to bring a local branch\nup-to-date with a remote branch is deferred until really needed.\nAn then \"git checkout\" does the right thing. A lot of automagic\nbut definitely intriguing.\n\n\tSteffen\n"},{"id":"57263","messageId":"47219A51.9090001@op5.se","threadId":"10194","inReplyTo":"1193373682-3608-1-git-send-email-stevenrwalter@gmail.com","subject":"Re: [PATCH] Make rebase smarter","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-26T07:42:09Z","receivedAt":"2007-10-26T07:42:09Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Steven Walter wrote:\n> It is a common workflow to run \"git fetch; git rebase origin/\" Where\n> foo is the remote tracking branch. git-rebase should default to using\n> the remote tracking branch if no other ref is given.\n> \n\nI like it. :)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57264","messageId":"47219CFD.3010409@op5.se","threadId":"10194","inReplyTo":"D38E4717-CF67-4897-983E-2B45CA217C11@zib.de","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-26T07:53:33Z","receivedAt":"2007-10-26T07:53:33Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Steffen Prohaska wrote:\n> \n> On Oct 25, 2007, at 10:18 PM, Andreas Ericsson wrote:\n> \n>> Junio C Hamano wrote:\n>>> Andreas Ericsson writes:\n>>\n>>> With that in mind, how about making \"git checkout foo\", after\n>>> foo is set up thusly, to show:\n>>> git log --pretty=oneline --left-right origin/pu...foo\n>>> if (and only if) they have diverged? Then you can deal with the\n>>> staleness of local tracking fork 'foo' in any way you want.\n>>> You could even go one step further and make this \"checkout foo\",\n>>> in addition to or instead of showing the above left-right log,\n>>> - automatically run \"git merge origin/pu\" if it is a\n>>> fast-forward, and say it did _not_ run that merge if it is\n>>> not a fast-forward;\n>>> - automatically run \"git merge origin/pu\" always, even if it is\n>>> not a fast-forward;\n>>> - automatically run \"git rebase origin/pu\" always;\n>>> Would that make your life easier?\n>>\n>> That it would, except the confusion would then be that it's automatically\n>> rebased for the branches one currently hasn't got checked out while \n>> pulling,\n>> and the branch that *is* checked out gets merged (crazy, yes), so those\n>> who prefer the rebase would get what they want by doing something \n>> completely\n>> bonkers, such as:\n>>\n>> git checkout -b just-gonna-pull HEAD^\n>> git pull\n>> git checkout whatever-other-branch-they-were-on\n>>\n>> (yes, \"aggresively ignorant\", I think Ted said in an earlier mail)\n>>\n>> It'd probably be better to go with Dscho's suggestion, although I'm \n>> not quite\n>> sure what that was any more. It involved automagical rebasing on fetch \n>> or pull\n>> though.\n> \n> git pull's automagic and the automatic behaviour of git checkout\n> proposed by Junio should always do the same. git pull should\n> be changed to act a if your three commands were fused into it\n> (but obviously implemented differently).\n> \n\nI think it would be better to implement it as a different command that\nwould do all those weird and tedious dwim things that suit a particular\nkind of developer, but only so long as those operations succeed without\nconflicts.\n\nSo for example the flow could go something like this;\n---\nread_branch_merge_config();\n\ngit fetch\n\nif prefetch(local == remote_tracking)\n\tset ref local to match ref remote_tracking;\nelse if (--safe-rebase)\n\ttry_rebase local onto remote_tracking;\n---\n\nIt's such a common operation that I really do think it's worth\nhaving support for it. Perhaps with a \"--try-rebase\" option to\ngit-pull.\n\nIf we then add a a \"--push-after-pull\" (to work on the current\nbranch only) we have the \"git sync\" alias readily available to\naccommodate the average reluctant git user, and I'm sure gui\nhackers could do wonders with it, especially on windows, where\npeople seem accustomed to a lot of things happening when clicking\na single button.\n\n> I think teaching \"git checkout\" a dwim mode is quite\n> interesting. The required work to bring a local branch\n> up-to-date with a remote branch is deferred until really needed.\n> An then \"git checkout\" does the right thing. A lot of automagic\n> but definitely intriguing.\n> \n\nYup, and it can be done with a post-checkout hook (which I notice\nthere are no examples for, so I've added that to my ever-growing\ntodo).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57268","messageId":"86fxzy2q0y.fsf@lola.quinscape.zz","threadId":"10194","inReplyTo":"20071025202744.GE31888@fieldses.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-26T09:17:49Z","receivedAt":"2007-10-26T09:17:49Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Thu, Oct 25, 2007 at 10:19:58PM +0200, Andreas Ericsson wrote:\n>> Federico Mena Quintero wrote:\n>>> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:\n>>>> Also, there's\n>>>> the restriction that we'd like to keep it looking good in plain ascii,\n>>>> so diagrams have to be done in ascii somehow.\n>>> Hmm, what's the rationale for this? I'd assume that most people read\n>>> the user's manual as a web page (or as bedside reading if they can print\n>>> a PDF thereof), where diagrams can be pretty.\n>>\n>> man pages.\n>\n> I think he's talking about Documentation/user-manual.txt, which\n> isn't turned into man pages. (Might be nice if it could be though,\n> I suppose.)\n\nI think it would be nicer if the man pages could be turned into an\nappendix in the user manual.\n\nI had no success in persuading the toolchain to do that, however.\n_WAY_ above my head to figure out the interaction of Docbook, Asciidoc\nand similar in order to achieve that effect.\n\n-- \nDavid Kastrup\n"},{"id":"57270","messageId":"Pine.LNX.4.64.0710261054300.4362@racer.site","threadId":"10194","inReplyTo":"1193373682-3608-1-git-send-email-stevenrwalter@gmail.com","subject":"Re: [PATCH] Make rebase smarter","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-26T09:57:12Z","receivedAt":"2007-10-26T09:57:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 26 Oct 2007, Steven Walter wrote:\n\n> It is a common workflow to run \"git fetch; git rebase origin/\" \n> Where foo is the remote tracking branch. git-rebase should default to \n> using the remote tracking branch if no other ref is given.\n\nThis is potentially dangerous, as git-rebase does not use a detached HEAD \nto replay the operations. Therefore you cannot go back easily when \nyou started \"git rebase\" just to see its usage, and instead it did \nunwanted things.\n\nSo I really think that you need a patch before this one, so that\n\n\tgit reset --hard @{1}\n\ngoes back to the pre-merge state after an inadvertent rebase. (Note: this \nbehaviour is already implemented in rebase -i, because detached HEAD was \navailable at that time, as opposed to the time when git-rebase was \nwritten.)\n\nCiao,\nDscho\n"},{"id":"57303","messageId":"85r6jh3as2.fsf@lola.goethe.zz","threadId":"10194","inReplyTo":"1193335339.4522.398.camel@cacharro.xalalinux.org","subject":"Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-26T20:01:49Z","receivedAt":"2007-10-26T20:01:49Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Federico Mena Quintero writes:\n\n> You don't find quantum physicists saying, \"... yeah, like Newton's\n> brain-damaged followers\" :)\n\nOh, one does get this sort of comments. Predominantly from those who\nunderstand neither theory.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"57309","messageId":"7vk5p9wpwd.fsf@gitster.siamese.dyndns.org","threadId":"10194","inReplyTo":"1193373682-3608-1-git-send-email-stevenrwalter@gmail.com","subject":"Re: [PATCH] Make rebase smarter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-26T21:02:26Z","receivedAt":"2007-10-26T21:02:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Walter writes:\n\n> It is a common workflow to run \"git fetch; git rebase origin/\" Where\n> foo is the remote tracking branch. git-rebase should default to using\n> the remote tracking branch if no other ref is given.\n\nThis would be a reasonable choice between refusing outright and\npicking one possible action. I do not have a strong preference\nas to what that \"one possible action\" should be, but if people\nlike to base on the remote tracking branch set to merge by\ndefault, I am fine with it.\n\n> +\tcurr_branch=$(git symbolic-ref -q HEAD)\n> +\tcurr_branch=${curr_branch//refs\\/heads\\//}\n> +\tmerge=$(git config branch.$curr_branch.merge)\n> +\tremote=$(git config branch.$curr_branch.remote)\n> +\tfetch=$(git config remote.$remote.fetch)\n> +\n> +\texpanded=$(git fetch--tool expand-refs-wildcard \"0000000000000000000000000000000000000000 $merge\" \"$remote\" \"$fetch\")\n> +\tupstream_name=${expanded/#*:/}\n> +fi\n> upstream=`git rev-parse --verify \"${upstream_name}^0\"` ||\n> die \"invalid upstream $upstream_name\"\n\n * How does this work if there is no such tracking configuration?\n\n - branch..merge may be missing;\n - branch..remote may be missing;\n - remote..fetch may be explicit, multiple and/or non-wildcard;\n\n * ${parameter/pattern/string} is a bashism we do not allow in\n git scripts.\n\nProblems in the implementation aside, it probably makes sense to\nfirst have a helper function that takes a local branch name and\ncomputes the remote tracking branch that a given local branch is\nset to merge from, if exists, and use it here. I suspect there\nare other places in the Porcelain that would benefit from such a\nhelper function.\n"},{"id":"57315","messageId":"Pine.LNX.4.64.0710270013030.4362@racer.site","threadId":"10194","inReplyTo":"7vk5p9wpwd.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Make rebase smarter","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-26T23:13:56Z","receivedAt":"2007-10-26T23:13:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 26 Oct 2007, Junio C Hamano wrote:\n\n> Steven Walter writes:\n> \n> > It is a common workflow to run \"git fetch; git rebase origin/\" \n> > Where foo is the remote tracking branch. git-rebase should default to \n> > using the remote tracking branch if no other ref is given.\n> \n> This would be a reasonable choice between refusing outright and\n> picking one possible action.\n\nAnother sensible choice would be \"git rebase FETCH_HEAD\", at least just \nafter a \"git fetch \"...\n\nCiao,\nDscho\n"},{"id":"57318","messageId":"7vtzodv4j5.fsf@gitster.siamese.dyndns.org","threadId":"10194","inReplyTo":"Pine.LNX.4.64.0710270013030.4362@racer.site","subject":"Re: [PATCH] Make rebase smarter","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-26T23:29:18Z","receivedAt":"2007-10-26T23:29:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 26 Oct 2007, Junio C Hamano wrote:\n>\n>> Steven Walter writes:\n>> \n>> > It is a common workflow to run \"git fetch; git rebase origin/\" \n>> > Where foo is the remote tracking branch. git-rebase should default to \n>> > using the remote tracking branch if no other ref is given.\n>> \n>> This would be a reasonable choice between refusing outright and\n>> picking one possible action.\n>\n> Another sensible choice would be \"git rebase FETCH_HEAD\", at least just \n> after a \"git fetch \"...\n\nWe can get the best of both worlds by noticing a line in\nFETCH_HEAD without not-for-merge marker and use that as the\n'onto' commit for the rebase.\n"}]}