I did a google search for a git bundle for textmate a while back and found several hits, one of which (I thought) was a git bundle that was being worked on by Allan. I can no longer find any trace of this anywhere.
Was Allan working on a git bundle? Is he still? Is anyone else?
I would switch to git in a heartbeat if textmate had support for it.
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 : )
On Aug 3, 2007, at 1:16 AM, 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 : )
Nice. Do I have to install it via svn or is there a way to configure getBundle to install and update it?
On Aug 3, 2007, at 9:59 AM, Rick Gigger wrote:
On Aug 3, 2007, at 1:16 AM, 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 : )
Nice. Do I have to install it via svn or is there a way to configure getBundle to install and update it?
Also when I try to checkout from svn I get the following:
svn: Can't convert string from 'UTF-8' to native encoding: svn: Create Branch?\226?\128?\166.tmCommand
On 8/3/07, Rick Gigger rick@alpinenetworking.com wrote:
Also when I try to checkout from svn I get the following:
svn: Can't convert string from 'UTF-8' to native encoding: svn: Create Branch?\226?\128?\166.tmCommand
Everything you need to know is here:
http://macromates.com/wiki/Main/SubversionCheckout
On Aug 3, 2007, at 10:12 AM, Ale Muñoz wrote:
On 8/3/07, Rick Gigger rick@alpinenetworking.com wrote:
Also when I try to checkout from svn I get the following:
svn: Can't convert string from 'UTF-8' to native encoding: svn: Create Branch?\226?\128?\166.tmCommand
Everything you need to know is here:
Oh, yeah. Thanks! Ever since GetBundle came out I haven't had to do use svn to manage bundles and forgot about those instructions.
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…
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@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.
-
Ale Muñoz -
Allan Odgaard -
Rick Gigger