[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) |
Hello,
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.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:address@hidden
- Re: [gpsd-dev] Repository move to gitlab may be pending,
Paul Fertser <=