public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@gmail•com>
To: Paul Jackson <pj@sgi•com>
Cc: git@vger•kernel.org
Subject: Re: Stacked GIT 0.1 (a.k.a. quilt for git)
Date: Fri, 24 Jun 2005 13:27:57 +0100	[thread overview]
Message-ID: <tnx4qbo548i.fsf@arm.com> (raw)
In-Reply-To: <20050624045627.6e9cbaff.pj@sgi.com> (Paul Jackson's message of "Fri, 24 Jun 2005 04:56:27 -0700")

Paul Jackson <pj@sgi•com> wrote:
>> there is no way to modify the log history.
>
> Aha.  If that means what I think it does, then I suspect I will remain
> with quilt.  The per-patch comment is often about the last thing that
> I put in the patch.

I think you got it a bit wrong.

That was the initial idea. Anyway, in a future version you will have
one commit which is trackable via HEAD and which represents the whole
patch. This commit's log should always contain the patch description
so that people pulling your HEAD know what it is about.

If this is useful, a patch can have a second commit (or chain of
commits) refering to the same tree but not trackable via .git/HEAD but
which can be useful to track the individual changes of a patch. This
would be stored under .git/patches/<head>/<name>/ and not accessible
to anyone pulling the HEAD (well, rsync might bring the object but it
can be cleaned-up). This might be useful if you have a bigger patch
and want to track its changes, only internally.

Anyway, I think I won't implement this second commit handling and the
per-patch history would be trashed. Now I think I understand why you
mean by not caring about the commit message.

> The special thing about quilt is that the patch set in every regard
> is infinitely changeable - the selection and order of the patches,
> the contents of the patches, and the comments and metadata associated
> with the patch can all be edited trivially.

Almost all of this can be done with stgit. A patch in stgit is a just
a diff between 2 snapshots of the tree. The patch is indefinitely
changeable via commit. This weekend I will implement the proper commit
handling so that every new commit represents the whole patch and not
just the last modification.

You can easily reorder patches by popping all of them and pushing in a
different order. This is done via diff3 merging.

> Quilt is not a change management system; it's a patch set composition
> system.

I think the confusion comes from the fact that I wanted to put both
patch composition and change management in the same tool without a
clear separation.

> That stgit is layered on git (a persistent data store), and that
> it has something (the log history you mention above) that cannot
> be modified, suggests that stgit is not a 'better quilt for git',
> but some other sort of tool.

Again, the log history should only be internal, if useful, and not
visible to the outside world.

> Good luck ;).

Thanks. At least it is good that you tried it and provided some ideas
about what's needed as a quilt replacement. I will release a 0.3
version this weekend with the above things and you can try it.

-- 
Catalin


  reply	other threads:[~2005-06-24 12:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-16 22:44 Stacked GIT 0.1 (a.k.a. quilt for git) Catalin Marinas
2005-06-17 22:10 ` Daniel Barkalow
2005-06-17 22:28   ` Jon Seymour
2005-06-18 21:43     ` Catalin Marinas
2005-06-18 21:35   ` Catalin Marinas
2005-06-19  4:26     ` Daniel Barkalow
2005-06-19  9:24       ` Catalin Marinas
2005-06-24  0:58 ` Paul Jackson
2005-06-24  9:05   ` Catalin Marinas
2005-06-24 10:47     ` Paul Jackson
2005-06-24 11:29       ` Catalin Marinas
2005-06-24 11:56         ` Paul Jackson
2005-06-24 12:27           ` Catalin Marinas [this message]
2005-06-28 10:03           ` Catalin Marinas
2005-06-29 21:28             ` Paul Jackson

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=tnx4qbo548i.fsf@arm.com \
    --to=catalin.marinas@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=pj@sgi$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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