[Toybox] [PATCH] setenforce takes exactly one argument

[Isaac Dunham]

On Thu, Apr 09, 2015 at 07:45:46AM -0700, enh wrote:
> On Wed, Apr 8, 2015 at 11:45 PM, Rob Landley <rob at landley.net> wrote:
> > On Tue, Apr 7, 2015 at 3:13 PM, enh <enh at google.com> wrote:
> >> submitted to AOSP as
> >> https://android-review.googlesource.com/#/c/145667/ (SHA
> >> ec13b088cdaf133e4fa5e7a94ed90eb0af59c126).
> >
> > Do you have a tree I can pull from with just changes to go upstream?
> >
> > I can't pull from
> > https://android.googlesource.com/platform/external/toybox because it's
> > got checked in generated files and top level .config.

What I'd do in git is ~ this:

# name the remote
git remote add android  \
    https://android.googlesource.com/platform/external/toybox
# don't pull: fetch will get the commits without modifying repository state
git fetch android
# checkout the Android master
git checkout android/master
# and create a branch from it
git checkout -b android-master

# and make a local branch that has just android commits:
git checkout -b android-upstream
git rebase master --interactive

(The main reason I ended up going for git instead of hg was that
branching didn't seem to work well in hg. I don't remember the
specifics at the moment, though.)

> no. i've been keeping "changes to go upstream" separate from
> "configuration changes", so you can at least cherrypick, but i hadn't
> thought of how you'd work out which changes to cherrypick and which
> not.
> 
> i don't think i imagined you merging because i assumed you'd want to
> review every change anyway. i don't _plan_ on making changes to the
> non-Android parts of the tree without getting them upstream first, but
> if the release team's breathing down my neck and we were supposed to
> have shipped two weeks ago, i might have to. i'd worry too about what
> happens if i "git rm" the existing uptime.c and add an Android one to
> toys/android/. again, i'm not planning on it (read: "would like to
> avoid that kind of mess at all costs"), but what if i go under a bus,
> or someone else thinks it's a good idea while i'm on vacation?
> 
> is there some kind of "git merge --interactive" that makes it easy to
> go through all the patches and skip the useless ones? actually, if you
> skip my modification of the .gitignore file, will merge drop future
> changes to the generated files on the floor automatically? or is that
> a conflict?

Deleted files are a conflict, though it's easier to resolve them than
other conflicts.
Pretty much the only way to do that apart from a scripted cherry-pick 
is creating a new branch out of the one to merge and doing 
"git rebase --interactive master" (or rebasing it from the common 
ancestor, if you want a more exact equivalent), then merge that.

> > (I'd be ok with
> > having android.mk be in scripts or in toys/android but would prefer
> > not to have it at the top level. Presumably your local tree could add
> > a symlink, but I dunno if that would be useful to you _without_ the
> > checked in .config and generated files... :)
> 
> losing the generated files is just a matter of work. i could have a
> much more complicated Android.mk that has all your scripts generate
> their output into the build system's intermediates directory, then
> adds that to the include path for building the source. that would be
> better for me too, but i haven't had time to look into how hard that
> would be. does your current setup support writing the generated files
> to an arbitrary directory?
> 
> i don't see a way around the Android.mk or the .config file though.
> the build system will stop at a directory without an Android.mk, so we
> can't easily hide it. and the need for the .config file is obvious
> (unless i use "git rm" as my configuration tool, but i assume that
> would be far more painful on your end!).

I know the Linux kernel lets you use multiple defconfigs; I wonder if
it would work to save .config as scripts/android.config and then load
that.


HTH,
Isaac Dunham

 1428596294.0