Re: [gpsd-dev] Repository move to gitlab may be pending

[Fred Wright]

On Thu, 1 Sep 2016, Paul Fertser wrote:

> Sorry, can't resist, but this notion feels to be completely wrong and
> harming the ecosystem.
>
> On Wed, Aug 31, 2016 at 03:42:00PM -0700, Fred Wright wrote:
> > Does GitLab have forks and pull requests like GitHub?
> > It's a much better workflow for contributions than patches via email.
>
> Since when using vendor-dependent convoluted way to contribute to a
> free software project is preferred to the standards-based way?
>
> Please compare, normal way:
>
> 1. "git clone" a repository
> 2. add commits implementing your desired features/bugfixes
> 3. "git send-email"
> 4. get feedback from the maintainers
> 5. "git fetch", "git rebase -i" (to rebase on top of current code, be
> careful), hack, hack
> 6. "git send-email"
> 7. repeat as necessary
>
> "GitHub" way:
>
> 1. Using complicated heavy-weight GUI software with integrated JIT
> compiler (a remote descendant of what was once used to navigate
> hypertext) register a GitHub account
> 2. using same software do a "fork" of a repository
> 3. "git clone" your fork
> 4. add commits implementing your desired features/bugfixes
> 5. "git push"
> 6. using the mentioned software create a "pull request"
> 7. get feedback from the maintainers
> 8a. using the mentioned software try to find the button to rebase your
> patches on top of the current code, if a conflict emerges, proceed to 8b.
> 8a.1. "git fetch", "git reset --hard" (be careful!)
> 8b. "git remote add upstream" to add the upstream URL to your local
> repository
> 8b.1. "git fetch", "git rebase -i" (be careful)
> 9. hack, hack
> 10. "git push -f" (be careful!)
> 11. repeat as necessary, sometimes from point 1 when the upstream
> decides to migrate from one SaaS provider to another; and if you're
> already used to workaround usability issues with API-specific tools
> (e.g. http://github.com/sigma/magit-gh-pulls) tough luck, sorry, they
> won't work with the new SaaS "platform".
>
> (this example assumes a workflow that is easier for the maintainers
> due to reasonably linear history providing a better readable log and
> less merge commits, hence less merge conflicts)
>
> Please feel free to prove me wrong. I can also note that I have
> experience with a project-controlled Gerrit instance, it seems sort of
> ok compared to "github" but I'd still prefer plain e-mail + patchwork.

You're conflating one-time or extremely rare steps with per-repo steps and
per-change steps, as well as conflating religious opinions about
implementations with user interface behavior.

I've stated before that patches via email are sooo twentieth-century. :-)

All kidding aside, putting patches in the main text of email risks having
them garbled by whatever email software happens to be involved.  And aside
from garbling, I've had a case where a patch couldn't be sent via email at
all, simply because it had excessively long lines.  These issues can be
avoided by sending the patch as an attachment, but that frequenctly makes
it difficult to view directly.

There's also the issue of tracking.  I normally try to make changes in a
way that no point in the history is worse than its predecessor, but I've
seen that property violated by having patches in a patchset applied out of
order, as well as by having some patches in the set inadvertently dropped.
A mailbox is not the best way to track pending changes.

Doing everything with git tools and git transport mechanisms is generally
more robust, but for contributions from developers without direct commit
access, this requires some form of "moderated push".  This in turn
requires that changes be "pullable" by someone with commit access.  There
are two ways to do this:

1) Keep your own machine up 24/7 and allow outside access to it.
or
2) Keep a mirror of your own repo online somewhere.

Option 2 is clearly preferable for most people, and that constitutes the
"fork", or whatever the hosting site chooses to call it.  In addition,
there has to be some form of authentication to write to this repo.  This
same authentication also serves as the authentication for the proposed
changes, and is almost certainly more difficult to spoof than the "From:"
line of an email.  Setting up an account isn't even per-repo, let alone
per-change.

Any scheme invoving an online mirror of one's personal repo has to have at
least two remotes, one for the personal mirror, and one for the primary
repo.  Setting up the additional remote is a per-repo step, not a
per-change step, and it's a single git command.  This is not specific to
GitHub.

The "normal" way above glosses over the "git format-patch" steps, as well
as the means for determining the commit range.  When the pull request
mechanism is used properly, the latter aspect is automatic.

The use of "rebase -i" (in both "ways") above suggests developing directly
in the master branch, which is usually a mistake.  It's best to keep all
branches which are mirrors of primary-repo branches (only "master" for
gpsd right now, but usually more than one) in a "pristine" (i.e.,
fast-fowardable) state, and use personal development branches for changes.

This means that:

1) "Mirror" branches can be kept updated fairly easily, since there are no
merge conflicts.  If you're paranoid, you can include the "--ff-only"
option on the merge just to be sure.  Ideally, fast-forward merges
wouldn't need to touch the index or working directory at all, but
unfortunately git isn't that smart, so pending uncommitted changes can get
in the way in some cases, for no good reason.

2) Rebasing local commits to reflect the upstream changes is just a simple
"git rebase <upstream branch> <your branch>" (with conflict resolution
needed in some cases).  No need for the heavyweight interactive rebase.
As with any rebase, push requires "-f" since it's rewriting history, but
in general, personal development branches should be expected to get forced
updates.

3) With a properly rebased development branch, one can simply use
"<upstream branch>...<your branch>" as the commit range for "git
format-patch" in the "normal way", or one can just reference that branch
in the pull request for the "GitHub way".

4) In the "normal way", the surviving commits in the personal branch after
later rebasing constitute a record of pending unmerged changes.  This is
usually not an issue with the "pull request" approach, though.

5) In the "normal way", one can also create an additional branch as a
marker along the development branch indicating which commits have been
emailed and which haven't, to avoid either missing some commits or
duplicating commits.  This is irrelevant with pull requests.

Suggesting that "git reset --hard" might ever be necessary for normal
merge purposes is absurd.  I mentioned it for the particular case where
the entire repo history had been rewritten, and hence it wasn't mergeable
with *itself*.  Although it happened to be on GitHub, that's completely
irrelevant to the issue.  Under normal circumstances, one only uses that
command as an "undo".

Suggesting that migrating from one primary repo host to another is a
normal (or even frequent) part of the workflow is also absurd, and blaming
it on GitHub is even more so.  This whole thread started because of doubt
about the reliability of Savannah.

And finally, regardless of where a repo is hosted, one *can* always send
patches via email if one wants.  But for reasons stated above, I think
it's best to discourage rather than encourage that approach, and using a
hosting site that provides a good "moderated push" approach is a step in
that direction.

Fred Wright