Thus said Abilio Marques on Thu, 19 Mar 2015 21:25:05 -0430: > 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.
I see, this is totally foreign to how I use git. I have never had to use ``git add -A'', nor have I had to do ``git add'' for files that were modified, only files that do not exist in the current checkout. > 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. Again, this is foreign to me. I'm not sure I see the benefit to such a feature. I can select which files (though not which lines) when I do ``fossil commit <files>.'' Having a step in between the commit and modifying the files just seems just more state that I have to worry about. > git status # You'll see it talks about unstaged changes by this point Oh, yes, I do use ``git status'' similar to how I use ``fossil status'' > git commit -m "another line in the test" # I believe it will refuse Yes, it will refuse. Normally, I just use git commit -a or git commit filename. So I think I can safely say that, no, I do not use the staging area, at least not the way Linus intended it. I think this is a non-feature. Thank you for taking the time to explain to me what I'm missing out on by using ``git commit -a'' and ``git commit <filename>'' :-) Andy -- TAI64 timestamp: 40000000550b84b7 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
