On 2022-11-02 10:45, Ævar Arnfjörð Bjarmason wrote:
On Tue, Nov 01 2022, Marc Branchaud wrote:
Instead the decision was to do nothing in Git, and instead let people
create their own post-checkout hooks to touch the files. I (and others)
argued this was inadequate, to no avail.
>> [1]
https://public-inbox.org/git/20180413170129.15310-1-mgorny@xxxxxxxxxx/#r
I think that's the wrong take-away from that thread. Maybe a patch for
this will get rejected in the end, but in that case it wasn't because
the git project is never going to take a patch like this.
Maybe it won't, but:
* That commit has no tests
* It's clearly controversial behavior, so *if* we add it I think it's
better to make it opt-in configurable.
* Once that's done, you'd need doc changes etc. for that.
Now, maybe a sufficiently polished version would also be "meh" for
whatever reason, I just think it's premature to say that a change in
this direction would never be accepted.
I did not say that it would never be accepted; perhaps I should have
said "outcome" instead of "decision". That 2018 thread barely discussed
changes to the patch itself. The patch's writer (not me) didn't pursue
the work, after its frosty initial reception.
Past discussions around these proposals have been negative, which
discourages people from polishing a submission as you suggest. I hope
that this time is different. (Before you suggest I submit a patch, I
sadly don't have the time to hack on Git these days.)
That being said, I do wonder if software in the wild is being
monkeypatched to work around issues with make (or make-like tools)
whether such a change isn't better advocated in e.g. GNU make itself.
If it added "B" to "MAKEFLAGS" if it detected:
* I'm in a git repository
* It's the first time I'm running here, or "nothing is built yet"
* My dependency graph would be different with "-B"
Wouldn't that be what people who want this feature are after?
It's not like it's SCM-agnostic, it already goes to significant trouble
to cater to RCS and SCCS of all things, so I don't see why they'd
categorically reject a patch to cater to modern VCS's.
And, unlike Gike, GNU make wouldn't need to guess that munging
timestamps would fix it, it can compute both versions of the dependency
graph, so it would know...
Fair points about advocating for changes in make. However, Gnu make
isn't the only flavour out there. Our builds use both BSD's and Gnu's
makes, for example. (Also, BSD make has a completely different
interpretation of -B, and does not have any flag that mirrors Gnu make's
-B.)
Git is really the ideal place to solve this problem, instead of playing
whack-a-mole with build tools and upstream projects. Making the
behaviour opt-in is perfectly reasonable.
M.
