René Scharfe <l.s.r@xxxxxx> writes: > Am 12.10.20 um 21:19 schrieb René Scharfe: >> Am 12.10.20 um 18:33 schrieb Junio C Hamano: >>> If this "feature" were experimental and if the experiment turns out >>> to be a failure, would we have a viable alternative definition? >>> >>> Perhaps "--add-file names an untracked file in the working tree and >>> the single '--prefix' that is used for entries that come from the >>> tree object is applied"? Or perhaps remove --add-file entirely as a >>> failed experiment? >> >> Removing --add-file entirely is certainly possible, but it's used in the >> Makefile now and I can't imagine what would make its disposal necessary. >> >> Turning it into a standard OPT_STRING_LIST option for full untracked >> paths and using the last --prefix value for all archive entries would be >> a more straightforward UI and might be versatile enough. > > Here's how that would have looked, but it seems I'm too late. I think the "unusual --prefix semantics" does not hurt that much. If people can play funny games, they can, but if they do not want to confuse themselves, they can just give a single --prefix at the very beginning (or no --prefix at all of course), and then the semantics they will get is the same as what this add-on patch gives, I think. > The Makefile rules get a bit more fragile because the version files are > special and the simpler --add-file forces us to create them at their > actual place if not present, which can lead to problems (stuck version) > if we don't delete them afterwards. Avoiding that was the reason for > the more complicated version that ended up in v2.29. That fragility > could be defused by teaching GIT-VERSION-GEN about version_is_generated. Thanks for a thoughtful analysis, as usual.
