git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Beyer <s-beyer@gmx.net>
To: "Stephen R. van den Berg" <srb@cuci.nl>
Cc: git@vger.kernel.org, Mike Hommey <mh@glandium.org>,
	Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
Subject: Re: RFC: grafts generalised
Date: Wed, 2 Jul 2008 21:31:57 +0200	[thread overview]
Message-ID: <20080702193157.GA21297@leksak.fem-net> (raw)
In-Reply-To: <20080702183701.GE16235@cuci.nl>

Hi,

I'm somehow quite confused about the desired workflow but I try an
answer.

Stephen R. van den Berg wrote:
> As far as I understood it, the new git sequencer rewrites history
> proper.  That is timeconsuming by definition, and thus it is *not*
> possible to make a tool based on the sequencer that supports the desired
> iterative-history-rewrite workflow.

If I got the problem right, it is possible.
But you have to rewrite and cannot just fake history, of course.
And, as Michael wrote:
> The currently planned set of commands would need to be amended, but the
> framework should be in place.

...for example, a "pick <commit>" that just picks the _tree_ of the
commit and not the _introduced changes_. (I've never used info/grafts,
but if I get the principle right, such tree-picks could realize a
linear list of info/grafts history fakes.)

Stephen wrote earlier:
> The problem I encounter is that any number of times I have to "edit"
> history in a non-parameterable fashion, in any of the following ways:

Hm, imho sequencer is well-suited for "non-parameterable" stuff.

> - Change parents.

The "pick" instruction (onto the new parent) is your friend.

> - Add merges.

"merge" instruction ;)

> - Change author, committer, commitdate, authordate.

sequencer doesn't allow to change committer data, but this could
be an easy change if you really need that.
The same with the author timestamp, that could only be reused from
an old commit by using -C option on pick.

> - Change the tree (because of conversion errors in the automated
>   conversion process) belonging to a single commit.
> - Retrofit a patch which has to ripple through all of history until
>   the present.

"pause" instruction, and then do manual changes, then
	git sequencer --continue

Stephan has also written:
> Also, having to run the sequencer to dig 20000 commits into the past,
> then change something, then come back up and rewrite all following
> history and relations (parents/tags/merges) will take a sizeable amount
> of time.

I wonder if grafts can be used in combination with sequencer in such a
way that you rewrite foo~20000..foo~19950 and then fake the parents of
foo~19949 to be the rewritten once.

> I need something that can be changed at will, then viewed with
> gitk a second later.

You can run gitk whenever you did "pause" in the sequencer file.
[Btw, an integration of sequencer into gitk is also on the TODO list,
 but that's OT here.]

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

  reply	other threads:[~2008-07-02 19:33 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-02 14:35 RFC: grafts generalised Stephen R. van den Berg
2008-07-02 16:35 ` Jakub Narebski
2008-07-02 16:43   ` Michael J Gruber
2008-07-02 17:42     ` Stephen R. van den Berg
2008-07-02 18:25       ` Mike Hommey
2008-07-02 18:34         ` Michael J Gruber
2008-07-02 19:31           ` Stephan Beyer [this message]
2008-07-02 19:36             ` Stephan Beyer
2008-07-02 20:42             ` Dmitry Potapov
2008-07-02 23:46               ` Stephan Beyer
2008-07-03  6:05                 ` Stephen R. van den Berg
2008-07-02 18:37         ` Stephen R. van den Berg
2008-07-07  6:28       ` Andreas Ericsson
2008-07-07  6:59         ` Stephen R. van den Berg
2008-07-02 17:32   ` Stephen R. van den Berg
2008-07-03  0:21     ` Petr Baudis
2008-07-03  7:11       ` Stephen R. van den Berg
2008-07-04  0:43     ` Jakub Narebski
2008-07-02 17:19 ` Dmitry Potapov
2008-07-02 17:58   ` Dmitry Potapov
2008-07-02 18:10     ` Stephen R. van den Berg
2008-07-02 18:33       ` Dmitry Potapov
2008-07-02 20:39       ` Dmitry Potapov
2008-07-02 21:18         ` Stephen R. van den Berg
2008-07-02 21:28           ` Avery Pennarun
2008-07-02 21:27         ` Junio C Hamano
2008-07-02 21:49           ` Junio C Hamano
2008-07-03  0:03             ` Junio C Hamano
2008-07-03  6:02       ` Johannes Sixt
2008-07-03  7:30         ` Stephen R. van den Berg
2008-07-03  7:42           ` Johannes Sixt
2008-07-03  9:37             ` Stephen R. van den Berg
2008-07-02 17:59   ` Stephen R. van den Berg
2008-07-03  0:13 ` Petr Baudis
2008-07-03  0:16   ` Petr Baudis
2008-07-03  0:28     ` Junio C Hamano

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=20080702193157.GA21297@leksak.fem-net \
    --to=s-beyer@gmx.net \
    --cc=git@vger.kernel.org \
    --cc=mh@glandium.org \
    --cc=michaeljgruber+gmane@fastmail.fm \
    --cc=srb@cuci.nl \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).