git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

From
CMCatalin Marinas <catalin.marinas@gmail.com>
Date
Jun 24, 2005, 12:27 UTC
Message-ID
<tnx4qbo548i.fsf@arm.com>
In-Reply-To
<20050624045627.6e9cbaff.pj@sgi.com>
Paul Jackson <pj@sgi.com> wrote:
Show 5 quoted lines
>> 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
Previous: Paul JacksonNext: Catalin Marinas
Message 13 of 15 in “Stacked GIT 0.1 (a.k.a. quilt for git)”
  1. Catalin MarinasJun 16, 2005
  2. Daniel BarkalowJun 17, 2005
  3. Jon SeymourJun 17, 2005
  4. Catalin MarinasJun 18, 2005
  5. Catalin MarinasJun 18, 2005
  6. Daniel BarkalowJun 19, 2005
  7. Catalin MarinasJun 19, 2005
  8. Paul JacksonJun 24, 2005
  9. Catalin MarinasJun 24, 2005
  10. Paul JacksonJun 24, 2005
  11. Catalin MarinasJun 24, 2005
  12. Paul JacksonJun 24, 2005
  13. Catalin MarinasJun 24, 2005
  14. Catalin MarinasJun 28, 2005
  15. Paul JacksonJun 29, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.