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."
> 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?
>
> Signed-off-by: Max Kirillov <m...@max630.net>
> ---
> gitk | 41 +++++++++++++++++++++++++++++++++--------
> 1 file changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/gitk b/gitk
> index 6069afe..6e22024 100755
> --- a/gitk
> +++ b/gitk
> @@ -2804,12 +2804,25 @@ proc doprogupdate {} {
> }
> }
>
> +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.
--
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
