also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2007.07.17.1535 +0200]: > So, you're proposing the following workflow is better > > git-add XXX > git-add YYY > git-status (check what's going to be committed) > git-diff --cached (check the actual diff to be committed) > debcommit > > rather than > > git-status (check what's going to be committed) > git-diff (check what's to be committed) > debcommit
Yes. Git's index and the necessity to call git add after every change is awesome; I can make changes to more than one file but then use git add or even git add -i to selectively choose which hunks to make part of the debcommit. > However, apparently there are people like you who value the notion > of using the git index file to notify which file to commit. Could > you elaborate why it's so useful? I personally have thought it's > one of the bare metal internals that are accidentally exposed due > to the internal design of git (but I might be biased, I've only > been a casual user of git for the past two years). I am only a git user for a month now and I love the feature. I don't think it's a function of the internal design — you can even work around it simply by providing something like an alias ci=commit -a. Rather, it is by choice. Also see this: http://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717 > Iff using index files is useful; I propose creating the following > three different scenarios, and adopt other SCMs to it. It will change > debcommit behavior on different SCMs. > > 1. commit what's in git-index (those which have been added with > git-add). > > debcommit (without any options) Yes, that's what my patch does, I think. > 2. commit what's specified on the command-line > > debcommit fileA fileB fileC > > which will do > > git-diff fileA fileB fileC You only need to diff debian/changelog, right? > git-commit fileA fileB fileC > > 3. commit what's changed (including those which have not been added > with git-add yet). > > debcommit -a > > which will do > > git-diff > git-commit -a This looks good. > Comments? > > This will need modification in the manual, and will have an > undecided behavior for 'debcommit' for other SCMs. I would > suggest making debcommit do nothing, or implicitly do '-a'. Of > course, this deviation will put off some users of other SCMs when > they move to git, but of course, git users are too special. I suggest to implicitly do -a. Moving to git already includes learning about the index, and I think most users will appreciate the additional control, especially those special git users. :) If we add a warning when git is in use (like my patch does), it'll be enough of a cluebat too, I think. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems
signature.asc
Description: Digital signature (GPG/PGP)
