From: Otavio Salvador <otavio@debian.org>
To: Catalin Marinas <catalin.marinas@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: StGit metadata grabbing with git clone
Date: Thu, 23 Nov 2006 12:31:23 -0200 [thread overview]
Message-ID: <87ejru1bgk.fsf@neumann.lab.ossystems.com.br> (raw)
In-Reply-To: <tnxslgawic2.fsf@arm.com> (Catalin Marinas's message of "Thu, 23 Nov 2006 10:47:09 +0000")
Catalin Marinas <catalin.marinas@arm.com> writes:
> Otavio Salvador <otavio@debian.org> wrote:
>> I'm a happy user of stgit together with git to maintain a patch queue
>> while I or the company team is working on patches that will be send
>> for merging. Both works great but we're having troubles when we try to
>> clone a stgit repository.
>>
>> When I clone the repository it grab the source but it loses the
>> metadata. I would like to grab those too. Does anybody has a solution
>> or a trick how I can do that?
>
> Most of the StGIT metadata can be generated by "uncommit" (the reason
> I still keep a lot of this metadata like author etc. is for
> speed). However, I'm not sure how well this would work since you can
> nor synchronise the patches afterwards. StGIT works well for sharing
> patches via e-mail but you might want to consider topic branches
> instead of patches (though StGIT seems more convenient).
>
> Another idea is to export the patches (stg export) to a common place
> and import them in the other tree (stg import --series --replace). I
> could also add a --sync option to "import", instead of --replace,
> which would perform a three-way merge with the coresponding local
> patches so that it grabs any additional changes in both repositories
> or branches (similar to "pick --fold", option which I added for the
> same reason).
>
> Yet another idea is a "stg import" command for remote repositories or
> branches which would bring in the StGIT metadata.
>
> At the bottom of the TODO list is something that would solve this,
> only that I've never found the time to think about it properly. I work
> on several branches (and even separate trees) and share patches
> between them. It would be nice to be able to synchronise the changes
> to these patches.
That would be a really nice feature. Besides, would be nice to have a
way to plug something on clone and push git methods so you might send
all those metadata without much hassle.
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
prev parent reply other threads:[~2006-11-23 14:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-22 12:05 StGit metadata grabbing with git clone Otavio Salvador
2006-11-22 20:29 ` Robin Rosenberg
2006-11-22 21:38 ` Petr Baudis
2006-11-22 23:56 ` Robin Rosenberg
2006-11-23 10:47 ` Catalin Marinas
2006-11-23 14:31 ` Otavio Salvador [this message]
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=87ejru1bgk.fsf@neumann.lab.ossystems.com.br \
--to=otavio@debian.org \
--cc=catalin.marinas@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.