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

Sat Jun 25 20:51:11 UTC 2016

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.

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

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.

And finally, regarding the linear history up to now: that's an artifact of
how SVN works (it doesn't actually track merges) and thus is reflected in
the imported history.

cheers,
Tim

Am 24.06.2016 16:11 schrieb "Ben Coman" <btc at openinworld.com>:
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160625/003bc30c/attachment-0001.htm