If you delete hunks from the patch that 'cg-commit -p' shows you, then they are lost 'forever'. Let's put back everything how it was beforehand instead. --- cg-commit | 25 +++++++++++++++++-------- 1 files changed, 17 insertions(+), 8 deletions(-) diff --git a/cg-commit b/cg-commit index 01a4eb7..81b3619 100755 --- a/cg-commit +++ b/cg-commit @@ -568,18 +568,16 @@ else fi rm "$LOGMSG2" +pine_for_darcs() { + die "unable to revert the new patch; the original patch is available in ...

Well, there was (abandoned for now) idea of rr2-cache, the cache of how renames were resolved during merge conflict resolving. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

I was not talking about "git pull". I was talking about "git show". -

I am not bold enough to say _exactly_ N places, but you missed at least one more important one. Merge simplification favors the earlier parents over later ones. -

There is another one similar to the gitweb one you mentioned: git-show --stat on a merge. We deliberately chose to show the difference from the first parent; it is called "showing the changes the person who made this merge saw". -

Hi, It seems stgit does not use git-rerere, so why not? Any reason other than it hasn't been done yet? I abuse stgit heavily, by frequently reording patches, which for some patches result in re-occuring conflicts. git-rerere seems to be the solution. What's the "rules" for when to invoke rerere? It seems it is mostly automatic in git, but since only the porcelainish commands use it, that means StGIT doesn't. So here is what I *think* needs to be done. Seems simple enough. stg push, ...

The names of options clash somewhat with -M and -C in diffcore, which detect contents 'M'oving (renaming files), and contents 'C'opying (copying files), where in git-pickaxe -C is still about code movement, only across files (-M -M or --MM?). Would git-pickaxe try to do also copy-and-paste within the file, and across files? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

This patch only adds the streaming capability to index-pack. Although the code is different it has the exact same functionality as before to make sure nothing broke. This is in preparation for receiving packs over the net, parse them on the fly, fix them up if they are "thin" packs, and keep the resulting pack instead of exploding it into loose objects. But such functionality should come separately. One immediate advantage of this patch is that index-pack can now deal with packs up ...

Hi, I promised this patch some time ago, made the changes, and then never sent them. This is slightly different from the current implementation in that it fails when both scripts are executable. Also, it factors out the script names and adds tests. Signed-off-by: Jim Meyering <jim@meyering.net> --- cg-commit | 43 ++++++++++++++++++++++++++++++------------- t/t9800-hooks.sh | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+), 13 deletions(-) diff ...

Not true. If GNU patch (and git-apply) can detect where diff begins, and can detect if diff was truncated, then highlighting mode can distinguish between diff -u part and rest... well, unless you intermix diff-u output and arbitrary text (so the patch would not apply, but what happens when commenting a patch). Still I'd rather relax highlighting code to not highlight "SPC LF" than to change diff -u format. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Mercurial also claims that. It probably depends on the benchmark, though. But Mercurial (hg) lacks from what I understand persistent branches, and has only partial support for renames. YMMV. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Check out http://git.or.cz/gitwiki/GitBenchmarks section "Quilt import comparison of Git and Mercurial" for the latest (OLS2006) benchmark by Mercurial. Probably not indexed by Google, or doesn't have high pagerank because it is in PDF and fairly new (therefore has low "citations" number). -- Jakub Narebski Poland -

That's fine, but please don't call the git rename handling "maybe" or "partial", like a lot of people seem to do. Git _definitely_ handles renames, both in everyday life and when merging. Some people may not like how it's done, but other (I'll say "equally informed", even though obviously I know better ;) people really don't like the way bzr or others do their rename handling. Linus -

isn't the default to consider them a copy if they are 80% the same, with a command line option to tweak this (IIRC -m, but I could easily be wrong) David Lang -

You really cannot expect to get any kind of performance at all unless you: - are able to ignore 99.9% of all files on merging (ie you have to be able to totally ignore the files that are identical in both sides, and you really shouldn't even _care_ about why they ended up being identical) - are able to ignore 99% of what the commits _did_ in between the merges (ie if you need to look at them at all, only look at the part that matters for the 0.1% of files that you ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That's interesting, because I've always thought one of the strengths of file-ids was that you only had to worry about end-points, not how you got there. How do you handle renames without looking at the history? Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - ...

Dear diary, on Fri, Oct 20, 2006 at 07:48:58PM CEST, I got a letter Well it's certainly "interesting" and fun to see, but is it equally fun to handle mismerges caused by a broken detection? I've talked to some people who really didn't mind (or even liked) Git's heuristics when it came to _inspecting_ movement of content, but were really nervous about merge following such heuristics. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl ...

sorry, missed that. David Lang -

Instead of comparing number of lines matched, look at the matched characters and count alnums, so that we do not pass blame on not-so-interesting lines, such as empty lines and lines that are indentation with closing brace. Add an option --score-debug to show the score of each blame_entry while we cook this further on the "next" branch. Signed-off-by: Junio C Hamano <junkio@cox.net> --- * This comes on top of "next". The next one makes output from "pickaxe -C commit" actually make ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I guess I don't mind a bit of high-mmv discussion, so long as it doesn't get in the way of real work. Polishing these kinds of things seems to I think the great motivator for exploring other merge algorithms has been criss-cross merge. There are some workflows (e.g. the Launchpad workflow) in which heavy mesh-merging takes place, leading to frequent criss-crosses. Bog-standard three-way doesn't handle that criss-cross very well. ...

Heh. We can probably tweak the heuristics (one of the _great_ things about content detection is that you can fix it after the fact, unlike the alternative). That said, I've personally actually found the content-based similarity analysis to often be quite informative, even when (and perhaps _especially_ when) it ended up showing something that the actual author of the thing didn't intend. So yeah, I've seen a few strange cases myself, but they've actually been interesting. Like ...

This sounds somewhat like what I think BK did. I'm not sure if BK actually marked it as a conflict or whether BK just warned about "changes to deleted file" or something similar, but it didn't entirely _silently_ throw them away. But I hope this shows some of the basic problems. The much more _serious_ problem of "file identity" tracking is actually that you can't track partial file movement or file copies sanely. The thing is, tracking things at file boundaries simply is ...

Aaron Bentley wrote: > === added directory

This adds scoring logic to blame_entry to prevent blames on very trivial chunks (e.g. lots of empty lines, indent followed by a closing brace) from being passed down to unrelated lines in the parent. The current heuristics are quite simple and may need to be tweaked later, but we need to start from somewhere. Signed-off-by: Junio C Hamano <junkio@cox.net> --- builtin-pickaxe.c | 36 ++++++++++++++++++++++++++++++++---- 1 files changed, 32 insertions(+), 4 deletions(-) diff --git ...

If I remember correctly, git decided on contents (plus filename) similarity based renames detection because 1), it is more generic as it covers (or can cover) contents moving not only wholesome rename of a file, and 2) because file-id based renames handling works only if you explicitely use SCM command to rename file, which is not the case of non-SCM-aware channel like for example patches (and accepting ordinary patches is important for Linux kernel, the project git was created for). Another ...

So yes, merges are the situation where renames are normally considered a "problem", but it's actually not nearly the most every-day situation at all. The most common one is actually just showing things as a diff. If you are looking at a code-change, there's an absolutely _huge_ difference if you look at the result as a "delete this huge file" and "create this other huge file" and seeing it as a "move this huge file from here to here, and change a few lines in the process". So ...

Git just slurps in all three trees. I actually think that the current merge-recursive.c does it the stupid way (ie it expands all trees recursively, regardless of whether it's needed or not), but I should really check with Dscho, since I had nothing to do with that code. I wrote a tree-level merger that avoided doing the recursive tree reading when the tree-SHA1's matched entirely, and re-doing the latest merge using that took all of 0.037s, because it didn't recursively expand any of ...

For people new to the list, the message is: http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217 I think I've quoted this link at least three times on this list; I consider it is _the_ most important message in the whole list archive. If you haven't read it, read it now, print it out, read it three more times, place it under the pillow before you sleep tonight. Repeat that until you can recite the whole message. It should not take more than a week. To me, ...

It may be worth doing something special for licenses. Logs of small Mozilla files are also getting tripped up by the large copyright notices. The notices take up a lot of space too. The Mozilla license has been changed five times. That is 110,000 files times one to five licenses at 800-1500 characters each. 500MB+ of junk before compression. You could have a file of macro substitutions that is applied/expanded when files go in/out of git. The macros would replace the copyright notices ...

Here's a real-life schenario that we hit several times with BK over the years: - take a real repository, and a patch that gets discussed that adds a new file. - take two different people applying that patch to their trees (or, do the equivalent thing, which is to just create the same filename independently, because the solution is obvious - and the same - to both developers). - now, have somebody merge both of those two peoples trees (eg me) - have the two people ...

(slightly corrected example). A$ git branch B A$ git mv data greetings A$ git commit -a -m "Renamed the data directory to greetings" A$ git checkout B B$ echo 'Goodbye World!' > data/goodbye.txt B$ git add data/goodbye.txt B$ git commit -a -m "Added goodbye message." B$ git checkout A A$ git pull . B Trying really trivial in-index merge... fatal: Merge requires file-level merging Nope. Merging HEAD with 4a8a1a7941f214c6173786b583830b4f74a67c1f Merging: ...

If you have only mega-diff, you can comment only on this mega-diff. It is more usefull for changes which have natural mult-commit history, As _series_ of patches. You have git-format-patch + git-send-email to format and send them, git-am to apply them (as patches, not as branch). I was under an impression that user sees only mega-patch of all the revisions in bundle together, and rest is for machine consumption only. cg-bundle doesn't have this "mega-diff", but has shortlog (does ...

You first handle all the non-renames that just merge on their own. That takes care of 99.99% of the stuff (and I'm not exaggerating: in the kernel, you have ~21000 files, and most merges don't have a single rename to worry about - and even when you do have them, they tend to be in the "you can count them on one hand" kind of situation). Then you just look at all the pathnames you _couldn't_ resolve, and that's usually cut down the thing to something where you can literally use a lot ...

AFAIR yes, it does the dumb thing, namely it does not take advantage of trees being identical when their SHA1s are identical. Not me. Only that there is much potential for optimization (meaning performance, not the basic algorithm). Ciao, Dscho -

I tried this to see what bzr would do. Here's the critical point where the first merges are done ("a" is mainline, "b" and "c" are external branches being merged into "a"). --- jeff@lsblap:~/tmp/linus-file-id/a$ bzr pull ../b All changes applied successfully. 1 revision(s) pulled. jeff@lsblap:~/tmp/linus-file-id/a$ bzr pull ../c bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. jeff@lsblap:~/tmp/linus-file-id/a$ bzr merge ../c Conflict adding file file2. ...

Btw, this is a pet peeve of mine, and it is not at all restricted to the SCM world. In CompSci in general, you see a _lot_ of papers about things that almost don't matter - not because the issues are that important in practice, but because the issues are something small enough to be something you can discuss and explain without having to delve into tons of ugly detail, and because it's something that has a lot of "mental masturbation" associated with it - ie you can discuss it ...

Please configure your mailer to _not_ send emails in Multipart/Mixed form! For example it screws up GMane news<->email interface. Which git version do you use? 1063:jnareb@roke:~/git> which git-send-email /usr/bin/git-send-email 1064:jnareb@roke:~/git> rpm -qf /usr/bin/git-send-email git-email-1.4.2.1-1 1065:jnareb@roke:~/git> git --version git version 1.4.2.1 git-send-email is created from git-send-email.perl during instalation (by make install). And it works. -- Jakub ...

Hi, your email is horridly mixed here. I get an empty subject here, and the complete email header at the beginning of the email: But it does! I just removed it, and "make" remade it. I don't even see in the Makefile why it should _not_ be made... Ciao, Dscho -

From 0e3c0aefc3276bd271553d171ed9bcc52d85230e Mon Sep 17 00:00:00 2001 From: Andy Parkins <andyparkins@gmail.com> Date: Fri, 20 Oct 2006 15:21:02 +0100 Subject: [PATCH] Use email address only for looking up signing key in git-tag To: git@vger.kernel.org MIME-Version: 1.0 X-TUID: 312298ab1a3cb74a X-UID: 98 X-Length: 2046 Content-Type: Multipart/Mixed; boundary="Boundary-00=_PtNOFMGj306NIAG" Message-Id: <200610201521.03122.andyparkins@gmail.com> This is a multi-part message in MIME ...

How does it come to the result, that this is a rename? Peter -

Perhaps the cause for not having plugins in GIT (besides the fact that it follows OSS + Unix guidelines) is that git is not libified, yet. It is "scriptified", i.e. it has many helper programs, and has options for pipelining that it is really easy to use in scripts (Cogito, pg, StGit), but the libification effort is [only] ongoing. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Well, indeed, I think bug _reporting_ should be somehow centralized, while bug _fixing_ can be decentralized: You fix a bug, you mark it as fixed, and then the main branch gets the information that the bug is fixed when the bugfix is merged. -- Matthieu -

Aaron Bentley wrote: >>>

Hi, You can document your disbelief. But it does not change a thing. Since v0.99~653, we do not have any collision check, even if compiled with COLLISION_CHECK. Ciao, Dscho -

I had the same disbelief as you about this, however the last time this came up Linus pointed out something that satisfied me. any action in git that could create or or recreate an object will not overwrite an object that it thinks that it already has. so if you create a new local file that would conflict and save it, git will accept your save and throw away the new file. if you pull from a remote repository and there is a file there that conflicts with a file you already have it ...

Or you can compile git with COLLISION_CHECK From Makefile: # Define COLLISION_CHECK below if you believe that SHA1's # 1461501637330902918203684832716283019655932542976 hashes do not give you # sufficient guarantee that no collisions between objects will ever happen. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

So if you want to compare merge performance with other SCM, you should either add time to run diffstat for other SCM, or substract time to run "git diff-tree --stat". -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Oh, you mean that document that I orphaned when I got sidetracked and forgot I hadn't quite finished it? :-) -- Shawn. -

I think that GIT separation of root, repository, and branches namespaces is why there are so many calls for adding subproject support to GIT; people want to change to GIT literally, for example putting everything in one large repository. In GIT there is no concept of root, like in CVS or SVN. You can put repository anywhere. By default GIT looks for repository in current directory or one of its parents; otherwise you have to provide location of repository either by using GIT_DIR ...

I would suggest one of two things: - specify the signing entity explicitly: git tag -u "andyparkins@gmail.com" adp-sign-tag - or just add a new alternate user ID to match the full git user ID. Currently, your pgp key has the full ID "Andy Parkins (Google) <andyparkins@gmail.com>", and the way gpg matches ID's, that will _not_ match an ID of "Andy Parkins <andyparkins@gmail.com>" But you can just do something like gpg --edit-key andyparkins@gmail.com and then do an ...

Andy Parkins <andyparkins@gmail.com> wrote: There very well might be... say you have a key for signing git stuff, another one for emailing, another one for signing RPMs you create, ... I believe that is the idea of the GPG comment field, precisely. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile ...

It is not quite fair to talk as if I still have a choice. Apparently a version of GNU diff that generates new format is already in the wild (I've received such a patch which was where this thread started). Whether I like your change or not, the damage is already done and its output needs to be dealt with, so that we do not break users. Coding a workaround is not a big deal; the change is simple and trivial. It's just I am somewhat unhappy, having to do a .1 release immediately after ...

perl v5.8.7 built for cygwin-thread-multi-64int, its chomp() doesn't strip trailing "\r" so that pre-commit reports "trailing whitespace" for every line. ActiveState Perl v5.8.8 can strip "\r" and "\n" properly. Changing if (/\s$/) { to if (/[:blank:]$/) { is also ok. diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit index 723a9ef..6a55612 --- a/templates/hooks--pre-commit +++ b/templates/hooks--pre-commit @@ -54,7 +54,7 @@ perl -e ' } if ...

The code to create pixmaps is older then the one to remove not visible pixmaps. Yes, please. Thanks Marco -

Not from me. I use "git diff" just to check that the tree is empty, and the fact that it now throws me into an empty pager is irritating. That said, "LESS=FRS" doesn't really help that much. It still clears the screen. Using "LESS=FRSX" fixes that, but the alternate display sequence is actually nice _if_ the pager is used. Still, I think I'd prefer FRSX as the default. Linus -

Huh?! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 -

I think this is an excellent idea. Nicolas -

I thought about that, too. But my primary intention was to get rid of 'merge', because the Solaris boxes I use from time to time lack merge, but have (GNU) diff3[1]. I already had a mental note to look into that. If Linus is right that there are systems that have merge but lack diff3, then a combined approach is maybe the best? That is, try diff3 and if that is missing, try merge. (Or the other way round if you prefer.) OK, I looked a bit deeper into rcs, and it seems to handle the BSD ...

As they currently are you can't either. Because currently it is guaranteed that the revnos will be the same in two branches with the same current revision. But when the current revisions differ, the numbers may as well. Moreover currently they can change for the same branch over time, while with the alternate proposal they would not, so you could reliably say 1) Partial sha-1 is still longer (starts being useful at 6 digits, usually you need 8) 2) Decimal numbers are easier to remember ...

If I understand correctly, if we see an unresolvable delta, we are just making the assumption that its base has arrived (or will arrive) in the same pack (without checking). This means that we could end up with a corrupted repository if the sender gives us a bad pack. I believe that git's network interaction has been designed specifically to avoid such possibilities (e.g., verifying completeness and integrity of downloaded objects). -Peff -

That's probably because Cogito still uses obsolete branches/ $ git clone git://git.kernel.org/pub/scm/git/git.git clones _whole_ repository, all the branches and tags, and saves information I should have said: bring working area to state given by some revision (instead of "populate working area"). -- Jakub Narebski Poland -

> repository.

Hi, It does not. You can fully expect the universe to go down before that happens. The only reasonable worry is about SHA-1 being broken some time in future, i.e. being able to construct a malign version of some source code _which has the same hash_. There were plenty of discussions about that; Please search the mailing list. (The consent was that those do not matter, because an existing object will _never_ be overwritten by a fetch, so you would not get that invalid object ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In Bazaar bundles, the text of the diff is an integral part of the data. It is used to generate the text of all the files in the revision. Bazaar bundles were designed to be used on mailing lists. So you can review the changes from the diff, comment on them, and if it seems It's my understanding that most changes discussed on lkml are provided as a series of patches. Bazaar bundles are intended as a direct replacement for patches in that ...

I've been following the git-vs-bzr discussion, and I'd like to ask a question (being new to both bzr and git). How does git disambiguate SHA1 hash collisions? I think git has an alternative way to name revisions (can someone please explain it in more detail, I've seen <ref>~<n> mentioned only in passing in this thread). It seems to me collisions are a good argument in favour of having two independent naming schemes, so that you're not solely relying on hashes being unique. A strong argument ...

There are two forms of checkout: a normal checkout which contains the complete history of the branch, and a lightweight checkout, which just has a pointer back to the original location of the history. In both cases, a "bzr commit" invocation will commit changes to the remote location. In general, you only want to use a lightweight checkout when there is a fast reliably connection to the branch (e.g. if it is on the local file system, or local network). Aaron would be talking about a normal ...

Well, I thought the discussion was about what meaning references have after branches were modified or removed. In which case the interesting situation is one where an object is gone but someone somewhere still holds a reference (because the SHA1 was mentioned in a bug report or an Could be. Anyway, the important difference between the SHA1 references and small integers is that there's no aliasing in the former case. Which is important--I'd rather have a reference to nothing than a ...

Dear diary, on Sat, Oct 21, 2006 at 12:50:31AM CEST, I got a letter It's not exactly convenient, but you can do xpasky@machine[0:0]~/git$ GIT_ALTERNATE_OBJECT_DIRECTORIES=../cogito/.git/objects cg-diff -r `GIT_DIR=../cogito/.git cg-object-id -c HEAD`..HEAD I don't personally think it's worth a special UI, but there're no boundaries for initiative... :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl ...

In what sense? Yes, you can make a guess if you have stored the SHA1 that contained the launch codes. But the point is that that particular SHA1 is no longer part of the repository. Keeping that SHA1 is no easier than just keeping the launch codes in the first place. -Peff -

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Agreed. I think it's okay to require extra work to set the scm up to It would surprise me if many SCMs that support atomic commit also That's something I'd like for software development, too. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFOEsO0F+nu1YWqI0RAo+6AJ9lzF0+O1I8rgkyCOdhsir1gjo0NQCfXEVV EIsDmS+eR/7cHKQfmnPJRA4= =g5jk -----END PGP ...

Dear diary, on Fri, Oct 20, 2006 at 09:47:16AM CEST, I got a letter This is just a notion that lets you point to revisions relative to a given id. <id>~<n> means n-th ancestor of the given commit. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) -

In bzr there are two different kind of checkouts. One is a called a lightweight checkout and that's really a "normal" checkout in the way svn for example does it. In this mode, you have the branch remotely and only the working tree locally. So it's just a checkout of the branch head (of any other revision if using -r when doing the checkout). Then there are none lightweight checkouts, heavyweight checkouts. These are the default type. A heavyweight checkout is in fact a full branch ...

So the "lightweight checkout" is equivalent of "lazy clone" we have much discussed on git mailing list about (without any resulting code, unfortunately). The point of problem was how to do this fast, without need for fast reliable connection to the repository it was cloned from. For example if to leave fetched objects in some kind of cache, or even in "lightweight checkout"/"lazy clone" repository database. If repository we do "lightweight checkout"/"lazy clone" from is on local file system ...

With the above layout, I would just type: bzr branch http://server/repo/branch1 This command behaves identically whether the repository data is in /repo or in /repo/branch1. Someone pulling from the branch doesn't have to care what the repository structure is. Having a separate namespace for branch names only really makes sense if the user needs to care about it. As for heirarchical names, there is nothing stopping you from using deaper directory structures with Bazaar too. Bazaar ...

By the way "diff d8a60" also works (unless d8a60 is merge commit, in By the way, git has the following extended SHA1 syntax for <commit-ish> (documented in git-rev-parse(1)): * full SHA1 (40-chars hexadecimal string) or abbreviation unique for repository * symbolic ref name. E.g. 'master' typically means commit object referenced by $GIT_DIR/refs/heads/master; 'v1.4.1' means commit object referenced [indirectly] by $GIT_DIR/refs/tags/v1.4.1. You can say 'heads/master' and ...

Not exactly (my mistake in explaining it). "cg clone git://host/repo@branch" clones only part of history DAG of commits reachable from given branch. Still it is full repository. You can add branches to it later with That is _very_ useful. And that is default option for Git. For example with git.git repository I'm interested both in 'master' branch (main line of development), and in 'next' branch (development branch). For example I send some patches, based on 'master', they get accepted but in ...

And here we have a feature which is as far as I see unique to git, namely to have persistent branches with _separate namespace_. It means that we can have hierarchical branch names (including names like "remotes/<remotename>/<branch of remote>", or "jc/diff"), and we don't have to guess where repository name ends and branch name begins. The idea of "branches (and tags) as directories" was if I understand it correctly introduced by Subversion, and from what can be seen from troubles with ...

Ooops, I mixed git-diff-tree (which behaves as mentioned above) with git-diff, which according to documentation compares with working tree (and not HEAD) if only one <tree-ish> is given. git-diff(1): ? When one <tree-ish> is given, the working tree and the named tree are compared, using git-diff-index. The option --cached can be given to com- pare the index file and the named tree. git-diff-tree(1): If there is only one <tree-ish> given, the commit is ...

I do not personally worry about people confusing -M/-C to pickaxe with -M/-C given to diff (to pickaxe, use of diff is purely an internal implementation issue), and reused -M and -C to mean quite different things. -M is to detect line movement inside a file (it is not strictly limited to "line movement", though. It _is_ about "copies and moves within the same file"). On the other hand, -C (and its stronger form -C -C) is to detect copies and moves across file boundaries (but wholesale ...