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
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 A, D, 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 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 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. snip... [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
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 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. snip... [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 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 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
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
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
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 undo-point 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
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 undo-point 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, 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, 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
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
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
