> 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
