> On Mon, May 13, 2013 at 12:23 PM, Andreas Krey <a.k...@gmx.de> wrote: > > On Mon, 13 May 2013 11:32:13 +0000, Les Mikesell wrote: > > ... > >> Maybe it is just my misconception, but I've always thought of the > >> difference between svn and git as being that svn conceptually tracks > >> complete revisions although sometimes it might generate or store > >> differences for some operations or internal storage convenience, > >> where git tracks changesets although it often has to generate > >> complete revisions. > > > > That indeed is just a misconception. git even goes to define exactly > > how each commit (aka revision) is stored including its checksum. > > This even though is it then going to internally store that in a dense > > packfile format. > > What it computes internally or uses as an internal storage isn't quite the > point. > Svn would also always compute the differences even though > it really only cares about the full revisions. What does git do if > you try to double-merge a change? Does it know about the previous merge by > its changeset commit id, look at the contents that are already present, or > just > do it twice?
Been a while since I have really got into the git internals, but I think each changeset has a SHA1 hash... if a changeset with that hash is already in a branch merging won't do anything... there will be nothing to merge. That said, I don't even think you can specify in git "what" to merge it just merges all the changes. I think it is possible to do a cherry-pick, but I think that creates a diff basically and applies that to the target. BOb > > >> The nature of branches seems to relate better to > > > > No, the basic difference is that VCS operating on the whole tree can > > only have branches (and thus merge info) on the whole tree either, so > > you *can't* go like subversion does and map branches into the tree and > > need to have them (and tags) as a separate concept. > > I can see why it might be a problem to support concurrent nested branch > changeset roots but that scenario is problematic any way you look at it. Why > would it be a problem to support parallel branching roots - perhaps with some > enforcement on the source/dest top levels having some common parent? > > > SVN, instead of having branches as a separate concept, also stores > > whole trees, but instead additionally stores 'this came from there' or > > 'that was merged here' as a separate concept. > > But does 'that was merged here', really know about the commit changeset > where the change originated? > > -- > Les Mikesell > lesmikes...@gmail.com
