Thread (1 message) 1 message, 1 author, 2019-01-18

Re: [PATCH v12 00/26] Convert "git stash" to C builtin

From: Junio C Hamano <hidden>
Date: 2019-01-18 17:49:41

Johannes Schindelin [off-list ref] writes:
Hi Junio,

On Thu, 3 Jan 2019, Junio C Hamano wrote:
quoted
Paul-Sebastian Ungureanu [off-list ref] writes:
quoted
This is a new iteration of git-stash which also takes
sd/stash-wo-user-name into account. I cherry-picked
some of dscho's commits (from [1]) to keep the scripted
version of `git stash` as `git-legacy-stash`.
I took a brief look and left a comment on 04/26 last year.  I had
some time blocked for this topic today to take another look at the
whole series again.  Thanks for working on this.

It seems that the last three or so steps are new, relative to the
previous round.  I made sure that what is added back at step 24
exactly matches the result of merging sd/stash-wo-user-name into the
current 'master', but such a manual validation is error prone.  Is
it possible to avoid "remove the scripted one prematurely at step
23, and then add it back as 'oops, that was wrong' fix at step 24"?
That would have been much more robust approach.
Sorry, I should have thought of that. My mistake.

As it is, Thomas verified that they are identical, so should we go forward
with ps/stash-in-c as-is? I'd prefer that...
Yes, before sending the message you are responding to, I made sure
the scripted version added back is identical to the current one, and
also there is no in-flight updates/fixes to the scripted one.

The benefit that would come from a possible reroll to start the
series from the last three patches would be fairly limited.

Such a reorganized series would have allowed investigation of
regressions and bugs during the development comparing the original
and rewritten implementations slightly easier, but experience from
seeing the evolution of these "reimplement in C" topics tells us
that we see major part of the regression fallouts after the series
is declared "feature complete" anyway, so in the long run, the
less-than-ideal organization of the topic does not matter much in
practice.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help