{"thread":{"id":"27280","subject":"Improvement of git commit interface","startedAt":"2011-05-06T12:03:20Z","lastAt":"2011-05-06T16:10:21Z","messageCount":2,"participants":["Patrick Häcker","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"167245","messageId":"201105061403.27242.patrick.haecker@lss.uni-stuttgart.de","threadId":"27280","inReplyTo":null,"subject":"Improvement of git commit interface","fromName":"Patrick Häcker","fromEmail":"patrick.haecker@lss.uni-stuttgart.de","sentAt":"2011-05-06T12:03:20Z","receivedAt":"2011-05-06T12:03:20Z","isPatch":false,"sender":{"key":"patrick.haecker@lss.uni-stuttgart.de","avatar":null},"body":"Hello,\n\nI introduce git to students and thus see, where they have a harder time than \nnecessary to understand git.\n\nThus, I was thinking about a CLI improvement regarding \"git commit\". It \nfollows from the observation, that the staging area is a very valuable \nthing, but it should not be needed for very simple workflows and thus should \nnot be the first concept, the students have to learn about.\n\nAfter a file has been added to the repository once, you can use git without \nknowing anything about the staging area, with \"git commit \". \nShouldn't we allow \"git commit \" for files never added to git, as \nwell?\nThen, IMHO this would be more consistent, as in a small project a typical \ncommit (with a new file) consists of adding a new file to the repository and \nchanging an existing file (e.g. to call a function located in the new file). \nATM this is done with \"git add && git commit\". But as we \ntrack content and not files, it were perfectly logical, if \"git commit \n \" were possible, as then it were completely consistent to \nonly change an existing file without adding a new file, which is \"git commit \n\".\n\nSo I suggest to change \"git commit \" so that if cannot \nbe found in the repository, it is also looked for in the working directory \nand basically a \"git add && git commit\" is done if the \nis found.\n\nI do _not_ suggest to change \"git commit -a\" to include all files never \nadded to git, because that would be rather error prone. So after the change \nwe would have an inconsistency between \"git commit \" and \"git \ncommit -a\", but I think this inconsistency is better than having the \ninconsistency between \"git commit \" and \"git commit \".\n\nKind regards\nPatrick\n\nP.S. Please CC, as I am not subscribed\n\n\n-- \nPatrick Häcker\nUniversität Stuttgart \nLehrstuhl für Systemtheorie und Signalverarbeitung \nTel: +49 711 685 67362\nE-Mail: patrick.haecker@lss.uni-stuttgart.de\nURL: http://www.lss.uni-stuttgart.de\n"},{"id":"167260","messageId":"7vvcxn24k2.fsf@alter.siamese.dyndns.org","threadId":"27280","inReplyTo":"201105061403.27242.patrick.haecker@lss.uni-stuttgart.de","subject":"Re: Improvement of git commit interface","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-06T16:10:21Z","receivedAt":"2011-05-06T16:10:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Häcker writes:\n\n> After a file has been added to the repository once, you can use git without \n> knowing anything about the staging area, with \"git commit \". \n> Shouldn't we allow \"git commit \" for files never added to git, as \n> well?\n\nThis and its extreme form \"git commit *\" (also \"git update-index *\"), do\nnot to touch untracked files. It was a very conscious and deliberate\ndesign to avoid mistakenly adding unnecessary/unwanted cruft, e.g. object\nfiles and editor backups, to the index. The primary reason we were extra\ncareful about adding cruft by fat fingers was because these operations\ncame before we had usable .gitignore support (in other words, this design\nis back from Linus's git days in early 2005).\n\nIn theory, as we have gitignore support, we now could change them and the\nend result would arguably be more consistent _as long as_ you always\nmaintain spiffy-clean gitignore list, but you need a very careful planning\nto migrate existing scripts and millions of users' fingers without\nbreaking them. Currently, the safety kicks in if you do this:\n\n\t$ >testing-01.c\n $ git commit *.c *.h\n\terror: pathspec 'testing-01.c' did ot match any file(s) known...\n\nand people are used to and do rely on this safety to keep them from\naccidentally committing throw-away experiments, debugging aids, etc. You\ncould argue that people _should_ teach their gitignore about \"testing-*.c\"\nbut in practice that won't fly because throw-away stuff bye their own\nnature come and go without planning, and catching things in gitingore\npattern is all about planning.\n\n> I do _not_ suggest to change \"git commit -a\" to include all files never \n> added to git, because that would be rather error prone.\n\nWe discussed \"git commit -A\" for this exact purpose in the past. It is\njust as error prone as making \"git commit *\" to add new paths, but \"-A\"\nhas a distinct advantage that it is _explicitly_ asking to add new paths,\nand also it did not exist so there is no migration to worry about.\n\n> P.S. Please CC, as I am not subscribed\n\nNo need to say this, as the convention on this list is never cull Cc:\nunless there is a good reason.\n"}]}