interesting discussion on git mailing list

[martin f krafft]

also sprach James Westby <jw+debian at jameswestby.net> [2007.07.10.1844 +0200]:
> > the way to do this in git would be to have an integration branch and
> > only merge those branches you want enabled. You cannot unmerge
> > a branch, I think, though it should be trivial too. Then you could
> > disable patches/branches.
> 
> 'git reset --hard ORIG_HEAD' just after a pull undoes that merge. For
> later on 'git revert' can do it, but I don't know about reverting a
> whole branch at once with it.

From an IRC discussion, I found that it's not possible to unmerge
a branch. You can easily revert a commit and if your merge was
a single commit, that's the ticket, but if you kept on merging
a feature branch into the integration branch, you'll have to revert
every single commit, I think, in reverse order.

> > > e) patches are reviewable on source-package level
> > 
> > This is an important point, I agree. It would make sense
> > actually to export source packages by converting branches to
> > dpatches, like Canonical's HCT tried. Unfortunately, I am not
> > sure where it stands or whether it's usable, but it should
> > actually not be that hard to implement in a script.
> 
> That would be good. A script should be possible. However HCT
> appears to be dead and abandoned, and the source is not available
> as far as I can see.

It was also bzr specific. It should not be too hard to write
a script that

  - determines which VCS is in use and loads the right handler
  - asks the handler for an export of the upstream branch, unless
    a tarball is available in ..
  - unpack the tarball to a temporary directory
  - asks the handler for the debiandir branch and applies it to the
    temporary directory
  - asks the handler for the list of feature branches and iterates
    them, for each asking the handler for a diff.
  - writes these diffs to <temp>/debian/patches
  - and does whatever needed to apply them, which is not the same as
    making everything depend on dpatch.

Obviously, some of this stuff should go into dpkg-source. For
instance, dpkg-source should really have the ability to apply
debian/patches/* after unpacking the .orig.tar.gz and applying the
.diff.gz.

> There has been talk of moving to a successor like the loom plugin
> on NoMoreSourcePackages, however I have not been able to get any
> contact from anyone involved in that originally to discuss
> problems with it and maybe move towards an implementation. I have
> had some conversations with Reinhard Tartler about it, and he may
> work on an implementation soon, but he has not commented on my
> concerns as yet.

https://wiki.ubuntu.com/NoMoreSourcePackages

I am absolutely not convinced that this should be done by the VCS.
Rather, it should be done in dpkg-source, don't you agree?

> The scheme described there is actually a lot more applicable to
> git that to bzr, so it might be interesting to implement it on git
> first anyway.

Well, the "scheme" seems to be exactly what Manoj has been using and
what we taught in the "forking debian every day" workshop at
Debconf7.

  http://arch.debian.org/arch/private/srivasta/
  https://penta.debconf.org/~joerg/events/53.en.html

Canonical have made a splendid effort from day one to completely
ignore Manoj's and my work on any of this.

Anyway, does anyone know what dpkg v2 is up to these days?

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck
 
spamtraps: madduck.bogus at madduck.net
 
"the most exciting phrase to hear in science, the one that heralds
 new discoveries, is not 'eureka!' but 'that's funny...'"
                                                     -- isaac asimov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (GPG/PGP)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20070710/7fa9118c/attachment.pgp