On Mon, Sep 29, 2008 at 12:01:25PM +0200, martin f krafft wrote:
[..snip..]
> Have you looked at topgit:debian/README.source? Do you think
> git-buildpackage could help automate this process?
We can certainly (at least) add another hook that calls a script that
does what's described under 4.) and
I wish people would change subject lines more often...
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.29.2242 +0200]:
> Of course, it would be great that with some tagging topgit could
> keep track of the history itself (as VCS' are supposed to be doing),
> and not make me sto
On Tue, Sep 30, 2008 at 09:02:31AM +0200, Guido Günther wrote:
> > Can git-buildpackage use information stored in the repository, such
> > as which branch to build from? It would be handy to be able to tell
> > people just to use git-buildpackage without expecting them to pass
> > the right branch
On Mon, Sep 29, 2008 at 03:42:46PM -0500, Manoj Srivastava wrote:
> *Sigh*. You are missing context. And the point.
I was in fact missing some context, but still I think you don't see my
big picture.
> c) Therefore, we need to additionally store the patch series generated
> from git
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.09.30.0932 +0200]:
> Hence, I see no need of versioning the patch series. Having just
> the last series, most likely in the Debian source package, would
> be enough.
I always thought the point of tagging commits in the VCS was to be
able to
also sprach Guido Günther <[EMAIL PROTECTED]> [2008.09.30.0902 +0200]:
> We can certainly (at least) add another hook that calls a script
> that does what's described under 4.) and git-import-orig could
> help with importing new upstream but I think Manoj has some valid
> points about the current w
martin f krafft wrote:
> I wish people would change subject lines more often...
Yes, it was time :-)
> See #500656.
Interesting... With Manoj's arguments and this bugreport, I now
paradoxically understand the point in having two separate build/master
branches.
IIUC, the problem is being able to
[ unrelated: is the list configured to not deliver a message Cc-ed to
a subscriber also via the list? Please avoid Cc-ing me, since the
result is that I receive the message only in my INBOX and (I guess due
to the setting above) without a List-Id header ... ]
On Tue, Sep 30, 2008 at 10:02:34AM +02
also sprach Stéphane Glondu <[EMAIL PROTECTED]> [2008.09.30.1019 +0200]:
> > refs/top-tags/debian/1.0-1/base and
> > refs/top-tags/debian/1.0-1/tip
>
> Doing it that way would pollute the tag namespace, IMO.
Yes and no. Normal tags are in refs/tags. I am proposing the
refs/top-tags namespace,
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.09.30.1036 +0200]:
> [ unrelated: is the list configured to not deliver a message Cc-ed
> to a subscriber also via the list?
This is a per-user setting in Mailman.
> Please avoid Cc-ing me, since the result is that I receive the
> message o
martin f krafft wrote:
> Yes and no. Normal tags are in refs/tags. I am proposing the
> refs/top-tags namespace, which is reserved for topgit anyway (topgit
> reserved refs/top-*).
Sorry, I didn't pay attention to this. I guess this needs a special
cloning/pushing/pulling procedure, then? BTW, you
On Tue, Sep 30, 2008 at 10:02 AM, martin f krafft <[EMAIL PROTECTED]> wrote:
> I always thought the point of tagging commits in the VCS was to be
> able to recreate pristine Debian source packages, no? Why do we
> bother tagging packages debian/1.0-1 if the tag cannot be used to
> actually obtain t
also sprach Stéphane Glondu <[EMAIL PROTECTED]> [2008.09.30.1159 +0200]:
> Sorry, I didn't pay attention to this. I guess this needs a special
> cloning/pushing/pulling procedure, then?
Yes, and that would be setup by tg-remote, which already sets this
up for refs/top-bases/*.
> BTW, you don't ta
Teemu Ikonen wrote:
> The obvious, although perhaps inelegant way to solve the storage of
> the released debian source would be to modify pristine-tar to work
> with deb-source packages and store them in a branch of their own,
> maybe called "released-deb" or similar. The storage overhead for this
On Tue, Sep 30, 2008 at 12:45 PM, Stéphane Glondu <[EMAIL PROTECTED]> wrote:
> Teemu Ikonen wrote:
>> First, find a path from tagged release commit in master to the commit
>> in topgit branch patch/x preceding the commit in master where patch/x
>> was last merged in. Let's call this commit Px. Next
Teemu Ikonen wrote:
> AFAIK, all branches in git are "just references", and branch names are
> not stored in commit objects. The proposed program would have to do a
> preliminary pass through the revision graph starting from the branch
> heads (patch/x and top-bases/patch/x) and tag all the commits
On Tue, Sep 30, 2008 at 1:28 PM, Stéphane Glondu <[EMAIL PROTECTED]> wrote:
> Teemu Ikonen wrote:
>> AFAIK, all branches in git are "just references", and branch names are
>> not stored in commit objects. The proposed program would have to do a
>> preliminary pass through the revision graph startin
Teemu Ikonen wrote:
> Update the current topic branch wrt. changes in the branches
> it depends on and remote branches.
> This is performed in two phases - first,
> changes within the dependencies are merged to the base,
> then the base is merged into the topic branch.
On Tue, Sep 30 2008, Stefano Zacchiroli wrote:
> On Mon, Sep 29, 2008 at 03:42:46PM -0500, Manoj Srivastava wrote:
>> c) Therefore, we need to additionally store the patch series generated
>> from git branches into yet another git branch (presumably not one
>> the patch series are genera
On Tue, Sep 30 2008, martin f krafft wrote:
> also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.09.30.0932 +0200]:
>> Hence, I see no need of versioning the patch series. Having just
>> the last series, most likely in the Debian source package, would
>> be enough.
> I always thought the po
On Tue, Sep 30, 2008 at 10:42:37AM +0200, martin f krafft wrote:
> > who cares if you won't be able to recreate the exactly same
> > package?
> Because the topgit branches you used to create the stable package
> cannot be used anymore to create the patches that went into the
> stable package.
OK,
On Tue, Sep 30, 2008 at 12:22:03PM +0200, Teemu Ikonen wrote:
> The obvious, although perhaps inelegant way to solve the storage of
> the released debian source would be to modify pristine-tar to work
> with deb-source packages and store them in a branch of their own,
> maybe called "released-deb"
also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.09.30.2104 +0200]:
> OK, my bad than, I didn't know this (rather gory) detail. I thought it
> was just a problem of not being able to create the exact
> representation (e.g., to preserve checksums of the source package), I
> didn't get that t
On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote:
> Not really. I prefer to have the source packages be unpackged
> even on a machine which does not run Debian, using just plain old tar
> and patch. Thus I tend to ship the diff.gz as something that creates
> the set of b
also sprach Teemu Ikonen <[EMAIL PROTECTED]> [2008.09.30.1431 +0200]:
> This would indicate that bases are managed by merging (which naturally
> can be a fast-forward merge) and not rebasing or otherwise rewriting
> history. The same applies for topic branches, which are merged to the
> latest base
also sprach Teemu Ikonen <[EMAIL PROTECTED]> [2008.09.30.1222 +0200]:
> First, find a path from tagged release commit in master to the
> commit in topgit branch patch/x preceding the commit in master
> where patch/x was last merged in. Let's call this commit Px. Next,
> starting from Px, find the c
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.30.2131 +0200]:
> At this point, pre-topgit, that is what my tags do:
> I tag the ./debian/ branch and the integration branch. Checking out the
> tag on the integration branch, and installing the submodules, are all
> you need to
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.30.2131 +0200]:
> At this point, pre-topgit, that is what my tags do:
> I tag the ./debian/ branch and the integration branch. Checking out the
> tag on the integration branch, and installing the submodules, are all
> you need to
On Tue, Sep 30, 2008 at 10:46 PM, martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Teemu Ikonen <[EMAIL PROTECTED]> [2008.09.30.1222 +0200]:
>> First, find a path from tagged release commit in master to the
>> commit in topgit branch patch/x preceding the commit in master
>> where patch/x w
On Tue, Sep 30 2008, martin f krafft wrote:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.30.2131 +0200]:
>> At this point, pre-topgit, that is what my tags do:
>> I tag the ./debian/ branch and the integration branch. Checking out the
>> tag on the integration branch, and
On Tue, Sep 30 2008, martin f krafft wrote:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.09.30.2131 +0200]:
>> At this point, pre-topgit, that is what my tags do:
>> I tag the ./debian/ branch and the integration branch. Checking out the
>> tag on the integration branch, and
On Tue, Sep 30 2008, Martin Bähr wrote:
> On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote:
>> Not really. I prefer to have the source packages be unpackged
>> even on a machine which does not run Debian, using just plain old tar
>> and patch. Thus I tend to ship the dif
Martin Bähr wrote:
>> I see the source package as something useful perhaps even in a
>> non distro specific setting.
>
> indeed, they are. but exactly for working outside of debian it would be
> preferable to have the patches easely accessible seperately. i
> occasionally try to pick patc
On Tue, Sep 30 2008, Stéphane Glondu wrote:
> Martin Bähr wrote:
>>> I see the source package as something useful perhaps even in a
>>> non distro specific setting.
>>
>> indeed, they are. but exactly for working outside of debian it would be
>> preferable to have the patches easely acce
* Manoj Srivastava <[EMAIL PROTECTED]> [080930 21:15]:
> On Tue, Sep 30 2008, Stéphane Glondu wrote:
Only if you like working with patch series, and prefer to lose
> all the information that the original VCS contained. I prefer to see
> the whole history, not just a snapshot, when I am j
On Tue, Sep 30 2008, Aidan Van Dyk wrote:
> * Manoj Srivastava <[EMAIL PROTECTED]> [080930 21:15]:
>> On Tue, Sep 30 2008, Stéphane Glondu wrote:
> Only if you like working with patch series, and prefer to lose
>> all the information that the original VCS contained. I prefer to see
>> t
On Tue, Sep 30, 2008 at 04:50:21PM -0500, Manoj Srivastava wrote:
> With a patch series that changes slowly from release to release,
> trackign changes in a patch from one release to the nhext becomes,
> for me, a nightmare.
how is that? (not that i have never done this yet so i simply have no
On Wed, Oct 01 2008, Martin Bähr wrote:
> On Tue, Sep 30, 2008 at 04:50:21PM -0500, Manoj Srivastava wrote:
>> With a patch series that changes slowly from release to release,
>> trackign changes in a patch from one release to the nhext becomes,
>> for me, a nightmare.
> how is that? (not that
On Tue, Sep 30, 2008 at 10:27:13PM +0200, Martin Bähr wrote:
> On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote:
> > Not really. I prefer to have the source packages be unpackged
> > even on a machine which does not run Debian, using just plain old tar
> > and patch. Thus
39 matches
Mail list logo
