"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
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:
Then you do the work that interrupted you, maybe making commits
B and then C:
At this point, you would want to restart working on whatever you
were doing, which is the difference between A->D applied on top
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