On Thu, 28 Oct 2010 10:40:03 +0300, Russel Winder <russel@russel.org.uk> wrote:

> For personal individual working GitHub is fine.  However, as far as I
> know, it has no notion of team.  Launchpad has both the notion of
> personal and of team.  For uncontrolled FOSS this perhaps doesn't
> matter, but it makes it a lot easier to actually emulate the high priest
> elite that many project like to have.

FWIW: GitHub recently introduced an "organizations" feature, which might be close to the "team" notion you describe.

I didn't consider Bazaar a "major player" because I only heard of a few projects using it.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Thu, 28 Oct 2010 15:45:08 +0300, Bruno Medeiros <brunodomedeiros+spam@com.gmail> wrote:

> On 27/10/2010 22:33, "Jérôme M. Berger" wrote:
>> 	Well, Mercurial offers much less opportunities to shoot oneself in
>> the foot and is much easier to use. This is especially true if you
>> come from another VCS like SVN: you can use the same commands for
>> the same results on the local repository and you only need to learn
>> a couple of commands for syncing. Git uses different commands for
>> everything (this is actually a stated design goal: try to make
>> things as different from CVS as possible!)
>>
>> 	The only true advantage that Git has over Mercurial is the staging
>> area, and even that is a two edged sword: IMO it should not be
>> enabled by default since it helps people to lose data. And the same
>> functionality can be emulated (and superseded) in Mercurial with
>> record and mq anyway.
>
> But isn't the staging area similar, if not identical to SVN? I mean, in svn you also have to do a command "svn add" to add new files to the "sandbox". They won't get commit otherwise, right?
>
> (note: im somewhat familiar with SVN and Git, but not with Mercurial)

No, that only marks the file to be added in the next commit.
Compared to SVN, when you type "git add file", you copy the file entirely into the index.
You can then continue editing it without changing that copy.
Git also allows you to only "stage" parts of a file, as I described in another post.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Thu, 28 Oct 2010 10:48:26 +0300, Russel Winder <russel@russel.org.uk> wrote:

> Any FOSS project allows this, you just want to use a hosting site.
> Launchpad and BitBucket behave like GitHub in this respect -- I don't
> know about Gitorious but I suspect it is the same.

I would expect nothing less. Human approval of projects in today's fast-moving world seems like stone-age.

> And the difference with others -- except the one-click being replaced by
> a command line?

Is this a serious question?
1) You don't need to take care of firewalls or your own hosting server to publish your changes
2) The repositories are semantically linked
3) Your commits will appear on the project's network graph, allowing anyone to merge/cherry-pick them

> Personal workflow, the model is not special.

If you say so.

> Git and GitHub are not special in any of the above points.

Sorry, I disagree. The second best project hosting website that I saw which allows this kind of implicit interoperability between forks was Launchpad.

I stand on my point that GitHub would fit D's development model the best of all other solutions that I noticed. Because D's project maintenance is not very reliable, anyone can start their own fork and e.g. add certain patches from Bugzilla. GitHub's network graph gives you the current state of a project of all its forks at a glance, which is extremely useful, and the next best thing is Launchpad's list of branches sorted by last activity.

Disregarding the capabilities of project hosting websites and judging the tools alone is absurd, IMO (unless your project's intended contributor audience dislikes project hosting websites as much as you do).

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

Vladimir Panteleev wrote:
> On Thu, 28 Oct 2010 00:33:54 +0300, Jérôme M. Berger <jeberger@free.fr> wrote:
> 
>>     The only true advantage that Git has over Mercurial is the staging
>> area, and even that is a two edged sword: IMO it should not be
>> enabled by default since it helps people to lose data. And the same
>> functionality can be emulated (and superseded) in Mercurial with
>> record and mq anyway.
> 
> Could you please explain to me how can the staging area cause you to lose data? The only way I see that can happen is if you forget that you staged some changes, then do "git diff" and think that your working directory (and index) are clean.
> 
git commit
git push # Is that the right command to send my changes
         # to the main repo?

# OK, I'm done working on that
cd ..
rm -r myrepo
# Ooops

>> - It is safer on Windows: in six years, I have never had a data loss or corruption, whereas I've had both with Git in a two days test without doing anything special;
> 
> Sorry, I don't consider this to be true at the moment based on my experience.
> 
>> - Repositories are smaller on Windows (ok, that's not so important
>> given the price of HDDs today);
> 
> How does that make sense? Doesn't Git use the same disk storage format everywhere? :o
> 
	I meant Mercurial repositories are smaller than Git repositories on
Windows (didn't check anywhere else)

>> - You really, really, really *always* need the staging area so you want to have it by default instead of using mq. If that is the case, you will probably wind up using quilt anyway (quilt is the Git equivalent for mq).
> 
> I think the staging area is an amazing feature, and I use it all the time, but perhaps not in the way you imagine:
> 
> 1) Hack up a bunch of changes
> 2) Fire up git gui
> 3) Quickly stage the chucks or lines you want to go into the first
> commit (one case where using a mouse-driven GUI is way more productive...)
> 4) Type commit description, Ctrl+Enter to instantly commit
> 5) Repeat, until working directory is clean
> 
> This allows me to work freely on my code and edit different parts of it, without having to worry that I should first commit / shelve unrelated changes first.
> 
	This workflow is fully supported by the crecord extension (or by
TortoiseHg).

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Bruno Medeiros wrote:
> On 27/10/2010 22:33, "Jérôme M. Berger" wrote:
>>     Well, Mercurial offers much less opportunities to shoot oneself in
>> the foot and is much easier to use. This is especially true if you
>> come from another VCS like SVN: you can use the same commands for
>> the same results on the local repository and you only need to learn
>> a couple of commands for syncing. Git uses different commands for
>> everything (this is actually a stated design goal: try to make
>> things as different from CVS as possible!)
>>
>>     The only true advantage that Git has over Mercurial is the staging
>> area, and even that is a two edged sword: IMO it should not be
>> enabled by default since it helps people to lose data. And the same
>> functionality can be emulated (and superseded) in Mercurial with
>> record and mq anyway.
> 
> But isn't the staging area similar, if not identical to SVN? I mean, in svn you also have to do a command "svn add" to add new files to the "sandbox". They won't get commit otherwise, right?
> 
> (note: im somewhat familiar with SVN and Git, but not with Mercurial)
> 
	No, because in Git if you make changes to an existing file, you
need to "add" that file again. In both SVN or Mercurial, you need to
"add" new files, but once a file is in the repository, any changes
to the file get committed by default (although there are ways to
commit only some files in both Mercurial and SVN and ways to commit
only some changes in Mercurial).

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

> git and gui? Come on...
Have you seen this: http://www.syntevo.com/smartgit/index.html ?

On 28/10/2010 18:51, "Jérôme M. Berger" wrote:
> Bruno Medeiros wrote:
>> But isn't the staging area similar, if not identical to SVN? I mean, in
>> svn you also have to do a command "svn add" to add new files to the
>> "sandbox". They won't get commit otherwise, right?
>>
>> (note: im somewhat familiar with SVN and Git, but not with Mercurial)
>>
> 	No, because in Git if you make changes to an existing file, you
> need to "add" that file again. In both SVN or Mercurial, you need to
> "add" new files, but once a file is in the repository, any changes
> to the file get committed by default (although there are ways to
> commit only some files in both Mercurial and SVN and ways to commit
> only some changes in Mercurial).
>
> 		Jerome

I see. Well, it's not identical then, but still, it seems very similar, since one can use "git commit -a" to do the same as "svn commit", isn't that so? I mean, is there any aspect to Git's staging area that makes "git commit -a" not be equivalent to "svn commit" ? (obviously for this question interactions with Git-only features should not be considered)


My confusion here stems not so much from the discussion in this thread, but from another discussion elsewhere on the web (not D related) where I also saw a developer comment that Git's staging index default behavior was more complex that necessary, and that it should be the simple thing by default. There was an implication, from the way he said it, that this was an issue of at least medium importance.
However, from my understanding, in the whole landscape of version control issues and comparisons, this one seems of very low importance, if not borderline irrelevance. Because even if a developer using Git shoots himself in the foot with this... it will be only *once*, on the learning phase. After that you'd know and remember to use "git commit -a" so the mistake would not be repeated. A /one-time issue/ cannot possibly be anywhere near in importance than a /many-times issue/.


-- 
Bruno Medeiros - Software Engineer

Bruno Medeiros wrote:
> On 28/10/2010 18:51, "Jérôme M. Berger" wrote:
>> Bruno Medeiros wrote:
>>> But isn't the staging area similar, if not identical to SVN? I mean, in svn you also have to do a command "svn add" to add new files to the "sandbox". They won't get commit otherwise, right?
>>>
>>> (note: im somewhat familiar with SVN and Git, but not with Mercurial)
>>>
>>     No, because in Git if you make changes to an existing file, you
>> need to "add" that file again. In both SVN or Mercurial, you need to
>> "add" new files, but once a file is in the repository, any changes
>> to the file get committed by default (although there are ways to
>> commit only some files in both Mercurial and SVN and ways to commit
>> only some changes in Mercurial).
>>
>>         Jerome
> 
> I see. Well, it's not identical then, but still, it seems very similar, since one can use "git commit -a" to do the same as "svn commit", isn't that so? I mean, is there any aspect to Git's staging area that makes "git commit -a" not be equivalent to "svn commit" ? (obviously for this question interactions with Git-only features should not be considered)
> 
> 
> My confusion here stems not so much from the discussion in this thread,
> but from another discussion elsewhere on the web (not D related) where I
> also saw a developer comment that Git's staging index default behavior
> was more complex that necessary, and that it should be the simple thing
> by default. There was an implication, from the way he said it, that this
> was an issue of at least medium importance.
> However, from my understanding, in the whole landscape of version
> control issues and comparisons, this one seems of very low importance,
> if not borderline irrelevance. Because even if a developer using Git
> shoots himself in the foot with this... it will be only *once*, on the
> learning phase. After that you'd know and remember to use "git commit
> -a" so the mistake would not be repeated. A /one-time issue/ cannot
> possibly be anywhere near in importance than a /many-times issue/.
> 
> 
	Ah, but it is a many-times issue. It is even an every-times issue.
The problem here is that you need to remember to add the appropriate
option each and every time you want to commit. Proper interface
design would be to have the common usage be the default and have an
option to enable the complex usage (especially for the most common
command).

	Additionally this makes it a lot more difficult to move back and
forth between several systems: imagine if all VCSes required special
options to do a simple commit, now each time you want to commit, you
need to remember whether this particular VCS requires an option and
which option you need to add to get the simple behaviour.

	Moreover, this is just the tip of the iceberg. The whole git UI is
"designed" like that and full of small irritations and inconsistencies.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 10/11/2010 10:20, "Jérôme M. Berger" wrote:
> Bruno Medeiros wrote:
>> On 28/10/2010 18:51, "Jérôme M. Berger" wrote:
>>> Bruno Medeiros wrote:
>>>> But isn't the staging area similar, if not identical to SVN? I mean, in
>>>> svn you also have to do a command "svn add" to add new files to the
>>>> "sandbox". They won't get commit otherwise, right?
>>>>
>>>> (note: im somewhat familiar with SVN and Git, but not with Mercurial)
>>>>
>>>      No, because in Git if you make changes to an existing file, you
>>> need to "add" that file again. In both SVN or Mercurial, you need to
>>> "add" new files, but once a file is in the repository, any changes
>>> to the file get committed by default (although there are ways to
>>> commit only some files in both Mercurial and SVN and ways to commit
>>> only some changes in Mercurial).
>>>
>>>          Jerome
>>
>> I see. Well, it's not identical then, but still, it seems very similar,
>> since one can use "git commit -a" to do the same as "svn commit", isn't
>> that so? I mean, is there any aspect to Git's staging area that makes
>> "git commit -a" not be equivalent to "svn commit" ? (obviously for this
>> question interactions with Git-only features should not be considered)
>>
>>
>> My confusion here stems not so much from the discussion in this thread,
>> but from another discussion elsewhere on the web (not D related) where I
>> also saw a developer comment that Git's staging index default behavior
>> was more complex that necessary, and that it should be the simple thing
>> by default. There was an implication, from the way he said it, that this
>> was an issue of at least medium importance.
>> However, from my understanding, in the whole landscape of version
>> control issues and comparisons, this one seems of very low importance,
>> if not borderline irrelevance. Because even if a developer using Git
>> shoots himself in the foot with this... it will be only *once*, on the
>> learning phase. After that you'd know and remember to use "git commit
>> -a" so the mistake would not be repeated. A /one-time issue/ cannot
>> possibly be anywhere near in importance than a /many-times issue/.
>>
>>
> 	Ah, but it is a many-times issue. It is even an every-times issue.
> The problem here is that you need to remember to add the appropriate
> option each and every time you want to commit. Proper interface
> design would be to have the common usage be the default and have an
> option to enable the complex usage (especially for the most common
> command).
>
> 	Additionally this makes it a lot more difficult to move back and
> forth between several systems: imagine if all VCSes required special
> options to do a simple commit, now each time you want to commit, you
> need to remember whether this particular VCS requires an option and
> which option you need to add to get the simple behaviour.
>
> 	Moreover, this is just the tip of the iceberg. The whole git UI is
> "designed" like that and full of small irritations and inconsistencies.
>
> 		Jerome


Well, yes, it is every-times with regards to having to add the extra commit option. But it is just 3 extra characters, and I'm guessing it is quite easy to remember every time (maybe a little bit less if you use different VCS often, yeah).
I'm not saying git would not be better designed if " -a" was the default, just that it's a very unimportant in terms of comparing VCS's. (It matters even less to my usage of VCS, since almost always I use Eclipse's graphical interface, which has a common behavior for the basic operations in all popular VCS. :) )

-- 
Bruno Medeiros - Software Engineer

Bruno Medeiros wrote:
> Well, yes, it is every-times with regards to having to add the extra
> commit option. But it is just 3 extra characters, and I'm guessing it is
> quite easy to remember every time (maybe a little bit less if you use
> different VCS often, yeah).
> I'm not saying git would not be better designed if " -a" was the
> default, just that it's a very unimportant in terms of comparing VCS's.
> (It matters even less to my usage of VCS, since almost always I use
> Eclipse's graphical interface, which has a common behavior for the basic
> operations in all popular VCS. :) )
> 
	Like I said, it is a pretty minor issue in and of itself. Its
importance is as a symptom of how poorly designed the interface is
in general. My main objections to Git are in order of importance:

1. Data corruption on Windows. That one is the killer issue;

2. Poor interface by design! The "-a" option is in this category, but it is not the only issue there by far. Most of those issues taken individually would be pretty minor, but added together they make Git very uncomfortable to work with;

3. Git is not a VCS so much as a PMS (Patch Management System). The difference is in the way each views history: for a VCS, history is important in and of itself, whereas for a PMS like Git history is just something you keep to help you merge branches. Git's much touted history rewriting abilities are more a liability than an asset for a VCS. In a roundabout way, this is why most Git users view the "-a" issue as negligible: if you forget part of a commit, just commit the missing changes and collapse the two changesets (which is easy since we don't care about history anyway).


	Points 1 and 2 are real issues. That is, they are intrinsically
negative points. Point 3 is more a difference between Git and
everything else, so it will be negative or neutral (*) depending on
what exactly you expect from a SCM.

		Jerome

(*) I wrote "neutral" instead of "positive", because IMO Mercurial offers similar abilities as a PMS if that is all you want.

-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr