On Sat, 13 Jan 2007, Peter Baumann wrote:
I'd favour the following model:
git-add: register the content of a previously unkown file to git
(there was now struct chache_entry in the index previously which
described a file with the same name)
git-rm: remove a struct cache_entry from the index and after some
safty checks remove the file, too. (see in the mailinglist archive;
there was much talk about git-rm and its semantic)
git-refresh (or git-stage or git-update or what-ever you call it):
replace the cache_entry by a new one
And this all about content; the content which would represent my next
tree object. Because developers don't think of "add" if they want to
remove a file from the commit. If the power users liked to have only one
command, wich does remove, add and update then lets not call it add.
Better make this commmand the above mentioned git-refresh which would do
"the right thing" if called with a new file/removed file
Im simply think its confusing to call the described command git-add, as
we have it now. It's at least *very* confusing for new starters.
Personally I actually find having a single add command to be the simplest
conceptual model ...
I think of it like this:
* start off with current content (index matches HEAD matches working tree)
* I do some stuff (add files, edit files, delete files)
* I add my changes to the index
* I do more stuff
* I add my changes to the index
* I do more stuff
* I realise that the latest changes are actually different, so I commit
the index, and then keep going, or I add the changes and commit.
The only thing I find slightly confusing is that the staging area for the
next commit is called the index.
(But then maybe I've been reading this list too long - though I have only
actually starting playing with git recently)
--
Julian
---
Power, like a desolating pestilence,
Pollutes whate'er it touches...
-- Percy Bysshe Shelley
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html