Re: Git at Better SCM Initiative comparison of VCS (long)

> > > Another thing here is that "git commit" is local, so I am not sure
> > > if this question includes network operations...
> > 
> > Well, I think this session would be better titled "Atomic Operations"
> > or just "Atomicity".  Although I'm not sure if for example in Git
> > all operations are atomic under all conditions...
> 
> I believe that all git basic operations are atomic. In fact, you either
> got a new revision with new SHA-1 or don't. Aborting operation may
> leave some dangling objects, but it is okay, because they will be
> garbage collected later. But I am not sure about additional utilities
> such as git-svn. Git-svn uses rebase as it dcommits, being interrupted,
> it may leave you in some strange state. It is possible to recover but
> it may be not obvious for newbies. Other than that, I think everything
> is very resilient to any interruption.

> > > So, perhaps, it should be two separate points:
> > > - ability to preserve history of rename (with detail clarification
> > >   of what it means)
> > > - ability to show renames in the project history
> > 
> > That are points '1' and '2' on my list, perhaps stated bit differently:
> > showing renames in full history / history of project as whole, and
> > following history of a single file across renames.
> 
> I did not mean '1' and '2' as priorities, but that it is slightly
> different features and both can be titled as support of renaming.

> > > 
> > > Git tracks content rather than file-ids, and therefore it uses heuristics
> > > for rename detection.  This approach has an advantage of being able to
> > > preserve history for code lines between files, which usually happens much
> > > more often than file renaming.
> > 
> > I would rather write
> > 
> >   Renames are supported for most practical purposes[1]. By design Git
> >   does heuristic <i>rename detection</i> (based on similarity score of
> >   pathnames and file contents), instead of doing rename tracking (which
> >   usually is based on some kind of file-ids).  This approach allows for
> >   more generic content tracking of code movement (which usually happens
> >   much often than wholesame file renaming), e.g. in "git blame -C -C".
> 
> Sounds good to me. Perhaps, I would drop '(which usually... file-ids)'
> to make the sentence a bit shorter.

> > > > scm>         <section id="tracking_uncommited_changes">
> > > > scm>             <title>Tracking Uncommited Changes</title>
> > > > scm>             <expl>
> > > > scm>                 Does the software have an ability to track the changes in the
> > > > scm>                 working copy that were not yet committed to the repository?
> > > > scm>             </expl>
> > > > 
> > > > This also should be made more clean.  Does it mean for example ability
> > > > to tell which files have changed, or ability to diff working copy to
> > > > either last comitted changes, or to any revision available in repository?
> > > 
> > > Also, ability to diff one or more specified files in the working copy to
> > > some specified revision.
> > 
> > Right.
> > 
> > I'm not sure now if "Tracking Uncommitted Changes" is a good name for
> > this feature / criterion, but I don't have definite idea for change...
> 
> Actually, I don't like this name either. In particular, the word
> "tracking". Perhaps, "Showing Uncommitted Changes" would be a better
> name. Yet, ability to show diff between the working copy as some
> arbitrary version should be listed as a separate feature.