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
On Thu, Aug 25, 2005 at 03:49:30PM -0500, Kirby C. Bohling wrote:
> On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
> > "Kirby C. Bohling" <[EMAIL PROTECTED]> writes:
> Just out of curiosity, why isn't the SHA1 of 'A' part of the
> diff or patch format? I mean it can't be that
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:
> >
> > > Another example is if I'm working on a commit and suddenly get a
> > > brilliant idea for so
On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
> "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
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:
>
> > 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
"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, i
On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
> 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 making this commit. I can do this easily with
>
> % git undo
>
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 w
On Wed, Aug 24, 2005 at 10:06:45PM -0700, Junio C Hamano wrote:
> > 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.
> 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
Well, both are good ideas. Both are stack oriented, though.
I see what you mean about adding an undo directory to .git/refs/. I
will do some tests... (read further)
On Wed, Aug 24, 2005 at 03:48:21PM -0700, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Generally, ea
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 su
On Wed, 24 Aug 2005, Carl Baldwin wrote:
> This is interesting. Can a ref be to a tree rather than a commit? And
> it still works? I guess it would. I hadn't thought about that.
Generally, each subdirectory of refs/ has refs to objects of the same
type, and heads/ is commits, but other direct
This is interesting. Can a ref be to a tree rather than a commit? And
it still works? I guess it would. I hadn't thought about that.
Will prune preserve any tree mentioned in any file in refs? How does
this work exactly?
Cheers,
Carl
On Wed, Aug 24, 2005 at 04:44:48PM -0400, Daniel Barkalow
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.
-Da
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, 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 th
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
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;
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 a
Hello,
So, one thing that I liked about GNU Arch when I tried it out was the
ability to undo and redo changes in the local working copy. I decided
to try to do this with git. What I have is preliminary. I'm sure it
could use some work.
So, I started with the assumption that all changes in the
21 matches
Mail list logo
