Petr Baudis wrote:

>> That is _NOT_ distro's business. If you want such things, do a clean
>> fork - w/ all implications. This creates a new/different package, out
>> of the original package's versioning line. (eg. ff vs. iceweasel).
> There are two parts to this:
> (a) It's totally unrealistic to do unless you absolutely have to (e.g.
> due to trademark issues).

Not really. I *have* my own forks of certain packages, because upstream
doesnt want my specific features (yet). Oh, and I rebase (instead of
merge) here, too.

> (b) Even if, you just push the issue around! 

Yes, I push it to those who are naturally responsible.
The term "distro" comes from distribution, not feature development.
These are two fundamentally different issues.

> 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 want to - I want (and *do*) simply rebase.
Gives me a clean history and branching graph.

>   (i) Have full and incremental history available for all changes.

I dont want all changes I ever made (if I want to, I still have the
old tags around) - I just want those changes which are needed from
upstream to my branches in a clean line.

>   (ii) Have the ability to produce a diff from current version to
> current upstream version for each logical change, for purposes of review
> or e.g. upstream submission.

git log ?
tig ?

> No matter how you push things around, you still need to reconcile (i)
> and (ii), or explain why they aren't interesting - you haven't done 
> that yet.

Well, I easily got around it for several years now. Perhaps you could
explain why I would need it now ;-P

 Enrico Weigelt, metux IT service --

 cellphone: +49 174 7066481   email:   skype: nekrad666
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme

vcs-pkg-discuss mailing list

Reply via email to