{"thread":{"id":"3239","subject":"2 questions/nits about commit and config","startedAt":"2006-02-04T21:23:37Z","lastAt":"2006-02-05T06:14:08Z","messageCount":8,"participants":["Michael Fischer","Junio C Hamano","Alan Chandler","Keith Packard","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15583","messageId":"20060204212337.GA8612@blinkenlights.visv.net","threadId":"3239","inReplyTo":null,"subject":"2 questions/nits about commit and config","fromName":"Michael Fischer","fromEmail":"michael@visv.net","sentAt":"2006-02-04T21:23:37Z","receivedAt":"2006-02-04T21:23:37Z","isPatch":false,"sender":{"key":"michael@visv.net","avatar":null},"body":"\nHi.\n\nWell, I went ahead and put my current project under git. So far so good.\n\nTwo nits: (yeah, I'm a \"recovering\" CVS user)\n\n1) git commit -m\"this is a commit message\"  doesn't work. \n   It has to have a space between -m and the first '\"'. \n   I *think* this is due to git-commit.sh and how it parses\n   the args, but I'm not quite sure of how to try to patch\n   that without mucking up the whole works. Very odd\n   and hard to figure out what was \"wrong\" for a CVS user.\n\n2) I can descend into subdirectories in my project, and \n   git diff, git status both work fine, but git commit\n   gets annoyed and says \"fatal: Not a git repository: '.git'\".\n   Irksome to say the least, and not a little suprising.\n   Is that something which can be fixed, or is there a \n   magic incantation (perhaps in .git/config) to make\n   git commit work anywhere in the source tree?\n\nIncidentally, I groped around my git mailbox, and google,\nlooking for some definitive list/examples of what can\ngo in the .git/config file. Seems there must be more\nthan what is listed in the manpage...\n\nThanks for all the cool work.\n\n\nMichael\n-- \nMichael Fischer                         Happiness is a config option.\nmichael@visv.net                        Recompile and be happy. \n"},{"id":"15585","messageId":"7voe1mvkls.fsf@assigned-by-dhcp.cox.net","threadId":"3239","inReplyTo":"20060204212337.GA8612@blinkenlights.visv.net","subject":"Re: 2 questions/nits about commit and config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-04T22:13:03Z","receivedAt":"2006-02-04T22:13:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Fischer <michael@visv.net> writes:\n\n> 1) git commit -m\"this is a commit message\"  doesn't work. \n>    It has to have a space between -m and the first '\"'. \n\nWell that is a minor inconvenience and would be trivial to\naccomodate, but please do not send patches in yet.  I do not\nknow if you have been following the list discussion, but it\nseems very likely that we will update the way git-commit command\nworks slightly in other semantic aspects and I do not want to\nworry about trivialities.  Duly noted and I'll try to remember\nthat command line parsing issue when we do a rewrite.\n\n> 2) I can descend into subdirectories in my project, and \n>    git diff, git status both work fine, but git commit\n>    gets annoyed..\n\nThis is more or less deliberate, and I personally do not have a\nstrong reason to change it (except perhaps making the error\nmessage a bit more helpful) even when we do a rewrite.\n\nUnlike CVS that does version control per file basis, commit in\ngit is really about the whole tree state, so even if we changed\n'git commit' to work from subdirectories that would commit\neverything, which would probably be more confusing.  That is,\nuntil somebody comes up with a good semantics and rationale why\nallowing that semantics is a good change and the code to do so.\n\nAn example of such semantic change would be: if I am in\nsubdirecotry foo/, commit changes to files in that subdirectory\nand subdirectory alone.  But that is actively _encouraging_\npartial commits (commits that records a state that never existed\nin your working tree as a whole) so I personally am not so\nenthused to buy such a _feature_.\n"},{"id":"15586","messageId":"7vhd7evk38.fsf@assigned-by-dhcp.cox.net","threadId":"3239","inReplyTo":"7voe1mvkls.fsf@assigned-by-dhcp.cox.net","subject":"Re: 2 questions/nits about commit and config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-04T22:24:11Z","receivedAt":"2006-02-04T22:24:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> An example of such semantic change would be: if I am in\n> subdirecotry foo/, commit changes to files in that subdirectory\n> and subdirectory alone.  But that is actively _encouraging_\n> partial commits (commits that records a state that never existed\n> in your working tree as a whole) so I personally am not so\n> enthused to buy such a _feature_.\n\nBefore people start complaining about it, I take this part\nback.  \"git commit -a\" inside a subdirectory \"foo\" is not much\ndifferent from \"git commit foo/a foo/b foo/c\" from the toplevel\ndirectory to explicitly say \"Don't worry about what I told the\nindex so far; I want to check in changes only to these paths\",\nand making a partial commit out of the current HEAD and the\nspecified working tree files using a temporary index (while\nupdating the main index at the same time), so I am inclined to\nsay we should support it that way, since during the previous\ndiscussion we have pretty much settled how we would want \"git\ncommit paths...\" and \"git commit --include paths...\" commands to\nbehave.\n"},{"id":"15588","messageId":"200602042259.27080.alan@chandlerfamily.org.uk","threadId":"3239","inReplyTo":"7vhd7evk38.fsf@assigned-by-dhcp.cox.net","subject":"Re: 2 questions/nits about commit and config","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-02-04T22:59:26Z","receivedAt":"2006-02-04T22:59:26Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Saturday 04 February 2006 22:24, Junio C Hamano wrote:\n> Junio C Hamano <junkio@cox.net> writes:\n> > An example of such semantic change would be: if I am in\n> > subdirecotry foo/, commit changes to files in that subdirectory\n> > and subdirectory alone.  But that is actively _encouraging_\n> > partial commits (commits that records a state that never existed\n> > in your working tree as a whole) so I personally am not so\n> > enthused to buy such a _feature_.\n>\n> Before people start complaining about it, I take this part\n> back.  \"git commit -a\" inside a subdirectory \"foo\" is not much\n> different from \"git commit foo/a foo/b foo/c\" from the toplevel\n> directory to explicitly say \"Don't worry about what I told the\n> index so far; I want to check in changes only to these paths\",\n> and making a partial commit out of the current HEAD and the\n> specified working tree files using a temporary index (while\n> updating the main index at the same time), so I am inclined to\n> say we should support it that way, since during the previous\n> discussion we have pretty much settled how we would want \"git\n> commit paths...\" and \"git commit --include paths...\" commands to\n> behave.\n\nAnd I did describe a use case this morning in another thread for this very \nthing.  For convenience I repeat it here\n\n[Incidentally there is a use case that doesn't seem to have been discussed in \nthis thread which I use cg-commit all the time for and will now have to see \nif there is a use index file equivalence for.  That is, I am developing a web \napplication and in the running version the database framework (iBatis) is \nusing Tomcats connection pooling.  In order to run my JUnit test harness, I \ndon't have tomcat, so I need to define a different version of iBatis \nconfiguration file to used its own database connection.  So I have created a \ntest branch and edited the configuration file in that branch, and I update \nboth code and tests in a edit/compile/fix and text loop until I have written \nor changed both code and tests.  I then do a cg-commit which lists the files \nI have changed.  I ONLY commit those in the test harness - by deleting the \nothers from cogito's list of files to commit - and then repeat the commit \ncommiting the rest].  I then switch back to my master branch and cherry pick \ncommit that is the code changes - not the text harness]\n\nIn this case the tests, and the code that it was testing were in different \nsubdirectories, so the ability to go into one directory and commit all in \nthat directory, followed by the ability to go into the other and do the same \nwould be extremely useful.\n\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\nOpen Source. It's the difference between trust and antitrust.\n"},{"id":"15589","messageId":"1139094055.4200.6.camel@evo.keithp.com","threadId":"3239","inReplyTo":"7vhd7evk38.fsf@assigned-by-dhcp.cox.net","subject":"Re: 2 questions/nits about commit and config","fromName":"Keith Packard","fromEmail":"keithp@keithp.com","sentAt":"2006-02-04T23:00:54Z","receivedAt":"2006-02-04T23:00:54Z","isPatch":false,"sender":{"key":"keithp@keithp.com","avatar":"https://gravatar.com/avatar/fa1f479cdd51322fe86215c955a81d296bbf66a1fe625f8a12d87a8ec7faf648?d=mp&s=160"},"body":"On Sat, 2006-02-04 at 14:24 -0800, Junio C Hamano wrote:\n\n> Before people start complaining about it, I take this part\n> back.  \"git commit -a\" inside a subdirectory \"foo\" is not much\n> different from \"git commit foo/a foo/b foo/c\" from the toplevel\n> directory \n\nmaking '-a' equivalent to '.' then? Seems like '.' is a whole lot more\nunderstandable than '-a', but maybe that's just my naïvité showing\nagain. I expected the '-a' flag to commit the whole tree from wherever\nyou were inside it...\n  \n-- \nkeith.packard@intel.com\n"},{"id":"15600","messageId":"7vu0bemkce.fsf@assigned-by-dhcp.cox.net","threadId":"3239","inReplyTo":"1139094055.4200.6.camel@evo.keithp.com","subject":"Re: 2 questions/nits about commit and config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-05T05:43:29Z","receivedAt":"2006-02-05T05:43:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Keith Packard <keithp@keithp.com> writes:\n\n> making '-a' equivalent to '.' then? Seems like '.' is a whole lot more\n> understandable than '-a', but maybe that's just my naïvité showing\n> again. I expected the '-a' flag to commit the whole tree from wherever\n> you were inside it...\n\nGood point.\n\nBecause I _never_ use 'git commit paths...'  form myself, I\nadmit that I did not even know that \"git commit .\"  meant\n\"commit all the changed files in this directory and under\".\n\nBut it apparently does ;-).\n\nI would not personally be confused if \"cd foo/ && git commit -a\"\ncommitted things outside foo/ directory, but I am not sure about\nothers.\n\nWe have had enough discussion on what the \"git commit paths..\"\nsemantics should be, and I think we settled most of the issues.\nUntil this latest \"committing from subdirectory\" monkey wrench\nwas thrown into it, that is X-<.\n\nHere is me thinking aloud again.\n\n - \"git commit\" without _any_ parameter would keep the current\n   behaviour.  It commits the current index.\n\n   We have two choices.  (1) we disallow this form to be run in\n   a subdirectory, or (2) we do the whole index even when this\n   form was run from a subdirectory.  I am inclined to say the\n   latter.\n\n - \"git commit --include paths...\" (or \"git commit -i paths...\")\n   is equivalent to:\n\n   \tgit update-index --remove paths...\n        git commit\n\n   So subdirectory semantics depends entirely on what we do for\n   the parameterless form.  Also note that we allow --remove but\n   never --add; this is what we do for \"git commit paths..\"\n   currently.\n\n - \"git commit paths...\" acquires a new semantics.  This is an\n   incompatible change that needs user training, which I am\n   still a bit reluctant to swallow, but enough people seem to\n   have complained.  It\n\n   1. refuses to run if $GIT_DIR/MERGE_HEAD exists (maybe\n      remind trained git users that the traditional semantics\n      now needs -i flag).\n   2. refuses to run if named paths... are different in HEAD and\n      the index (ditto about reminding).\n   3. reads HEAD commit into a temporary index file.\n   4. updates named paths... from the working tree in this\n      temporary index (similar to -i form, we never --add).\n   5. does the same updates of the paths... from the working\n      tree to the real index.\n   6. makes a commit using the temporary index that has the\n      current HEAD as the parent, and updates the HEAD with this\n      new commit.\n\n   The first check is needed because otherwise during a merge\n   you would end up inserting an unrelated commit between the\n   original HEAD and the eventual merge result.  The second\n   check is to prevent \"skewed commit\" from confusing people.\n   If you updated index, modified the file further and then used\n   \"git commit paths...\" to make a commit, next \"git commit\"\n   without paths would record a partial revert otherwise.\n\n   For this one, I think running from subdirectory is a natural\n   thing to allow.\n\n - \"git commit --all\".  Now what should we do about this?  As\n   you reminded me, it is equivalent to \"git commit -i .\" if run\n   from the toplevel (because of the \"index must match HEAD on\n   named paths\" requirements for the partial commits with named\n   paths, it is equivalent to \"git commit .\" only if your index\n   is clean).  I am inclined to say that this should commit all\n   changes in the whole working tree, regardless of where it is\n   run.\n"},{"id":"15602","messageId":"7vek2imjmt.fsf@assigned-by-dhcp.cox.net","threadId":"3239","inReplyTo":"7vu0bemkce.fsf@assigned-by-dhcp.cox.net","subject":"Re: 2 questions/nits about commit and config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-05T05:58:50Z","receivedAt":"2006-02-05T05:58:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Here is me thinking aloud again.\n\nBefore I started writing this message, I meant to address an\nexcellent point Carl Worth raised in an earlier thread.  \"What\nwould I do for final sanity check before committing?\".  So here\nis a follow-up.\n\n>  - \"git commit\"\n\n\"git diff --cached HEAD\".\n\n>  - \"git commit --include paths...\" (or \"git commit -i paths...\")\n\nThis is for people who work by taking advantage of the power of\nthe index file, i.e. perform \"checking in without committing\" by\nrunning update-index whenever the changes so-far look good.\nCombined use of \"git diff --cached HEAD\" (to look at diffs for\npaths other than paths...) and \"git diff HEAD paths...\" would be\nthe _full_ \"final sanity check\", but in practice \"git diff HEAD\npaths...\" or even \"git diff paths...\" would be more useful for\nthese people.  They've verified the changes so-far were sane\nwhen they did update-index already.\n\n>  - \"git commit paths...\" acquires a new semantics.  This is an\n>    incompatible change that needs user training, which I am\n>    still a bit reluctant to swallow, but enough people seem to\n>    have complained.\n\n\"git diff HEAD paths...\".\n"},{"id":"15603","messageId":"Pine.LNX.4.64.0602050053280.6773@iabervon.org","threadId":"3239","inReplyTo":"7vu0bemkce.fsf@assigned-by-dhcp.cox.net","subject":"Re: 2 questions/nits about commit and config","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-02-05T06:14:08Z","receivedAt":"2006-02-05T06:14:08Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 4 Feb 2006, Junio C Hamano wrote:\n\n> Here is me thinking aloud again.\n> \n>  - \"git commit\" without _any_ parameter would keep the current\n>    behaviour.  It commits the current index.\n> \n>    We have two choices.  (1) we disallow this form to be run in\n>    a subdirectory, or (2) we do the whole index even when this\n>    form was run from a subdirectory.  I am inclined to say the\n>    latter.\n\nI'd guess this would primarily happen when the user goes into a \nsubdirectory to look at related files when resolving a conflicted merge. \nIf you're committing the prepared index, the working tree isn't \nparticularly important, so the pwd isn't, either.\n\n>  - \"git commit paths...\" acquires a new semantics.  This is an\n>    incompatible change that needs user training, which I am\n>    still a bit reluctant to swallow, but enough people seem to\n>    have complained.  It\n> \n>    1. refuses to run if $GIT_DIR/MERGE_HEAD exists (maybe\n>       remind trained git users that the traditional semantics\n>       now needs -i flag).\n>    2. refuses to run if named paths... are different in HEAD and\n>       the index (ditto about reminding).\n>    3. reads HEAD commit into a temporary index file.\n>    4. updates named paths... from the working tree in this\n>       temporary index (similar to -i form, we never --add).\n\nI think the following sequence should be permitted:\n\n% git add foo\n% git commit foo\n\nI think this means we want --add in step 4, but want to check that the \nnamed paths exist in the index in step 3, although they're allowed to not \nexist in HEAD.\n\n>    5. does the same updates of the paths... from the working\n>       tree to the real index.\n>    6. makes a commit using the temporary index that has the\n>       current HEAD as the parent, and updates the HEAD with this\n>       new commit.\n> \n>    The first check is needed because otherwise during a merge\n>    you would end up inserting an unrelated commit between the\n>    original HEAD and the eventual merge result.  The second\n>    check is to prevent \"skewed commit\" from confusing people.\n>    If you updated index, modified the file further and then used\n>    \"git commit paths...\" to make a commit, next \"git commit\"\n>    without paths would record a partial revert otherwise.\n> \n>    For this one, I think running from subdirectory is a natural\n>    thing to allow.\n> \n>  - \"git commit --all\".  Now what should we do about this?  As\n>    you reminded me, it is equivalent to \"git commit -i .\" if run\n>    from the toplevel (because of the \"index must match HEAD on\n>    named paths\" requirements for the partial commits with named\n>    paths, it is equivalent to \"git commit .\" only if your index\n>    is clean).  I am inclined to say that this should commit all\n>    changes in the whole working tree, regardless of where it is\n>    run.\n\nAgreed.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}