Johannes Sixt wrote:
quoted text
>Stephen R. van den Berg schrieb:
>> Dmitry Potapov wrote:
>>> On second thought, it may be not necessary. You can extract an old commit
>>> object, edit it, put it into Git with a new SHA1, and then use the graft file to
>>> replace all references from an old to a new one. And you will be able to see
>>> changes immediately in gitk.

quoted text
>> Hmmmm, interesting thought.  That just might solve my problem.

quoted text
>I don't think it would.

quoted text
>You want to apply a patch through a part of the history. To do that, it is
>not sufficient to apply the patch to only one commit/tree and then fake
>parenthood of its child commits. You still need to apply the patch to all
>children.

I am aware of that.
There are actually two common cases:
- Historical changes which are confined and don't ripple through.  The
  above solution works just fine for that.
- Ripple-through changes.  They indeed need to be applied to every tree
  in the first-parent chain.  Even though this is going to take a
  considerable amount of time, there still are certain advantages to
  doing this using the method described above:
  + You can apply the patch to every commit/tree "interactively" if you want.
    (Yes, I know, git-sequencer supports this one as well, but not the
    next point).
  + You can view the change at any point in time (including in relation to the
    tree that follows it), right after making the amendments (without letting
    it ripple through to the end).
  + The ripple-through does not need to be performed in topological order,
    i.e. eventually you'll have to touch everything, but you can do it
    in the order you see fit (whatever is most efficient to work on).
  + If, at some point during the ripple-through process, you find out
    that you forgot some change(s), you can abort or restart the
    ripple-through without having spent all that time waiting for a
    full-ripple-through.

Actually, ripple-through changes are rare.  In the current project it
seems I need exactly one, but it's buried deep in the past (sadly).
The reason why I need it, is to make sure that git-bisect will work for
any revision in the past (i.e. the tree contained/contains some
too-clever-for-their-own-good $Revision$-expansion dependencies)
-- 
Sincerely,
           Stephen R. van den Berg.

This is a day for firm decisions!  Or is it?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html