On 12/21/2016 08:07 PM, Marc Branchaud wrote: > On 2016-12-20 07:05 PM, Michael Haggerty wrote: >> On 12/20/2016 04:01 PM, Marc Branchaud wrote: >>> [...] >>> Please don't change the remotebgcolor default. >>> >>> Also, perhaps the default remoterefbgcolor should be >>> set remoterefbgcolor $headbgcolor >>> ? >>> >>> I say this because when I applied the series, without the last patch, I >>> was miffed that the remote/ref colour had changed. >> >> This is a one-time inconvenience that gitk developers will experience. I >> doubt that users jump backwards and forwards in gitk versions very often. > > In what way do you mean it's restricted to gitk developers?
Maybe I misunderstood your objection. While developing this, I realized that the very first time your run gitk (i.e., when you don't already have a configuration file), it writes the then-current default colors into your configuration file. If you later switch gitk versions to a version with different default colors, the colors from the first-run version are preserved (unless the names of the variables used to hold the colors are changed). So if you would run the tip version of my branch first, then the parent of that version, you would continue to see the colors as modified by the final commit. If you then switch to the master version, the remote branch names go back to green (because it goes back to using `headbgcolor` again), but the remote prefix stays light brown. I thought you were unhappy about some form of this unexpected persistence problem. But this problem will mostly be experienced by gitk developers who jump back and forth between versions. A normal user probably mostly moves forward through version numbers, and only occasionally. Such a user, jumping from master to the tip of my branch (assuming they haven't customized anything), would see * local branches stay lime * remote branch prefixes stay pale orange (they don't change to light brown because the pale orange color from master is stored in their configuration file) * remote branch names change from lime to brown (because the `remoterefbgcolor` configuration setting didn't exist before) > Patch 12 introduces remoterefbgcolor, with a specific default value. > Prior to that, the "ref part" of remote refs was rendered with > headbgcolor. Users who changed their headbgcolor are used to seeing the > "ref part" of remote refs in the same color as their local heads. > Applying patch 12 changes the "ref part" color of remote refs, for such > users. > > All I'm saying is that make the remoterefbgcolor default be $headbgcolor > avoids this. For somebody who thinks that most people will want local and remote-tracking branch names to be rendered in the same color, your suggestion would be an improvement. But for somebody like me who thinks it is a good idea to render remote-tracking branch names in a different color than local branch names, this is a feature, not a bug. Even a user who explicitly configured `headbgcolor` to, say, purple, wasn't necessarily expressing a wish to have remote-tracking branch names rendered in purple. Until now they had no choice to set these colors separately! So even for somebody who configured this setting before, I think that having the remote-tracking branch names change color when the user upgrades to this version is a good thing, because it lets the user know that these two things can now be colored independently. If they don't like the new default brown color, such a user knows where to change it (even to make it agree with `headbgcolor` if they want that). But I understand that this is a matter of personal preference. I have but one "vote" :-) Michael
