Re: [PATCH v5 3/3] ls-files.c: add --deduplicate option

2 messages, 2 authors, 2021-03-19 · open the first message on its own page

Re: [PATCH v5 3/3] ls-files.c: add --deduplicate option

From: Junio C Hamano <hidden>
Date: 2021-01-22 18:11:10

Johannes Schindelin [off-list ref] writes:
quoted
And should I still use gitgitgadget PR on my origin branch "dedup"or
send patch on branch "zh/ls-files-deduplicate"?
The way GitGitGadget is designed asks for contributors to adjust their
patch(es) via interactive rebase, implementing the suggestions and
addressing the concerns while doing so, then force-pushing, optionally
amending the first PR comment (i.e. the description) with a list of
those changes, and then submitting a new iteration via `/submit`.
Thanks for clearly explaining the rules.

As I suspect many people are afraid of forcing their pushes, it
would assure them to explain that it is OK to force when them
restart the series from scratch by replacing the commits.

And it would very much help on the receiving end when the
description gets updated.

Just being curious, but when a series hits 'next', would the way in
which the user interacts with GGG change?  With or without GGG, what
is done on the local side is not all that different---you build new
commits on top without disturbing the commits that are in 'next'.
Then what?  Push it again (this time there is no need to force) and
submit the additional ones via `/submit`?

Thanks.

GitGitGadget and `next`, was Re: [PATCH v5 3/3] ls-files.c: add --deduplicate option

From: Johannes Schindelin <hidden>
Date: 2021-03-19 13:56:07

Hi Junio,

I just noticed that this still waited in my inbox for me to answer it.

On Fri, 22 Jan 2021, Junio C Hamano wrote:
Just being curious, but when a series hits 'next', would the way in
which the user interacts with GGG change?
My hunch is that we should probably tell new users (for who GitGitGadget
now uses the "new user" PR label) about the expectations of only adding
patches on top (i.e. in a new PR), unless the branch gets kicked out of
`next`.
With or without GGG, what is done on the local side is not all that
different---you build new commits on top without disturbing the commits
that are in 'next'. Then what?  Push it again (this time there is no
need to force) and submit the additional ones via `/submit`?
GitGitGadget would send the entire patch series, which is probably not a
good idea.

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