From: Catalin Marinas <catalin.marinas@gmail.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: Stacked GIT 0.1 (a.k.a. quilt for git)
Date: Sun, 19 Jun 2005 10:24:49 +0100 [thread overview]
Message-ID: <tnxll56y9zy.fsf@arm.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0506182338300.30848-100000@iabervon.org> (Daniel Barkalow's message of "Sun, 19 Jun 2005 00:26:25 -0400 (EDT)")
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Sat, 18 Jun 2005, Catalin Marinas wrote:
>> Having different series would be a good idea but it might complicate
>> the tool usage. I will thing about it once I'm sure the basic
>> operations work fine.
>
> You could future-proof yourself a bit by simply saving the base as
> .git/refs/bases/master and making the patches be
> .git/patches/master/. That way, you'd be ready when you start to support
> multiple series.
You are right. I will do this for the next release (0.2, probably of
the end of this week), something like the tree structure below:
.git/refs/bases/<head>
.git/series/<head>/
.git/series/<head>/applied
.git/series/<head>/unapplied
.git/series/<head>/current
.git/series/<head>/patches/*
I don't know whether a git-diff-* command would look into
.git/refs/bases (I can do this in stgit but, this was only for
convenience).
[...]
> Note that it gets more complex if mainline takes only your second patch
> (due to it not requiring your first, and your first not being as
> acceptable). In this case, it needs to entire mainline as a patch, because
> merges can't cherrypick, whereas patches can act arbitrarily. But it would
> be nice to store the information of what happened even with patches that
> cherrypick, such that we have a better chance for managing things
> later.
You can cherry-pick the second patch by first commuting it with the
previous patches. If they are independent, the commuting via diff3
wouldn't generate any conflict. Even with the current stgit, you can
pop all the patches and only push those to be merged upstream. HEAD
would only contain the those patches.
If you want to implement a full-featured patch treacking, you might
end up with something like darcs which doesn't scale to the size of
the Linux kernel. On the other hand, you might not agree with the
changes to your accepted patch and a conflict is welcomed so that you
can choose whether to keep the old version or not.
> But I think that you have the right ideas about how
> patches should be represented, and it would be good to get your
> representation implemented inside git, because operations more central to
> git would benefit from having this information.
Do you mean creating a new git type like the blob, tree or commit? I
would prefer not to modify git or have my own version of git. StGIT
should be a tool running directly on top of an existing installation
of git.
Instead of having a directory for every patch (with bottom, top
etc. files), I could create a git blob to store this information and
the series files (applied/unapplied files) would only contain the blob
id. This could simplify things if, in a future version, stgit would
allow patch cherry-picking.
--
Catalin
next prev parent reply other threads:[~2005-06-19 9:21 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 [this message]
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
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=tnxll56y9zy.fsf@arm.com \
--to=catalin.marinas@gmail.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
/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).