* [PATCH v3 7/8] git-remote-testpy: don't do unbuffered text I/O
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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: fix
race when spawning fast-import).
Signed-off-by: John Keeping <john@keeping.me.uk>
---
git-remote-testpy.py | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index 197b7be..5dbf1cc 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -154,7 +154,7 @@ def do_import(repo, args):
refs = [ref]
while True:
- line = sys.stdin.readline()
+ line = sys.stdin.readline().decode()
if line == '\n':
break
if not line.startswith('import '):
@@ -225,7 +225,7 @@ def read_one_line(repo):
line = sys.stdin.readline()
- cmdline = line
+ cmdline = line.decode()
if not cmdline:
warn("Unexpected EOF")
@@ -277,7 +277,11 @@ def main(args):
more = True
- sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
+ # Use binary mode since Python 3 does not permit unbuffered I/O in text
+ # mode. Unbuffered I/O is required to avoid data that should be going
+ # to git-fast-import after an "export" command getting caught in our
+ # stdin buffer instead.
+ sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
while (more):
more = read_one_line(repo)
--
1.8.1.353.gc992d5a.dirty
^ permalink raw reply related
* [PATCH v3 8/8] git-remote-testpy: call print as a function
From: John Keeping @ 2013-01-20 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sverre Rabbelier
In-Reply-To: <cover.1358686905.git.john@keeping.me.uk>
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 in that
case Python 2 will interpret '()' as an empty tuple and print it as
'()'; inserting an empty string fixes this.
Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
---
git-remote-testpy.py | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
index 5dbf1cc..c7a04ec 100644
--- a/git-remote-testpy.py
+++ b/git-remote-testpy.py
@@ -87,9 +87,9 @@ def do_capabilities(repo, args):
"""Prints the supported capabilities.
"""
- print "import"
- print "export"
- print "refspec refs/heads/*:%s*" % repo.prefix
+ print("import")
+ print("export")
+ print("refspec refs/heads/*:%s*" % repo.prefix)
dirname = repo.get_base_path(repo.gitdir)
@@ -98,11 +98,11 @@ def do_capabilities(repo, args):
path = os.path.join(dirname, 'git.marks')
- print "*export-marks %s" % path
+ print("*export-marks %s" % path)
if os.path.exists(path):
- print "*import-marks %s" % path
+ print("*import-marks %s" % path)
- print # end capabilities
+ print('') # end capabilities
def do_list(repo, args):
@@ -115,16 +115,16 @@ def do_list(repo, args):
for ref in repo.revs:
debug("? refs/heads/%s", ref)
- print "? refs/heads/%s" % ref
+ print("? refs/heads/%s" % ref)
if repo.head:
debug("@refs/heads/%s HEAD" % repo.head)
- print "@refs/heads/%s HEAD" % repo.head
+ print("@refs/heads/%s HEAD" % repo.head)
else:
debug("@refs/heads/master HEAD")
- print "@refs/heads/master HEAD"
+ print("@refs/heads/master HEAD")
- print # end list
+ print('') # end list
def update_local_repo(repo):
@@ -164,7 +164,7 @@ def do_import(repo, args):
ref = line[7:].strip()
refs.append(ref)
- print "feature done"
+ print("feature done")
if os.environ.get("GIT_REMOTE_TESTGIT_FAILURE"):
die('Told to fail')
@@ -172,7 +172,7 @@ def do_import(repo, args):
repo = update_local_repo(repo)
repo.exporter.export_repo(repo.gitdir, refs)
- print "done"
+ print("done")
def do_export(repo, args):
@@ -192,8 +192,8 @@ def do_export(repo, args):
repo.non_local.push(repo.gitdir)
for ref in changed:
- print "ok %s" % ref
- print
+ print("ok %s" % ref)
+ print('')
COMMANDS = {
--
1.8.1.353.gc992d5a.dirty
^ permalink raw reply related
* git interactive rebase 'consume' command
From: Stephen Kelly @ 2013-01-20 14:05 UTC (permalink / raw)
To: git
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 1313a5e to 'f'. An alternative
would be to squash 's' c2f62a3 into 1313a5e and clean up the commit message.
The problem with that is it ends up with the wrong author time information.
So, I usually reorder and then fixup, but that can also be problematic if I
get a conflict during the re-order (which is quite likely).
I would prefer to be able to mark a commit as 'should be consumed', so that:
pick 07bc3c9 Good commit.
consume 1313a5e Commit to fixup into c2f62a3.
pick c2f62a3 Another commit.
will result in
pick 07bc3c9 Good commit.
pick 62a3c2f Another commit.
directly.
Any thoughts on that?
Thanks,
Steve.
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: John Keeping @ 2013-01-20 14:17 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git
In-Reply-To: <kdgtir$apt$1@ger.gmane.org>
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 commit.
>
> So, I have to reorder the commits, and change 1313a5e to 'f'. An alternative
> would be to squash 's' c2f62a3 into 1313a5e and clean up the commit message.
> The problem with that is it ends up with the wrong author time information.
>
> So, I usually reorder and then fixup, but that can also be problematic if I
> get a conflict during the re-order (which is quite likely).
>
> I would prefer to be able to mark a commit as 'should be consumed', so that:
>
> pick 07bc3c9 Good commit.
> consume 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 Another commit.
>
> will result in
>
> pick 07bc3c9 Good commit.
> pick 62a3c2f Another commit.
>
> directly.
>
> 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.
(Which is not to say that I wouldn't find an option like 'consume'
useful but I find myself reordering the list very rarely since I started
using "git commit --fixup=...".)
John
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: Stephen Kelly @ 2013-01-20 14:23 UTC (permalink / raw)
To: git
In-Reply-To: <20130120141725.GL31172@serenity.lan>
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 it's not related to the proposal I made.
Mostly my proposal is about avoiding unnecessary conflict resolution.
Thanks,
Steve.
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Chris Rorvick @ 2013-01-20 15:22 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130120125838.GK31172@serenity.lan>
On Sun, Jan 20, 2013 at 6:58 AM, John Keeping <john@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 Eric (fixes revision map.)
>
> Did you post the fix for the revision map publicly anywhere?
It's in Eric's repo and included in version 3.8:
https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6
Chris
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: John Keeping @ 2013-01-20 15:28 UTC (permalink / raw)
To: Chris Rorvick; +Cc: git
In-Reply-To: <CAEUsAPZKd+mw2iK7nd6rTtB8N+B99ud19FkuSx0HVitNxrxxZA@mail.gmail.com>
On Sun, Jan 20, 2013 at 09:22:03AM -0600, Chris Rorvick wrote:
> On Sun, Jan 20, 2013 at 6:58 AM, John Keeping <john@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, 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 publicly anywhere?
>
> It's in Eric's repo and included in version 3.8:
>
> https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6
Thanks. For some reason I thought the fix would be to
git-cvsimport-3.py. Obviously I should have read more carefully.
Sorry for the noise.
John
^ permalink raw reply
* Re: [PATCH v3] am: invoke perl's strftime in C locale
From: Junio C Hamano @ 2013-01-20 17:47 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Jeff King, Antoine Pelisse, git
In-Reply-To: <20130119202853.GD1652@altlinux.org>
"Dmitry V. Levin" <ldv@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 FYI, "LC_ALL=C LANG=C" comes from the inertia dating back when
not everybody understood LC_*; I do not personally know of a system
that will be helped by the extra LANG=C these days, but I know it
will not hurt anybody, so...
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-20 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: git, spearce, mfick
In-Reply-To: <20130119165042.GB12307@sigill.intra.peff.net>
Jeff King <peff@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 when there already is a patch exists; I'd
rather take existing and tested patch ;-)
As I said, I view this primarily as solving the cluttering issue.
The use of hiderefs to hide these refs that point at objects I do
not consider belong to my repository from the pushers equally makes
sense as such, I think.
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-20 18:19 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, spearce, mfick
In-Reply-To: <7v38xxnfv3.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Duy Nguyen <pclouds@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
>> selection it's interested in. upload-pack may need more updates to do
>> that, I think.
>
> What you are talking about is a different goal.
>
> Look at this as a mechanism for the repository owner to control the
> clutter in what is shown to the intended audience of what s/he
> publishes in the repository. Network bandwidth reduction of
> advertisement is a side effect of clutter reduction, and not
> necessarily the primary goal.
As a separate and follow-up topic, I can see a future where we also
have .delayref (in addition to .hideref) configuration, that causes
the upload-pack to:
* omit refs that are marked as "delayed";
* advertise "allow-expand-ref=<value>" where the value is the
pattern used to specify which refs are omitted via this mechanism
(e.g. "refs/*" in your extreme example, or perhaps "refs/tags/"
if you only advertise branches in order to limit the bandwidth);
and then a fetch-pack that is interested in fetching "refs/foo/bar",
after seeing that it matches one of the "allow-expand-ref" patterns,
to ask "expand-ref refs/foo/bar", expect the upload-pack to respond
with "refs/foo/bar <value of that ref>" (or "refs/foo/bar does not
exist"), before going into the usual "want" exchange ("ls-remote"
would of course do the same, and pattern-less "ls-remote" may even
ask to expand everything by saying "expand-ref refs/*" (where the
capability said "allow-expand-ref=refs/*" in your extreme example)
to grab everything discoverable).
That is _primarily_ for trading network bandwidth with initial
latency; as far as the end-result is concerned, delayed ones to be
expanded on demand are just as discoverable as the ones advertised
initially.
I think we'd want to have both in the end. It just happens I just
posted the beginning of clutter-reduction one, as I think developing
both in parallel would be messy and hideref is probably less
involved than the delayref.
^ permalink raw reply
* Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Junio C Hamano @ 2013-01-20 18:33 UTC (permalink / raw)
To: David Aguilar; +Cc: Thomas Ackermann, git
In-Reply-To: <CAJDDKr5_AWFF6MR2Kwt5FzA0vaSE-wx8xFO3xcRnKZ168hXBrg@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann <th.acker@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 web interface for Git repositories.
>
> What about GITweb?
>
>> diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
>> index d377a35..0df13ff 100644
>> --- a/Documentation/git-update-ref.txt
>> +++ b/Documentation/git-update-ref.txt
>> @@ -73,7 +73,7 @@ in ref value. Log lines are formatted as:
>> Where "oldsha1" is the 40 character hexadecimal value previously
>> stored in <ref>, "newsha1" is the 40 character hexadecimal value of
>> <newvalue> and "committer" is the committer's name, email address
>> -and date in the standard GIT committer ident format.
>> +and date in the standard Git committer ident format.
>
> IMO some of these look nicer when everything is lowercase.
> e.g. "standard git committer ident format".
I do not think we ever intended to change the *name* of the
software.
In the early days, we wrote GIT in places where, if we were doing a
fancier typography, we would have used drop-caps for the latter two
(i.e. it is "Git" spelled in a font whose lower case alphabets have
the same shape as upper case ones but are smaller). So there were
only "git" vs "Git".
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 like any other ordinary word? That is, we
say "git" (without double-quotes, of course), unless it comes at the
beginning of a sentence?
^ permalink raw reply
* Re: [PATCH] unpack-trees: do not abort when overwriting an existing file with the same content
From: Junio C Hamano @ 2013-01-20 18:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1358594648-26851-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@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.
> + */
That is a regression, isn't it? Is it too cumbersome to avoid
losing the permission bits by stopping in that case?
> + if (ce &&
> + S_ISREG(st->st_mode) && S_ISREG(ce->ce_mode) &&
> + st->st_size < 1024 * 1024 && /* should be configurable */
> + sha1_object_info(ce->sha1, &ce_size) == OBJ_BLOB &&
> + ce_size == st->st_size) {
> + void *buffer = NULL;
> + unsigned long size;
> + enum object_type type;
> + struct strbuf sb = STRBUF_INIT;
> + int matched =
> + strbuf_read_file(&sb, ce->name, ce_size) == ce_size &&
> + (buffer = read_sha1_file(ce->sha1, &type, &size)) != NULL &&
> + type == OBJ_BLOB &&
> + size == ce_size &&
> + !memcmp(buffer, sb.buf, size);
> + free(buffer);
> + strbuf_release(&sb);
> + if (matched)
> + return 0;
> + }
> +
> return o->gently ? -1 :
> add_rejected_path(o, error_type, name);
> }
^ permalink raw reply
* Re: [RFC] git rm -u
From: Junio C Hamano @ 2013-01-20 18:42 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky
In-Reply-To: <vpq622s9jk1.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@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 good change to begin with? Pointers?
^ permalink raw reply
* Re: [RFC] git rm -u
From: Junio C Hamano @ 2013-01-20 18:53 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jonathan Nieder, Eric James Michael Ritz, git, Tomas Carnecky
In-Reply-To: <vpq622s9jk1.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@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 forbidden from a
> subdirectory (with an error message pointing to "git rm -u :/" and "git
> rm -u ."), waiting for a possible "git add -u" change.
Yeah, that sounds sensible. Start with a "'git rm -u' is forbidden
without arguments", give advise to use either "." or ":/". And stop
there.
The first step of "git add -u" migration plan would be to warn when
no argument is given and update all the existing index entries, and
give the same advise to use either "." or ":/". Keep this for three
cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year.
The second step would be to forbid "git add -u", and keep the
advise. That will make it in-line with "git rm -u".
^ permalink raw reply
* Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Joachim Schmitz @ 2013-01-20 18:53 UTC (permalink / raw)
To: git
In-Reply-To: <7vehhfn1r0.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> David Aguilar <davvid@gmail.com> writes:
>
>> On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann
>> <th.acker@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 web interface for Git repositories.
>>
>> What about GITweb?
>>
>>> diff --git a/Documentation/git-update-ref.txt
>>> b/Documentation/git-update-ref.txt index d377a35..0df13ff 100644
>>> --- a/Documentation/git-update-ref.txt
>>> +++ b/Documentation/git-update-ref.txt
>>> @@ -73,7 +73,7 @@ in ref value. Log lines are formatted as:
>>> Where "oldsha1" is the 40 character hexadecimal value previously
>>> stored in <ref>, "newsha1" is the 40 character hexadecimal value of
>>> <newvalue> and "committer" is the committer's name, email address
>>> -and date in the standard GIT committer ident format.
>>> +and date in the standard Git committer ident format.
>>
>> IMO some of these look nicer when everything is lowercase.
>> e.g. "standard git committer ident format".
>
> I do not think we ever intended to change the *name* of the
> software.
>
> In the early days, we wrote GIT in places where, if we were doing a
> fancier typography, we would have used drop-caps for the latter two
> (i.e. it is "Git" spelled in a font whose lower case alphabets have
> the same shape as upper case ones but are smaller). So there were
> only "git" vs "Git".
>
> 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 like any other ordinary word? That is, we
> say "git" (without double-quotes, of course), unless it comes at the
> beginning of a sentence?
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?
Bye, Jojo
^ permalink raw reply
* Re: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
From: Junio C Hamano @ 2013-01-20 18:54 UTC (permalink / raw)
To: John Keeping; +Cc: git, Pete Wyckoff
In-Reply-To: <20130120110620.GJ31172@serenity.lan>
John Keeping <john@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 updated?
>
> [1] http://www.python.org/dev/peps/pep-0404/
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> Acked-by: Pete Wyckoff <pw@padd.com>
> ---
> Since v1:
> - Fixed a typo in the commit message.
>
> INSTALL | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/INSTALL b/INSTALL
> index 28f34bd..c456d1c 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -131,7 +131,7 @@ Issues of note:
> use English. Under autoconf the configure script will do this
> automatically if it can't find libintl on the system.
>
> - - Python version 2.6 or later is needed to use the git-p4
> + - Python version 2.6 or 2.7 is needed to use the git-p4
> interface to Perforce.
>
> - Some platform specific issues are dealt with Makefile rules,
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Junio C Hamano @ 2013-01-20 18:57 UTC (permalink / raw)
To: John Keeping; +Cc: Chris Rorvick, git
In-Reply-To: <20130120152857.GM31172@serenity.lan>
John Keeping <john@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 <john@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, 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 publicly anywhere?
>>
>> It's in Eric's repo and included in version 3.8:
>>
>> https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6
>
> Thanks. For some reason I thought the fix would be to
> git-cvsimport-3.py. Obviously I should have read more carefully.
>
> Sorry for the noise.
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's repository is proven enough. Will Eric be the gatekeeper, or
will you be sending patches this way as well?
^ permalink raw reply
* Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Junio C Hamano @ 2013-01-20 19:02 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <kdheeh$ntf$1@ger.gmane.org>
"Joachim Schmitz" <jojo@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
The `git` command started as a thin wrapper to many
subcommand of the `git-subcmd` form.
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: Junio C Hamano @ 2013-01-20 19:05 UTC (permalink / raw)
To: Stephen Kelly; +Cc: git
In-Reply-To: <kdgtir$apt$1@ger.gmane.org>
Stephen Kelly <steveire@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.
>
>
> So, I have to reorder the commits, and change 1313a5e to 'f'. An alternative
> would be to squash 's' c2f62a3 into 1313a5e and clean up the commit message.
> The problem with that is it ends up with the wrong author time information.
>
> So, I usually reorder and then fixup, but that can also be problematic if I
> get a conflict during the re-order (which is quite likely).
>
> I would prefer to be able to mark a commit as 'should be consumed', so that:
>
> pick 07bc3c9 Good commit.
> consume 1313a5e Commit to fixup into c2f62a3.
> pick c2f62a3 Another commit.
>
> will result in
>
> pick 07bc3c9 Good commit.
> pick 62a3c2f Another commit.
>
> directly.
>
> Any thoughts on that?
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?
^ permalink raw reply
* Re: git interactive rebase 'consume' command
From: Stephen Kelly @ 2013-01-20 19:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vk3r7llod.fsf@alter.siamese.dyndns.org>
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 multiple commits
realize that a hunk you committed in an early patch belongs in a later one.
use git rebase -i to fix it.
Is that more clear?
Thanks,
Steve.
^ permalink raw reply
* Re: [RFC] git rm -u
From: Eric James Michael Ritz @ 2013-01-20 19:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Jonathan Nieder, git, Tomas Carnecky
In-Reply-To: <7v1udfn0tm.fsf@alter.siamese.dyndns.org>
On 01/20/2013 01:53 PM, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@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 forbidden
>> from a subdirectory (with an error message pointing to "git rm -u
>> :/" and "git rm -u ."), waiting for a possible "git add -u" change.
>
> Yeah, that sounds sensible. Start with a "'git rm -u' is forbidden
> without arguments", give advise to use either "." or ":/". And stop
> there.
I was unaware of any plan to change `git add -u`, but the above makes
sense to me. I will use those suggestions as guidelines for the
initial implementation of `git rm -u`. In particular, it will require
an argument like `.` or `:/`. It sounds like the future direction of
`git add -u` will play a role in how `git rm -u` should behave so that
there is consistency between the two, so I will try to take a
conservative approach in my implementation. Thank you both for the
advice and insight.
--
ejmr
南無妙法蓮華經
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: John Keeping @ 2013-01-20 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Rorvick, git
In-Reply-To: <7vsj5vlm1d.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 10:57:50AM -0800, Junio C Hamano wrote:
> John Keeping <john@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 <john@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, 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 publicly anywhere?
>>>
>>> It's in Eric's repo and included in version 3.8:
>>>
>>> https://gitorious.org/cvsps/cvsps/commit/abe81e1775a8959291f629029513d1b7160bbde6
>>
>> Thanks. For some reason I thought the fix would be to
>> git-cvsimport-3.py. Obviously I should have read more carefully.
>>
>> Sorry for the noise.
>
> 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's repository is proven enough. Will Eric be the gatekeeper, or
> will you be sending patches this way as well?
In this case the patch was to the C portion of cvsps, not the Python
cvs-import, so not relevant for this particular case.
I currently have a set of patches on top of jc/cvsimport-upgrade, which
is slightly out-of-sync with git-cvsimport.py in Eric's cvsps
repository, because I hadn't realised that the latter existed until
about an hour ago.
I haven't decided yet whether to rebase those onto the git-cvsimport.py
in the cvsps repository or send them here to apply on top of
jc/cvsimport-upgrade. Given that git-cvsimport is a command which has
been around for a while and (although this is a complete re-write) the
aim of these changes is to keep it working as the upstream project
changes, I have a slight preference for keeping git-cvsimport here and
recommending that the copy in the cvsps repository is removed.
John
^ permalink raw reply
* Re: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
From: John Keeping @ 2013-01-20 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pete Wyckoff
In-Reply-To: <7vwqv7lm6b.fsf@alter.siamese.dyndns.org>
On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
> John Keeping <john@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 updated?
I haven't done a thorough audit to check what the actual minimum
supported version is, this is just the minimal change to say "not
Python 3".
Personally, I'm not sure of the value of having version checks at the
top of the Python scripts, I would rather set a project-wide minimum
supported version (as in my recent CodingGuidelines patch) and check it
once in the Makefile.
John
^ permalink raw reply
* Re: [PATCH v2] Make git selectively and conditionally ignore certain stat fields
From: Robin Rosenberg @ 2013-01-20 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, j sixt, Shawn Pearce
In-Reply-To: <7va9sa6f0h.fsf@alter.siamese.dyndns.org>
----- 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 "loose" with
> short, minimum or whatever adjective that is more appropriate---I am
> not good at picking phrases, it sounds to me a way to more loosely
> define stat info cleanliness than we usually do) that makes us
> ignore all fields (regardless of their zero-ness) other than those
> two fields might not be a bad way to go.
Would something like this be good?
core.statinfo =
default = all fields
minimal = whole seconds of mtime and size
medium = seconds, nanos of mtime and size
nonzero = all non-zero fields
-- robin
^ permalink raw reply
* Re: [PATCH v2] INSTALL: git-p4 doesn't support Python 3
From: Junio C Hamano @ 2013-01-20 19:54 UTC (permalink / raw)
To: John Keeping; +Cc: Eric S. Raymond, git, Pete Wyckoff
In-Reply-To: <20130120192831.GB7498@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Sun, Jan 20, 2013 at 10:54:52AM -0800, Junio C Hamano wrote:
>> John Keeping <john@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 updated?
>
> I haven't done a thorough audit to check what the actual minimum
> supported version is, this is just the minimal change to say "not
> Python 3".
>
> Personally, I'm not sure of the value of having version checks at the
> top of the Python scripts, I would rather set a project-wide minimum
> supported version (as in my recent CodingGuidelines patch) and check it
> once in the Makefile.
OK; I'll leave that for later a day (Cc'ed Eric but stakeholders of
other Python scripts may want to express their opinions), and will
apply this patch as is.
If we end up deciding to rip out the "prerequisite per file", that
will be a tree-wide change that is independent from your patch we
are discussing in this thread. If we end up not doing that, then we
would instead be updating git-p4.py to set a higher floor to the
prerequiste but that can come as a separate patch.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox