> On Mon, May 13, 2013 at 12:23 PM, Andreas Krey <a.krey_at_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
> lesmikesell_at_gmail.com
Received on 2013-05-13 20:36:08 CEST