Carl Baldwin [EMAIL PROTECTED] writes:
For this, I may also use branching, as suggested. I meant for undo/redo
to be a lighter weight alternative to allow for a faster context switch.
I have been missing the undo command since I started to use git, so
I'll share a user's perspective.
I was
Kirby C. Bohling [EMAIL PROTECTED] writes:
I guess my final question is what does undo/redo have over saving
stuff away in a patch assuming that the patch captures all of the
SCM meta-data (the add/move/remove file type commands). If git
doesn't capture all the meta-data in a patch, it would
On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:
On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
snip...
Another example is if I'm working on a commit and suddenly get a
brilliant idea for some easy modification that I want to make and commit
by itself before
On Thu, Aug 25, 2005 at 02:37:33PM -0600, Carl Baldwin wrote:
On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:
On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
snip...
Another example is if I'm working on a commit and suddenly get a
brilliant idea for some
On Thu, Aug 25, 2005 at 04:09:29PM -0500, Kirby C. Bohling wrote:
I guess I can see that. I just see it as much easier to manage
multiple undo-redo states manually. I mean, I wouldn't make anyone
use git directly if the difference between the two commands bothers
them. git seems too low a
Oops. I forgot to actually exit from the script if git-diff-files is
non-empty.
Also, looking at it now, I don't think keeping undo information in a
stack is the right thing. But keeping more than just one would be good.
Oh well, my first shot is never perfect. ;-)
Carl
On Wed, Aug 24, 2005
Carl Baldwin [EMAIL PROTECTED] writes:
Attached are the two scripts. Comments and criticism are welcome.
An obligatory non-technical comment. I would have liked to see
this not in a MIME multipart format, which made commenting on it
a bit harder than necessary.
Content-Type: text/plain;
On Wed, 24 Aug 2005, Carl Baldwin wrote:
Oops. I forgot to actually exit from the script if git-diff-files is
non-empty.
Also, looking at it now, I don't think keeping undo information in a
stack is the right thing. But keeping more than just one would be good.
Oh well, my first shot
On Wed, Aug 24, 2005 at 11:51:32AM -0700, Linus Torvalds wrote:
On Wed, 24 Aug 2005, Carl Baldwin wrote:
Oops. I forgot to actually exit from the script if git-diff-files is
non-empty.
Also, looking at it now, I don't think keeping undo information in a
stack is the right thing.
On Wed, Aug 24, 2005 at 11:18:42AM -0700, Junio C Hamano wrote:
Carl Baldwin [EMAIL PROTECTED] writes:
Attached are the two scripts. Comments and criticism are welcome.
An obligatory non-technical comment. I would have liked to see
this not in a MIME multipart format, which made
On Wed, 24 Aug 2005, Carl Baldwin wrote:
This brings up a good point (indirectly). git prune would destroy the
undo objects. I had thought of this but decided to ignore it for the
time being.
If you made undo store the tree under refs somewhere, git prune would
preserve it.
-Daniel
Daniel Barkalow [EMAIL PROTECTED] writes:
Generally, each subdirectory of refs/ has refs to objects of the same
type, and heads/ is commits, but other directories are other things. tags/
is all tag objects, and you could have undo/ be trees.
That's OK from the prune front, but I am not sure
So, I've tried cloning, pulling to|from, pushing to|from and resolving
merges in a repository with undo information stored under
.git/refs/undo. None of these operations seem to notice the existence
of this directory. I think this is good.
What I meant was that, when undo/bar is a tree
13 matches
Mail list logo
