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

[Ben Coman]

On Mon, Jun 20, 2016 at 5:55 PM, Tim Felgentreff
<timfelgentreff at gmail.com> wrote:
>
>
> I've pushed a CONTRIBUTING.md to the repository that we can iterate
> over and discuss.
>
> If you go to https://github.com/OpenSmalltalk/vm/commit/5052e307fda0369f04550966fcfdf0a372aeaf39
> you can leave comments inline or at the end.
>

Thanks Tim, thats a really good starting point.  Usually github would
be the place to comment in-line, but this influences community
workflow a a broader audience is useful.

The thing I want to understand most is the strong discouragement of
rebasing rather than using it to maintain a tidy history.

First there is...
> This also means that you should avoid rebasing or squashing
> your work. Just keep the history.

I happened to look at Laura's PR that adds some good info to
CONTRIBUTING, so I use that as an example...
   https://github.com/OpenSmalltalk/vm/pull/14
Do you really want all four commits to appear in the master history?
I hunted up a dozen articles around this point, and even though a
little long winded, the best was this one...

   http://blog.izs.me/post/37650663670/git-rebase

I particularly liked how the two camps of rebase or not were
characterised into platform or service, as well as the explanation of
bisect.

Then there is...
> Every so many commits it is a good idea to push your work.
> Please refrain from rebasing, unless your history looks like this:

So the need for history cleanup is alluded to, but no guidance is
given on *how* to do it safely.
The critical point to make is to distinguish between cleaning private
branches and leaving public branches alone.  This is a good article
providing some examples...

    https://sandofsky.com/blog/git-workflow.html

Thirdly there is...
> However, if you're unsure what rebasing is, just forget about it
> and push the history as-is.

Again this seems to instil fear of a very useful tool for cleaning up
work in progress commits before submitting a pull request.  But first
the community needs to discuss the degree to which a clean linear
history is beneficial or desired.  Then we might define some recipes
to achieve that.

Finally it says...
> You will be thankful later when you need to use `git bisect` to find where a bug comes from.

But IIUC, bisect works better with a clean and linear history.  Also
from the the repository network graph...

   https://github.com/OpenSmalltalk/vm/network

before the 25 May the SVN history is *very* linear (or is this just an
artefact of the migration?) And after the 19 June (considering only
within the OpenSmalltalk swim lane, i.e. ignoring the personal repo
forks) the history is less linear.  Now branching is one of git's
greatest strengths to encourage participation, but that doesn't mean
every branch needs a permanent record in the trunk history.

So considering one particular workflow case, an afternoons work on
documentation or a quick bug fix, which yet may have several commits
but is only pushed once upon completion -- I believe a reasonable
workflow here would be for  `rebase -i`  to squash down to a single
commit prior to issuing the pull request.

Any subsequent commits to the PR from feedback would remain separate
until it is ready to integrate, when the integrator could squash them
as described here...

   "Merge pull request” [Big Green Button] Considered Harmful
   https://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful

However it sounds like you've some personal war stories that might be
useful for us to hear.  To me rebase seems straightforward for certain
defined situations, but maybe there is more about the risks I need to
learn...
> Seriously, skipping bad commits  a bisect is easier than fixing
> someones git tree once they have lost commits to the depths of reflog.
> Especially if their recovery attempts have already triggered a Git GC.

cheers -ben