On Sat, 13 Nov 2010 12:24:58 +0100
>>>>>> "Jérôme" == <jeberger@free.fr> wrote:

Jérôme> 3. Git is not a VCS so much as a PMS (Patch Management
Jérôme> System).The difference is in the way each views history: for a
Jérôme> VCS, history is important in and of itself, whereas for a PMS
Jérôme> like Git history is just something you keep to help you merge
Jérôme> branches.

I agree (coming from darcs world) and just switched to Fossil which is
very nice keeping 'artifacts' immutable. Something for D. :-)


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------

Gour wrote:
> On Sat, 13 Nov 2010 12:24:58 +0100
>>>>>>> "Jérôme" == <jeberger@free.fr> wrote:
> 
> Jérôme> 3. Git is not a VCS so much as a PMS (Patch Management
> Jérôme> System).The difference is in the way each views history: for a
> Jérôme> VCS, history is important in and of itself, whereas for a PMS
> Jérôme> like Git history is just something you keep to help you merge
> Jérôme> branches.
> 
> I agree (coming from darcs world) and just switched to Fossil which is
> very nice keeping 'artifacts' immutable. Something for D. :-)
> 
	Nice, I didn't know about Fossil.

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

On 13/11/2010 11:24, "Jérôme M. Berger" wrote:
> 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.
>

Hum, thanks, this post was quite informative.

But what exactly is that data corruption issue on Windows?

-- 
Bruno Medeiros - Software Engineer

"add + commit" is not a bad design at all. It is just design choice, and it also about "patch control system", that allows more logical commit history and more precise control over VCS. It allows to code all things you want and place into commit only part of your changes. You even can stage part of file - if, for example, you done two logically different changes without commit between them. May be, good analogy will be reading file with one command versus "open-read-close" sequence - simplicity versus good control.

This feature allows very comfortable, free coding style - you write what you want ad understand now, and later you can divide your changes to logically related sets. You do not controlled by limits imposed by VCS - "work on one feature, commit, work on another". Instead VCS works in your style and rhythm. Usually you don't want run "commit -a". Instead when you run "git status" you see several files that you do not want to commit right now. So you use "add + commit" sequence, may be - several times to commit different changesets as distinct entities with distinct comments.

I think it's very good point of view - to track not file versions, patchsets that represent something meaningful - new features, bugfixes etc, and have VCS follow your practices and rhythm - and have understandable version tree at the end.

Bruno Medeiros wrote:
> But what exactly is that data corruption issue on Windows?
> 
	In some cases (I didn't try to isolate the precise conditions), Git
will replace '\n' with '\r\n' in binary files. This is with the
default config. It might be possible to change the configuration so
that this won't happen, but the simple fact that this happens with
the *default* config does not fill me with confidence regarding data
integrity and Git...

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

Alexey Khmara wrote:
> "add + commit" is not a bad design at all. It is just design choice, and it also about "patch control system", that allows more logical commit history and more precise control over VCS. It allows to code all things you want and place into commit only part of your changes. You even can stage part of file - if, for example, you done two logically different changes without commit between them. May be, good analogy will be reading file with one command versus "open-read-close" sequence - simplicity versus good control.
> 
> This feature allows very comfortable, free coding style - you write what you want ad understand now, and later you can divide your changes to logically related sets. You do not controlled by limits imposed by VCS - "work on one feature, commit, work on another". Instead VCS works in your style and rhythm. Usually you don't want run "commit -a". Instead when you run "git status" you see several files that you do not want to commit right now. So you use "add + commit" sequence, may be - several times to commit different changesets as distinct entities with distinct comments.
> 
> I think it's very good point of view - to track not file versions, patchsets that represent something meaningful - new features, bugfixes etc, and have VCS follow your practices and rhythm - and have understandable version tree at the end.

	This has nothing to do with Git's staging area. Mercurial also
tracks patchsets that represent something meaningful and has full
support for partial commits (with record or crecord) so you can
"write what you want and understand now, and later [...] divide your
changes to logically related sets". On the other hand, you are not
forced into this model when you know you have only worked on a
single feature and want to commit it.

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

On 11/17/10 10:32 PM, "Jérôme M. Berger" wrote:
> […] you are not
> forced into this model when you know you have only worked on a
> single feature and want to commit it.

You are not forced to use the staging area with Git either (although most of the developers I know do use it), it's just the default that is different.

If you want to save the extra characters per commit, just add an alias like »ci = commit -a« to your ~/.gitconfig, just like you might want to use »nudge = push --rev .« with Mercurial…

On 11/17/10 10:27 PM, "Jérôme M. Berger" wrote:
> […]It might be possible to change the configuration so
> that this won't happen, but the simple fact that this happens with
> the *default* config does not fill me with confidence regarding data
> integrity and Git...

This is not exactly true, at least not for the Git on Windows installer, which presents you with the three possible choices for handling line endings.

Also, I am not quite sure if this deserves the label »data corruption«, because even if you have auto-conversion of line endings turned on and Git fails to auto-detect a file as binary, no history data is corrupted and you can fix the problem by just switching off auto-conversion (either globally or just for the file in question via gitattributes) – in contrast to actual history/database corruption.

On 17/11/2010 21:27, "Jérôme M. Berger" wrote:
> Bruno Medeiros wrote:
>> But what exactly is that data corruption issue on Windows?
>>
> 	In some cases (I didn't try to isolate the precise conditions), Git
> will replace '\n' with '\r\n' in binary files. This is with the
> default config. It might be possible to change the configuration so
> that this won't happen, but the simple fact that this happens with
> the *default* config does not fill me with confidence regarding data
> integrity and Git...
>
> 		Jerome

Hum, my impression is that Git is actually pretty mindful about data integrity, not just on history, but on commits as well. However, it also seems like Git was designed with Linux in mind, so Git on Windows is kinda like a second-class platform (for example, performance is apparently lower on Windows). But hopefully that will improve on the future.



The comments above made tip my preference slightly over to Mercurial. But I think ultimately the decision of whether I would use Mercurial or Git would be decided more by external factors, like the quality of IDE-integrated tools (read: Eclipse plugins), and the availability or preference of those DVCS in hosting-sites/organizations. For example Google Code only supports Mercurial. On the other hand the Eclipse Foundation is moving their repositories to Git. (if it wasn't for that I'd likely have gone with Mercurial and not looked back on Git)

-- 
Bruno Medeiros - Software Engineer

klickverbot wrote:
> On 11/17/10 10:27 PM, "Jérôme M. Berger" wrote:
>> […]It might be possible to change the configuration so
>> that this won't happen, but the simple fact that this happens with
>> the *default* config does not fill me with confidence regarding data
>> integrity and Git...
> 
> This is not exactly true, at least not for the Git on Windows installer, which presents you with the three possible choices for handling line endings.
> 
	Yes, I saw this option and left the default selected.

> Also, I am not quite sure if this deserves the label »data corruption«, because even if you have auto-conversion of line endings turned on and Git fails to auto-detect a file as binary, no history data is corrupted and you can fix the problem by just switching off auto-conversion (either globally or just for the file in question via gitattributes) – in contrast to actual history/database corruption.

	It deserves the label "data corruption" since Git did the
conversion when committing the file, which means that the version
stored in the history was corrupted.

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