On Tue, Jul 25, 2017 at 03:55:08PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: extracting upstream source."):
> > dgit often has "something like" the upstream source tree as a git tree
> > object. dgit should provide a way for you to get at it.
>
> This is now #869675.
For our Ubuntu
On Tue, Jun 13, 2017 at 03:18:27PM +0100, Ian Jackson wrote:
> Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git
> directories in source package uploads?]"):
> > I disagree here. We don't need to "hope". I don't expect the b
On Tue, Jun 13, 2017 at 03:04:46PM +0100, Robie Basak wrote:
> 1. The imported git trees are defined to escape /^\.git.*/ by
> prepending a '.'.
It just occurred to me that this would also escape '.gitignore' to
'..gitignore', which personally I'd like, but others might find
surprisi
On Mon, Jun 12, 2017 at 05:46:14PM +0100, Ian Jackson wrote:
> Again, I don't follow why `fail' occurs. You seem to be suggesting
> that importing a .dsc containing a .git would generate ..git.
Correct. I'm suggesting "fail" for the round-tripping - for "git ubuntu
build-source" to "unescape"
On Mon, Jun 12, 2017 at 04:57:06PM +0100, Ian Jackson wrote:
> `dgit clone' disables these .gitattributes; provides a separate verb
> for disabling them in other trees; and `dgit fetch' warns about them
> if it finds them.
So...you have a wrapper?
I don't really follow what you're saying. Are
On Mon, Jun 12, 2017 at 04:31:48PM +0100, Ian Jackson wrote:
> Robie Basak writes ("Re: What to do with .git directories in source package
> uploads?"):
> > In mitigation, we have "build" and "build-source" wrappers that could
> > always do t
On Wed, May 24, 2017 at 10:56:52PM +0100, Ian Jackson wrote:
> But if there are packages where the .git directory is somehow actually
> used in the build, your scheme won't help because a build from the
> imported git tree will use your history, not the history found in the
> .dsc's .git.
I don't
Hi Peter,
On Thu, Jan 19, 2017 at 02:16:27AM +, peter green wrote:
> Some time ago I put together what I call the "autoforwardporter". The
> aim of this is to take downstream changes and apply them on top of new
> debian uploads.
Can you expand on this? We do exactly this in Ubuntu as
On Mon, Jan 09, 2017 at 05:17:08PM +, Ian Jackson wrote:
> Robie Basak writes ("Re: patches-applied historical imports (usd import)"):
> > Right now, we're accepting rich history only for Ubuntu-specific
> > commits. I don't think we have really considered yet what wou
On Mon, Jan 09, 2017 at 02:02:34PM +, Ian Jackson wrote:
> Robie Basak writes ("Re: patches-applied historical imports (usd import)"):
> > On Mon, Jan 09, 2017 at 01:45:52PM +, Ian Jackson wrote:
> > > Ideally you and I could agree on a commit structure for
Hi Sean,
Since our UOS session will start very soon, I'll reply just to the
things that I think I can address immediately for now.
On Tue, Nov 15, 2016 at 10:24:32AM -0700, Sean Whitton wrote:
> The most important part of the tutorial for realising this is putting
> "single-debian-patch" and
FTR, I answered most questions about "why not dgit?" in the thread I
just moved to vcs-pkg-discuss only[1].
For some specific questions here:
On Thu, Nov 10, 2016 at 12:31:31AM +, Ian Jackson wrote:
> dgit can work on Ubuntu too, in a readonly mode. (It would be nice to
> make `dgit push'
Cutting out the debian-devel and ubuntu-devel-discuss lists. I think
this subthread has quite a risk of fragmenting, so I'm moving it to the
one list (vcs-pkg-discuss) that seems most appropriate for this thread.
I have seen a few comments about "why not dgit?" and I realise that I
have yet to
13 matches
Mail list logo
