On Tue, Oct 1, 2013 at 6:07 AM, Eric Wong wrote:
> Johan Herland 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
Johan Herland 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 risk of
> clobb
The "next" and "prev" buttons are lacking consistency and logic. For RTL
languages previous is almost always on the left, and next on the right.
The words are contradictory, "next" actually goes to backwards
chronologically, and "prev" goes forward. Could the positions of the
buttons be switche
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 ma
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 exp
On Tue, Oct 1, 2013 at 2:33 AM, Jonathan Nieder 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 for the no
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
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 wha
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 (e
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.
On Thu, Aug 22, 2013 at 11:02 AM, Thomas Ferris Nicolaisen
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. Although I'm not
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
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 colli
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
>
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 lik
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 t
On Mon, Sep 30, 2013 at 7:00 PM, René Scharfe 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 1f10
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 -W
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 fo
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,
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"
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 war
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 sig
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
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 i
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 trac
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
> s
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
>> wrote:
>> [...]
>>> * How would somebody (e.g., an interim maintainer) suck down tags from
>>> a project into his own refs/tags/* namespace? (Wou
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.
29 matches
Mail list logo