Re: ms/customizable-ident-expansion

Ævar Arnfjörð Bjarmason [off-list ref] writes:

On Fri, Dec 10 2021, Junio C Hamano wrote:

[CC-ing Maksym, the topic author]

quoted

* ms/customizable-ident-expansion (2021-09-01) 1 commit
 - keyword expansion: make "$Id$" string configurable

 Instead of "$Id$", user-specified string (like $FreeBSD$) can be
 used as an in-blob placeholder for keyword expansion.

 Will discard.
 Stalled for too long.
 cf. <xmqqfsuosvrh.fsf@gitster.g>
 cf. [ref]
 source: [ref]

I'd like to see this go in, not because I'd personally find it useful,
but mainly because I didn't find anything wrong with it (per my review
id [1] linked above), and more importantly because the saga ending here
seems rather unfriendly to a first-time contributor.

Wasn't the "stalled for too long" mainly a victim of timing? I.e. that
it happened to be submitted/discussed around the end of the last release
cycle?

I do not think timing has much to do with it.

I have been fairly clear from the very first review of the initial
iteration that I do not want us to commit to "per-path" attribute.
It will open can of worms [*], and paint us into a corner we cannot
get out of easily once such an overly flexible system gets to users'
hands.  I also was fairly clear that instead I'd expect it would be
more sensible if it were a single "instead of $Id$, use $FooId$
throughout the tree" configuration.

I also did not want to force a first-time contributor to commit to
deal with a fallout from such a design.  A new feature with a very
limited scope will have better chance to allow us extend it later
without breaking compatibility with the initial version and would be
better suited for first-timers.


[Footnote]

* I have already mentioned that users have to figure out when adding
  a new file which keyword applies to the path.  It also troubles me
  that it is not part of the design what should happen when people
  want to move files around.  Not allowing per-path settings means
  we do not have to worry about the extra flexibility hurting the
  users of this (not "customizable" part but the "ident replacement"
  as a whole) misguided feature that shouldn't have been added in
  the first place.