Thread (2 messages) 2 messages, 2 authors, 2017-11-27

Re: git status always modifies index?

From: Johannes Schindelin <hidden>
Date: 2017-11-27 20:50:56

Hi Junio,

On Mon, 27 Nov 2017, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
Again, maybe the bit above explains my viewpoint a bit more. I'm
certainly sympathetic to the pain of upstreaming.

I do disagree with the "no good reason" for this particular patch.

Certainly you should feel free to present your hunches. I'd expect you
to as part of the review (I'm pretty sure I even solicited your opinion
when I sent the original patch). But I also think it's important for
patches sent upstream to get thorough review (both for code and design).
The patches having been in another fork (and thus presumably being
stable) is one point in their favor, but I don't think it should trumps
all other discussion.
I haven't been following this subthread closely, but I agree.  I
think your turning a narrow option that was only about status into
something that can be extended as a more general option resulted in
a better design overall.
The --no-optional-locks feature is

- hard to find,

- in the current scenarios less desirable than a very concrete "do not
  write index.lock files in `git status`",

- too simple to introduce to merit introducing it *before* a need for it
  arises that is larger than `git status --no-lock-index`, and you would
  still have to keep the latter because it is a very concrete and real use
  case that is unlikely to want to avoid other .lock files too.

So while you two are happily on agreeing with one another, the reality is
that this supposedly better design is nothing else than premature
optimization.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help