Dear git Developers,
Apologies if this is not the right forum for bug reports. I was unable
to find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor
some "proper procedure" on the git web page.
I have been (ab)using git-svn for committing to a central SVN
repository while doing my work locally with git. To this end, I've
written a set of scripts and hooks which perform squash merges locally
and then dcommit them with proper svn:mergeinfo annotations. The final
result is the perfect appearance of having done a native SVN merge in
the central repository, while using only local git commands and
gaining the full benefit of git's conflict resolution and developer
convenience.
However, to make this work with git 1.7.6, I needed to make *one* change
to the git internals: --merge-info does not allow setting mergeinfo for
more than one branch. Because it's a complete overwrite operation
instead of an update, this is a serious issue preventing its use for
nontrivial branches.
Might I suggest adding a block like the following around line 552 of
git-svn?
if (defined($_merge_info))
{
$_merge_info =~ tr{ }{\n};
}
This will replace any spaces in --merge-info with newlines, allowing
specification of an svn:mergeinfo that contains merges from more than a
singe branch. So the user can provide "--merge-info
'/branch1:r2323-3849,r8888 /branch2:r9999'" and the like.
Thank you for your consideration. I am not subscribed to this list, so
if there are any replies, please copy my address.
Bryan Jacobs
From: Jeff King <hidden> Date: 2016-06-15 22:51:56
On Mon, Aug 29, 2011 at 01:20:52PM -0400, Bryan Jacobs wrote:
Dear git Developers,
Apologies if this is not the right forum for bug reports. I was unable
to find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor
some "proper procedure" on the git web page.
Yes, this is the right place. This question seems to be coming up a lot
lately. And indeed, looking at the webpage and the wiki, we are not very
clear that the mailing list is the place for such things.
Do you mind telling us where you looked? That will give us at least one
spot that we know should be more clear. :)
In the meantime, I've updated:
1. The GitCommunity wiki page to mention that bug reports should go
to the list.
2. Added an entry "How do I report a bug in git?" to the FAQ on the
wiki.
3. Sent Scott a patch for git-scm.org to mention bug reporting under
the big "Got questions" banner on the front page that points people
to the mailing list. Pull request is here:
https://github.com/schacon/gitscm/pull/11
It may make sense to have a specific page on reporting bugs, and
link to it via a bigger "how to report bugs" somewhere on the front
page of git-scm.org.
-Peff
On Mon, 29 Aug 2011 15:26:18 -0400
Jeff King [off-list ref] wrote:
On Mon, Aug 29, 2011 at 01:20:52PM -0400, Bryan Jacobs wrote:
quoted
Dear git Developers,
Apologies if this is not the right forum for bug reports. I was
unable to find a Bugzilla/Redmine/Flyspray instance for issue
maintenance, nor some "proper procedure" on the git web page.
Yes, this is the right place. This question seems to be coming up a
lot lately. And indeed, looking at the webpage and the wiki, we are
not very clear that the mailing list is the place for such things.
Do you mind telling us where you looked? That will give us at least
one spot that we know should be more clear. :)
I looked at the git-scm.com main page, the "documentation" sub-page,
the wiki front page, and googled the site for terms like "issue tracker"
and "bug reports", then read the FAQ.
In the meantime, I've updated:
1. The GitCommunity wiki page to mention that bug reports should go
to the list.
2. Added an entry "How do I report a bug in git?" to the FAQ on the
wiki.
3. Sent Scott a patch for git-scm.org to mention bug reporting under
the big "Got questions" banner on the front page that points
people to the mailing list. Pull request is here:
https://github.com/schacon/gitscm/pull/11
It may make sense to have a specific page on reporting bugs, and
link to it via a bigger "how to report bugs" somewhere on the
front page of git-scm.org.
Thank you very much for your efforts. It looks like you hit all but one
of the places I looked. I agree that having a link from some part of the
git-scm landing page would make sense, that's common practice for
software projects and seems to me a logical place for it. I (obviously)
read the text under the "got questions" bit; it was what sent me to
this list. If it had said "report a bug here" I would have felt more
confident about sending this message.
Bryan Jacobs
Heya,
On Mon, Aug 29, 2011 at 19:20, Bryan Jacobs [off-list ref] wrote:
Apologies if this is not the right forum for bug reports. I was unable
to find a Bugzilla/Redmine/Flyspray instance for issue maintenance, nor
some "proper procedure" on the git web page.
This is indeed the correct way of reporting bugs :).
However, to make this work with git 1.7.6, I needed to make *one* change
to the git internals: --merge-info does not allow setting mergeinfo for
more than one branch. Because it's a complete overwrite operation
instead of an update, this is a serious issue preventing its use for
nontrivial branches.
Might I suggest adding a block like the following around line 552 of
git-svn?
if (defined($_merge_info))
{
$_merge_info =~ tr{ }{\n};
}
This will replace any spaces in --merge-info with newlines, allowing
specification of an svn:mergeinfo that contains merges from more than a
singe branch. So the user can provide "--merge-info
'/branch1:r2323-3849,r8888 /branch2:r9999'" and the like.
Why not submit this as a proper patch [0] to the list, I reckon Eric
(cc-ed, the maintainer of git-svn) wouldn't mind including it.
Thank you for your consideration. I am not subscribed to this list, so
if there are any replies, please copy my address.
On Wed, 31 Aug 2011 15:59:26 +0200
Sverre Rabbelier [off-list ref] wrote:
Why not submit this as a proper patch [0] to the list, I reckon Eric
(cc-ed, the maintainer of git-svn) wouldn't mind including it.
I have submitted a patch, following your conventions as best I could. I
forgot the CC line, sorry Eric!
There was an inaccurate line in the documentation concerning the
svn:mergeinfo property ("git-svn does not currently make use of this")
which I clobbered with my documentation change. I did not document the
whole of how "git svn fetch" deals with the property, but this should
probably be done at some point.
Side notes: It may also be productive to automatically set mergeinfo
when all parents of a merge commit have git-svn-info annotations, but I
have not done this (as I said earlier, I use scripts external to git
for this task). Finally, I am uncertain why the git-svn-info lines are
stored in commit bodies instead of as notes; a notes-based approach
would not involve commit hashes changing when they are pushed to an
upstream SVN server.
Thanks all,
Bryan Jacobs
Heya,
On Wed, Aug 31, 2011 at 18:55, Bryan Jacobs [off-list ref] wrote:
Finally, I am uncertain why the git-svn-info lines are
stored in commit bodies instead of as notes
Hysterical raisins mostly. I think git-notes predates git-svn by
several years :). I suspect that if someone would wade through the
mess that is git-svn.perl and tought it to (optionally) use git-notes
instead of commit messages that would be highly welcome.
--
Cheers,
Sverre Rabbelier
From: Michael Haggerty <hidden> Date: 2016-06-15 22:51:57
On 08/29/2011 07:20 PM, Bryan Jacobs wrote:
I have been (ab)using git-svn for committing to a central SVN
repository while doing my work locally with git. To this end, I've
written a set of scripts and hooks which perform squash merges locally
and then dcommit them with proper svn:mergeinfo annotations. The final
result is the perfect appearance of having done a native SVN merge in
the central repository, while using only local git commands and
gaining the full benefit of git's conflict resolution and developer
convenience.
However, to make this work with git 1.7.6, I needed to make *one* change
to the git internals: --merge-info does not allow setting mergeinfo for
more than one branch. Because it's a complete overwrite operation
instead of an update, this is a serious issue preventing its use for
nontrivial branches.
Might I suggest adding a block like the following around line 552 of
git-svn?
if (defined($_merge_info))
{
$_merge_info =~ tr{ }{\n};
}
Naive question: why can't you pass a newline (properly quoted, of
course) directly within the string argument to the --mergeinfo option?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
On Thu, 01 Sep 2011 10:59:51 +0200
Michael Haggerty [off-list ref] wrote:
On 08/29/2011 07:20 PM, Bryan Jacobs wrote:
quoted
I have been (ab)using git-svn for committing to a central SVN
repository while doing my work locally with git. To this end, I've
written a set of scripts and hooks which perform squash merges
locally and then dcommit them with proper svn:mergeinfo
annotations. The final result is the perfect appearance of having
done a native SVN merge in the central repository, while using only
local git commands and gaining the full benefit of git's conflict
resolution and developer convenience.
However, to make this work with git 1.7.6, I needed to make *one*
change to the git internals: --merge-info does not allow setting
mergeinfo for more than one branch. Because it's a complete
overwrite operation instead of an update, this is a serious issue
preventing its use for nontrivial branches.
Might I suggest adding a block like the following around line 552 of
git-svn?
if (defined($_merge_info))
{
$_merge_info =~ tr{ }{\n};
}
Naive question: why can't you pass a newline (properly quoted, of
course) directly within the string argument to the --mergeinfo option?
The only way I know of to do that in bash is to assign the
newline-bearing string to a variable, and then use the variable in a
command line option. Extremely awkward.
I think the long-term solution for this issue is probably to have
git-svn populate the mergeinfo on its own, reducing the need for
users manipulating the value directly. This could in theory be done for
both cherry picks and merges, provided that the merge was --no-ff or
bears a body (so there is a commit object to carry the property
change) and both parents are tagged with SVN revs at the time the merge
is dcommitted (or, correspondingly, that the cherry-pick source carries
an SVN revision number). I will send patches for some to all of this
shortly as I pull my bash scripts into git-svn.perl and clean up the
code.
The cost of the automatic svn:mergeinfo pushing will be an SVN property
retrieval before each dcommit operation. I plan to have this behavior
disabled by default.
Bryan Jacobs
From: Carlos Martín Nieto <hidden> Date: 2016-06-15 22:51:59
On Thu, 2011-09-01 at 10:43 -0400, Bryan Jacobs wrote:
On Thu, 01 Sep 2011 10:59:51 +0200
Michael Haggerty [off-list ref] wrote:
quoted
On 08/29/2011 07:20 PM, Bryan Jacobs wrote:
quoted
I have been (ab)using git-svn for committing to a central SVN
repository while doing my work locally with git. To this end, I've
written a set of scripts and hooks which perform squash merges
locally and then dcommit them with proper svn:mergeinfo
annotations. The final result is the perfect appearance of having
done a native SVN merge in the central repository, while using only
local git commands and gaining the full benefit of git's conflict
resolution and developer convenience.
However, to make this work with git 1.7.6, I needed to make *one*
change to the git internals: --merge-info does not allow setting
mergeinfo for more than one branch. Because it's a complete
overwrite operation instead of an update, this is a serious issue
preventing its use for nontrivial branches.
Might I suggest adding a block like the following around line 552 of
git-svn?
if (defined($_merge_info))
{
$_merge_info =~ tr{ }{\n};
}
Naive question: why can't you pass a newline (properly quoted, of
course) directly within the string argument to the --mergeinfo option?
The only way I know of to do that in bash is to assign the
newline-bearing string to a variable, and then use the variable in a
command line option. Extremely awkward.
You can also save the mergeinfo to a file, add the line, and use
--mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
blindly replacing every space with a newline is not always the right
option. If a merged directory contains a space, this change will break
the mergeinfo, even if you're properly quoting your variable or using
the $(cat /some/file) method.
Cheers,
cmn
On Tue, 06 Sep 2011 14:56:38 +0200
Carlos Martín Nieto [off-list ref] wrote:
You can also save the mergeinfo to a file, add the line, and use
--mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
blindly replacing every space with a newline is not always the right
option. If a merged directory contains a space, this change will break
the mergeinfo, even if you're properly quoting your variable or using
the $(cat /some/file) method.
Cheers,
cmn
Ah, a situation I neglected to consider! Perhaps we should revert this
patch, since I worked up the initiative to write an
auto-populating-mergeinfo patch for git-svn anyhow.
Bryan Jacobs
From: Carlos Martín Nieto <hidden> Date: 2016-06-15 22:51:59
On Tue, 2011-09-06 at 09:52 -0400, Bryan Jacobs wrote:
On Tue, 06 Sep 2011 14:56:38 +0200
Carlos Martín Nieto [off-list ref] wrote:
quoted
You can also save the mergeinfo to a file, add the line, and use
--mergeinfo=$(cat /tmp/some-file) to set it. It is indeed awkward, but
blindly replacing every space with a newline is not always the right
option. If a merged directory contains a space, this change will break
the mergeinfo, even if you're properly quoting your variable or using
the $(cat /some/file) method.
Cheers,
cmn
Ah, a situation I neglected to consider! Perhaps we should revert this
patch, since I worked up the initiative to write an
auto-populating-mergeinfo patch for git-svn anyhow.
As it can cause regressions, I think reverting is the right option. And
since git-svn is going to learn to do it by itself, the functionality
isn't a big loss.
Cheers,
cmn