151–160 of 189 posts
One of his last points seems to be incorrect (or I'm misreading him). One that I like that replaces my most frequent usage of magit is crecord: interactively select hunks for committing. this is literally 'git add -p', and the -p flag can be passed to a load of different git tools to have this functionality?
Earlier quoted context omitted.
You mean tortoiseHG? There's tortoisegit as well. And the first Windows-only proprietary client I could find supports both systems (Smartgithg: http://www.syntevo.com/smartgithg/ )
No, I mean the whole experience. Mercurial being Python based has less UNIX feeling than Git on its workflow experience. Plus there are better plugins for Visual Studio integration available then for Git.
Earlier quoted context omitted.
> Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. `bookmarks` will do that. Or you can use unnamed heads and track them manually[0] (that's essentially what bookmarks — and git branches — do). "Detached heads" are not a thing in mercurial, heads don't have to be named. [0] obviously there's nothing to track if you're jus…
This is it exactly. A lot of people miss this with hg. hg bookmarks are the equivalency to git branches. hg branches are "permanent." So you have, say, 'dev,' 'test' and 'stable' branches. Then you do hot-fixes and feature development on bookmarks, and merge them back into the branches. It's a beautiful thing, really
In my opinion, this is not all good although it clearly solves a problem. Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations.
If branches are permanent, who are allowed to create branches? Everyone or just maintainers/core developers? What if a would-be contributor creates a branch that isn't wanted as a permanent branch or has a bad name? Need to rename a branch or do some tricks to comply with the upstream conventions? It ends up being a similar social/political issue to git rebase vs. git merge.
The easier learning curve argument was more relevant when people were coming to hg from svn/cvs backgrounds. These days more and more people are coming from a git background.
Earlier quoted context omitted.
This is bullshit rhetorical sophistry, and I'm pretty sure you know it. Choosing an incompatible license is the fault of the person who chose the license. The FSF made a mistake in not building "... or any later version" into the GPLv2; they acknowledge this. They've been recommending for some time - since long before the start of the Git project - that projects interested in being GPLv2 compatible include "... or an…
> This is bullshit rhetorical sophistry, and I'm pretty sure you know it. No, I don't know it. The GNU's license absolutism is what got them into this mess in the first place. It's inherent in their aims. > Imagine it was a piece of software with a bug. Imagine that it's a piece of software with a new UX direction not everyone agrees with.
Dismantling of copyright and a replacement with a requirement ensuring the freedoms the FSF cares about would thrill them, and not produce this license-incompatibility mess. It is plain, therefore, that it is not at all inherent to their aims. It may be inherent to this particular strategy - but again, license compatibility is something they've been looking at explicitly since making the mistake with GPLv2.
"Imagine that it's a piece of software with a new UX direction not everyone agrees with."
If the criticism was "They did not use GPLv3", that might be a more reasonable analogy than mine. The criticism was they used GPLv2 when they could have used GPLv2+. It's like using the buggy version specifically because others can't use the new UX with it (even though I can still use my old UX with the fixed version). Characterizing that as a move in opposition to those that like the new UX is the only reasonable characterization, absent other overriding factors (back out of metaphor, the only possible reason I could see is a need to use a lot of GPLv2 code in Git - someone else would have to speak to whether that is reality).
Earlier quoted context omitted.
No, I mean the whole experience. Mercurial being Python based has less UNIX feeling than Git on its workflow experience. Plus there are better plugins for Visual Studio integration available then for Git.
Isn't git built into Visual Studio?
I was forced to use mercurial for a few years at work and I really hated it. Sure it has a better learning curve than git (or did) but I found it to be incredibly frustrating already knowing git. In addition, I found it to be slower, less flexible, and prone to permanent repository corruption - yes, in git you do see repo corruption but because of the cryptographic nature of git objects you know immediately. HG will…
Earlier quoted context omitted.
The people who avoid the GPL3 do it because they do not share the goals of the GNU project. The GPL3 expresses the same philosophy as the GPL2. GNU released a new version only because companies discovered a loophole (a bug if you will) in the GPL which allowed them to build non-free (as in GNU) systems based on GPL software. GNU was founded to fight such systems. However, Linus Torvalds (Linux and git) has no problem…
Not agreeing with the FSF's rather dogmatic stances does not make you "anti-free-software". Having no problem with closed source does not make you "anti-free-software". (Except in the eyes of zealots, but who cares about them?)
Earlier quoted context omitted.
> Having no problem with closed source does not make you "anti-free-software". While true, its a bit odd of a statement. The following statements are also equally true: Having no problem with deforestation does not make you "anti-environmentalist". Having no problem with Ku Klux Klan members does not make you "anti-tolerance". Having no problem with murder and theft does not make you "anti-government". Except... if y…
>So why do you label FSF as zealots for disliking actions that helps those that want to threaten users with lawsuits Without even getting into the broken-ness of your analogies, being anti-DRM and anti-patent-abuse and so on is one thing. Calling someone evil because they don't publish the source of their app is quite another. According to their dogma, if I write a program and don't release the source code, I have pe…
Earlier quoted context omitted.
>Say you developed a program that keep tracks of group of people. The Ku Klux Klan use it to track down black people, and the anti-tolerance movement use it to track Ku Klux Klan. Stop it. You're basically engaging in a not-hitler version of Godwin's Law. And it's not even relevant, since the GPL is only about source code, not about whatever that code is used for. In your completely arbitrary and fucked up example, a…
What you said was: > BSD is a de-facto more permissive license. ... And people who want to use my code don't have to get involved in GPL politics and drama! So yes, you statement was an "BSD as the right choice, GPL is the wrong choice". If you actually want to be tolerant of people right to license what they want, you should not badmouth their choices when they don't pick the same as you. > as long as the KKK releas…
The day when people will say "oh I like BSD better" instead of "OMG BSD is much more free you are fucking idiots for liking GPL" will be a good day.
Earlier quoted context omitted.
This is it exactly. A lot of people miss this with hg. hg bookmarks are the equivalency to git branches. hg branches are "permanent." So you have, say, 'dev,' 'test' and 'stable' branches. Then you do hot-fixes and feature development on bookmarks, and merge them back into the branches. It's a beautiful thing, really
> hg bookmarks are the equivalency to git branches. In my opinion, this is not all good although it clearly solves a problem. Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations. If branches are permanent, who are allowed to create branches? Everyone or just mainta…
As far as learning curve, the branch/bookmark confusion doesn't seem to be all that big in practice IMO.