On 3. Aug 2007, at 09:16, Ale Muñoz wrote:
On 8/3/07, Rick Gigger rick@alpinenetworking.com wrote:
Was Allan working on a git bundle? Is he still? Is anyone else?
Check this: <http://macromates.com/svn/Bundles/trunk/Work%20in%20Progress/ Bundles/Git.tmbundle/> But please note it is in the "Work in Progress" folder for a reason : )
It is indeed Work in Progress -- almost as quickly as I started it, I ran into a rather big challenge trying to deal with committing under git.
As you may know git has an “index tree” -- when you commit, you commit that, not the working copy. So to commit, you first add to the index tree, then commit. When you add, you do not add the filename but the actual file content. So in practice you can add a file to the index tree, change the file, then commit the index tree, which will not be the version in your working copy, but rather the state of the file at the time you added it.
Okay, so the problem is that this is tedious, and you can do “git- commit -a .” which does an implicit add on everything changed first, or you can do “git-commit «file»” and it does the add only on the file before committing.
For TextMate, we definitely want to do something like the latter, and that is what I currently do, *but* that gives a real problem if the user already did add something to the index tree, because then we do *not* want to add that file again (overwriting the one the user added).
I think though that I will make it so, that we always commit the working copy, and I add a check to ensure that the index tree is “clean”, and if it is not, simply tell the user that the commit command will not work in such state.
A minor problem is that untracked files needs to be added (to the index tree) before they can be committed. This can be done from the commit window presently, but the commit window expects the add (shell) command to return status which it uses to update the state of the commit window, but no such status is returned (so the code for the commit window needs to be updated to somehow handle this differently).
A related problem is that all the git commands (like diff) can work either on the working copy or the index tree. I wasn’t sure how to handle this, IMO this index tree really should never have been exposed like it is, and probably the best is to ignore that it is there, for the TM git front end -- of course this is not completely possible, since e.g. scheduling a (new) file for addition or (an old one for) removal is done on the index tree, and so “status” will include changes done to the index tree…