Well you really wouldn't want to have "overlay" code for that kind of thing anyway, because your overlay would end up having a copy of whatever the code was at the point you made it, and wouldn't track later changes that happen to it. That's really no different than forking, but just in a less rigorous and safe way.
Unfortunately I am not a git expert to help out with this... I am pretty sure the build system doesn't have a way to automatically apply a patch, though. On Sat, Aug 21, 2010 at 4:33 AM, Al Sutton <a...@funkyandroid.com> wrote: > [copied to list] > > I'm a fan of the KISS principal, so if I can reduce the number of > repositories involved then I tend to head that way. > > One of the patches we have to make is a single line change to a two files > (we could do it in one, but it's for frameworks/policies/base so we do it in > both the mid and phone profiles). Unfortunately, we have to fork and > maintain a whole repository for the project just because of the one line > change, and that, to me, seems like a lot of overhead (you can see the patch > at > http://www.gitorious.org/openaos-testing/frameworks_policies_base/commit/51dcc06ce534fee03dd356e788535ba17c7f39e5 > ) > > If that's the way it needs to be done, then that's the way it needs to be > done, but it would make things simpler from an admin and maintenance point > of view if everyone on the OpenAOS project could use the "standard" repo and > have the one line patch applied. > > > Al. > -- > > * Looking for Android Apps? - Try http://andappstore.com/ * > > ====== > Funky Android Limited is registered in England & Wales with the company > number 6741909. > > The views expressed in this email are those of the author and not > necessarily those of Funky Android Limited, it's associates, or > it's subsidiaries. > > On 21 Aug 2010, at 11:11, Magnus Bäck wrote: > > On Saturday, August 21, 2010 at 09:51 CEST, > Al Sutton <a...@funkyandroid.com> wrote: > > We've ended up with a forked repository at the moment. The main > > problem with post checkout patching (or file copying) is that repo > > will then refuse to update the files due to detecting local changes. > > > Easily fixed with git stash. > > The ideal system would allow us to continue to use repo to keep the > > checked out tree up to date and apply the required changes during a > > build so we can keep all our changes in the vendor/xxx tree. Is that > > possible with the current build system? > > > Don't fight the system. You are de facto branching the git in question, > so use the facilities for branching that Repo and Git provide. If it's > just your personal changes you can simply commit them on a topic branch > and Repo will automatically rebase it for you each time you sync. If > it's a shared branch you probably want to set up a manifest branch where > you change the `revision' attribut to point to the shared branch. You > could also use a local manifest to accomplish the same thing. It's hard > to be more specific without details about your environment. > > -- > Magnus Bäck Opinions are my own and do not necessarily > SW Configuration Manager represent the ones of my employer, etc. > Sony Ericsson > > -- > unsubscribe: android-porting+unsubscr...@googlegroups.com > website: http://groups.google.com/group/android-porting > > > -- > unsubscribe: > android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com> > website: http://groups.google.com/group/android-porting > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
