On Sun, 14 Sep 2008, Dmitry Potapov wrote: > On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote: > > > 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. I was thinking here about long-lasting and multiple-parts operations like for example git-clone. Nevertheless we would never be in inconsistent state. > > > 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. I didn't mean '1' and '2' as priorities; they are more or less equal, although I would say that '1' might be prerequisite to '2'. '0' is however a base which must be satisfied for tool to be named to have "rename support". > > > > > > 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. O.K. (But I would wait a bit for final proposal, with sending patch for scm-comparison.xml to Alexey and Shlomi.) > > > > 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. I don't have good name either. It is <something> about Uncommitted Changes. Dealing with, or support for, or something... -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
