On 3 June 2013, Josh Hoff <[email protected]> wrote:
> On Jun 3, 2013, at 6:25 AM, LCD 47 <[email protected]> wrote:
[...]
> > About GitHub now. GitHub project started in ~2008. Back then, some
> > of us have been writing code for ~20 years, and we were generally
> > doing fine in our unenlightened ways. :) Back then GitHub was a
> > Rails app that shelled out to Git, and, while they do have a number
> > of brilliant people working at the site now, I'd humbly submit that
> > some of that initial architecture is still showing through. It's
> > social features are really nice these days, yes. But is it wise to
> > start _depending_ on them? Maybe not.
>
> What social features are you talking about depending on? Issues?
> Pages? Something else?
I'm referring to the beginning of this thread: issues, web-based
merges, commenting on particular lines from files, automatically marking
patches as obsolete. These are all nice and well thought-out. Some of
them have good equivalents outside GitHub (issues f.i. can be handled
with a bug tracker), others don't (say, commenting on a line from a
patch). The ones that don't are ultimately locking users to GitHub.
> > So, to answer your initial question: I'd personally like to see
> > Mercurial (or Git) used as a real DVCS (that is, people would start
> > submitting pull requests from their own repos). I'd also like to
> > see a more functional issue tracker in place, and people actually
> > using it. For the social features, I don't really care though.
> > Things can be coordinated just fine over a mailing list, like other
> > projects do: see f.i. Linux kernel, KDE, *BSD.
> >
> > As for solving the "this patch" problem, I'd say "please merge my
> > commit 31bed2d" is pretty much equivalent to "please include the
> > attached patch".
> >
>
> Not quite. If you push a commit up I can find it on the web ui, and
> send people links to it, or I can pull it from your remote repo and
> play with it by knowing your username and the sha/branch name. However
> I'd guess finding and using things through the ml would be a bit less
> elegant, though this is probably my inexperience with mailing lists
> showing through.
[...]
What I'm suggesting is something like this: I push a change to some
publicly available repo (on my own server, or GitHub, or whatever), then
send the link to the list, and also to Bram personally if he prefers so.
This keeps the repo decentralised, as opposed to tied to a central
GitHub / BitBucket. But yes, the price you have to pay for this is that
in order to find my patch you'll have to read the list (or search the
group archives).
/lcd
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
