Re: [PATCH 0/5] My set of stgit companion scripts.

From: Yann Dirson <ydirson@altern.org>
Date: Jan 9, 2007, 22:26 UTC
Message-ID: <20070109222602.GE17093@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0701090221o6437fc0ana17bb190eb1eae0b@mail.gmail.com>

On Tue, Jan 09, 2007 at 10:21:30AM +0000, Catalin Marinas wrote:

> >stg-what-changed is invaluable when shuffling patches in the stack.
> 
> It's interesting to see the diff of diffs but it takes some time to
> get used to it :-).

Sure :)

I think there is a lot of room for improvement here, which is possibly a bit outside the scope of StGIT itself - eg. detecting that a change was indeed done but in a different place, detecting changes impacting only the context, etc.

> There is 'stg log (--patch|--graphical)' which
> shows the diff of every refresh you did on the patch. What it doesn't
> show is the diff of a push since this creates a new patch version
> every time.

I'm not sure what you mean here, I do get diffs for pushes, they just reflect the changes done in patches below (which indeed confused me very must when I first saw them - I even thought at first that patch logging was confused by something in my repos).

OTOH, there are other places where the log shows nothing but should record something, eg. on "refresh -e" when only editing the message.

> Maybe this could be extended so that for push with
> conflicts, it first stores a version with conflict markers and another
> version after fixing them and refreshing.

Well, that could possibly help when browsing with existing tools, but I'm not sure it would be the right way to do things.

To be fair, I have mixed feelings towards the current patch logs already. Specifically, a patch log conceptually records how a patch changes, but the current implementation (just like the one in "pg") makes it so changes to below patches are reflected in the log.

I'd rather thing patchlog entries should link 2 commits (ie. maybe we should add the ability for commit object to point to a commit in its "tree" field, or maybe we should add a new "metacommit" type of object), and that we should develop a set of tools to deal with changes in changes, just like we already have tools to deal with changes. Not a trivial thing, but that should be fun :)

Best regards,

-- 
Yann.