Hello Filippo,
On Tue, Jun 30, 2009 at 03:22:04PM +0200, Filippo Giunchedi wrote:
> On Tue, Jun 30, 2009 at 09:36:20AM +0200, Uwe Kleine-König wrote:
> > > However when sending them upstream it would be nice to be able to send
> > > the full history as git format-patch would do but excluding .topdeps and
> > > .topmsg (or using it as basis for --cover-letter), IOW have tg patch
> > > accept an option to behave like format-patch but output the full history
> > I don't understand what exactly you want. Incremental patches? I think
> > this won't work in general because the history typically contains merges
> > that are not representable by a patch. Hm, you could leave out the
> > merges. But then they might not apply cleanly to upstream's tree.
>
> In general you are right, merges could be a problem
>
> > Do you really consider the intermediate steps interesting? IMHO a topic
> > branch is a unit and if it's sensible to send in in (say) three mails
> > then the patch should better be seperated into three patches/topic
> > branches.
>
> disclaimer: note that I might be missing something as I'm using topgit since
> some weeks and topgit might not the best tool for the scenario below
>
> > Maybe you could present an example where you can show that having the
> > full history is sensible?
>
> My scenario is that I'm maintaining a topic branch against upstream which also
> uses git, for the sake of consistency I'm using topgit as that branch will
> probably go in debian/patches/
>
> If I want to send the branch upstream for review I would like incremental
> patches as that is nicer on upstream, OTOH for debian packaging I'm exporting
> as
> a single patch.
Obviously you don't want to feed your complete patch upstream as is, OK.
But in general you want to squash more the one commit to get a nice
patch. Your approach only works if you did your patch right right from
the beginning. (Note: you could simply use git-format-patch for that.)
I assume you don't mean with incremental that you only send the new
changes if you send an updated patch, do you?
> So far so good, the problem is that sending upstream incremental patches from
> topgit as you would normally do with git format-patch you have to exclude
> .topmsg and .topdeps which tg patch already does
>
> I fear that having a branch per topic is generally okay but not if you want
> clean history including micro commits to be send upstream.
Try this:
Collect your patches in a single topic branch as you do now. I'll call
it t/debian-sid-pu. If you want to send something upstream do the
following (assuming your upstream branch is called "upstream"):
$ tg create t/nice-name-for-topic upstream
$ vim .topmsg; vim $file; git add .topmsg $file; git commit
expecting that you duplicate a part of t/debian-sid-pu in
t/nice-name-for-topic. If you want you can also cherry pick from
top-bases/t/debian-sid-pu..t/debian-sid-pu. Then
$ git checkout t/debian-sid-pu
$ tg depend add t/nice-name-for-topic
If your changes in t/debian-sid-pu are seperated enough, the last
command should just merge t/nice-name-for-topic into t/debian-sid-pu
without changing the tree of t/debian-sid-pu. (Otherwise you get a
merge conflict that you probably want to resolve such that again the
tree of t/debian-sid-pu doesn't change.)
With this workflow you can create your topic branches on demand after
the changes are already used. Still it allows to group more than one
commit into a topic.
If I didn't understood you right (or you didn't understood me) I suggest
you join
irc://chat.freenode.net/#topgit
I'm usually around there when I'm online and a few others, too.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
