To answer your trivially: git diff -r <cset1> mdocml-1.12.1 The precise value of <cset1> will be the changeset where I push the combined change.
(mdocml-1.12.1 is a git branch, which is just like any other change set except that it has no direct descendants, except perhaps further integrations of mdocml-1.12.2, etc.) - Garrett On Thu, Jul 17, 2014 at 12:20 PM, Hans Rosenfeld via illumos-discuss < [email protected]> wrote: > On Thu, Jul 17, 2014 at 11:48:01AM -0700, Garrett D'Amore via > illumos-discuss wrote: > > git submodules are, IMO, a terrible idea. STOP trying to manage this > like > > you would oi-userland or something like that. > > I don't know what oi-userland does, and I don't think it is relevant. > This idea really is based on how NetBSD does it, and it seems to work > well for them. > > > The number of external things brought into tree should be small. mandoc > > made sense here. OpenSSL makes sense here. SunSSH is a different > matter, > > but yeah. There aren't many other such bits. > > > > The one-commit-per-bug rule is actually very important, because you never > > have to ask the question "what commit was this feature introduced in". > > Relaxing that rule can lead to terrible, terrible breakage. I have been > > down that particular road at Nexenta, and it took a lot of fighting in my > > early days of employment there to fix it. > > This has nothing to do with relaxing that rule, just with keeping > information in the gate that is helpful for updating external stuff. If > done properly, there is no confusion and no breakage. > > (You could even have one bug for the import, and another one for > adaptions and hooking it into to build, not violating the rule at all. > It doesn't really have anything to do with whether it's one commit > per bug or not.) > > When updating code in the gate that is externally maintained, you always > want to know what local changes were made along with the last import, > but often you don't know because nobody cared to keep that information > available. We can of course continue to it the way we always did, and > make life harder for us in the long run. > > (Externally maintained code also includes drivers, btw. -- either > drivers that were once ported from other systems, or those which vendors > drop on us in irregular intervals, like the recent Emulex wads I'm > working on. We have the same problems there.) > > > Having separate branches for tracking initial imports of 3rd party > software > > is not a big overhead; its easy to use those to answer those questions > you > > want to ask (what changed), since you can diff across branches. > > Can you elaborate a bit on how exactly that is supposed to look like? > > Assuming you integrate mandoc now, and in a year from now I want to > update it, how would I know which changes were made for integration? > > > Hans > > > > -- > %SYSTEM-F-ANARCHISM, The operating system has been overthrown > > > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: > https://www.listbox.com/member/archive/rss/182180/22003744-9012f59c > Modify Your Subscription: > https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
