Re: [RFC] undo and redo
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 level. I would think one of the > procelains would be be a better level. However, having a unified > interface for all the porcelains seems a reasonable request. Maybe Porcelain is the right place for it. The question would be "Is it important that porcelains handle undo/redo in a way that interoperates?" > > > > Is there something wrong with having flexibility? It seems most of the > > criticism of this feature is that there is already a way to accomplish > > what I want to do. Tools that can't be used flexibly are not tools that > > I like to use. Heck, I'm on UNIX aren't I? > > > > Oops, sorry for the rant. I'm really not in a bad mood... really. I > > hope it didn't sound like that :-). Oh, and I didn't mean to suggest > > that git is not flexible in other regards. I think its great! Moving > > along... > > > > > Assuming your patch creation and application tools capture all the > > > meta-data the SCM has (which I believe git does), it's pretty simple > > > to simulate what you want manaully. With only a handful of > > > commands. > > > > I can simulate git manually too with just a few more commands. Where's > > the cutoff? This analogy *was* a bit extreme. Cheers, Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 hard to add it as a > single line of data that git can parse to extract that piece of > information. Then a patch would enable you to do the 3-way merge > you describe. If added properly "regular" patch would just ignore > that line. The patch would then record that it is relative to 'A'. Not a bad idea. It could be ignored in most cases and used when needed. Carl > Assuming git could be taught "git-merge-patch" and then take use > the patch that's saved during the "undo" step and has the anchor for > the patch to use as the pivot point (as described above). Life > should be good. There are probably corner cases I don't understand, > but it sure looks like if you have the pivot or anchor point for the > patch embedded in the patch, you have all the needed information to > pull this off. > > I would think this would be generally useful outside of the > context of "undo/redo" also. > > Kirby > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 some easy modification that I want to make and commit > > > by itself before making this commit. I can do this easily with > > > > > > % git undo > > > % carefully make easy change > > > % git commit > > > % git redo > > > > > > Having a light-weight alternative like this could make the difference > > > between realizing the easy, brilliant idea and forgetting about it on > > > the back burner because it was just too cumbersome to make the context > > > switch. > > > > > > The bottom line is that I don't argue against using the existing > > > work-flows. I hope to add the flexibility to use various work-flows to > > > fit the job at hand. > > > > > > > > > [Not much of a git user, but am evaluating it for possible future > > usage]... > > > > Why not just save the changes to a file via a patch. Just like you > > would if you were sending a patch to someone else. I have the work > > flow you are talking about when I use CVS. I just create a patch, > > apply the patch in reverse (or run the command to get you a clean > > working tree in the SCM). Make my unrelated changes commit it. > > Then apply the patch, possibly resolve merge conflicts, and proceed > > with finishing my original work. > > I used to do this with CVS too. For you and me, people who are patch > savy veterans, this is great! However, as easy as it is I knew very few > other developers who even thought about doing it. In the real world, > many people see a huge difference between: > > git diff-cache > $patchfile > cat $patchfile | patch -R -p1 > do work > cat $patchfile | patch -p1 > > AND > > git undo > do work > git redo > > The first one simply never happens with most developers. Most don't > really think of doing something outside the tool. The second option > will likely get used. Plus, I know at least one person here who is very > good with patches and working outside the tool and still would love to > have the second approach available. 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 level. I would think one of the procelains would be be a better level. However, having a unified interface for all the porcelains seems a reasonable request. > > Is there something wrong with having flexibility? It seems most of the > criticism of this feature is that there is already a way to accomplish > what I want to do. Tools that can't be used flexibly are not tools that > I like to use. Heck, I'm on UNIX aren't I? > > Oops, sorry for the rant. I'm really not in a bad mood... really. I > hope it didn't sound like that :-). Oh, and I didn't mean to suggest > that git is not flexible in other regards. I think its great! Moving > along... > > > Assuming your patch creation and application tools capture all the > > meta-data the SCM has (which I believe git does), it's pretty simple > > to simulate what you want manaully. With only a handful of > > commands. > > I can simulate git manually too with just a few more commands. Where's > the cutoff? Yes and no. I meant the order and style of commands was nearly identical. I meant applying the command line in reverse was the only additional step. As a workflow, I'd just document it in the HOWTO's. I'm a minimalist in that sense. Sure, I use more then echo, redirection and netcat even though in theory I could send you this e-mail with it. IMHO, the above undo/redo doesn't seem to save enough effort to me. I wouldn't bother learning undo/redo unless it was superior to the patch way, it's just one more thing I'd have to remember. > > > I see the appeal of not having manually deal with the files, but > > assuming you don't feel it's branch worthy, and you don't want to > > have it be something someone else can access externally, it doesn't > > seem like a feature I can't get almost as simply with existing git > > commands. > > Not having to manually manage a set of patches may seem small but it > reduces a barrier that may otherwise be just high enough to hurt > productivity in certain situations. I don't mean to discourge it's implementation, I really questioned it because I figured there had to be some more subtle implications I didn't understand about undo/redo that patch couldn't capture. It also seems like multiple levels of undo/redo or undo/redo on multiple branches could get tricky for the user to track and for git to be able to display the information to the user sanely. Thanks, Kirby - To unsubscribe from this list: send the line "u
Re: [RFC] undo and redo
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 type commands). If git > > doesn't capture all the meta-data in a patch, it would seem better > > to make it do that and get this as a side-affect. > > One thing that Carl's undo saves that is not easily available in > the patch form is the "what is this patch based on" information. > If you had it, you could do a three-way merge instead of patch > application. > You were at A (time flows from left to right) when somebody > (maybe your bright idea) interrupted you. You take a snapshot > of your tree state D as a pair , and rewind the tree to > original commit A's state: > > -->A > \ > D > > Then you do the work that interrupted you, maybe making commits > B and then C: > > -->A-->B-->C > \ > D > > At this point, you would want to restart working on whatever you > were doing, which is the difference between A->D applied on top > of C. > > You could keep that information as a patch between A->D and > apply it on top of C to get there, which is your approach if I > am reading you correctly. Carl does a three-way merge between C > and D using A as the pivot point. 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 hard to add it as a single line of data that git can parse to extract that piece of information. Then a patch would enable you to do the 3-way merge you describe. If added properly "regular" patch would just ignore that line. The patch would then record that it is relative to 'A'. Assuming git could be taught "git-merge-patch" and then take use the patch that's saved during the "undo" step and has the anchor for the patch to use as the pivot point (as described above). Life should be good. There are probably corner cases I don't understand, but it sure looks like if you have the pivot or anchor point for the patch embedded in the patch, you have all the needed information to pull this off. I would think this would be generally useful outside of the context of "undo/redo" also. Kirby - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 making this commit. I can do this easily with > > > > % git undo > > % carefully make easy change > > % git commit > > % git redo > > > > Having a light-weight alternative like this could make the difference > > between realizing the easy, brilliant idea and forgetting about it on > > the back burner because it was just too cumbersome to make the context > > switch. > > > > The bottom line is that I don't argue against using the existing > > work-flows. I hope to add the flexibility to use various work-flows to > > fit the job at hand. > > > > > [Not much of a git user, but am evaluating it for possible future > usage]... > > Why not just save the changes to a file via a patch. Just like you > would if you were sending a patch to someone else. I have the work > flow you are talking about when I use CVS. I just create a patch, > apply the patch in reverse (or run the command to get you a clean > working tree in the SCM). Make my unrelated changes commit it. > Then apply the patch, possibly resolve merge conflicts, and proceed > with finishing my original work. I used to do this with CVS too. For you and me, people who are patch savy veterans, this is great! However, as easy as it is I knew very few other developers who even thought about doing it. In the real world, many people see a huge difference between: git diff-cache > $patchfile cat $patchfile | patch -R -p1 do work cat $patchfile | patch -p1 AND git undo do work git redo The first one simply never happens with most developers. Most don't really think of doing something outside the tool. The second option will likely get used. Plus, I know at least one person here who is very good with patches and working outside the tool and still would love to have the second approach available. Is there something wrong with having flexibility? It seems most of the criticism of this feature is that there is already a way to accomplish what I want to do. Tools that can't be used flexibly are not tools that I like to use. Heck, I'm on UNIX aren't I? Oops, sorry for the rant. I'm really not in a bad mood... really. I hope it didn't sound like that :-). Oh, and I didn't mean to suggest that git is not flexible in other regards. I think its great! Moving along... > Assuming your patch creation and application tools capture all the > meta-data the SCM has (which I believe git does), it's pretty simple > to simulate what you want manaully. With only a handful of > commands. I can simulate git manually too with just a few more commands. Where's the cutoff? > I see the appeal of not having manually deal with the files, but > assuming you don't feel it's branch worthy, and you don't want to > have it be something someone else can access externally, it doesn't > seem like a feature I can't get almost as simply with existing git > commands. Not having to manually manage a set of patches may seem small but it reduces a barrier that may otherwise be just high enough to hurt productivity in certain situations. > 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 seem better > to make it do that and get this as a side-affect. > > Thanks, > Kirby Thanks for your comments. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
"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 seem better > to make it do that and get this as a side-affect. One thing that Carl's undo saves that is not easily available in the patch form is the "what is this patch based on" information. If you had it, you could do a three-way merge instead of patch application. You were at A (time flows from left to right) when somebody (maybe your bright idea) interrupted you. You take a snapshot of your tree state D as a pair , and rewind the tree to original commit A's state: -->A \ D Then you do the work that interrupted you, maybe making commits B and then C: -->A-->B-->C \ D At this point, you would want to restart working on whatever you were doing, which is the difference between A->D applied on top of C. You could keep that information as a patch between A->D and apply it on top of C to get there, which is your approach if I am reading you correctly. Carl does a three-way merge between C and D using A as the pivot point. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 > % carefully make easy change > % git commit > % git redo > > Having a light-weight alternative like this could make the difference > between realizing the easy, brilliant idea and forgetting about it on > the back burner because it was just too cumbersome to make the context > switch. > > The bottom line is that I don't argue against using the existing > work-flows. I hope to add the flexibility to use various work-flows to > fit the job at hand. > [Not much of a git user, but am evaluating it for possible future usage]... Why not just save the changes to a file via a patch. Just like you would if you were sending a patch to someone else. I have the work flow you are talking about when I use CVS. I just create a patch, apply the patch in reverse (or run the command to get you a clean working tree in the SCM). Make my unrelated changes commit it. Then apply the patch, possibly resolve merge conflicts, and proceed with finishing my original work. Assuming your patch creation and application tools capture all the meta-data the SCM has (which I believe git does), it's pretty simple to simulate what you want manaully. With only a handful of commands. I see the appeal of not having manually deal with the files, but assuming you don't feel it's branch worthy, and you don't want to have it be something someone else can access externally, it doesn't seem like a feature I can't get almost as simply with existing git commands. 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 seem better to make it do that and get this as a side-affect. Thanks, Kirby - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 also considering undo as a really lightweight command, nothing too fancy. Usually, I want to try implement something wild or stupid, but almost immediately decide to abandon it. With 'git undo', this kind of prototyping would be really easy. For me, redo would be just a backup if (read: when) I undo something important, nothing more. For anything else I would use branches, as was suggested. -- Kalle Valo - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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. I think this is good. > > What I meant was that, when "undo/bar" is a tree object, things > may work in a funny way: > > $ git pull ../repo-with-undo/.git refs/undo/bar > > $ git push ../other-repo/.git undo/bar:refs/heads/foo > $ cd ../other-repo && git resolve master foo 'Attempt to merge undo' I was thinking that undo trees should not be pushed and pulled between repositories. For this I would use a new branch with proper commits as Linus suggested. > I think this undo/redo first needs to be thought about how best > it is used. My guess is that the workflow you have in mind is > something like this: > > $ git checkout master > $ hack hack hack > # Hmph, it almost works, and but my boss says work on > # some other feature that is more urgent > $ git undo > Saved current state as 2005-08-24T20:32:22 > $ work work work > $ git commit -m 'Boring but urgent fix' > # Ok, now let's back to the thing I wanted to do. > $ git redo > # I happen to know it is the last undo, so I did not name > # it, but I could have said 2005-08-24T20:32:22 > $ hack more > $ git commit -m 'Finally fix frotz.' 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 am reluctant to commit what I have in my working directory unless I have taken the time to review the changes using diff tools and cleaned up considerably. This is my way of being a careful developer. Not all developers share my style but I know many that do. This makes committing a heavy weight operation for me. So, referring to your example. If my 'boss' says that I need to switch to working on 'Boring but urgent fix' for the next *week* or more I will likely take the time to make the full context switch to a new branch and work on the fix. I may also choose to just clone my repository and use a new working directory. If the fix takes just a day or two I may do the same. Now, let's say that the 'fix' is something that I can do in an hour or two and quickly get back to where I was. In this context, making the full context switch can feel very cumbersome compared to the amount of work required to make the fix. Now, a simple 'git undo' will ease this switch. 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 % carefully make easy change % git commit % git redo Having a light-weight alternative like this could make the difference between realizing the easy, brilliant idea and forgetting about it on the back burner because it was just too cumbersome to make the context switch. The bottom line is that I don't argue against using the existing work-flows. I hope to add the flexibility to use various work-flows to fit the job at hand. [ stuff deleted ] > $ git checkout master > $ hack hack hack > # Hmph, it almost works, and but my boss says work on > # some other feature that is more urgent > $ git commit -m 'WIP - fix frotz' > $ git branch anchor-frotz > $ git reset --hard master^ > $ work work work > $ git commit -m 'Boring but urgent fix' > # Ok, now let's go back to the thing I wanted to do. > $ git pull . anchor-frotz > $ rm .git/heads/anchor-frotz > $ git reset --soft master^ > $ hack more > $ git commit -m 'Finally fix frotz.' Again, these are effective. I simply want to provide an alternative light weight way of accomplishing this. > The above flow would be something somebody not so organized > (like myself) would do. A perfect person would have done this: > > $ git checkout -b frotz master > $ hack hack hack > # Hmph, it almost works, and but my boss says work on > # some other feature that is more urgent > $ git commit -m 'WIP - fix frotz' > $ git checkout master > $ work work work > $ git commit -m 'Boring but urgent fix' > # Ok, now let's go back to the thing I wanted to do. > $ git checkout frotz > $ git reset --soft HEAD^ > $ hack more > $ git commit -m 'Finally fix frotz.' > $ git checkout master > $ git pull . frotz > $ rm .git/refs/heads/frotz > > The "perfect person" approach has an added benefit that you > could have made intermediate commits while doing "hacking", > because your hackery is always done in the "frotz" branch. > > Of course, the scenarios your undo/redo is useful for may not be > limited to this "handling interrupt" use case. If that is the > only
Re: [RFC] undo and redo
> 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 object, things may work in a funny way: $ git pull ../repo-with-undo/.git refs/undo/bar $ git push ../other-repo/.git undo/bar:refs/heads/foo $ cd ../other-repo && git resolve master foo 'Attempt to merge undo' I think this undo/redo first needs to be thought about how best it is used. My guess is that the workflow you have in mind is something like this: $ git checkout master $ hack hack hack # Hmph, it almost works, and but my boss says work on # some other feature that is more urgent $ git undo Saved current state as 2005-08-24T20:32:22 $ work work work $ git commit -m 'Boring but urgent fix' # Ok, now let's back to the thing I wanted to do. $ git redo # I happen to know it is the last undo, so I did not name # it, but I could have said 2005-08-24T20:32:22 $ hack more $ git commit -m 'Finally fix frotz.' I see some problems in this. One is minor. As you mentioned about "giving undo a symbolic name", after you accumulate a handful undo, you would need them to have descriptive names, and a way to list them before using "git redo". But as Linus suggested in another reply, you could as well have done this without inventing these two commands. $ git checkout master $ hack hack hack # Hmph, it almost works, and but my boss says work on # some other feature that is more urgent $ git commit -m 'WIP - fix frotz' $ git branch anchor-frotz $ git reset --hard master^ $ work work work $ git commit -m 'Boring but urgent fix' # Ok, now let's go back to the thing I wanted to do. $ git pull . anchor-frotz $ rm .git/heads/anchor-frotz $ git reset --soft master^ $ hack more $ git commit -m 'Finally fix frotz.' The above flow would be something somebody not so organized (like myself) would do. A perfect person would have done this: $ git checkout -b frotz master $ hack hack hack # Hmph, it almost works, and but my boss says work on # some other feature that is more urgent $ git commit -m 'WIP - fix frotz' $ git checkout master $ work work work $ git commit -m 'Boring but urgent fix' # Ok, now let's go back to the thing I wanted to do. $ git checkout frotz $ git reset --soft HEAD^ $ hack more $ git commit -m 'Finally fix frotz.' $ git checkout master $ git pull . frotz $ rm .git/refs/heads/frotz The "perfect person" approach has an added benefit that you could have made intermediate commits while doing "hacking", because your hackery is always done in the "frotz" branch. Of course, the scenarios your undo/redo is useful for may not be limited to this "handling interrupt" use case. If that is the only thing it solves, then I do not see much point having them as new commands. I think the undo/redo has potential beyond that. So let's first clarify what kind of workflow these new commands would help, how well that workflow is applicable in general, and then how well these new commands would help that workflow. > I would be glad to write up documentation and provide a patch. Sure. I think a set of patches for new commands, and new options to existing commands should ideally include the following: - Justification, such as: - The problems new commands/options address. - The expected workflow the new commands/options fit in. - How useful that workflow is. - How impossible or cumbersome to achieve that workflow using existing tools. Some of these should go to the commit log message, and the documentation to describe the "best practice" workflow using the new feature should go to Documentation/howto/ directory. - Documentation. Files Documentation/git-*.txt to describe new commands or updates to existing pages, new entry in Documentation/Makefile as necessary, and a new link from Documentation/git.txt to reach that page. - Implementation. - Test scripts in t/ directory, either a new test script or updates to existing ones, if the patch is to fix existing implementation. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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, 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 what the > ramifications of this for pulling, pushing, and resolving. > I would not recommend it without really thinking it through. 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. The cloned repository does not end up 'inheriting' the undo directory (as I would expect) but does end up with any objects reachable from the undo tree. However, these objects get pruned on the next 'git prune'. This, I think, is minor. Pull seems to ignore the undo directory and, of course, the objects reachable by the undo trees. This is what I expected and wanted. Resolving merges worked as expected. I think undo trees should be considered local to the repository and this is the behavior that I observed. I think this is a positive. Before reading your message, I polished up the scripts and changed them so that they store the undo tree and the base tree's hashes in the .git/refs/undo directory. Also, git-redo-script can take an optional argument...the name of the undo to replay. I guess undo should also take an optional argument to give the undo tree some symbolic name. I think this is getting rather solid. Let me know what you think. Here is the git-undo-script: #!/bin/sh . git-sh-setup-script || die "Not a git archive" git-update-cache --refresh || exit 1 undodir=$GIT_DIR/refs/undo undoinfo=$undodir/$(date +%Y.%m.%d.%H.%M.%S) headtree=$(git-cat-file commit $(cat $GIT_DIR/HEAD) | sed -n 's/^tree //p') undotree=$(git-write-tree) if [ $headtree == $undotree ]; then echo There are no changes to undo. else mkdir -p $(dirname $undoinfo) echo $headtree > $undoinfo.base echo $undotree > $undoinfo.undo echo Saved current state in $undodir as $(basename $undoinfo) git-read-tree -m -u $undotree $headtree fi # --- SNIP --- and here, is the redo script #!/bin/sh . git-sh-setup-script || die "Not a git archive" git-update-cache --refresh || exit 1 usage () { echo >&2 "Usage: git-redo-script [undo name]" exit 1 } undodir=$GIT_DIR/refs/undo # If an 'undo name' was given on the command line then try to use it. # If not, then automatically pick the most recent undo. undoinfo= case "$#" in 0) undoinfo=$undodir/$(ls -tr $undodir | sed -n 's/\.undo$//p' | tail -n 1) ;; 1) if [ -s $undodir/$1 ]; then undoinfo=$(echo $undodir/$1 | sed -n "s/\.[^.]*$//p") elif [ -s $undodir/$1.undo -a -s $undodir/$1.base ]; then undoinfo=$undodir/$1 else usage fi ;; *) usage ;; esac # Perform a three-way merge between the base tree, undo tree and current index if [ ! -s $undoinfo.undo -o ! -s $undoinfo.base ]; then echo "No undo information available" else git-read-tree -u -m $(cat $undoinfo.base) $(cat $undoinfo.undo) $(git-write-tree) git-merge-cache git-merge-one-file-script -a rm -f $undoinfo.* test -z "$(ls $undodir)" && rmdir $undodir fi # --- SNIP --- I would be glad to write up documentation and provide a patch. Cheers, Carl > Also note that tags/ is not all tag objects. I think "git tag" > by default creates a lightweight tag, not an annotated kind. > > I think you could do either one of two things. As usual, totally > untested. Just thinking aloud. > > (1) A hack. > > - Have a single "undo-redo" branch, which was forked from >somewhere on the "master" branch. > > - When doing "undo", make a commit that has the current top >of undo-redo branch as the first parent and the current >HEAD commit as the second parent, using the tree that >represents your snapshot, to grow "undo-redo" branch. > >No, this commit does *not* represent a merge, but I am >abusing the capability to record more than one parent >commits. > > - When running "redo", you would want a handy way to name >what to redo. You can say "undo-redo~N" to mean "Nth >from the top of undo-redo branch. > >Your implementation of "redo" can either be (patch way): > >git-diff-tree -p undo-redo~N^ undo-redo~N | git apply --index > >or (merge way): > >git-read-tree -m undo-redo~N^2 undo-redo~N HEAD && >git-merge-cache -o git-merge-one-file-script -a > > (2) Try StGIT. > > -- - - - - - - -
Re: [RFC] undo and redo
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 what the ramifications of this for pulling, pushing, and resolving. I would not recommend it without really thinking it through. Also note that tags/ is not all tag objects. I think "git tag" by default creates a lightweight tag, not an annotated kind. I think you could do either one of two things. As usual, totally untested. Just thinking aloud. (1) A hack. - Have a single "undo-redo" branch, which was forked from somewhere on the "master" branch. - When doing "undo", make a commit that has the current top of undo-redo branch as the first parent and the current HEAD commit as the second parent, using the tree that represents your snapshot, to grow "undo-redo" branch. No, this commit does *not* represent a merge, but I am abusing the capability to record more than one parent commits. - When running "redo", you would want a handy way to name what to redo. You can say "undo-redo~N" to mean "Nth from the top of undo-redo branch. Your implementation of "redo" can either be (patch way): git-diff-tree -p undo-redo~N^ undo-redo~N | git apply --index or (merge way): git-read-tree -m undo-redo~N^2 undo-redo~N HEAD && git-merge-cache -o git-merge-one-file-script -a (2) Try StGIT. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 directories are other things. tags/ is all tag objects, and you could have undo/ be trees. > Will prune preserve any tree mentioned in any file in refs? How does > this work exactly? It keeps any object reachable from an object that there's a ref to in refs. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 wrote: > 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 > *This .sig left intentionally blank* > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 commenting on it > a bit harder than necessary. > > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: attachment; filename=git-undo-script > > > > #!/bin/sh > > > > . git-sh-setup-script || die "Not a git archive" > > > > if [ -n "$(git-diff-files)" ]; then > > echo The following files should be updated! > > echo > > git-diff-files | awk '{print $6}' > > fi > > There is nothing wrong with the above, but I would have written > it like this (I think you forgot to exit after showing the list > of files): > > git-update-cache --refresh || exit I'll take this. This is what I was going for but being new to git I didn't know all that was available. A good reason to request comments :-) > Also nice to learn here is "git-diff-files --name-only". Also good to know, thanks. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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. But keeping more than just one would be good. > > Oh well, my first shot is never perfect. ;-) > > I would actually argue that > > git checkout -b newbranch > > is the perfect undo. Yes, this does the job nicely. I've used it like this effectively. I meant for undo/redo to be a lighter weight way of moving (uncommitted) changes out of the way briefly and then replaying them onto the working directory later. > It leaves the old state in the old branch, and creates a new branch (and > checks it out) with the state you want to revert to. The advantage is > exactly that there is no "stack" of undo's: you can have multiple > independent undo's pending, and you can continue development at any of > them. And merge the results together. The "stack" was the wrong thing to do. I think I would have undo pick a name like undo-1, undo-2 etc. Or something like that. redo would pick the most recent unless told to do otherwise. A possible advantage of undo is having the freedom to stay on the current branch or switch to another. > Of course, right now we don't have a "delete branch" command, but it's > really as simple as > > rm .git/refs/heads/branchname > > (and eventually you may want to do a "git prune" to get rid of stale > objects, but that's a separate issue). > > Linus > 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. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 is never perfect. ;-) I would actually argue that git checkout -b newbranch is the perfect undo. It leaves the old state in the old branch, and creates a new branch (and checks it out) with the state you want to revert to. The advantage is exactly that there is no "stack" of undo's: you can have multiple independent undo's pending, and you can continue development at any of them. And merge the results together. Of course, right now we don't have a "delete branch" command, but it's really as simple as rm .git/refs/heads/branchname (and eventually you may want to do a "git prune" to get rid of stale objects, but that's a separate issue). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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; charset=us-ascii > Content-Disposition: attachment; filename=git-undo-script > > #!/bin/sh > > . git-sh-setup-script || die "Not a git archive" > > if [ -n "$(git-diff-files)" ]; then > echo The following files should be updated! > echo > git-diff-files | awk '{print $6}' > fi There is nothing wrong with the above, but I would have written it like this (I think you forgot to exit after showing the list of files): git-update-cache --refresh || exit Also nice to learn here is "git-diff-files --name-only". > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename=git-redo-script > > #!/bin/sh > > . git-sh-setup-script || die "Not a git archive" > > if [ -n "$(git-diff-files)" ]; then > echo The following files should be updated! > echo > git-diff-files | awk '{print $6}' > fi Same here. > currenttree=$(git-write-tree) > git-read-tree -u -m $basetree $currenttree $redotree > git-merge-cache git-merge-one-file-script -a Interesting. Very interesting. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] undo and redo
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 at 11:23:39AM -0600, Carl Baldwin wrote: > 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 working copy > have been updated to the cache. My scripts check this (with > git-diff-files) and abort if this is not the case. > > Undo calls git-write-tree to write the changes to the object store. It > stores that tree's hash and the current HEAD's tree's hash in a file. > Then it reverts the working copy to HEAD. > > Redo grabs these two trees from the file, does git-write-tree to produce > a third tree and merges the three using the old HEAD's tree as the base > of the merge. This way, new commits can happen and the local copy can > be modified since the undo and it should still work assuming no > conflicts emerge. > > Attached are the two scripts. Comments and criticism are welcome. > > Cheers, > Carl > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Carl BaldwinSystems VLSI Laboratory > Hewlett Packard Company > MS 88 work: 970 898-1523 > 3404 E. Harmony Rd. work: [EMAIL PROTECTED] > Fort Collins, CO 80525 home: [EMAIL PROTECTED] > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > #!/bin/sh > > . git-sh-setup-script || die "Not a git archive" > > if [ -n "$(git-diff-files)" ]; then > echo The following files should be updated! > echo > git-diff-files | awk '{print $6}' > fi > > undostack=$GIT_DIR/undostack > > if [ ! -s $undostack ]; then > echo "No undo information in $undostack" > else > # Read the top of the stack > basetree=$(cat $undostack | tail -n 2 | head -n 1) > redotree=$(cat $undostack | tail -n 1) > > # Pop the stack > cat $undostack | head -n -2 > $undostack.tmp > mv $undostack{.tmp,} > > currenttree=$(git-write-tree) > > git-read-tree -u -m $basetree $currenttree $redotree > git-merge-cache git-merge-one-file-script -a > fi > #!/bin/sh > > . git-sh-setup-script || die "Not a git archive" > > if [ -n "$(git-diff-files)" ]; then > echo The following files should be updated! > echo > git-diff-files | awk '{print $6}' > fi > > undostack=$GIT_DIR/undostack > > headtree=$(git-cat-file commit $(cat $GIT_DIR/HEAD) | head -n 1 | sed -e > 's/tree //') > undotree=$(git-write-tree) > > if [ $headtree == $undotree ]; then > echo There are no changes to undo. > else > { >echo $headtree >echo $undotree > } >> $undostack > > echo Saved current state as tree $undotree. > echo Reverting to HEAD, $headtree... > > git-checkout-script -f > fi -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] undo and redo
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 working copy have been updated to the cache. My scripts check this (with git-diff-files) and abort if this is not the case. Undo calls git-write-tree to write the changes to the object store. It stores that tree's hash and the current HEAD's tree's hash in a file. Then it reverts the working copy to HEAD. Redo grabs these two trees from the file, does git-write-tree to produce a third tree and merges the three using the old HEAD's tree as the base of the merge. This way, new commits can happen and the local copy can be modified since the undo and it should still work assuming no conflicts emerge. Attached are the two scripts. Comments and criticism are welcome. Cheers, Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #!/bin/sh . git-sh-setup-script || die "Not a git archive" if [ -n "$(git-diff-files)" ]; then echo The following files should be updated! echo git-diff-files | awk '{print $6}' fi undostack=$GIT_DIR/undostack if [ ! -s $undostack ]; then echo "No undo information in $undostack" else # Read the top of the stack basetree=$(cat $undostack | tail -n 2 | head -n 1) redotree=$(cat $undostack | tail -n 1) # Pop the stack cat $undostack | head -n -2 > $undostack.tmp mv $undostack{.tmp,} currenttree=$(git-write-tree) git-read-tree -u -m $basetree $currenttree $redotree git-merge-cache git-merge-one-file-script -a fi #!/bin/sh . git-sh-setup-script || die "Not a git archive" if [ -n "$(git-diff-files)" ]; then echo The following files should be updated! echo git-diff-files | awk '{print $6}' fi undostack=$GIT_DIR/undostack headtree=$(git-cat-file commit $(cat $GIT_DIR/HEAD) | head -n 1 | sed -e 's/tree //') undotree=$(git-write-tree) if [ $headtree == $undotree ]; then echo There are no changes to undo. else { echo $headtree echo $undotree } >> $undostack echo Saved current state as tree $undotree. echo Reverting to HEAD, $headtree... git-checkout-script -f fi