From: Carl Baldwin <cnb@fc.hp.com>
To: "Kirby C. Bohling" <kbohling@birddog.com>
Cc: Junio C Hamano <junkio@cox.net>, Carl Baldwin <cnb@fc.hp.com>,
Daniel Barkalow <barkalow@iabervon.org>,
Linus Torvalds <torvalds@osdl.org>,
git@vger.kernel.org
Subject: Re: [RFC] undo and redo
Date: Thu, 25 Aug 2005 15:28:51 -0600 [thread overview]
Message-ID: <20050825212851.GA3311@hpsvcnb.fc.hp.com> (raw)
In-Reply-To: <20050825204930.GE7461@birddog.com>
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" <kbohling@birddog.com> 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 Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
next prev parent reply other threads:[~2005-08-25 21:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-24 17:23 [RFC] undo and redo Carl Baldwin
2005-08-24 18:10 ` Carl Baldwin
2005-08-24 18:51 ` Linus Torvalds
2005-08-24 19:56 ` Carl Baldwin
2005-08-24 20:44 ` Daniel Barkalow
2005-08-24 20:47 ` Carl Baldwin
2005-08-24 21:04 ` Daniel Barkalow
2005-08-24 22:48 ` Junio C Hamano
2005-08-25 2:41 ` Carl Baldwin
2005-08-25 5:06 ` Junio C Hamano
2005-08-25 16:32 ` Carl Baldwin
2005-08-25 17:39 ` Kalle Valo
2005-08-25 19:59 ` Kirby C. Bohling
2005-08-25 20:19 ` Junio C Hamano
2005-08-25 20:49 ` Kirby C. Bohling
2005-08-25 21:28 ` Carl Baldwin [this message]
2005-08-25 20:37 ` Carl Baldwin
2005-08-25 21:09 ` Kirby C. Bohling
2005-08-25 21:42 ` Carl Baldwin
2005-08-24 18:18 ` Junio C Hamano
2005-08-24 20:01 ` Carl Baldwin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050825212851.GA3311@hpsvcnb.fc.hp.com \
--to=cnb@fc.hp.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=kbohling@birddog.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.