By doing git commit -a, your doing an implicit git add -A before the commit, which stages all the uncommitted changes, and then you're working close to what you would in fossil.
But we're talking about the Linus dream: You do some changes, then you select the files (not it seems that even line by line changes are selectable) you want to include in the commit by doing "git add", and then you commit. Try this on an empty directory (I'm running by memory now, so don't believe me completely): git init echo "line 1" > test.txt git add test.txt git commit -m "this is a test" echo "line 2" >> test.txt git status # You'll see it talks about unstaged changes by this point git commit -m "another line in the test" # I believe it will refuse On Thu, Mar 19, 2015 at 9:17 PM, Andy Bradford <amb-fos...@bradfords.org> wrote: > Thus said Abilio Marques on Thu, 19 Mar 2015 21:08:55 -0430: > > > (1) modify a file or files > > (2) add the files (every single time... this sucks sometimes, as Joerg > said) > > (3) commit > > I'm not sure what (2) is unless you mean that I create new files in the > working checkout and then use ``git add'' to add them. As to why this > would suck, I'm not sure, isn't ``git add'' a necessary evil to get > something into the repository? > > Here's my typical git day: > > (1) modify or create file(s) > (1a) git add files if necessary > (2) review changes with git diff > (3) git commit -a (or git commit for a specific file if some changes > are not ready > (4) git pull; git push when ready > > So, let me ask this, if this means I'm using the staging area, why don't > I feel like this is any different than how I use Fossil? > > Andy > -- > TAI64 timestamp: 40000000550b7c54 > > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
