[TxMt] git bundle

[Allan Odgaard]

On 3. Aug 2007, at 09:16, Ale Muñoz wrote:

> On 8/3/07, Rick Gigger <rick at 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…