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

[Ben Coman]

On Tue, Jun 28, 2016 at 11:41 PM, Ben Coman <btc at openinworld.com> wrote:
> 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.

It took some work to determine out how to upgrade git, so I share that
for reference...

The easy path didn't work...
$ sudo apt-get dist-upgrade
$ lsb_release -a
Debian GNU/Linux 8.4 (jessie)
$ git --version
2.1.4

So I built from source per...
http://superuser.com/questions/644586/how-to-upgrade-to-latest-git-on-debian-7

$ sudo apt-get install devscripts
$ mkdir ~/devel && cd $_
$ dget http://ftp.de.debian.org/debian/pool/main/g/git/git_2.8.1-1.dsc
$ dpkg-source -x git_2.1.4-2.1.dsc
$ cd git
$ dpkg-checkbuilddeps

$ apt-get build-dep git

$ dch --bpo
$ dpkg-buildpackage -uc -us -b
$ cd ..
$ sudo  dpkg -i git_*.deb   git-man_*.deb
$ git --version
2.8.1


cheers -ben


>
> ((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