Re: updating merge request

[Luca Fascione]

At first I saw it like you Aaron,
but after thinking about this for the last several hours it occurred to me
that we're only rewriting the history of the current MR, we're not junking
a big part of the project.
The idea is that given that there's no squash upon acceptance, the history
in the MR will go in "as is".
I do see the value in this, and I'd think you'll want a judicious user of
git, with a developed taste for repo grooming to
use a mix of history rewrites and additions during the lifetime of an MR if
there's back and forth on it.

I do keep my commit history very clean while working, I'd put in maybe up
to 8-10 commits, and then pause and rebase -i onto that
until I'm happy that the story told by the commits to my colleagues is
sensible. At that point I push, because our stuff is not MR-based.
But for the projects based on MR's we always did "squash on merge", which
left me uneasy. I must say I do prefer that the contributor
does have a say in how to best represent their work as a series of commits,
so although it's scary and "different", I feel this idea of
force-pushing amends and such onto an MR is actually a nice idea.

Luca

On Fri, Jan 20, 2023 at 3:03 PM Aaron Hill <lilypond@hillvisions.com> wrote:

> On 2023-01-20 3:22 am, Jean Abou Samra wrote:
> > Rewriting history is just something that one might not be used to
> > coming
> > from other projects, but perfectly fine for our purposes.
>
> It was impressed upon me to treat rewriting history as fraught with
> peril, potentially even Bad(tm) in the Ghostbusters sense:
>
>      "Try to imagine all life as you know it stopping instantaneously and
>       every molecule in your body exploding at the speed of light." --
> Egon Spengler
>
> One might argue that anything in your development branch is not really
> part of "history" yet as it has not been accepted.  (The situation gets
> murkier when people are forking forks.)  As such, it *should* be safe to
> mess about with commits to clean up typos or catch missing files, what
> have you.  And I would agree this results in a cleaner submission that
> is easier to review for correctness.  (I probably should clarify my
> earlier comments that I do not intentionally make my commits messy, just
> that I usually do not stress about them being so absolutely pristine;
> again, I am used to work being squashed, so any niceness I put in there
> gets lost.)
>
> So I can see --amend being useful for the little things.  But let's say
> during a review, it is determined that the scope could increase to cover
> more items than originally planned but that still feels part of the same
> submission.  (Anything too distinct really should be an independent
> request.)  Now, you might not necessarily want to force all of the new
> development work into the existing commit.  Reviewers might even
> appreciate seeing the individual slices of the task more cleanly
> delineated.  In a sense, there is some "history" to the process that
> might be worth preserving during this stage.
>
>
> -- Aaron Hill
>
>

-- 
Luca Fascione