[TxMt] git bundle

[Rick Gigger]

On Aug 3, 2007, at 11:51 PM, Allan Odgaard wrote:

> 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 few ideas here...

1. just ignore the advanced features and just make it work just like  
subversion does.  If someone gets the advanced features they are  
probably going to be doing some stuff from the command line anyway.   
This seems fairly reasonable as it seems many of the clients for git  
use it as just an underlying engine and some don't even ensure that  
their repositories maintain perfect compatibility with the standard  
git client.

2.  In the commit window have an extra column to indicate if the  
version being committed is the most recent version.  Add an action to  
the list that adds the most recent version of an already added file.

> 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).

can't you use the -v (verbose) flag on git add to return a status?

> 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…

I agree you should just ignore it.  if you use the TM client  
exclusively though, can't control when the index gets updated so that  
it is never out of sync with the working copy?

I am still learning the ins and outs of git myself so maybe nothing  
I'm saying here makes sense but I think if the TM client gave us  
basically svn like functionality I for one would be pretty happy.   
What I mostly want is a distributed system will all the features of  
svn.  But TM support is kind of a must so I'll be sticking with svn  
for now.