[Analytics] Do not drop .homebrew_analytics_user_uuid in HOME #145

Closed
zmwangx opened this Issue Apr 25, 2016 · 37 comments

Projects

None yet

9 participants

@zmwangx
Contributor
zmwangx commented Apr 25, 2016 edited

analytics.sh currently hard-codes HOMEBREW_ANALYTICS_USER_UUID_FILE to $HOME/.homebrew_analytics_user_uuid, but many of us don't want to have additional dotfiles cluttering our home directory.

There are several alternatives I can think of:

  1. Follow XDG Base Dir Spec. Put the file in ${XDG_DATA_HOME:-$HOME/.local/share}/homebrew, i.e.,

    HOMEBREW_ANALYTICS_USER_UUID_FILE=${XDG_DATA_HOME:-$HOME/.local/share}/homebrew/analytics_user_uuid

    (The patch won't be as simple as replacing a line; one still needs to mkdir -p -m.)

  2. Make XDG Base Dir Spec an opt-in (only loosely follow it), i.e., use XDG_DATA_HOME if it's set and non-nil:

    if [[ -n $XDG_DATA_HOME ]]; then
        HOMEBREW_ANALYTICS_USER_UUID_FILE=$XDG_DATA_HOME/analytics_user_uuid
    else
        HOMEBREW_ANALYTICS_USER_UUID_FILE=$HOME/.homebrew_analytics_user_uuid
    fi
  3. Use $HOME/Library/Application Support/Homebrew or /Library/Application Support/Homebrew, like standard OS X applications. Homebrew is not an "application" in the app bundle sense, but since we already use /Library/Caches/Homebrew it won't be too strange. Whether to use user Library or system Library is debatable; technically speaking Homebrew is system-wide by default, but it mostly targets "single-user" systems, and users may choose to install to home directory, so $HOME/Library is probably better.

  4. Of course there's also the traditional one-more-env-var approach. I'm personally not a fan of it.

  5. (Added Apr 26 11:41:41 PDT 2016, courtesy of @apjanke) Put the file somewhere inside $HOMEBREW_PREFIX to make it installation local;

  6. (Added Apr 26 11:41:41 PDT 2016) Add a config variable homebrew.analyticsuuid in $HOMEBREW_PREFIX/.git/config (modeled on homebrew.analyticsdisabled which already exists) and get rid of the UUID file entirely.

What are your opinions?

@zmwangx
Contributor
zmwangx commented Apr 25, 2016

I just noticed that analytics.sh includes analytics for Linuxbrew too. Of course 3. in the top post doesn't apply to Linuxbrew.

@apjanke
Contributor
apjanke commented Apr 26, 2016

Items 1, 2, and 3 all make sense to me. Especially 1 and 2: that way, if the user is syncing their XDG_HOME between multiple machines, they would share an identifier, and this would reduce the amount of double-counting that is done for users who are running Homebrew on multiple machines. And it would be synced without the user having to take special action to do so, as with $HOME/.homebrew_analyitics_user_uuid.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016 edited

I'm also in favor of 1 especially, but I do realize hostility towards XDG from part of the Mac (and *ix in general) community, hence 2 as a compromise to 1, and 3 as a compromise to 1 and 2. Let's see what other maintainers have to say.

@jasonkarns
Contributor

I am strongly in favor of 1. One shouldn't need to opt-in to the standard since the spec itself defines default values. Requiring users (2) to set the XDG_DATA_HOME in order to realize its benefits, if they were to set it to its spec-defined default value rather defeats the purpose of defaults.

If this were configuration data, I can understand the desire for some people to not have it in XDG directories. But since this is not something that will ever be user-edited, and should be completely transparent to the user, I see no reason why this needs to be opt-in. But since this isn't configuration data, I would also support option 3.

For other tools that are using configuration data and need to migrate from the old location (~/.tool) to XDG ($XDG_CONFIG_HOME/tool/config), I generally recommend:

if exists "~/.tool"
  use "~/.tool"
else
  use "${XDG_CONFIG_HOME:-$HOME/.config}/tool/config"

This way the legacy behavior is supported. New/fresh installs only use the XDG location. And users can manually "upgrade" to the XDG behavior by either moving the files themselves or deleting the legacy location (depending on the tool and impact of this). Of course, the tool itself can obviously handle the migration itself, too.

@DomT4
Contributor
DomT4 commented Apr 26, 2016

1 seems a reasonable enough suggestion to me. I'm reluctant to encourage more environment variables based on the feedback we've had that people loathe having to find them. I start to wonder if a Homebrew configuration file isn't the worst idea in the world, although it'd be a fair chunk of work to support.

@MikeMcQuaid
Member

if [[ -n $XDG_DATA_HOME ]]; then
HOMEBREW_ANALYTICS_USER_UUID_FILE=$XDG_DATA_HOME/analytics_user_uuid

I'm definitely up for adding this ๐Ÿ‘

@damieng
damieng commented Apr 26, 2016 edited

Would also recommend renaming this from user-uuid to installation-uuid. It's not a user, if you have two machines they are both different and in GA terms user ID is a different thing which brew doesn't use.

Additionally opt-out should clear this value so if you ever opt-in again it's treated as new install.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016 edited

@mikemcquaid There seems to be a divide here. Other folks on this thread prefer 1 (XDG_DATA_HOME or ~/.local/share, no HOME), but you seem be against 1, is that correct? I think Jason made a good case for 1:

If this were configuration data, I can understand the desire for some people to not have it in XDG directories. But since this is not something that will ever be user-edited, and should be completely transparent to the user, I see no reason why this needs to be opt-in.

Indeed, the UUID file should be transparent to the user so there's little reason to put it in HOME where users visit every day and possibly list quite often. ~/.homebrew_analytics_user_uuid just feels makeshifty.

@jasonkarns

For other tools that are using configuration data and need to migrate from the old location (~/.tool) to XDG ($XDG_CONFIG_HOME/tool/config), I generally recommend:

I don't see a migration issue here. It's been up for like two or three days, and the existing UUID file can be left there without any negative effect, except users might want to remove it manually to unclutter HOME. (Actually there's a positive effect: more users will be made aware of the analytics thing when they see it in HOME...)

@damieng

Additionally opt-out should clear this value so if you ever opt-in again it's treated as new install.

It already does.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016 edited

@DomT4

I'm reluctant to encourage more environment variables based on the feedback we've had that people loathe having to find them.

It's not only a problem of people loathing to find them; more env vars have practical consequences. All env vars count toward ARG_MAX which is 262144 at the moment, so you can only have a finite number of them, and as you add more of them to your environment you have less space for argv, which means shorter command lines, more instances spawned by xargs, and so on.

@apjanke
Contributor
apjanke commented Apr 26, 2016

Question: Do we in fact want this to be a per-installation ID, or closer to a user ID? Depending on where we install it, it could be placed somewhere under $HOME which could be shared between different computers, via a $HOME that is mounted on multiple machines, synced via Dropbox, or something similar. (Though there are some issues with that: a location shared between multiple Homebrew installations, where some but not all have analytics disabled, could cause "thrashing" of the user ID as it's repeatedly deleted and recreated, inflating user counts.)

The XDG spec sounds like it doesn't allow sharing its directories across machines.

If it's really per-installation, maybe it should be stuck under $HOMEBREW_PREFIX/Library to be truly part of each Homebrew installation, and not stored per-user or per-machine.

As a maintainer, I think we're trying to get closer to counting human users, not installations, so we don't prioritize users with multiple installations over those with a single one. For example, I run Homebrew on about a dozen distinct machines/VMs as part of testing, and share my config files between them using Dropbox and a "dotfiles" GitHub repo. Should that count as 1 or 12 "users"? I suspect this is a pretty unusual case; maybe unusual enough that it doesn't matter which way we count it. But I don't really know.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016 edited

@apjanke

The XDG spec sounds like it doesn't allow sharing its directories across machines.

While it's not written in the specs (is it?), I don't think it's a good idea to share XDG directories across machines (mounting HOME on different machines is a different story; it's totally fine, unless when you have incompatible versions of the same software in /usr of different machines, but that's out of the scope of this issue). CACHE_HOME and RUNTIME_DIR should definitely not be shared, DATA_HOME sharing is also a pretty bad idea I'd say, and CONFIG_HOME can be shared with some caveats, because there are certain software packages that write parameters (that maybe different for different machines) automatically to your CONFIG_HOME (e.g. gitk writes git/gitk which contains window size and such, but obviously you may want to have different window sizes on machines with different-sized monitors). What I do is to "sync" the config dir with git, by versioning the relevant files and ignoring the others.

a location shared between multiple Homebrew installations, where some but not all have analytics disabled, could cause "thrashing" of the user ID as it's repeatedly deleted and recreated, inflating user counts.

That's an interesting point, but I don't think it should affect $XDG_DATA_HOME/~/.local/share. While it's theoretically possible to mount the same data share on different machines, as I said above it will work very badly in practice (even config dir sharing is problematic, let alone data dir). I can hardly picture anyone sharing it, let alone Mac users (I assume no one will blindly sync ~/Library/Application Support).

If it's really per-installation, maybe it should be stuck under $HOMEBREW_PREFIX/Library to be truly part of each Homebrew installation, and not stored per-user or per-machine.

That's a reasonable solution too. Will add to the top post.

As a maintainer, I think we're trying to get closer to counting human users, not installations

That's a respectable goal, but honestly speaking, I can't picture many people syncing the UUID file via Dropbox wherever it is written to (the number is probably negligible compared to the total number of users/installations).

@zmwangx
Contributor
zmwangx commented Apr 26, 2016

Now that I think about it, since we already have homebrew.analyticsdisabled in $HOMEBREW_PREFIX/.git/config, can we also add homebrew.analyticsuuid and get rid of a separate UUID file entirely?

@apjanke
Contributor
apjanke commented Apr 26, 2016

While it's not written in the specs (is it?)...

The XDG Base Dir Spec you linked to says "The directory MUST be on a local file system and not shared with any other system." I can't quite tell if it's talking about all the directories it defines (and is worded a little oddly), or just $XDG_RUNTIME_DIR.

Rereading it again, I think it's talking only about $XDG_RUNTIME_DIR.

What I do is to "sync" the config dir with git, by versioning the relevant files and ignoring the others.

That at least sounds like something we could support, and if this is going to be a user ID and not an installation ID, it could go in there.

but I don't think it should affect $XDG_DATA_HOME/~/.local/share ...
I can hardly picture anyone sharing it, let alone Mac users (I assume no one will blindly sync ~/Library/Application Support).

Both these are probably true.

That's a respectable goal, but honestly speaking, I can't picture many people syncing the UUID file via Dropbox wherever it is written to (the number is probably negligible compared to the total number of users/installations).

The number of people adding it specifically? Probably zero. But if we put it in the user's XDG config dir, and they're already syncing that between machines, then they get syncing of the UUID file for "free", basically. But... we haven't done stuff with XDG before, and now we're getting in to respecting it, worrying about whether it's synced, and possibly auto-creating part of its hierarchy. Hmm.

We don't have a user survey so we don't know how many of our users are running multiple brew installs with shared/synced home/config dirs. I'd guess the proportion is very small. So probably what we should worry about is just avoiding inflating their influence through pathological behavior like UUID thrashing, and not worry about whether we count their multiple installations as separate users.

This and your comments are making me think an installation ID would be more appropriate and conservative than any attempt to share a per-user ID across instalaltions.

Now that I think about it, since we already have homebrew.analyticsdisabled in $HOMEBREW_PREFIX/.git/config, can we also add homebrew.analyticsuuid and get rid of a separate UUID file entirely?

This is sounding like a good idea. And then all of your Homebrew analytics related settings are in the same place and can be viewed together.

It would over-weight the activity of users who have multiple Homebrew installations per machine, but given how unusual that is (it's barely supported), that is probably negligible.

@apjanke
Contributor
apjanke commented Apr 26, 2016

Would also recommend renaming this from user-uuid to installation-uuid. It's not a user, if you have two machines they are both different and in GA terms user ID is a different thing which brew doesn't use.

I think this may be right. Or even if we don't rename the file and variables, we should understand this to really be an installation ID and guide the implementation that way. It's feasible for us to code things so that we have one ID per Homebrew installation. It's probably unrealistic to think that we'll be able to set things up so that it corresponds closer to human users: most users with multiple machines will probably not share these config/data files between their machines, won't (and shouldn't) go out of their way to do so, and trying to do so opens us up to more edge case behavior. So it'll behave closer to an installation ID anyway. We may as well recognize what we're actually measuring and stick with that.

Users who want to sync analytics behavior across machines can still set HOMEBREW_NO_ANALYTICS in their shell rc files, which I think they're more likely to have set up to share between machines anyway.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016 edited

The XDG Base Dir Spec you linked to says "The directory MUST be on a local file system and not shared with any other system."

Even if that applies to all XDG directories, mounting them locally on different machines or syncing their contents among local filesystems of different machines doesn't violate the rule. Although as I said it would make a mess in practice.

What I do is to "sync" the config dir with git, by versioning the relevant files and ignoring the others.

That at least sounds like something we could support, and if this is going to be a user ID and not an installation ID, it could go in there.

To be clear, I won't commit a semi-randomly-generated UUID file into git โ€” it is among the files ignored, and I'd be surprised if others will (unless they blindly commits everything in the directory), so still it won't be shared.

It would over-weight the activity of users who have multiple Homebrew installations per machine, but given how unusual that is (it's barely supported), that is probably negligible.

Those are probably Homebrew fanatics and they should be taken more seriously ๐Ÿ˜‰ One vote for each installation ๐Ÿ˜‰

@apjanke
Contributor
apjanke commented Apr 26, 2016

To be clear, I won't commit a semi-randomly-generated UUID file into git โ€” it is among the files ignored, and I'd be surprised if others will (unless they blindly commits everything in the directory), so still it won't be shared.

Good point. If I encountered this and I hadn't been part of this discussion, I would also assume it was supposed to be machine-local and throw it in my .gitignore.

I think we can assume that people syncing a user ID file across multiple machines will be very rare, and we just need to avoid having that break things outright.

@chdiza
Contributor
chdiza commented Apr 26, 2016

If the goal is to avoid polluting the user's $HOME, it certainly won't help if ~/.local gets created. I'd wager most users have no dir ~/.local in the first place.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016

I think we can assume that people syncing a user ID file across multiple machines will be very rare, and we just need to avoid having that break things outright.

Exactly. I find somewhere inside $HOMEBREW_PREFIX (probably .git/config) very appealing now.

I'd wager most users have no dir ~/.local in the first place.

I wouldn't be so sure about that. Quite a few tools follow XDG or at least offer it as an option these days. I currently have 33 subdirectories in ~/.local/share (although I'll be honest and admit that most of those are not the default).

Even if people don't have ~/.local, I bet a considerable percentage of people have the other two XDG directories, ~/.config and ~/.cache. And ~/.local/share is a logical and harmless step from there.

@chdiza
Contributor
chdiza commented Apr 26, 2016

I bet a considerable percentage of people have the other two XDG directories, ~/.config and ~/.cache.

Really? I'd bet not.

Just put it in ~/Library/Application Support, which is where this kind of thing is supposed to go.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016

Really? I'd bet not.

git uses ~/.config and npm uses ~/.cache, just to give one example for each.

Just put it in ~/Library/Application Support, which is where this kind of thing is supposed to go.

I already suggested this so obviously I have no objection, but Homebrew hardly qualifies as an "application".

@chdiza
Contributor
chdiza commented Apr 26, 2016 edited

Dumping yet another unasked-for dotfile on my machine would be sufficient reason, for me, to just set HOMEBREW_NO_ANALYTICS. It's already bad enough that there are markdown files and dotfiles littering /usr/local. I make HOMEBREW_REPOSITORY live outside /usr/local (which is still my Cellar) to avoid this.

git uses ~/.config and npm uses ~/.cache, just to give one example for each

Only if you want it to, apparently. I use git and I have neither of those, and I didn't have to flip some special switch to make it like this.

EDIT: Didn't spot the npm part in the quote.

@chdiza
Contributor
chdiza commented Apr 26, 2016

It would be so easy to make such a file live in a place where everyone can escape pollution, not just XDG fans or some other subset of people who happen to already have a certain dot-folder sitting in $HOME.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016 edited

Only if you want it to

Okay, I just checked and you can use ~/.gitconfig or $GIT_DIR/config too. Not sure you gain anything out of a standalone file instead of a centralized directory. But you can't get away with that if you ever need a global gitignore file, which has to be ~/.config/git/ignore or $GIT_DIR/info/exclude (Also, if you don't have XDG_CONFIG_HOME and ever run gitk, it will drop another unasked-for ~/.gitk in your home.)

As for npm, I don't think it's an opt-in.

It would be so easy to make such a file live in a place where everyone can escape pollution

You apparently ignored Linuxbrew.

EDIT: I thought GIT_DIR could be separately set, but apparently it's just a placeholder in the man pages.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016

But again, I (and Andrew it seems) prefer an installation-local solution now, so all this debate about HOME, XDG_DATA_HOME or ~/Library/Application Support wouldn't matter if that path is taken.

@apjanke
Contributor
apjanke commented Apr 26, 2016 edited

But you can't get away with that if you ever need a global gitignore file, which has to be ~/.config/git/ignore or $GIT_DIR/info/exclude

You can reconfigure it to use any file with git config --global core.excludesfile, and I think that's common since that's what GitHub's doco suggests you do.

But yeah, this might all be moot. Let's set aside the XDG stuff for the moment before people reach for the flamethrowers, and give some other folks a chance to weigh in, yes? This isn't urgent: we have an easy migration path to put the UUID at another location, and can automatically clean up the ~/.homebrew_analytics_uuid file as part of that migration.

@zmwangx
Contributor
zmwangx commented Apr 26, 2016

You can reconfigure it to use any file with git config --global core.excludesfile

Yeah forgot that (I only read the synopsis of man 5 gitignore).

Let's set aside the XDG stuff for the moment before people reach for the flamethrowers, and give some other folks a chance to weigh in, yes?

Yeah, sorry about my attitude.

@dunn
Member
dunn commented Apr 26, 2016

Maybe worth noting that ~/Library/Application Support will only work on OSX, so we'd have to choose an alternative location anyway if/when we begin to support other platforms.

@apjanke
Contributor
apjanke commented Apr 26, 2016

Maybe worth noting that ~/Library/Application Support will only work on OSX, so we'd have to choose an alternative location anyway if/when we begin to support other platforms.

Good point. The analytics code already has some support for Linux/non-OSX, so this is probably relevant now.

@MikeMcQuaid
Member

@zmwangx Things have calmed down so I'd be happy to have an pull request for the XDG stuff here ๐Ÿ‘

@zmwangx
Contributor
zmwangx commented Apr 27, 2016

@mikemcquaid There has been a lot of discussions so I guess it's hard to follow, but I currently prefer adding a config variable homebrew.analyticsuuid in $HOMEBREW_PREFIX/.git/config and get rid of the UUID file completely (point 6 in the top post, added later). What do you think about this?

Once we decide on what's the best approach, a PR should be pretty simple.

@MikeMcQuaid
Member

@zmwangx I'm maybe ๐Ÿ‘ on that. @xu-cheng @apjanke: thoughts?

@apjanke
Contributor
apjanke commented Apr 27, 2016

I agree with @zmwangx: I think sticking it in the git config with the other analytics settings is the best approach, both in terms of bringing the settings together in one place for viewing/editing, and for clarifying the de facto one-ID-per-installation behavior we have. It also avoids a couple potential edge cases with ID "thrashing" if a user has multiple Homebrew installations/machines and they don't all have the same analytics settings.

@UniqMartin
Contributor

Coming from the multiple Homebrew installations per machine camp, I think we should be making this a per-installation UUID instead of a per-user UUID. (Seems like this is already the agreement thus far.) For the vast majority of users that only run a single installation, this won't make any difference, so that's also not going to significantly impact the analytics we gather.

I'm not sure if we still support installation from a tarball, but if we do, there's the problem that .git might not exist in the Homebrew prefix. Thus sticking (more) things into .git/config that aren't really specific to a Git repository might be not the best solution. (This also includes homebrew.analyticsdisabled.)

My suggestion would be to start using etc/homebrew/ in the Homebrew prefix and put the UUID file in that directory. In a long-term effort we could also start using this location for other Homebrew-specific configuration data, that is currently exclusively contained in HOMEBREW_* environment variables. (@zmwangx has mentioned why it might be desirable to avoid further environment variable inflation. It would also make it easier to configure multiple Homebrew installations on the same machine differently.)

@MikeMcQuaid
Member

๐Ÿ‘ to .git/config from me.

@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 27, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to .homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
3b96699
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 27, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
72ebc12
@zmwangx
Contributor
zmwangx commented Apr 27, 2016

Submitted #162.

@zmwangx
Contributor
zmwangx commented Apr 27, 2016

@UniqMartin

I'm not sure if we still support installation from a tarball, but if we do, there's the problem that .git might not exist in the Homebrew prefix.

I don't think that's much of an issue. Currently one necessary condition for analytics is homebrew.analyticsmessage in the git config file being set to true, which won't happen until one has run brew update at least once, which should initialize the git repository, so the worst case scenario is a bunch of error messages from git-config. We can append 2>/dev/null to git-config calls if that's preferred.

My suggestion would be to start using etc/homebrew/ in the Homebrew prefix and put the UUID file in that directory.

This might be a good idea. Since git-config homebrew.analyticsmessage and homebrew.analyticsdisabled are already shipped on the master branch, I'd prefer to stick to git-config at this point. A separate config file/directory could be another discussion (and definitely an interesting one).

@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 27, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
a045501
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 27, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
71a3c27
@UniqMartin
Contributor

Thanks everyone for the discussion! Closing in favor of #162.

@UniqMartin UniqMartin closed this Apr 28, 2016
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 29, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
c2ff424
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 29, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
51b7458
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 29, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
740d9a8
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 30, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
5dfb837
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 30, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
fc58dc2
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 30, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
baa44b2
@zmwangx zmwangx added a commit to zmwangx/brew that referenced this issue Apr 30, 2016
@zmwangx zmwangx Analytics: Relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.
ff3e425
@UniqMartin UniqMartin added a commit that referenced this issue Apr 30, 2016
@zmwangx @UniqMartin zmwangx + UniqMartin analytics: relocate UUID to homebrew.analyticsuuid in .git/config
This way analytics related settings and parameters (currently
analyticsdisabled, analyticsmessage and analyticsuuid) are all kept in
the same place.

Note that in this commit we offer a path of migration: if
~/.homebrew_analytics_user_uuid already exists, read the UUID from it,
write to homebrew.analyticsuuid, and remove it.

See more detailed discussions in #145.

Closes #162.

Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
c63400d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment