On Thu, Sep 11, 2014 at 10:19:56AM -0700, Junio C Hamano wrote:
> Max Kirillov <m...@max630.net> writes:
>
>> If a variable is changed in a concurrent gitk or manually it is
>> preserved unless it has changed in this instance
>
> It would have been easier to understand why this is a desirable
> change if you stated what problem you are trying to solve before
> that sentence. "If I do X, Y happens, which is bad for reason Z.
> With this change, Y no longer happens as long as I do not do W."
Something like:
"""
When gitk contains some changed parameter, and there is
existing instance of gitk where the parameter is still old,
it is reverted to that old value when the instance exits.
After the change, a parameter is stored in config only it is
has been modified in the exiting instance. Otherwise, the
value which currently is in file is preserved. This allows
editing the configuration when several instances are
running, and don't get rollback of the modification if some
other instance where the cinfiguration was not edited is
closed last.
"""
Does it looks appropriate?
(Actually, the main motivation was the 3/3 part, for views,
scalar parameters merging was just low hanging fruit by the
way)
>> This change does not affect geometry and views save; geometry does not
>> need it, and views need special merging, which treats each view
>> separately rather that fully replace the shole list.
>
> s/sh/wh/ I presume?
Sure. Thanks
>> +proc config_variable_change_cb {name name2 op} {
>> + global config_variable_changed
>> + if {$op eq "write"} {
>> + set config_variable_changed($name) 1
>> + }
>> +}
>
> Hmm, wouldn't it make more sense to save the original value where
> you set up the variable trace, and make the savestuff procedure do a
> 3-way merge? That way, when you and the other party changed a
> variable to a different value, you can give a better diagnosis to
> the user to know what is going on. If both of you changed to the
> same value, then the end result would be the same, of course.
This is going to complicate UI, something like "closing
confirmation dialog". Not nice. And, I am actually not sure
it is really needed, because "the other party" is me again,
in another gitk window, and most probably I would want the
same change.
Though storing the old value and comparing to it makes sanse
to do anyway, because trace may produce bogus events, so it
would be better to doublecheck has the value actually been
changed.
--
Max
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
