On Jun 3, 2013 6:42 PM, "LCD 47" <[email protected]> wrote: > > 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.
There are line comments in bitbucket. > > > 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. > > -- -- 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.
