Re: Using git to track my PhD thesis, couple of questions

seanh [off-list ref] writes:

In response to Matthieu and Paolo, I'm not sure I understand the git 
internals involved in the discussion around merge --squash, I had a 
feeling this would produce a 'merge' that git in some sense would 'not 
know about',

Yes, that's it. Git does a merge, and immediately forgets it was a
merge. The consequence is when you merge again later, Git will not be
able to use the merge information to be clever about merging. Somehow,
Git will be as bad as SVN for merging if you don't know what you're
doing ;-).

since it sounds complex and I don't understand it I don't think I
want to go there.

Well, it's fun also to learn Git notions in more details ;-).

-- 
Matthieu

Matthieu Moy schrieb:

seanh [off-list ref] writes:

quoted

In response to Matthieu and Paolo, I'm not sure I understand the git 
internals involved in the discussion around merge --squash, I had a 
feeling this would produce a 'merge' that git in some sense would 'not 
know about',

Yes, that's it. Git does a merge, and immediately forgets it was a
merge. The consequence is when you merge again later, Git will not be
able to use the merge information to be clever about merging. Somehow,
Git will be as bad as SVN for merging if you don't know what you're
doing ;-).

To be fair, SVN versions 1.5 and newer can track merges. If the repository
predates 1.5, it has to be updated on the server side (see the release notes for
details). It just tracks which revisions have been merged and which not, for
further details, see the svn book. (http://svnbook.red-bean.com/ IIRC)

Matthias Andree [off-list ref] writes:

Matthieu Moy schrieb:

quoted

seanh [off-list ref] writes:

quoted

In response to Matthieu and Paolo, I'm not sure I understand the git 
internals involved in the discussion around merge --squash, I had a 
feeling this would produce a 'merge' that git in some sense would 'not 
know about',

Yes, that's it. Git does a merge, and immediately forgets it was a
merge. The consequence is when you merge again later, Git will not be
able to use the merge information to be clever about merging. Somehow,
Git will be as bad as SVN for merging if you don't know what you're
doing ;-).

To be fair, SVN versions 1.5 and newer can track merges. If the
repository predates 1.5, it has to be updated on the server side
(see the release notes for details). It just tracks which revisions
have been merged and which not, for further details, see the svn
book. (http://svnbook.red-bean.com/ IIRC)

From what I understand (from what I have read, and browsed, and

lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
in very different way that in Git:

 * the svn:mergeinfo is client-side property; if I understand
   correctly this would help you in repeated merges, but not anyone
   other

 * svn:mergeinfo contains _per-file_ merge info, so it is much, much
   more "chatty" than Git multiple parents.  This might be more
   powerfull approach, in the same sense that more advanced merge
   strategies that 3-way merge were more powerfull -- but 3-way merge
   is best because it is simple (and either it is simple that 3-way
   merge is enough, or complicated so manual intervention is required).

 * You have to explicitely enable using svn:mergeinfo in log and blame

 * The command to merge trunk into branch is different from command to
   merge branch into trunk.

Also IIRC there is warning (well, at least there was in Subversion 1.5
release notes) that merge tracking doesn't work entirely correctly in
the face of criss-cross merges (multiple merge bases) and renaming
(although I do hope that they fixed problem with silent corruption if
there is rename during merge).

-- 
Jakub Narebski

Git User's Survey 2009: http://tinyurl.com/GitSurvey2009

On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski[off-list ref] wrote:

From what I understand (from what I have read, and browsed, and
lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
in very different way that in Git:

 * the svn:mergeinfo is client-side property; if I understand
  correctly this would help you in repeated merges, but not anyone
  other

I don't believe there is such a thing as a "client-side property" in
svn.  I see someone said this on stackoverflow
(http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent)
but I'm pretty sure they were either mistaken or using a different
definition of "client-side."

I think they probably meant that it's the client's responsibility to
set the property correctly, not the server's, and if your client is
too old any you do a merge, it'll forget to set svn:mergeinfo, causing
confusion for everyone.  There's discussion in the svn book
(http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but
nothing implies that it's a non-replicated property.  Indeed, I can
see no particular reason that anyone would want it to be, for the
reasons you specify.

 * svn:mergeinfo contains _per-file_ merge info, so it is much, much
  more "chatty" than Git multiple parents.  This might be more
  powerfull approach, in the same sense that more advanced merge
  strategies that 3-way merge were more powerfull -- but 3-way merge
  is best because it is simple (and either it is simple that 3-way
  merge is enough, or complicated so manual intervention is required).

svn people really love their cherry-picks and want to keep track of
which things get cherry picked from one branch to another.  This is
nice (at least for informational purposes) although they go through
some probably-unnecessary contortions *after* doing this, including
splitting a merge from "maint" into "master" into two sequential
merges, if you've previously cherry-picked a commit from master into
maint.  The above svn book link describes this in a bit more detail.

I don't think that behaviour would be much help in any situation I've
ever experienced, so I agree with your comment that 3-way merge is
generally better.

Tracking cherry picks in git would be really nice *sometimes*, but it
creates a tradeoff where you then have to slurp in huge amounts of
history that you might not want.  In svn, this tradeoff doesn't exist,
since anything you cherry pick must have already existed on the server
anyway, and can never go away.

 * You have to explicitely enable using svn:mergeinfo in log and blame

Conversely, in git you can basically disable it using --first-parent,
which is sometimes handy.  (It's handiest if your team has a policy of
always using --no-ff when merging into trunk, which makes git act a
bit more like svn's merge tracking.  I realize this is a bit heretical
to suggest on the git list, but I appreciate that the option exists
despite its heresy :))

Have fun,

Avery

Am 28.08.2009, 17:29 Uhr, schrieb Avery Pennarun [off-list ref]:

I think they probably meant that it's the client's responsibility to
set the property correctly, not the server's, and if your client is
too old any you do a merge, it'll forget to set svn:mergeinfo, causing
confusion for everyone.  There's discussion in the svn book
(http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but
nothing implies that it's a non-replicated property.  Indeed, I can
see no particular reason that anyone would want it to be, for the
reasons you specify.

It is replicated, and the common remedy against older clients is to refuse  
commits from those clients that do not support mergeinfo. This is done by  
defining a repository hook on the server side that validates this. AFAIR  
such a hook example ships with SVN.

-- 
Matthias Andree

On Fri, 28 Aug 2009, Avery Pennarun wrote:

On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski[off-list ref] wrote:

quoted

From what I understand (from what I have read, and browsed, and
lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
in very different way that in Git:

 * the svn:mergeinfo is client-side property; if I understand
  correctly this would help you in repeated merges, but not anyone
  other

I don't believe there is such a thing as a "client-side property" in
svn.

What about svn:ignore or svn:mimetype (IIRC) property?

I see someone said this on stackoverflow 
(http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent)
but I'm pretty sure they were either mistaken or using a different
definition of "client-side."

I think I got this (wrong?) impression from there.

quoted

 * svn:mergeinfo contains _per-file_ merge info, so it is much, much
  more "chatty" than Git multiple parents.  This might be more
  powerfull approach, in the same sense that more advanced merge
  strategies that 3-way merge were more powerfull -- but 3-way merge
  is best because it is simple (and either it is simple that 3-way
  merge is enough, or complicated so manual intervention is required).

svn people really love their cherry-picks and want to keep track of
which things get cherry picked from one branch to another.  This is
nice (at least for informational purposes) although they go through
some probably-unnecessary contortions *after* doing this, including
splitting a merge from "maint" into "master" into two sequential
merges, if you've previously cherry-picked a commit from master into
maint.  The above svn book link describes this in a bit more detail.

I don't think that behaviour would be much help in any situation I've
ever experienced, so I agree with your comment that 3-way merge is
generally better.

Errr... what I meant here that I have read (on some blog, but either
I didn't bookmark it, or I can't find the bookmark) that svn:mergeinfo
is not as simple as listing _revisions_ which are merged (i.e. either
all parents, or additional parent), but it lists per-file merge 
information, and can be quite large.
 

quoted

 * You have to explicitely enable using svn:mergeinfo in log and blame

Conversely, in git you can basically disable it using --first-parent,
which is sometimes handy. [...]

In git-log.  But in git-blame?

-- 
Jakub Narebski
Poland

[culling most of Cc: list]

Am 28.08.2009, 18:19 Uhr, schrieb Jakub Narebski [off-list ref]:

On Fri, 28 Aug 2009, Avery Pennarun wrote:

quoted

On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski[off-list ref] wrote:

quoted

quoted

From what I understand (from what I have read, and browsed, and
lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
in very different way that in Git:

 * the svn:mergeinfo is client-side property; if I understand
  correctly this would help you in repeated merges, but not anyone
  other

I don't believe there is such a thing as a "client-side property" in
svn.

What about svn:ignore or svn:mimetype (IIRC) property?

All this is committed to the repository, so there isn't a question of if  
it's client-side in a sense of "local to the client/checkout". Some  
properties (such as svn:mergeinfo) require a bit of additional server-side  
support, but that's about it.

Oh, and to complicate matters, let me mention revprops (such as  
svn:log).   SCNR :^)

-- 
Matthias Andree

On Fri, Aug 28, 2009 at 4:19 PM, Jakub Narebski[off-list ref] wrote:

On Fri, 28 Aug 2009, Avery Pennarun wrote:

quoted

On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski[off-list ref] wrote:

quoted

 * You have to explicitely enable using svn:mergeinfo in log and blame

Conversely, in git you can basically disable it using --first-parent,
which is sometimes handy. [...]

In git-log.  But in git-blame?

I don't know about git-blame, as I rarely use it.  If it doesn't
support --first-parent, I imagine it would be easy to add, if it were
important to someone.

Avery

On Fri, 28 Aug 2009, Matthieu Moy wrote:

seanh [off-list ref] writes:

quoted

In response to Matthieu and Paolo, I'm not sure I understand the git
internals involved in the discussion around merge --squash, I had a
feeling this would produce a 'merge' that git in some sense would 'not
know about',

Yes, that's it. Git does a merge, and immediately forgets it was a
merge. The consequence is when you merge again later, Git will not be
able to use the merge information to be clever about merging. Somehow,
Git will be as bad as SVN for merging if you don't know what you're
doing ;-).

I thought that was what rere did?

David Lang

On Fri, 2009-08-28 at 08:12 -0700, Jakub Narebski wrote:

 * svn:mergeinfo contains _per-file_ merge info, so it is much, much
   more "chatty" than Git multiple parents.

It can.  But more often, if you're merging complete paths, you will get
complete revision ranges.

See eg
https://trac.parrot.org/parrot/browser/trunk

Note how trac is also hiding the branches that were subsequently deleted
from the mergeinfo ticket.

 * The command to merge trunk into branch is different from command to
   merge branch into trunk.

This is a caveat of url-based branches.

Also IIRC there is warning (well, at least there was in Subversion 1.5
release notes) that merge tracking doesn't work entirely correctly in
the face of criss-cross merges (multiple merge bases) and renaming
(although I do hope that they fixed problem with silent corruption if
there is rename during merge).

Not sure about that one.  I also heard - unconfirmed - that things start
to go awry if you start branching off branches and merging around the
place.  But if that happens it's likely a bug rather than a design flaw
(I think).

Sam

On Mon, Aug 31, 2009 at 07:41:56AM +1200, Sam Vilain wrote:

On Fri, 2009-08-28 at 08:12 -0700, Jakub Narebski wrote:

quoted

Also IIRC there is warning (well, at least there was in Subversion 1.5
release notes) that merge tracking doesn't work entirely correctly in
the face of criss-cross merges (multiple merge bases) and renaming
(although I do hope that they fixed problem with silent corruption if
there is rename during merge).

Not sure about that one.  I also heard - unconfirmed - that things start
to go awry if you start branching off branches and merging around the
place.  But if that happens it's likely a bug rather than a design flaw
(I think).

Some of the initial issues that existed in SVN 1.5.0 have been resolved,
but some others remain. Here is one bug report related to merge:
http://subversion.tigris.org/issues/show_bug.cgi?id=2897
It was reported two years ago, but the problem is still not fixed.
And there is a few others (some of them even older but even with less
prospect of being fixed any time soon):
http://subversion.tigris.org/issues/show_bug.cgi?id=2837
http://subversion.tigris.org/issues/show_bug.cgi?id=2898
http://subversion.tigris.org/issues/show_bug.cgi?id=3056
http://subversion.tigris.org/issues/show_bug.cgi?id=3157

I don't think they would exist for long if they were ease to fix.  Merge
in Subversion is essence automatic cherry-picking, and it is not easy to
implement that in the way it would be reasonably fast and work correctly
in a general case.

Darcs is probably the best when it comes to cherry-picking but clearly
it is not a speed demon. In case of Subversion, the problem is worse,
because it has to make decision on a per file basis rather than operate
each patch as a unit. So, it is even more difficult to implement that
correctly and efficiently.

What you can do relatively simple is to handle a of one directional
merge, and that was the primary design goal of Subversion merge
tracking feature.

Here is what Daniel Berlin wrote about it:
<<<
The initial merge tracking implementation was not meant to handle
repeated bidirectional merging, at least, as designed.

It was designed to allow cherry picks, and mainly for maintaining
feature branches that were mostly one way merges, with the very
occasional merge in the other direction and then branch death :).

For these cases, it works out fine.

For more complex cyclical merge patterns, you really can't use what
we've got. Trying to work around these cases, or build algorithms
that handle them, is just going to lead you into 20 years of edge
cases that made people come up with changeset dags in the first place.

quoted

quoted

Source: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=892215

So, I do not think that SVN merge will ever work correctly for those
edge cases.

But even if Subversion learns how to handle all those complex cases
correctly, it will still come with some surprises. One of the main
advantage of the simple 3-way merge is that it is easy to understand
and it makes the right thing most of time. Linus provided a really good
explanation of it here:
http://thread.gmane.org/gmane.comp.version-control.git/60457/focus=60644


Dmitry