>
> Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
> (as can be seen in the corresponding release note where 'GIT' was
> changed to 'Git' in the header line).
>
> Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
> Git system. So change every occurren
Ramsay Jones wrote:
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -85,12 +85,6 @@
> #define _NETBSD_SOURCE 1
> #define _SGI_SOURCE 1
>
> -#ifdef WIN32 /* Both MinGW and MSVC */
> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> -#include
> -#include
> -#en
On 20.01.13 11:10, Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -85,12 +85,6 @@
>> #define _NETBSD_SOURCE 1
>> #define _SGI_SOURCE 1
>>
>> -#ifdef WIN32 /* Both MinGW and MSVC */
>> -#define WIN32_LEAN_AND_MEAN /* stops windows.h i
On Sat, Jan 19, 2013 at 05:31:35PM -0800, David Aguilar wrote:
> On Sat, Jan 19, 2013 at 4:01 AM, John Keeping wrote:
>> Since Pyhton
>> 2.8 will never exist [1]
>
> Tiny typo: Python misspelled as Pyhton
Thanks. v2 on its way.
John
--
To unsubscribe from this list: send the line "unsubscrib
Torsten Bögershausen wrote:
> I wonder, if if we can go one step further:
>
> Replace
> #ifdef WIN32 /* Both MinGW and MSVC */
[...]
> with
> #if defined(_MSC_VER)
I thought Git for Windows was built using mingw, which doesn't define
_MSC_VER?
Puzzled,
Jonathan
--
To unsubscribe from this list:
git-p4 supports Python 2.6 and later versions of Python 2. Since Python
2.8 will never exist [1], it is most concise to just list the supported
versions.
[1] http://www.python.org/dev/peps/pep-0404/
Signed-off-by: John Keeping
Acked-by: Pete Wyckoff
---
Since v1:
- Fixed a typo in the commit
Hi Ping,
Ping Yin wrote:
> Following setup works for me in ubuntu (10.04,11.04) for a long time
>
> alias gtlg='git log'
> complete -o default -o nospace -F _git_log gtlg
>
> However, in debian (testing, wheezy), it doesn't work
>
> $ gtlg or
> gtlg or-bash: [: 1: unary operator expected
> -bash
Thomas Ackermann writes:
> The whole point of my patch is to use 'Git' consistently when
> we are talking about the system and not the individual command.
I like the idea. "git" should obviously remain lower-case when talking
about the command, but deserves a capital when talking about the
soft
- The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
(starting with 1.8.0) in order to make clear that this one has special
support for git and prevent confusion with the TortoiseSVN TortoiseMerge
version.
- The tortoisemerge mergetool does not work with filenames which ha
Jonathan Nieder writes:
> Eric James Michael Ritz wrote:
>
>> When I came to my senses and realized that does not work I began to
>> wonder if `git rm -u` should exist. If any deleted, tracked files are
>> not part of the index to commit then `git rm -u` would add that change
>> to the index.
>
Thomas Ackermann writes:
>> Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
>> (as can be seen in the corresponding release note where 'GIT' was
>> changed to 'Git' in the header line).
>>
>> Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
>> Git syst
Hi Chris,
On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
> These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
> tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent
> to Eric (fixes revision map.)
Did you post the fix for the revision map pub
This series does enough so that everything except git-p4 runs under
Python 3.
As discussed with Pete, it may not make sense to change git-p4 to
support Python 3 until Perforce's Python output mode is changed. So
doe
Change inline Python to call "print" as a function not a statement.
This is harmless because Python 2 will see the parentheses as redundant
grouping but they are necessary to run this code with Python 3.
Signed-off-by: John Keeping
---
git_remote_helpers/Makefile | 2 +-
1 file changed, 1 inser
Although 2to3 will fix most issues in Python 2 code to make it run under
Python 3, it does not handle the new strict separation between byte
strings and unicode strings. There is one instance in
git_remote_helpers where we are caught by this, which is when reading
refs from "git for-each-ref".
Fi
When different version of python are used to build via distutils, the
behaviour can change. Detect changes in version and pass --force in
this case.
Signed-off-by: John Keeping
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files changed, 8 insertions(+),
Using the approach detailed in the Python documentation[1], run 2to3 on
the code as part of the build if building with Python 3.
The code itself requires no changes to convert cleanly.
[1] http://docs.python.org/3.3/howto/pyporting.html#during-installation
Signed-off-by: John Keeping
Acked-by:
The changes to allow this script to run with Python 3 are minimal and do
not affect its functionality on the versions of Python 2 that are
already supported (2.4 onwards).
Signed-off-by: John Keeping
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method to hex
bytes so that we don't need to worry about failures to encode that might
occur if we chose a textual encoding.
This changes the directory used by git-remote-t
Python 3 forbids unbuffered I/O in text mode. Change the reading of
stdin in git-remote-testpy so that we read the lines as bytes and then
decode them a line at a time.
This allows us to keep the I/O unbuffered in order to avoid
reintroducing the bug fixed by commit 7fb8e16 (git-remote-testgit: f
This is harmless in Python 2, which sees the parentheses as redundant
grouping, but is required for Python 3. Since this is the only change
required to make this script just run under Python 3 without needing
2to3 it seems worthwhile.
The case of an empty print must be handled specially because i
Hi there,
I find the fixup command during an interactive rebase useful.
Sometimes when cleaning up a branch, I end up in a situation like this:
pick 07bc3c9 Good commit.
pick 1313a5e Commit to fixup into c2f62a3.
pick c2f62a3 Another commit.
So, I have to reorder the commits, and change 13
On Sun, Jan 20, 2013 at 03:05:18PM +0100, Stephen Kelly wrote:
> I find the fixup command during an interactive rebase useful.
>
> Sometimes when cleaning up a branch, I end up in a situation like this:
>
> pick 07bc3c9 Good commit.
> pick 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 A
John Keeping wrote:
>> Any thoughts on that?
>
> Are you aware of the "--autosqush" option to git-rebase (and the
> "rebase.autosquash" config setting)? I find that using that combined
> with the "--fixup" option to git-commit makes this workflow a lot more
> intuitive.
Yes, I'm aware of it, but
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping wrote:
> Hi Chris,
>
> On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
>> These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
>> tests in t9600 fail, one of which is fixed w/ a cvsps patch I've sent
>> to Eric (fixes
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping wrote:
>> On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
>>> These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
>>> tests in t9600 fail, one of which
"Dmitry V. Levin" writes:
> Personally I prefer 2nd edition that is simpler and does the right thing
> (not that LC_ALL=C is necessary and sufficient, you neither need to add
> things like LANG=C nor can relax it to LC_TIME=C).
I guess everybody involved is in agreement, then.
Just FYI, "LC_ALL
Jeff King writes:
>> [uploadPack]
>> hiderefs = refs/changes
>
> Would you want to do the same thing on receive-pack? It could benefit
> from the same reduction in network cost (although it tends to be invoked
> less frequently than upload-pack).
Do *I* want to do? Not when th
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> Should the client side learn how to list hidden refs too? I'm thinking
>> of an extreme case where upload-pack advertises nothing (or maybe just
>> refs/heads/master) and it's up to the client to ask for the ref
>> selection it's interested in. up
David Aguilar writes:
> On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann wrote:
>> @@ -55,7 +55,7 @@ History Viewers
>>
>> - *gitweb* (shipped with git-core)
>>
>> - GITweb provides full-fledged web interface for GIT repositories.
>> + GITweb provides full-fledged web interface for Git
Nguyễn Thái Ngọc Duy writes:
> + /*
> + * If it has the same content that we are going to write down,
write down???
> + * there's no point in complaining. We still overwrite it in the
> + * end though. Permission is not checked so it may be lost.
> + */
That is a regre
Matthieu Moy writes:
> "git add -u" is one of the only exceptions (with "git grep"). I consider
> this as a bug, and think this should be changed. This has been discussed
> several times here, but no one took the time to actually do the change
Did we ever agree that it is a good change to begin
Matthieu Moy writes:
> Implementing "git rm -u" as a tree-wide command would create a
> discrepancy with "git add -u". Implementing it as a "current directory"
> command would make the migration harder if we eventually try to change
> "git add -u". Perhaps "git rm -u" should be forbidden from a
>
Junio C Hamano wrote:
David Aguilar writes:
On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann
wrote:
@@ -55,7 +55,7 @@ History Viewers
- *gitweb* (shipped with git-core)
- GITweb provides full-fledged web interface for GIT repositories.
+ GITweb provides full-fledged web interface
John Keeping writes:
> git-p4 supports Python 2.6 and later versions of Python 2. Since Python
> 2.8 will never exist [1], it is most concise to just list the supported
> versions.
Thanks; Eric's patch recently updated git-p4.py to require 2.4 I
think. Shouldn't it also be updated?
>
> [1] htt
John Keeping writes:
> On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
>> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping wrote:
>>> On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
These patchs apply on top of of Eric Raymond's cvsimport patch. 7 of 15
test
"Joachim Schmitz" writes:
> Because then it could get confused with "git", the command? That would
> be lower case even at the beginning of a sentence, wouldn't it?
Is it a real-world problem?
I think in a prose when you refer to "git" the command, you would
say something like
The `git
Stephen Kelly writes:
> Hi there,
>
> I find the fixup command during an interactive rebase useful.
>
> Sometimes when cleaning up a branch, I end up in a situation like this:
>
> pick 07bc3c9 Good commit.
> pick 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 Another commit.
>
>
> So, I
Junio C Hamano wrote:
> Sorry, but I do not understand what you are trying to solve.
>
> How can 1313a5e, which fixes misakes made in c2f62a3, come before
> that commit in the first place?
One scenario is something like this:
Start with a clean HEAD (always a good idea :) )
hack hack hack
mak
On 01/20/2013 01:53 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Implementing "git rm -u" as a tree-wide command would create a
>> discrepancy with "git add -u". Implementing it as a "current
>> directory" command would make the migration harder if we eventually
>> try to change "git add
On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>> On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
>>> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping wrote:
On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
> These patchs
On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
>> git-p4 supports Python 2.6 and later versions of Python 2. Since Python
>> 2.8 will never exist [1], it is most concise to just list the supported
>> versions.
>
> Thanks; Eric's patch recently updated g
- Ursprungligt meddelande -
> That configurability is a slipperly slope to drag us into giving
> users
> more complexity that does not help them very much, I suspect.
>
> Earlier somebody mentioned "size and mtime is often enough", so I
> think a single option core.looseStatInfo (substi
John Keeping writes:
> On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>>
>>> git-p4 supports Python 2.6 and later versions of Python 2. Since Python
>>> 2.8 will never exist [1], it is most concise to just list the supported
>>> versions.
>>
>> Thanks;
On Thu, Jan 17, 2013 at 7:09 PM, Junio C Hamano wrote:
> Ben Walton writes:
>
>> The Git::get_tz_offset is meant to provide a workalike replacement for
>> the GNU strftime %z format specifier. The algorithm used failed to
>> properly handle DST boundary cases.
>>
>> For example, the unix time 11
I've now spent some time looking at git-cvsimport-3.py from
jc/cvsimport-upgrade and made some progress in making it pass more of
the Git test suite (my work in progress is at [1]).
However, I think there is a fundamental problem with the way it handles
incremental imports and I'm hoping someone w
>
> If I were to decide today to change the spellings, with an explicit
> purpose of making things more consistent across documentation, it
> may make sense to use even a simpler rule that is less error-prone
> for people who write new sentences that has to have the word. How
> about treating it
On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano wrote:
> John Keeping writes:
>
>> On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
>>> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping wrote:
On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
> These patchs apply
Stephen Kelly writes:
> Junio C Hamano wrote:
>> Sorry, but I do not understand what you are trying to solve.
>>
>> How can 1313a5e, which fixes misakes made in c2f62a3, come before
>> that commit in the first place?
>
> One scenario is something like this:
>
> Start with a clean HEAD (always a
Robin Rosenberg writes:
> - Ursprungligt meddelande -
>
>> That configurability is a slipperly slope to drag us into giving
>> users
>> more complexity that does not help them very much, I suspect.
>>
>> Earlier somebody mentioned "size and mtime is often enough", so I
>> think a single
On Sun, Jan 20, 2013 at 11:28 AM, John Keeping wrote:
> On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
>> John Keeping writes:
>>
>>> git-p4 supports Python 2.6 and later versions of Python 2. Since Python
>>> 2.8 will never exist [1], it is most concise to just list the support
Ben Walton writes:
> also avoids the oddball 1/2 hour DST shift. I can re-roll the series
> with your code (and credit for it) or you can apply you change on top
> of my series...whichever is easiest for you.
Please reroll, as I do not have patience either to set up a test
case and verify the e
Thomas Ackermann writes:
>> If I were to decide today to change the spellings, with an explicit
>> purpose of making things more consistent across documentation, it
>> may make sense to use even a simpler rule that is less error-prone
>> for people who write new sentences that has to have the wor
On Sun, Jan 20, 2013 at 1:24 PM, John Keeping wrote:
> On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote:
>> This is not a noise, though.
>>
>> Chris, how would we want to proceed? I'd prefer at some point to
>> see cvsimport-3 to be in sync when the one patched and tested in
>> Eric
On Sun, Jan 20, 2013 at 10:19:39PM +0100, Per Cederqvist wrote:
> On 01/16/13 03:26, Jonathan Nieder wrote:
> >Hi Jeff and other guilty parties,
> >
> >I collected all the guilt patches I could find on-list and added one
> >of my own. Completely untested, except for running the regression
> >tests
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> "git add -u" is one of the only exceptions (with "git grep"). I consider
>> this as a bug, and think this should be changed. This has been discussed
>> several times here, but no one took the time to actually do the change
>
> Did we ever agree
On 01/16/13 03:26, Jonathan Nieder wrote:
Hi Jeff and other guilty parties,
I collected all the guilt patches I could find on-list and added one
of my own. Completely untested, except for running the regression
tests. These are also available via git protocol from
git://repo.or.cz/guilt/mo
Junio C Hamano writes:
> Jeff King writes:
>
>>> [uploadPack]
>>> hiderefs = refs/changes
>>
>> Would you want to do the same thing on receive-pack? It could benefit
>> from the same reduction in network cost (although it tends to be invoked
>> less frequently than upload-pack).
On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> "git add -u" is one of the only exceptions (with "git grep"). I consider
>>> this as a bug, and think this should be changed. This has been discussed
>>> several times here, but no on
John Keeping :
> I don't think there is any way to solve this without giving cvsps more
> information, probably the last commit time for all git branches, but
> perhaps I'm missing a fast-import feature that can help solve this
> problem.
Yes, you are. The magic incantation is
from refs/head
Eric S. Raymond wrote:
> You get to integrate this. I think the transition strategy Junio
> has chosen is seriously mistaken, leading to unnecessary grief for users
> who will be fooled into thinking it's OK to still use cvsps-2.x.
So our choices are:
a. support current users, offend ESR, don'
Eric S. Raymond wrote:
> You get to integrate this. I think the transition strategy Junio
> has chosen is seriously mistaken, leading to unnecessary grief for users
> who will be fooled into thinking it's OK to still use cvsps-2.
Ah, I missed a detail on first reading. I think there has been a
Jonathan Nieder writes:
> Eric S. Raymond wrote:
>
>> You get to integrate this. I think the transition strategy Junio
>> has chosen is seriously mistaken, leading to unnecessary grief for users
>> who will be fooled into thinking it's OK to still use cvsps-2.x.
>
> So our choices are:
>
> a. s
Junio C Hamano writes:
> ..., so I do not think it is a big loss to rely on the same
> assumptions and choose b. from our point of view.
Of course the last sentence is a typo: "choose c." is what I meant.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
Sven Strickroth writes:
> - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe
> (starting with 1.8.0) in order to make clear that this one has special
> support for git and prevent confusion with the TortoiseSVN TortoiseMerge
> version.
> - The tortoisemerge mergetool d
Jonathan Nieder :
> Junio proposed a transition strategy, but I don't think it's fair to
> say he has chosen it without discussion or is imposing it on you.
I have said everything I could about the bad effects of encouraging
people to continue to use cvsps-2.x, it didn't budge Junio an
inch, and I
Signed-off-by: Barry Wardell
---
t/t9100-git-svn-basic.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 749b75e..4fea8d9 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -306,5 +306,13 @@ test_expect_su
Since git-rev-parse already checks for the $GIT_DIR environment
variable and that it returns an actual git repository, there is no
need to repeat the checks again here.
This also fixes a problem where git-svn did not work in cases where
.git was a file with a gitdir: link.
Signed-off-by: Barry Wa
These patches fix a bug which prevented git-svn from working with repositories
which use gitdir links.
Changes since v2:
- Rebased onto latest master.
- Added test case which verifies that the problem has been fixed.
- Fixed problems with git svn (init|clone|multi-init).
- All git-svn test cas
On Sun, Jan 20, 2013 at 2:17 PM, Chris Rorvick wrote:
> On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano wrote:
>> John Keeping writes:
>>
>>> On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping wrote:
> On Thu, Jan 10, 2013 at 1
On Mon, Jan 21, 2013 at 1:35 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> + /*
>> + * If it has the same content that we are going to write down,
>
> write down???
hmm.. "overwrite" then.
>> + * there's no point in complaining. We still overwrite it in the
>> +
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell wrote:
>
> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
> like it succeeds, except the warning, but (as we learned last time I
> screwed up), it doesn't put the branchname because it can't know.
I think this should be fixed
On Sun, Jan 20, 2013 at 2:16 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Should the client side learn how to list hidden refs too? I'm thinking
>> of an extreme case where upload-pack advertises nothing (or maybe just
>> refs/heads/master) and it's up to the client to ask for the ref
>> s
On Sun, Jan 20, 2013 at 12:23:41PM -0800, Junio C Hamano wrote:
> In any case, the intent of the author timestamp is to record the
> time the author _started_ working on the change and came up with an
> initial, possibly a partial, draft. It does not record the time
> when the commit was finalize
Barry Wardell writes:
> These patches fix a bug which prevented git-svn from working with repositories
> which use gitdir links.
>
> Changes since v2:
> - Rebased onto latest master.
> - Added test case which verifies that the problem has been fixed.
> - Fixed problems with git svn (init|clone
Linus Torvalds writes:
> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell wrote:
>>
>> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
>> like it succeeds, except the warning, but (as we learned last time I
>> screwed up), it doesn't put the branchname because it can't know
tgredgtrfb
--
View this message in context:
http://git.661346.n2.nabble.com/fgdrf-tp7575606.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano wrote:
>
> What you mean by "corrupt" is not clear to me
Some versions would just silently change the actual name you were using.
So if you said "for-linus", it might change it to "linus", just
because that branch happened to have the same SHA1 com
> > I probably won't be sending any more patches on this. My hope was to
> > get cvsimport-3 (w/ cvsps as the engine) in a state such that one
> > could transition from the previous version seamlessly. But the break
> > in t9605 has convinced me this is not worth the effort--even in this
> > triv
Linus Torvalds writes:
> On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell wrote:
>>
>> Due to the delay on git.kernel.org, git request-pull fails. It *looks*
>> like it succeeds, except the warning, but (as we learned last time I
>> screwed up), it doesn't put the branchname because it can't know
On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell wrote:
>
> I'm confused. The default argument is HEAD: what does it know about tag
> names?
Ugh. I actually thought that if you give it the tag name directly (as
the "end") it will use that.
But no. It figures it out with "git describe --exact" int
On Sun, Jan 20, 2013 at 7:14 PM, Jonathan Nieder wrote:
> Hi Ping,
>
> Ping Yin wrote:
>>
>> However, in debian (testing, wheezy), it doesn't work
>>
>> $ gtlg or
>> gtlg or-bash: [: 1: unary operator expected
>> -bash: [: 1: unary operator expected
>
> Yes, I can reproduce this. "git bisect" tel
On 20.01.13 12:06, Jonathan Nieder wrote:
> Torsten Bögershausen wrote:
>
>> I wonder, if if we can go one step further:
>>
>> Replace
>> #ifdef WIN32 /* Both MinGW and MSVC */
> [...]
>> with
>> #if defined(_MSC_VER)
>
> I thought Git for Windows was built using mingw, which doesn't define
> _MS
Ideals extremely stunning and really unpleasant, but i even now surrounding
the failure, was that failure is the mother of results. on the other hand,
quite a few fail to get a victory. this kind of is life in all his existence
to comprehensive all hungry glimpse, all the dreams, and then went to h
I'm a man, a pretty common one particular at that, and as these kinds of
current obtaining has in no way been my sturdy position. So soon after
getting my other-50 percent a pair of wellies for Christmas final 12 months,
I quickly learned my lesson that this wasn't heading to be an acceptable
optio
Now there are some beautiful leather and restricted edition selections which
I think begin from just 30, all the way via to gold alternatives for a
little more than a thousand kilos. The silver or the silver with a gold
clasp are apparently the most common, but here's a word of suggestions
if a
Eric S. Raymond wrote:
> I have said everything I could about the bad effects of encouraging
> people to continue to use cvsps-2.x, it didn't budge Junio an
> inch, and I'm tired of fighting about it.
What I think you misunderstood is that Junio is not the person you
would have needed to convince
"Eric S. Raymond" writes:
> Jonathan Nieder :
>> Junio proposed a transition strategy, but I don't think it's fair to
>> say he has chosen it without discussion or is imposing it on you.
>
> I have said everything I could about the bad effects of encouraging
> people to continue to use cvsps-2.x,
Junio C Hamano writes:
> If you want to abandon cvsps2 users, that is perfectly fine by me.
> As long as cvsps3 and cvsimport-3 combo works, Git before this
> series will have a _working_ cvsimport as far as I am concerned.
The above obviously is "Git _after_ this series".
Git before this serie
89 matches
Mail list logo
