When parsing a commit object, git-svn wrongly think that a line
containing spaces means the end of headers and the start of the commit
message. In case of signed commit, the gpgsig entry contains a line with
one space, so git svn dcommit will include part of the signature in
the commit message.
On 13-09-29 12:29 AM, Michael Haggerty wrote:
On 09/28/2013 11:42 PM, Johan Herland wrote:
On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
[...]
* How would somebody (e.g., an interim maintainer) suck down tags from
a project into his own refs/tags/*
On Mon, 30 Sep 2013, Marc Branchaud wrote:
Why would there be ambiguity warnings? The fetch command shouldn't issue any
warnings, since all the remotes' names get safely tucked away in distinct
namespaces.
Are we talking about DWIM warnings? Aside from git-describe I don't see why
such
On 17.07.2013 15:33, John Keeping wrote:
On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote:
I'm looking for a specification or guidelines on how a Git client should
integrate with bug tracking systems. For SVN, one can use
bugtraq-properties [1] to specify e.g. the issue tracker
Am 29.09.2013 04:56, schrieb Wataru Noguchi:
Hi,
Thanks for comments.
My currently working repository is
https://github.com/wnoguchi/git/tree/hotfix/mingw-multibyte-path-checkout-failure
I have revert commits to 1f10da3.
I'll try failure step.
- gcc optimization level is O2.(fail)
Hi,
Marc Strapetz wrote:
On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote:
I'm looking for a specification or guidelines on how a Git client should
integrate with bug tracking systems.
[...]
Finally, I've created a minimal spec which is sufficient to parse and
display issue
Nicolas Vigier wrote:
When parsing a commit object, git-svn wrongly think that a line
containing spaces means the end of headers and the start of the commit
message. In case of signed commit, the gpgsig entry contains a line with
one space, so git svn dcommit will include part of the
On 13-09-30 11:52 AM, Nicolas Pitre wrote:
On Mon, 30 Sep 2013, Marc Branchaud wrote:
Why would there be ambiguity warnings? The fetch command shouldn't issue any
warnings, since all the remotes' names get safely tucked away in distinct
namespaces.
Are we talking about DWIM warnings?
Keshav Kini wrote:
Keshav Kini (4):
git-svn.txt: fix AsciiDoc formatting error
git-svn.txt: reword description of gc command
git-svn.txt: replace .git with $GIT_DIR
git-svn.txt: elaborate on rev_map files
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the
Michael Haggerty wrote:
That being said, independent of aliases, there are many other config
settings that can affect commands that might be used in documentation or
scripts, and which also could be the source of errors for the non-vigilent.
Yep, this is a problem, too (I'm looking at you,
On Mon, 30 Sep 2013, Marc Branchaud wrote:
On 13-09-30 11:52 AM, Nicolas Pitre wrote:
Consider that I have in my Linux kernel tree:
- a remote branch corresponding to Linus' master tree
- multiple remote branches corresponding to Linux stable branches
- a remote for linux-next
On Sun, Sep 29, 2013 at 12:00:17PM -0700, Jonathan Nieder wrote:
--- a/Makefile
+++ b/Makefile
@@ -349,7 +349,7 @@ GIT-VERSION-FILE: FORCE
# CFLAGS and LDFLAGS are for the users to override from the command line.
-CFLAGS = -g -O2 -Wall
+CFLAGS = -g -O2 -Wall
On Mon, Sep 30, 2013 at 7:00 PM, René Scharfe l@web.de wrote:
Am 29.09.2013 04:56, schrieb Wataru Noguchi:
Hi,
Thanks for comments.
My currently working repository is
https://github.com/wnoguchi/git/tree/hotfix/mingw-multibyte-path-checkout-failure
I have revert commits to 1f10da3.
On 13-09-30 04:08 PM, Nicolas Pitre wrote:
On Mon, 30 Sep 2013, Marc Branchaud wrote:
On 13-09-30 11:52 AM, Nicolas Pitre wrote:
Consider that I have in my Linux kernel tree:
- a remote branch corresponding to Linus' master tree
- multiple remote branches corresponding to Linux stable
Jeff King wrote:
I think we'd be better off to
simply mark up the few callsites. Workarounds are here:
http://article.gmane.org/gmane.comp.version-control.git/230026
Yeah, that looks okay (ugly but tolerable). It's tempting to do
something like
On Mon, Sep 30, 2013 at 02:26:36PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
I think we'd be better off to
simply mark up the few callsites. Workarounds are here:
http://article.gmane.org/gmane.comp.version-control.git/230026
Yeah,
Kirill A. Shutemov wrote:
collapse_todo_ids() uses `git rev-parse --short=7' to abbrev commit ids.
Let's drop argument from --short to use default (7) or config value
instead.
Since the todo ids are expanded immediately after the editor exits,
there is not much risk of accidental hash
On 09/30/2013 10:14 PM, Jeff King wrote:
On Sun, Sep 29, 2013 at 12:00:17PM -0700, Jonathan Nieder wrote:
--- a/Makefile
+++ b/Makefile
@@ -349,7 +349,7 @@ GIT-VERSION-FILE: FORCE
# CFLAGS and LDFLAGS are for the users to override from the command line.
-CFLAGS = -g -O2 -Wall
On Thu, Aug 22, 2013 at 11:02 AM, Thomas Ferris Nicolaisen
tfn...@gmail.com wrote:
I've recently been forced back into using git-svn, and while I was at
it, I noticed that git-svn generally behaves a lot better when it is
initialized using the --prefix option.
Thanks for raising this issue.
On Mon, 30 Sep 2013, Marc Branchaud wrote:
On 13-09-30 04:08 PM, Nicolas Pitre wrote:
Again, in the cases where there is actually a SHA1 conflict between all
possible tags that match a tag short-end then listing them and asking the
user to be more explicit is the right thing to do. But
git-svn by default puts its Subversion-tracking refs directly in
refs/remotes/*. This runs counter to Git's convention of using
refs/remotes/$remote/* for storing remote-tracking branches.
Furthermore, combining git-svn with regular git remotes run the risk of
clobbering refs under refs/remotes
On Mon, Sep 30, 2013 at 06:44:09PM -0400, Nicolas Pitre wrote:
Again, I don't think that's the common case. I think it's just as likely
for
there to be multiple remotes with duplicate tag names that refer to
different
objects.
Why do you say so? I'm curious to know what kind of
On Mon, Sep 30, 2013 at 11:38:33PM +0200, Stefan Beller wrote:
To be honest, I'm surprised that -Wall doesn't create problems for
older cc implementations. We've had patches for compiling with
antique SUNWspro and MIPSpro compilers, and I sort of assumed that those
don't handle -Wall. But
On Tue, Oct 1, 2013 at 2:33 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Michael Haggerty wrote:
That being said, independent of aliases, there are many other config
settings that can affect commands that might be used in documentation or
scripts, and which also could be the source of errors
On 13-09-30 06:44 PM, Nicolas Pitre wrote:
On Mon, 30 Sep 2013, Marc Branchaud wrote:
On 13-09-30 04:08 PM, Nicolas Pitre wrote:
Again, in the cases where there is actually a SHA1 conflict between all
possible tags that match a tag short-end then listing them and asking the
user to be more
On Mon, 30 Sep 2013, Marc Branchaud wrote:
On 13-09-30 06:44 PM, Nicolas Pitre wrote:
On Mon, 30 Sep 2013, Marc Branchaud wrote:
On 13-09-30 04:08 PM, Nicolas Pitre wrote:
Again, in the cases where there is actually a SHA1 conflict between all
possible tags that match a tag
Johan Herland jo...@herland.net wrote:
git-svn by default puts its Subversion-tracking refs directly in
refs/remotes/*. This runs counter to Git's convention of using
refs/remotes/$remote/* for storing remote-tracking branches.
Furthermore, combining git-svn with regular git remotes run the
27 matches
Mail list logo
