On Sun, Mar 28, 2010 at 03:56:54PM -0700, Manoj Srivastava wrote:
> On Sun, Mar 28 2010, Petr Baudis wrote:
>
> > My original motivation for TopGit development was that I actually was
> > the _only_ developer, but I needed to maintain and develop in multiple
> >
On Sun, Mar 28, 2010 at 09:40:45AM -0700, Manoj Srivastava wrote:
> On Sun, Mar 28 2010, Enrico Weigelt wrote:
> > Usually, you have only one person or very few ones working very
> > closely together per package. So that shouldnt hurt so much that
> > it's worth all the complexity.
>
> Fal
On Sun, Mar 28, 2010 at 08:21:48AM +0200, Enrico Weigelt wrote:
> > You would want to still use something like the topgit model in your
> > "forked upstream", since again, you will probably want to have the
> > two desirable properties we seek to preserve - to reiterate them,
>
> Actually, I dont
On Sat, Mar 27, 2010 at 03:22:22PM +0100, Enrico Weigelt wrote:
> > I have heard people say that distributions should not carry
> > feature branches or long term fixes, but push it upstream; but in a
> > non ideal world some upstreams do not respond as quickly as one wants,
> > and seco
On Wed, Mar 24, 2010 at 04:36:14PM +0100, Enrico Weigelt wrote:
> Petr Baudis wrote:
>
> > But what if you need to change one of the already committed patches?
>
> Simply add a new commit ?
> Remember: we're not thinking in "patches" here (forget that term
>
On Wed, Mar 24, 2010 at 01:42:18AM +0100, Enrico Weigelt wrote:
> Once a new upstream is out, somebody simply forks a new branch from
> the last one, rebases it to the new upstream and publishes it when done.
> We actually dont rebase _existing_ (already published) branches, but
> add new ones whic
On Mon, Mar 22, 2010 at 08:59:40AM +0100, Thomas Koch wrote:
> In all three cases you're free to either keep or throw away the old patchset.
Yes, but to the same degree e.g. with StGIT I'm free to keep the head of
the old patch series. That does not mean the operation *preserves* the
history, only
Hi!
On Sun, Mar 21, 2010 at 10:18:14PM +0100, Enrico Weigelt wrote:
> > Although the above is quite a harsh judgement, I'd like to note, that tg
> > has
> > had its merrit to promote one right idea: Patches should be managed in the
> > form of branches by the means of the underlying VCS and n
On Sat, Mar 20, 2010 at 07:53:34PM +0100, Thomas Koch wrote:
> Petr Baudis:
> - tg recreate
> Creates a new patchset with root by creating new patch branches
> for each patch branch in
> This command is useful if you need to keep the old patchset to maintain
> a
Hi!
On Sat, Mar 20, 2010 at 06:02:51PM +0100, Thomas Koch wrote:
> I'd like to argue, that topgit (tg) fails to fullfill it's task and propose a
> different approach to the problem of patch management on top of git.
>
> IMHO tg fails due to the following reasons:
>
> - it pollutes the patch b
On Sat, May 09, 2009 at 11:13:17AM +0200, martin f krafft wrote:
> also sprach Stefano Zacchiroli [2009.05.07.1902 +0200]:
> > When I, as a newcomer of a given repo, do "git tag" I know I'm
> > looking at a lot of "not current" information. On the contrary,
> > when I do "git branch" I start tryin
Hi,
On Thu, Dec 18, 2008 at 09:26:17PM +0100, martin f krafft wrote:
> Do you know of any instances of cross-distro collaboration where the
> VCS is shared between packagers?
>
> Have any of you reached out to other distros' packagers? Would you
> share your experiences?
you might want to st
On Fri, Nov 14, 2008 at 07:47:06AM +0100, martin f krafft wrote:
> In the long run, I really want to supersede "Closes:" anyway.
> Ideally, the bug gets marked 'fix-committed' when a signed-off
> commit closing the bug hits the repo (or a tag like closes-123456
> appears), and an upload would ident
On Thu, Nov 13, 2008 at 01:28:17PM +0100, Manuel Prinz wrote:
> Am Donnerstag, den 13.11.2008, 12:54 +0100 schrieb Adeodato Simó:
> > Though I agree with your reasoning here, I find (2) a tad too verbose
> > (mostly because of the colon appearing twice, which requires two passes
> > from your brain
On Tue, Aug 12, 2008 at 08:10:37PM -0300, martin f krafft wrote:
> also sprach Petr Baudis <[EMAIL PROTECTED]> [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 wh
On Tue, Aug 12, 2008 at 07:41:55PM -0300, martin f krafft wrote:
> also sprach Santi Béjar <[EMAIL PROTECTED]> [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 defini
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 tw
Hi,
On Sat, Aug 09, 2008 at 03:08:21AM +0200, Petr Baudis wrote:
> On Thu, Aug 07, 2008 at 02:56:24PM -0300, martin f krafft wrote:
> > Assuming a number of interdependent topic branches, does TopGit
> > provide a way for me to linearise/flatten/serialise these branches
> &g
Hi!
On Thu, Aug 07, 2008 at 02:56:24PM -0300, martin f krafft wrote:
> Assuming a number of interdependent topic branches, does TopGit
> provide a way for me to linearise/flatten/serialise these branches
> in a one-patch-per-branch fashion, so that I could turn any TopGit
> repository into a quilt
19 matches
Mail list logo
