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 occurrence of
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 winsock2.h
-#include
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 including
On Sat, Jan 19, 2013 at 05:31:35PM -0800, David Aguilar wrote:
On Sat, Jan 19, 2013 at 4:01 AM, John Keeping j...@keeping.me.uk 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
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: send
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 j...@keeping.me.uk
Acked-by: Pete Wyckoff p...@padd.com
---
Since
Thomas Ackermann th.ac...@arcor.de 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
- 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
Jonathan Nieder jrnie...@gmail.com 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
Thomas Ackermann th.ac...@arcor.de 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
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
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
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 j...@keeping.me.uk
---
git_remote_helpers/Makefile | 2 +-
1 file
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.
Fix
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 j...@keeping.me.uk
---
git_remote_helpers/.gitignore | 1 +
git_remote_helpers/Makefile | 8 +++-
2 files
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
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 j...@keeping.me.uk
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+),
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
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:
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
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
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 Another
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 I think
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk 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
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping j...@keeping.me.uk 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,
Dmitry V. Levin l...@altlinux.org 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
Jeff King p...@peff.net 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
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com 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
David Aguilar dav...@gmail.com writes:
On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann th.ac...@arcor.de 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
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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.
+ */
Matthieu Moy matthieu@grenoble-inp.fr 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
Matthieu Moy matthieu@grenoble-inp.fr 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
Junio C Hamano wrote:
David Aguilar dav...@gmail.com writes:
On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann
th.ac...@arcor.de wrote:
@@ -55,7 +55,7 @@ History Viewers
- *gitweb* (shipped with git-core)
- GITweb provides full-fledged web interface for GIT repositories.
+ GITweb
John Keeping j...@keeping.me.uk 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
John Keeping j...@keeping.me.uk 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 j...@keeping.me.uk wrote:
On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick wrote:
These patchs apply on top of of Eric Raymond's
Joachim Schmitz j...@schmitz-digital.de 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
Stephen Kelly steve...@gmail.com 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.
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
make
On 01/20/2013 01:53 PM, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr 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
On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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 j...@keeping.me.uk wrote:
On Thu, Jan 10, 2013 at 10:27:16PM -0600, Chris Rorvick
On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
- 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 (substitute
John Keeping j...@keeping.me.uk writes:
On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
On Thu, Jan 17, 2013 at 7:09 PM, Junio C Hamano gits...@pobox.com wrote:
Ben Walton bdwal...@gmail.com 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
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
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 just
On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk 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 j...@keeping.me.uk wrote:
On Thu, Jan 10, 2013 at 10:27:16PM -0600,
Stephen Kelly steve...@gmail.com 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
Robin Rosenberg robin.rosenb...@dewire.com 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
On Sun, Jan 20, 2013 at 11:28 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
git-p4 supports Python 2.6 and later versions of Python 2. Since Python
2.8 will never exist [1], it is most
Ben Walton bdwal...@gmail.com 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
Thomas Ackermann th.ac...@arcor.de 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
On Sun, Jan 20, 2013 at 1:24 PM, John Keeping j...@keeping.me.uk 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
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. These
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr 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
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
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net 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
On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr 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
John Keeping j...@keeping.me.uk:
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
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't
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 jrnie...@gmail.com 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:
Junio C Hamano gits...@pobox.com 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
Sven Strickroth sven.strickr...@tu-clausthal.de 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.
-
Jonathan Nieder jrnie...@gmail.com:
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
Signed-off-by: Barry Wardell barry.ward...@gmail.com
---
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
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
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
On Sun, Jan 20, 2013 at 2:17 PM, Chris Rorvick ch...@rorvick.com wrote:
On Sun, Jan 20, 2013 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
On Sun, Jan 20, 2013 at 6:58 AM, John
On Mon, Jan 21, 2013 at 1:35 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au 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
On Sun, Jan 20, 2013 at 2:16 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
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 finalized.
Barry Wardell barry.ward...@gmail.com 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
Linus Torvalds torva...@linux-foundation.org writes:
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au 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
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 gits...@pobox.com 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
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
trivial case
Linus Torvalds torva...@linux-foundation.org writes:
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au 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
On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell ru...@rustcorp.com.au 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
On Sun, Jan 20, 2013 at 7:14 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi Ping,
Ping Yin wrote:
However, in debian (testing, wheezy), it doesn't work
$ gtlg orTAB
gtlg or-bash: [: 1: unary operator expected
-bash: [: 1: unary operator expected
Yes, I can reproduce this. git bisect
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
_MSC_VER?
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
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
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
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 e...@thyrsus.com writes:
Jonathan Nieder jrnie...@gmail.com:
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
Junio C Hamano gits...@pobox.com 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
88 matches
Mail list logo
