lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Jan 2012 18:28:32 -0800
From:	Junio C Hamano <gitster@...ox.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...com>, linux-kernel@...r.kernel.org,
	Git Mailing List <git@...r.kernel.org>
Subject: Re: Regulator updates for 3.3

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> Addid junio and git to the cc just to bring up this issue of bad UI
> once again. I realize it could break old scripts to start up an editor
> window, but still..

It is a non-starter to unconditionally start an editor. We would need a
good way for users to conveniently say "I am doing this unusual merge that
needs to be justified, and I want an editor to write my justification".

Obviously, "git merge -e regulator/for-linus" would work and is just three
keystrokes, which can be said "convenient enough" once the user gets used
to, but I think this is still inadequate as a solution, as the real
problem is it is _too_ easy to forget to give the option.  Until the user
becomes _aware_ of the issues, it will not even occur to the user that
s/he _has_ to justify a merge (or not create a merge at all) in certain
circumstances and directions.  After all, you have been repeating the "do
not make meaningless merges" for the past five years on the list. UI tweak
alone will not fix that.

If we are to rely on user's conscious action, I think it may be something
like a set of configurations that say things like:

 - This branch is for advancing a specific topic, and not for merging
   random development that happen elsewhere;

 - This branch is for merging works by people downstream from me;

 - This remote tracking branch (and by extension that branch at that
   remote that uses this as its remote tracking branch) is my upstream and
   I should not be merging back from it; and

 - This remote tracking branch is my downstream, and I should freely merge
   it when I heard it is ready.

and depending on the combination of what is being merged into what, toggle
the --edit option by default for "git merge" when neither "--edit" nor
"--no-edit" is given, just like "git merge" defaults to "--edit" when
merging an annotated tag.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ