headers
martin f krafft | 12 Aug 18:14
Favicon

TopGit: problem with patch series generation

Hi folks,

I am playing around with TopGit and encountered a (conceptual)
problem. I'd love to hear some input.

I want to use TopGit for distro packaging. Any of my packages have
one or more feature branches, some intended for upstream, some
distro-specific. As I am packaging TopGit for Debian, I encountered
the situation that two branches conflict with each other (they
change the same line), but there is no dependency between the
branches. Thus, when I squash the branches into a series, the
resulting patches will not apply (they both change the same original
line to something else).

Obviously, I can introduce a "fake" dependency to force TopGit to
create one patch based on another. However, this then prevents me
from testing and developing the depending branch in isolation,
meaning that I always have to have the dependent branch applied when
I want to work on the second feature. Furthermore, it's not
trivially possible in this situation to cherry-pick only the second
patch.

I see that this is a hard problem with no obvious solution. The only
thing that comes to my mind is maintaining multiple patches for each
branch. In the above, if B "fake-depends" on A, which depends on
master, then I would have A and B depend on master only, but have
TopGit also manage B2 for me, which is a diff against A.

Doing this for all branches is polynomial, but then again, the
number of independent branches, or rather branch trees, is likely to
(Continue reading)

Permalink | Reply |
headers
Avery Pennarun | 12 Aug 18:25

Re: TopGit: problem with patch series generation

On Tue, Aug 12, 2008 at 12:18 PM, martin f krafft <madduck <at> debian.org> wrote:
> As I am packaging TopGit for Debian, I encountered
> the situation that two branches conflict with each other (they
> change the same line), but there is no dependency between the
> branches. Thus, when I squash the branches into a series, the
> resulting patches will not apply (they both change the same original
> line to something else).

Isn't this what git-rerere is for?  If TopGit doesn't use rerere,
maybe it would be easy to add...

Have fun,

Avery
Permalink | Reply |
headers
martin f krafft | 12 Aug 19:52

Re: TopGit: problem with patch series generation

also sprach Avery Pennarun <apenwarr <at> gmail.com> [2008.08.12.1325 -0300]:
> Isn't this what git-rerere is for?  If TopGit doesn't use rerere,
> maybe it would be easy to add...

I'd rather avoid the need to replay conflict resolution and do it in
one place only. It always seemed to me that git-rerere is a solution
to a problem that could have been avoided.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"it is only the modern that ever becomes old-fashioned." 
                                                        -- oscar wilde

spamtraps: madduck.bogus <at> madduck.net

also sprach Avery Pennarun <apenwarr <at> gmail.com> [2008.08.12.1325 -0300]:
> Isn't this what git-rerere is for?  If TopGit doesn't use rerere,
> maybe it would be easy to add...

I'd rather avoid the need to replay conflict resolution and do it in
one place only. It always seemed to me that git-rerere is a solution
to a problem that could have been avoided.

--

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"it is only the modern that ever becomes old-fashioned." 
                                                        -- oscar wilde
(Continue reading)

Permalink | Reply |
headers
Bert Wesarg | 12 Aug 20:54

Re: TopGit: problem with patch series generation

On Tue, Aug 12, 2008 at 18:25, Avery Pennarun <apenwarr <at> gmail.com> wrote:
> On Tue, Aug 12, 2008 at 12:18 PM, martin f krafft <madduck <at> debian.org> wrote:
>> As I am packaging TopGit for Debian, I encountered
>> the situation that two branches conflict with each other (they
>> change the same line), but there is no dependency between the
>> branches. Thus, when I squash the branches into a series, the
>> resulting patches will not apply (they both change the same original
>> line to something else).
>
> Isn't this what git-rerere is for?  If TopGit doesn't use rerere,
> maybe it would be easy to add...
I thought about this too, but have no experience with rerere.

Bert
>
> Have fun,
>
> Avery
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Permalink | Reply |
headers
Petr Baudis | 12 Aug 19:32
Favicon

Re: TopGit: problem with patch series generation

  Hi,

On Tue, Aug 12, 2008 at 01:18:54PM -0300, martin f krafft wrote:
> I want to use TopGit for distro packaging. Any of my packages have
> one or more feature branches, some intended for upstream, some
> distro-specific. As I am packaging TopGit for Debian, I encountered
> the situation that two branches conflict with each other (they
> change the same line), but there is no dependency between the
> branches. Thus, when I squash the branches into a series, the
> resulting patches will not apply (they both change the same original
> line to something else).

  yes, that is good point.

> Obviously, I can introduce a "fake" dependency to force TopGit to
> create one patch based on another. However, this then prevents me
> from testing and developing the depending branch in isolation,
> meaning that I always have to have the dependent branch applied when
> I want to work on the second feature. Furthermore, it's not
> trivially possible in this situation to cherry-pick only the second
> patch.

  Well, at least we're not _worse_ off than when using a classical patch
series instead of TopGit, since all the downsides would be the same as
if we had this "fake dependency", right? Though of course, it would be
nice if we could do better here.

> As an alternative, it may be possible, however, to let TopGit know
> about a "fake dependency" from B on A. When serialised, TopGit would
> notice that there are multiple paths from master to B (master->B and
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 13 Aug 01:07

Re: TopGit: problem with patch series generation

also sprach Petr Baudis <pasky@...> [2008.08.12.1432 -0300]:
> I'm not really happy about this idea, though. It would complicate
> TopGit even much more than it is now, and I'm not sure if this is
> worth it instead of just requiring you to maintain your
> dependencies more carefully when you intend to serialize your
> series later.

Sure, but there are no dependencies between some of these branches.

--

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"i worked myself up from nothing to a state of extreme poverty."
                                                       -- groucho marx

spamtraps: madduck.bogus@...

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
"Santi =?iso-8859-1?q?B=E9jar=22?= | 12 Aug 23:28

Re: TopGit: problem with patch series generation

On Tue, Aug 12, 2008 at 18:18, martin f krafft <madduck <at> debian.org> wrote:
> Hi folks,
>
> I am playing around with TopGit and encountered a (conceptual)
> problem. I'd love to hear some input.
>
> I want to use TopGit for distro packaging. Any of my packages have
> one or more feature branches, some intended for upstream, some
> distro-specific. As I am packaging TopGit for Debian, I encountered
> the situation that two branches conflict with each other (they
> change the same line), but there is no dependency between the
> branches. Thus, when I squash the branches into a series, the
> resulting patches will not apply (they both change the same original
> line to something else).
>

I don´t know if it fits topgit, but this is what Junio uses:

http://article.gmane.org/gmane.comp.version-control.git/24498

Basically he creates a new feature branch that is the merge of the
conflicting branches (it works for both semantically and explicit
conficts), and there he resolves the conficts. Then if one of the
branches are merged in master (in you case a patch is created) then
the other branch fast-forward to the merge.

HTH,

Santi
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 13 Aug 00:41

Re: TopGit: problem with patch series generation

also sprach Santi Béjar <sbejar@...> [2008.08.12.1828 -0300]:
> I don´t know if it fits topgit, but this is what Junio uses:
> 
> http://article.gmane.org/gmane.comp.version-control.git/24498

I think this is definitely something TopGit can automate.

--

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"life is what happens to you while you're busy making other plans."
                                                        -- john lennon

spamtraps: madduck.bogus@...

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
Petr Baudis | 13 Aug 00:59
Favicon

Re: TopGit: problem with patch series generation

On Tue, Aug 12, 2008 at 07:41:55PM -0300, martin f krafft wrote:
> also sprach Santi Béjar <sbejar <at> gmail.com> [2008.08.12.1828 -0300]:
> > I don´t know if it fits topgit, but this is what Junio uses:
> > 
> > http://article.gmane.org/gmane.comp.version-control.git/24498
> 
> I think this is definitely something TopGit can automate.

This seems to be in principle the same as the tie branches. It might
make sense to have a way to _optionally_ make a tie branch.

How should that work? Maybe there needs to be even an explicit support
for this - should TopGit just check the dependency tree when
sequencing the topic branches and have a step that says:

	"I'm going to sequence branch A. If there is branch T that has
	only already sequenced branches + branch A as dependencies,
	use T's content instead of A."

Would that be satisfactory?

Finding out this information would be very expensive, of course. But for
other reasons, we might want to keep a cache of branch dependencies.

Of course, in the case of

        A1--A2--A3--A4--C
                       /
        B1--B2--B3--B4.
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 13 Aug 01:10

Re: TopGit: problem with patch series generation

also sprach Petr Baudis <pasky <at> suse.cz> [2008.08.12.1959 -0300]:
> > I think this is definitely something TopGit can automate.
> 
> This seems to be in principle the same as the tie branches. It might
> make sense to have a way to _optionally_ make a tie branch.

Yes, optional would make sense!

> How should that work? Maybe there needs to be even an explicit support
> for this - should TopGit just check the dependency tree when
> sequencing the topic branches and have a step that says:
> 
> 	"I'm going to sequence branch A. If there is branch T that has
> 	only already sequenced branches + branch A as dependencies,
> 	use T's content instead of A."
> 
> Would that be satisfactory?

Yes, that's what I was thinking about, if I read you correctly.

> Of course, in the case of
> 
>         A1--A2--A3--A4--C
>                        /
>         B1--B2--B3--B4.
> 
> the sequenced branches would still be like
> 
>         A1--A2--A3--A4--B1--B2--B3--C
>
(Continue reading)

Permalink | Reply |
headers
Petr Baudis | 13 Aug 02:18
Favicon

Re: TopGit: problem with patch series generation

On Tue, Aug 12, 2008 at 08:10:37PM -0300, martin f krafft wrote:
> also sprach Petr Baudis <pasky@...> [2008.08.12.1959 -0300]:
> > How should that work? Maybe there needs to be even an explicit support
> > for this - should TopGit just check the dependency tree when
> > sequencing the topic branches and have a step that says:
> > 
> > 	"I'm going to sequence branch A. If there is branch T that has
> > 	only already sequenced branches + branch A as dependencies,
> > 	use T's content instead of A."
> > 
> > Would that be satisfactory?
> 
> Yes, that's what I was thinking about, if I read you correctly.

But we _REALLY_ want to do this only for stage branches!

> > Of course, in the case of
> > 
> >         A1--A2--A3--A4--C
> >                        /
> >         B1--B2--B3--B4.
> > 
> > the sequenced branches would still be like
> > 
> >         A1--A2--A3--A4--B1--B2--B3--C
> > 
> > unless you create the T1..T4 branches manually.
> 
> Yes. Or add a dependency. I'd just prefer not to add a dependency
> where there is none; instead, I'd prefer if TopGit could be aided
(Continue reading)

Permalink | Reply |

Gmane