[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Fertser
Subject: Re: [gpsd-dev] Repository move to gitlab may be pending
Date: Thu, 1 Sep 2016 12:15:46 +0300
User-agent: Mutt/1.5.23 (2014-03-12)


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

Be free, use free ( software!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]