From: "Enrico Weigelt" Sent: Saturday, November
10, 2012 10:29 AM
This is often the key point that requires the 'new mindset'. Most
folk
use/used the directory heirarchy (subtle distinction with the .git
'repo' directory heirarchy to be noted) as a way of separating
ownership
between groups. The
> This is often the key point that requires the 'new mindset'. Most
> folk
> use/used the directory heirarchy (subtle distinction with the .git
> 'repo' directory heirarchy to be noted) as a way of separating
> ownership
> between groups. They find it very hard to undo the old mindset and
> use
>
From: "Enrico Weigelt" Sent: Saturday, November
10, 2012 7:13 AM
I've picked out Enrico's key points.
Maybe I should try to explain the problem in terms of repository
hierarchy. Let's assume, there is this hierarchy of repositories:
Let's talk about branches instead - repos are just containe
> Let me ask a different question: What is wrong with cherry-picking
> downstream changes to your upstream branch? Without rebasing it to
> downstream.
Naah, dont rebase the upstream ontop of downstream - this doenst make
any sense (yeah, my devs sometimes doing exatly this wong ;-o).
Instead, a
> I am somewhat unsure whether it would work this way. After all, there
> seems to
> be an unbreakable rule with git: never rebase published branches.
I dont see a big problem if you just tell the downstreams to rebase
instead of merge downwards.
That's eg. my default approach for handling thing
Am 06.11.2012 22:07, schrieb Josef Wolf:
On Tue, Nov 06, 2012 at 08:21:25PM +, Pyeron, Jason J CTR (US) wrote:
Maybe I lost sight of your problem. Can you give a specific example of where
"it" does not work?
I guess it's _me_ who's lost. I can't figure how this is supposed to
work. Maybe
On Tue, Nov 06, 2012 at 08:21:25PM +, Pyeron, Jason J CTR (US) wrote:
> Maybe I lost sight of your problem. Can you give a specific example of where
> "it" does not work?
I guess it's _me_ who's lost. I can't figure how this is supposed to
work. Maybe you have an example?
--
To unsubscribe fr
; To: git@vger.kernel.org
> Subject: Re: Workflow for templates?
>
> No suggestions on this one?
>
> On Wed, Oct 31, 2012 at 11:44:04AM +0100, Josef Wolf wrote:
> > I am somewhat unsure whether it would work this way. After all, there
> seems to
> > be an unbreakable rule
No suggestions on this one?
On Wed, Oct 31, 2012 at 11:44:04AM +0100, Josef Wolf wrote:
> I am somewhat unsure whether it would work this way. After all, there seems to
> be an unbreakable rule with git: never rebase published branches.
>
> Thus, once I have published my work to other people who
On Sat, Oct 27, 2012 at 08:45:45PM +0200, Enrico Weigelt wrote:
> I'd suggest a 3 level branch hierachy (IOW: the lower level
> is rebased ontop of the next higher level):
>
> * #0: upstream branch
> * #1: generic local maintenance branch
> * #2: per-instance cutomization branches
>
> Normal addi
Hi,
I'd suggest a 3 level branch hierachy (IOW: the lower level
is rebased ontop of the next higher level):
* #0: upstream branch
* #1: generic local maintenance branch
* #2: per-instance cutomization branches
Normal additions go to the lowest level #2. When you've got
some generic commit, you
Hello everybody,
I am looking for a setup where teplates can be handled easily.
For a better explanation of what I'm trying to achieve, I use the apache
httpd project as an example.
Apache httpd provides an extensively commented httpd.conf template, which
users can use as a starting point for th
12 matches
Mail list logo
