[Vm-dev] Should I push or request a pull?

[Ben Coman]

On Sun, Jun 26, 2016 at 4:51 AM, Tim Felgentreff
<timfelgentreff at gmail.com> wrote:
>
>
> Hi Ben,
>
> One of your arguments is about history cleaning.
> Mostly my discouraging of rebase -i comes from experience with people who made a mistake (e.g. as simple as deleting a line and then getting "lucky" and having git not complain about conflicts during the rebase) to lose a commit entirely. And sometimes they continued working for a while, eventually a git gc was triggered, and then that commit was cleaned up and was lost for good by the time they noticed their work was gone. This happened to people around me more than just once, and then I wasn't able to help because git gc had run. Eventually I gave up and encouraged people who do not want to spend the time to really put in the work and understand how git works and what the internal structures are to not use rebase.

Ah, it never cross my mind to delete a line. So I never hit the problem.

At  https://git-scm.com/docs/git-rebase  I found
    rebase.missingCommitsCheck - If set to "warn", print warnings
about removed commits in interactive mode. If set to "error", print
the warnings and stop the rebase. If set to "ignore", no checking is
done. "ignore" by default.

which you can see in action here...
https://github.com/git/git/blob/cf4c2cfe52be5bd973a4838f73a35d3959ce2f43/git-rebase--interactive.sh
    warn "Warning: some commits may have been dropped" \
             "accidentally."
    warn "Dropped commits (newer to older):"

but that didn't work for me and I had to ask on #git  IRC  to discover
this was introduced in 2.6.0.
I'm only 2.1.4 and current release is 2.9.0.

((Also btw I learnt a new trick, at the top of that last link, click <Blame>,
then search for "missingCommitsCheck" and scroll back up
to click on the commit, and at the bottom of the commit
it says  "master v2.9.0…v2.6.0-rc0" ))



>
> Your other argument is about bisecting. Another experience I had was with people rebasing to "clean up" history by grouping related changes together, but then not checking that each commit still compiles. So the bisect scripts we used in these projects still had to include the logic to skip non-compiling commits.

Good point. Although I do like Holger's
    git rebase -i --execute "./compile_and_test_all.sh" origin/master
but this is probably hard to police in an open source environment.

> As would any script used on a repository where no one used rebase to remove such 'bad' commits.
> Secondly, if people tried a bunch of different approaches and finally refactored their code and then squashed it all together, any bisects will only find one large commit as the culprit without explanatory history around it, making debugging harder.

I wouldn't expect every commit to be squashed, just the minuscule
things.  Logical groups of work should remain.

>
> All that being said, if you all think it's safe and we all agree that no one has the right to complain about git if they loose their commits, I won't strongly oppose rebasing.

Its probably too early for anyone new to git to form an experiential
opinion on whether rebase is safe.   Still the main contributors coudl
choose to be conservative.  I think the CONTRIBUTION page could say
something like...
   "git rebase is a dangerous but useful tool for a narrow range of
well defined tasks.  Receipies for these tasks are presented below.
For project consistency, you should adhere strongly to the recipe and
if something unexpected occurs, do... git rebase --abort.    Please
discuss any deviations on the mail list."

and if that sounds reasonable, I'll follow up with some recipes, one
of which might be check "git --version" and upgrade to latest git to
make rebase a bit safer.

cheers -ben

P.S. while on the topic of disasters we can learn from, this "Disaster
2" story [1] might be a useful read for anyone adapting from SVN.
[1] https://randyfay.com/content/avoiding-git-disasters-gory-story