On Mon, Mar 11, 2013 at 3:51 PM, Sean Farley wrote:
> I think you're conflating the timings here. Let's first isolate network
> speed:
>
> $ time git clone -n https://bitbucket.org/jedbrown/petsc-git-leanpetsc-git
> Cloning into 'petsc-git'...
> remote: Counting objects: 297100, done.
> remote: C
On Mon, Jan 21, 2013 at 11:42 AM, Jed Brown wrote:
>
> On Mon, Jan 21, 2013 at 11:18 AM, Sean Farley
> wrote:
>>
>> On Mon, Jan 21, 2013 at 11:03 AM, Jed Brown wrote:
>> >
>> > On Mon, Jan 21, 2013 at 10:53 AM, Sean Farley
>> > wrote:
>> >>
>> >> Well ? did you try this with the equivalent merc
On Mon, Jan 21, 2013 at 11:18 AM, Sean Farley wrote:
> On Mon, Jan 21, 2013 at 11:03 AM, Jed Brown wrote:
> >
> > On Mon, Jan 21, 2013 at 10:53 AM, Sean Farley
> > wrote:
> >>
> >> Well ? did you try this with the equivalent mercurial feature:
> >> largefiles?
> >
> >
> > Nope, feel free. Most
On Mon, Jan 21, 2013 at 11:03 AM, Jed Brown wrote:
>
> On Mon, Jan 21, 2013 at 10:53 AM, Sean Farley
> wrote:
>>
>> Well ? did you try this with the equivalent mercurial feature:
>> largefiles?
>
>
> Nope, feel free. Most of the speedup is independent of the large files
> (which only change the g
On Mon, Jan 21, 2013 at 10:53 AM, Sean Farley wrote:
> Well ? did you try this with the equivalent mercurial feature:
> largefiles?
>
Nope, feel free. Most of the speedup is independent of the large files
(which only change the git repo size from 78MB to 50MB).
> Which version of mercurial is
On Mon, Jan 21, 2013 at 10:07 AM, Jed Brown wrote:
> As a test for my "git-fat" extension, I liberated the large files from
> PETSc's history (managing them outside the repository so that they need not
> be fetched by everyone; though if you fetch them, the working tree behaves
> identically to if
As a test for my "git-fat" extension, I liberated the large files from
PETSc's history (managing them outside the repository so that they need not
be fetched by everyone; though if you fetch them, the working tree behaves
identically to if they were in the repository). This brings the git version
o
On 01/10/13 11:23 AM, Barry Smith wrote:
> On Jan 9, 2013, at 10:19 PM, Dmitry Karpeev wrote:
>
>> My summary would be that
>> 1. Git's ui is bad
>> 2. There is the crappy index thingie
>> 3. I don't see how git branches are better than hg bookmarks (again, the ui
>> is bad).
>> 4. I still use m
On Wed, Jan 9, 2013 at 10:32 PM, "C. Bergstr?m" wrote:
> On 01/10/13 11:23 AM, Barry Smith wrote:
>
>> On Jan 9, 2013, at 10:19 PM, Dmitry Karpeev wrote:
>>
>> My summary would be that
>>> 1. Git's ui is bad
>>> 2. There is the crappy index thingie
>>> 3. I don't see how git branches are better
On 1/10/13 12:02 AM, Jed Brown wrote:
> On Wed, Jan 9, 2013 at 10:46 PM, Sean Farley
> mailto:sean.michael.farley at gmail.com>>
> wrote:
> [...]
> It should be obvious that I started the thread mostly to instigate. I
> didn't expect the trolling conditions to be so good tonight. ;-D
>
> However
On 1/9/13 11:37 PM, Barry Smith wrote:
> On Jan 9, 2013, at 10:35 PM, Richard Tran Mills wrote:
>
>> Git does some very cool stuff, but I have to agree with Sean's assessment of
>> the user interface, and that's the reason I prefer Mercurial. This is not
>> so much an issue with PETSc developer
Git does some very cool stuff, but I have to agree with Sean's
assessment of the user interface, and that's the reason I prefer
Mercurial. This is not so much an issue with PETSc developers, but I
like that the interface to Mercurial is so clean and simple that I can
get collaborators who are
On Wed, Jan 9, 2013 at 11:22 PM, Richard Tran Mills wrote:
> Emacs support? Oh, but I'm a Vim user! I used to be an Emacs user,
> actually, but I switched because I decided that Emacs was too bloated.
>
See the screencasts here:
https://github.com/tpope/vim-fugitive
>
> Now *there's* some go
On Wed, Jan 9, 2013 at 10:46 PM, Sean Farley
wrote:
> Jed, you have to realize that you're the only one in this thread that
> has been disgruntled with mercurial. Even that random dude that
> commented still doesn't like git.
>
> Yes, yes, git did this light-weight branching first. But, IMHO,
> me
On Wed, Jan 9, 2013 at 10:50 PM, Jed Brown wrote:
> On Wed, Jan 9, 2013 at 10:39 PM, Sean Farley gmail.com>
> wrote:
>>
>> Well, first of all, mq is being deprecated. Matt Mackall wanted a
>> general solution that would work in the mercurial framework. That
>> solution is the changeset evolution
On Wed, Jan 9, 2013 at 10:39 PM, Sean Farley
wrote:
> Well, first of all, mq is being deprecated. Matt Mackall wanted a
> general solution that would work in the mercurial framework. That
> solution is the changeset evolution concept. Once I started using that
> workflow, I whole-heartedly agree t
On Wed, Jan 9, 2013 at 10:40 PM, Jed Brown wrote:
> On Wed, Jan 9, 2013 at 10:28 PM, Sean Farley gmail.com>
> wrote:
>>
>> I've found most of your bugs in the mercurial tracker. Almost all of
>> your use cases that you are referencing are solvable after the
>> introduction of evolving changesets.
On Wed, Jan 9, 2013 at 10:28 PM, Sean Farley
wrote:
> I've found most of your bugs in the mercurial tracker. Almost all of
> your use cases that you are referencing are solvable after the
> introduction of evolving changesets. The key feature missing was the
> ability to mark a changeset as 'kille
On Wed, Jan 9, 2013 at 10:33 PM, Jed Brown wrote:
> On Wed, Jan 9, 2013 at 10:08 PM, Sean Farley gmail.com>
> wrote:
>>
>> There has historically been only one branching model ? ever.
>
>
> They have one thing they call a branch, another thing they call a bookmark,
> another thing they call mq...
On Jan 9, 2013, at 10:32 PM, "C. Bergstr?m" wrote:
> On 01/10/13 11:23 AM, Barry Smith wrote:
>> On Jan 9, 2013, at 10:19 PM, Dmitry Karpeev wrote:
>>
>>> My summary would be that
>>> 1. Git's ui is bad
>>> 2. There is the crappy index thingie
>>> 3. I don't see how git branches are better th
On Jan 9, 2013, at 10:35 PM, Richard Tran Mills wrote:
> Git does some very cool stuff, but I have to agree with Sean's assessment of
> the user interface, and that's the reason I prefer Mercurial. This is not so
> much an issue with PETSc developers, but I like that the interface to
> Mercu
On Wed, Jan 9, 2013 at 10:08 PM, Sean Farley
wrote:
> There has historically been only one branching model ? ever.
>
They have one thing they call a branch, another thing they call a bookmark,
another thing they call mq... They're all taking different approaches to
mostly-overlapping problems. Gi
On Jan 9, 2013, at 10:25 PM, Dmitry Karpeev wrote:
>
> On Jan 9, 2013 10:13 PM, "Barry Smith" wrote:
> >
> >
> > On Jan 9, 2013, at 10:03 PM, Dmitry Karpeev wrote:
> >
> > >
> > > On Jan 9, 2013 9:51 PM, "Barry Smith" wrote:
> > >
> > > > Then I would consider switching over to git and proc
On Wed, Jan 9, 2013 at 10:17 PM, Jed Brown wrote:
> On Wed, Jan 9, 2013 at 10:03 PM, Sean Farley gmail.com>
> wrote:
>>
>> * branching
>> - git has light-weight branches (this means that the branch metadata
>> is not written in the changeset)
>> - mercurial calls these things bookmarks
>
>
>
On Jan 9, 2013 10:13 PM, "Barry Smith" wrote:
>
>
> On Jan 9, 2013, at 10:03 PM, Dmitry Karpeev wrote:
>
> >
> > On Jan 9, 2013 9:51 PM, "Barry Smith" wrote:
> >
> > > Then I would consider switching over to git and proceeding to make
fun of hg users,
> > Is this the only reason to switch?
>
>
On Jan 9, 2013, at 10:19 PM, Dmitry Karpeev wrote:
> My summary would be that
> 1. Git's ui is bad
> 2. There is the crappy index thingie
> 3. I don't see how git branches are better than hg bookmarks (again, the ui
> is bad).
> 4. I still use multiple repos along with branches in git.
> 5. I
My summary would be that
1. Git's ui is bad
2. There is the crappy index thingie
3. I don't see how git branches are better than hg bookmarks (again, the
ui is bad).
4. I still use multiple repos along with branches in git.
5. I am willing to bet money Satish will use multiple repos, rather than
b
On Wed, Jan 9, 2013 at 10:03 PM, Sean Farley
wrote:
> * branching
> - git has light-weight branches (this means that the branch metadata
> is not written in the changeset)
> - mercurial calls these things bookmarks
>
Bookmarks have always been an extension that you have to explicitly enable
(
On Jan 9, 2013, at 10:13 PM, Sean Farley
wrote:
> On Wed, Jan 9, 2013 at 9:51 PM, Barry Smith wrote:
>>
>
>> 3) We can continue to use bitbucket more or less that same way as now (or
>> is there a reason to shift to github and it has decent "project" support?)?
>
> Bitbucket finally added
On Jan 9, 2013, at 10:03 PM, Dmitry Karpeev wrote:
>
> On Jan 9, 2013 9:51 PM, "Barry Smith" wrote:
>
> > Then I would consider switching over to git and proceeding to make fun of
> > hg users,
> Is this the only reason to switch?
Yes, making fun of other people is the highest priority
On Wed, Jan 9, 2013 at 9:51 PM, Barry Smith wrote:
>
> On Jan 9, 2013, at 7:17 PM, Jed Brown wrote:
>
>> Libmesh just moved to github as well.
>>
>> I think if you carefully consider the branching model, it has a clear
>> advantage over everything else. Dusty Phillips put it nicely in his recent
On Jan 9, 2013 10:10 PM, "Sean Farley"
wrote:
>
> On Wed, Jan 9, 2013 at 9:13 PM, Dmitry Karpeev
wrote:
> > I personally find git (and its branches) rather cumbersome and wish
libmesh
> > used mercurial instead :-)
>
> Not to mention git's atrocious interface.
Yes, I forgot to mention that.
>
> >
On Wed, Jan 9, 2013 at 9:13 PM, Dmitry Karpeev wrote:
> I personally find git (and its branches) rather cumbersome and wish libmesh
> used mercurial instead :-)
Not to mention git's atrocious interface.
> And if hgsubversion actually worked there would no need for git :-)
I've used that to acce
On Wed, Jan 9, 2013 at 7:17 PM, Jed Brown wrote:
> Libmesh just moved to github as well.
>
> I think if you carefully consider the branching model, it has a clear
> advantage over everything else. Dusty Phillips put it nicely in his recent
> blog post [1]:
>
> Git branches are simple and elegant.
On Wed, Jan 9, 2013 at 5:48 PM, Barry Smith wrote:
>
> Yes but given their absolutely horrible decision to stick with SVN all
> these years I cannot trust their decision to go with GIT. Sadly this is a
> very big argument for NOT switching PETSc to GIT. This email is only partly
> in jest, it
On Jan 9, 2013 9:51 PM, "Barry Smith" wrote:
>
>
> On Jan 9, 2013, at 7:17 PM, Jed Brown wrote:
>
> > Libmesh just moved to github as well.
> >
> > I think if you carefully consider the branching model, it has a clear
advantage over everything else. Dusty Phillips put it nicely in his recent
blog
I'll set up a git mirror (probably this weekend) so we can compare workflow.
On Wed, Jan 9, 2013 at 9:51 PM, Barry Smith wrote:
>
> On Jan 9, 2013, at 7:17 PM, Jed Brown wrote:
>
> > Libmesh just moved to github as well.
> >
> > I think if you carefully consider the branching model, it has a c
On Jan 9, 2013, at 7:17 PM, Jed Brown wrote:
> Libmesh just moved to github as well.
>
> I think if you carefully consider the branching model, it has a clear
> advantage over everything else. Dusty Phillips put it nicely in his recent
> blog post [1]:
>
> Git branches are simple and elegant
I personally find git (and its branches) rather cumbersome and wish libmesh
used mercurial instead :-)
And if hgsubversion actually worked there would no need for git :-)
Dmitry
On Jan 9, 2013 7:17 PM, "Jed Brown" wrote:
> Libmesh just moved to github as well.
>
> I think if you carefully consid
Libmesh just moved to github as well.
I think if you carefully consider the branching model, it has a clear
advantage over everything else. Dusty Phillips put it nicely in his recent
blog post [1]:
Git branches are simple and elegant. Mercurial branches are? well, it
depends what kind of branch y
Yes but given their absolutely horrible decision to stick with SVN all these
years I cannot trust their decision to go with GIT. Sadly this is a very big
argument for NOT switching PETSc to GIT. This email is only partly in jest, it
has a serious component as well: is the "everyone's switchin
41 matches
Mail list logo
