* [PATCH 0/3] A smoother transition plan for cvsimport
From: Junio C Hamano @ 2013-01-14 1:40 UTC (permalink / raw)
To: git; +Cc: jrnieder, mhagger, esr, chris
In-Reply-To: <7v8v7wiv3a.fsf@alter.siamese.dyndns.org>
So here is a start of how such a transition plan outlined in the
previous message may look like.
The first two are preparatory step to allow the current code to
still work even when cvsps2 and cvsps3 are both available on the
system.
The last patch is mostly for illustration purposes; the cvsimport-3.py
script it adds was taken from the patch Eric sent earlier and I relayed
to the list, and does not have later improvements in Eric's tree or
any of Chris's patches.
Junio C Hamano (3):
cvsimport: allow setting a custom cvsps (2.x) program name
cvsimport: introduce a version-switch wrapper
cvsimport: start adding cvsps 3.x support
.gitignore | 1 +
Makefile | 28 +-
git-cvsimport-2.perl | 1179 ++++++++++++++++++++++++++++++++++++++++++++++++++
git-cvsimport-3.py | 344 +++++++++++++++
git-cvsimport.perl | 1177 -------------------------------------------------
git-cvsimport.sh | 5 +
t/lib-cvs.sh | 4 +-
7 files changed, 1553 insertions(+), 1185 deletions(-)
create mode 100755 git-cvsimport-2.perl
create mode 100755 git-cvsimport-3.py
delete mode 100755 git-cvsimport.perl
create mode 100755 git-cvsimport.sh
--
1.8.1.421.g6236851
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #05; Fri, 11)
From: Duy Nguyen @ 2013-01-14 1:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobgsheko.fsf@alter.siamese.dyndns.org>
On Mon, Jan 14, 2013 at 6:02 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Sat, Jan 12, 2013 at 6:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> * nd/parse-pathspec (2013-01-11) 20 commits
>>>
>>> Uses the parsed pathspec structure in more places where we used to
>>> use the raw "array of strings" pathspec.
>>>
>>> Unfortunately, this conflicts a couple of topics in flight. I tried
>>> to be careful while resolving conflicts, though.
>>
>> parse_pathspec has not picked up init_pathspec changes from
>> jk/pathspec-literal and nd/pathspec-wildcard (already in master) so
>> --literal-pathspecs is probably broken in 'pu' after a lot of
>> init_pathspec -> parse_pathspec conversion.
>
> I guess it may be a better way forward to hold the series off, and
> instead help polishing the other topics that are depended on so that
> they can graduate sooner, given multiple topics in flight wants to
> touch pathspecs (either change the way they are handled, or adds new
> places that use them).
No problem. Just tell me when you want me to flood git@vger again.
--
Duy
^ permalink raw reply
* Re: [PATCH v3 03/31] Add parse_pathspec() that converts cmdline args to struct pathspec
From: Duy Nguyen @ 2013-01-14 1:11 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Junio C Hamano
In-Reply-To: <CANiSa6icv7V7hoEzHQT0mgqjCDcSkuLvZ2M=6Q5gp6NcXJ20jQ@mail.gmail.com>
On Mon, Jan 14, 2013 at 7:05 AM, Martin von Zweigbergk
<martinvonz@gmail.com> wrote:
> On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
>> +static void parse_pathspec(struct pathspec *pathspec,
>> + unsigned magic_mask, unsigned flags,
>> + const char *prefix, const char **argv)
>> +{
>> + struct pathspec_item *item;
>> + const char *entry = *argv;
>> ...
>> + for (i = 0; i < n; i++) {
>> + const char *arg = argv[i];
>
> Nit: "*argv" was assigned to "entry" above. Reassign that variable instead?
Yeah. Thanks for catching.
--
Duy
^ permalink raw reply
* cvs-fast-export release announcement
From: Eric S. Raymond @ 2013-01-14 0:13 UTC (permalink / raw)
To: git
Version 0.2 of the code formerly known as parsecvs has just shipped as
cvs-fast-export. Project page, with links to documentation and the
public repository, is at <http://www.catb.org/esr/cvs-fast-export/>.
I have some cvsps and reposurgeon patches to merge before I can get
back to the script wrapper.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
The most foolish mistake we could possibly make would be to permit
the conquered Eastern peoples to have arms. History teaches that all
conquerors who have allowed their subject races to carry arms have
prepared their own downfall by doing so.
-- Adolph Hitler, April 11 1942.
^ permalink raw reply
* Re: [PATCH v3 03/31] Add parse_pathspec() that converts cmdline args to struct pathspec
From: Martin von Zweigbergk @ 2013-01-14 0:05 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1358080539-17436-4-git-send-email-pclouds@gmail.com>
On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> +static void parse_pathspec(struct pathspec *pathspec,
> + unsigned magic_mask, unsigned flags,
> + const char *prefix, const char **argv)
> +{
> + struct pathspec_item *item;
> + const char *entry = *argv;
> ...
> + for (i = 0; i < n; i++) {
> + const char *arg = argv[i];
Nit: "*argv" was assigned to "entry" above. Reassign that variable instead?
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Junio C Hamano @ 2013-01-13 23:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Michael Haggerty, Eric S. Raymond, git, Chris Rorvick
In-Reply-To: <7v8v7wiv3a.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Michael Haggerty wrote:
>>
>>> Regarding your claim that "within a few months the Perl git-cvsimport is
>>> going to cease even pretending to work": It might be that the old
>>> git-cvsimport will stop working *for people who upgrade to cvsps 3.x*.
>>> But it is not realistic to expect people to synchronize their git and
>>> cvsps version upgrades. It is even quite possible that this or that
>>> Linux distribution will package incompatible versions of the two packages.
>>
>> Moreover, I feel an obligation to point the following out:
>>
>> In a hypothetical world where cvsps 3.x simply breaks "git cvsimport"
>> it is likely that some distributions would just stick to the existing
>> cvsps and not upgrade to 3.x. Maybe that's a wrong choice, but that's
>> a choice some would make. An even more likely outcome in that
>> hypothetical world is that they would ship it renamed to something
>> like "cvsps3" alongside the existing cvsps. Or they could rename the
>> old version to "cvsps2". If we were the last holdout, we could even
>> bundle it as compat/cvsps.
>>
>> So please do not act as though the cvsps upgrade is a crisis that we
>> need to break ourselves for at threat of no longer working at all.
>> The threat doesn't hold water.
>>
>> Luckily you have already written patches to make "git cvsimport" work
>> with cvsps 3.x, and through your work you are making a better
>> argument: "The new cvsimport + cvsps will work better, at least for
>> some users, than the old tool."
>>
>> Just don't pretend you have the power to force a change for a less
>> sensible reason than that!
>
> After a quick survey of various distros, I think it is very unlikely
> that we will see "distros move on to newer cvsps, leaving cvsimport
> broken" situation. If anything, it is more like "distros decide to
> ignore the new cvsps, until it is made to work with cvsimport" [*1*].
>
> I think it is probably sensible to rename the current cvsimport to
> cvsimport-2, write a small wrapper git-cvsimport.sh which is
> something like this:
>
> ----- >8 -----
> #!/bin/sh
>
> if test -z "$GIT_CVSPS_VERSION"
> then
> case "$(cvsps -h 2>&1 | grep 'cvsps version')" in
> 2.*)
> GIT_CVSPS_VERSION=2
> ;;
> 3.*)
> GIT_CVSPS_VERSION=3
> ;;
> esac
> fi
>
> if test -z "$GIT_CVSPS_VERSION"
> then
> echo >&2 "No supported cvsps available"
> exit 1
> fi
>
> exec git cvsimport-$GIT_CVSPS_VERSION "$@"
> ----- 8< -----
>
> and put Eric's one as git-cvsimport-3 (after ripping out the code to
> fallback to the old cvsimport). The longer term trend will be to
> move away from cvsimport-2, as it is unlikely cvsps-2.x will gain
> improvements, if any; keeping fallback code outside cvsimport-3 will
> be a better first step in the healthier long term code evolution.
>
> We will keep the current t96xx series of tests, and have them export
> GIT_CVSPS_VERSION=2 at the beginning, protect them with test prereq
> that requires presence of cvsps 2.x; this will still make sure that
> the current cvsimport users will not see any regressions.
>
> Eric's one should be polished enough to produce good results on the
s/should be polished enough/should be in a polished enough state/
that is. Also "if not right now" may better convey what I meant if
written "if not already".
> simpler sample CVS histories t96xx deal with soonish if not right
> now, so we can use a method similar to how we shared tests between
> blame and annotate while both were _different_ implementations to
> make sure the newer blame did not inroduce regression by running the
> same set of tests. Where the result _ought_ to differ, we should
> also add tests that work only with the new cvsimport, of course.
>
> I could help getting the ball rolling on this, if everybody agrees
> that the above is a sensible direction to go, given the real world
> constraints of distro inertia.
>
> Agreed?
>
>
> [References]
>
> *1* Fedora, Debian and Ubuntu do not even have cvsps 3.x in their
> bleeding edges, OpenBSD and NetBSD do not seem to have it either,
> and Gentoo and ArchLinux have the cvsps 3.x blocked due to
> incompatiblity.
>
> http://pkgs.fedoraproject.org/cgit/cvsps.git/
> http://packages.debian.org/search?keywords=cvsps
> http://packages.ubuntu.com/search?keywords=cvsps
>
> http://packages.gentoo.org/package/dev-vcs/cvsps
> https://bugs.gentoo.org/show_bug.cgi?id=450424
>
> https://bugs.archlinux.org/task/33363?project=1&cat%5B0%5D=2&string=cvsps
^ permalink raw reply
* Re: [PATCH] t0050: mark TC merge (case change) as success
From: Junio C Hamano @ 2013-01-13 23:24 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <201301132138.37154.tboegi@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> The test "merge (case change)" passes on a case ignoring file system
>
> Use test_expect_success to remove the "known breakage vanished"
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
Interesting. When did this change? Do you happen to have a
bisection? Or did the test pass from the very beginning?
> t/t0050-filesystem.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
> index 78816d9..ccd685d 100755
> --- a/t/t0050-filesystem.sh
> +++ b/t/t0050-filesystem.sh
> @@ -77,7 +77,7 @@ $test_case 'rename (case change)' '
>
> '
>
> -$test_case 'merge (case change)' '
> +test_expect_success 'merge (case change)' '
>
> rm -f CamelCase &&
> rm -f camelcase &&
^ permalink raw reply
* Re: [PATCH v3 00/31] nd/parse-pathspec
From: Junio C Hamano @ 2013-01-13 23:21 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1358080539-17436-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Changes from v2 (it's hard to keep track of after the rebase, so I may
> be missing something here):
>
> - rebased on top of recent master, incorporate changes in
> init_pathspec from jk/pathspec-literal and nd/pathspec-wildcard to
> parse_pathspec
>
> - kill strip_trailing_slash_from_submodules and treat_gitlinks
> (pretty sure it'll cause conflicts with as/check-ignore)
>
> - kill init_pathspec, match_pathspec, diff_tree_setup_paths and
> diff_tree_release_paths
>
> - check points for future pathspec development
>
> As far as I understand the "pathspec unification", I'd say we are
> there, with a few exceptions like "mv", external commands.. But those
> are pretty much isolated.
>
> I'll send another WIP series implementing :(icase) and :(glob), mainly
> to show (me) how future pathspec feature development looks like after
> this.
;-)
Thanks; looking forward to reading it.
^ permalink raw reply
* Re: git-completion.bash should not add a space after a ref
From: Junio C Hamano @ 2013-01-13 23:16 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git@vger.kernel.org, SZEDER Gábor, Felipe Contreras
In-Reply-To: <50F1AD0F.7080503@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> This is not really a bug, but a small usability problem.
>
> When completing a reference, Bash will add a space after the reference name.
>
> As an example in:
>
> $git show master<TAB>
>
> The problem is that an user may want to show a tree or blog object from
> master:
>
> $git show master:git.c
Or the user may want to see only changes to the documentation, e.g.
$ git show master Documentation/
so removing a SP is a regression in the other way around.
Given that "refer to an object in a tree" is a much less often used
operation, I have a feeling that the current behaviour happens to
make a good trade-off between these two conflicting purposes that
cannot be satisfied both at the same time.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #05; Fri, 11)
From: Junio C Hamano @ 2013-01-13 23:02 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <CACsJy8CRbkLAD7LtoE_6FA_zW4YTW6Nb0mJU3ejqbu5URTrU1Q@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Sat, Jan 12, 2013 at 6:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * nd/parse-pathspec (2013-01-11) 20 commits
>>
>> Uses the parsed pathspec structure in more places where we used to
>> use the raw "array of strings" pathspec.
>>
>> Unfortunately, this conflicts a couple of topics in flight. I tried
>> to be careful while resolving conflicts, though.
>
> parse_pathspec has not picked up init_pathspec changes from
> jk/pathspec-literal and nd/pathspec-wildcard (already in master) so
> --literal-pathspecs is probably broken in 'pu' after a lot of
> init_pathspec -> parse_pathspec conversion.
I guess it may be a better way forward to hold the series off, and
instead help polishing the other topics that are depended on so that
they can graduate sooner, given multiple topics in flight wants to
touch pathspecs (either change the way they are handled, or adds new
places that use them).
^ permalink raw reply
* Re: [PATCH v5] git-completion.bash: add support for path completion
From: Junio C Hamano @ 2013-01-13 22:56 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git, szeder, felipe.contreras, peff
In-Reply-To: <50F178C8.40806@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> Il 11/01/2013 23:02, Junio C Hamano ha scritto:
>> Manlio Perillo <manlio.perillo@gmail.com> writes:
>>
>>> +# Process path list returned by "ls-files" and "diff-index --name-only"
>>> +# commands, in order to list only file names relative to a specified
>>> +# directory, and append a slash to directory names.
>>> +__git_index_file_list_filter ()
>>> +{
>>> + # Default to Bash >= 4.x
>>> + __git_index_file_list_filter_bash
>>> +}
>>> +
>>> +# Execute git ls-files, returning paths relative to the directory
>>> +# specified in the first argument, and using the options specified in
>>> +# the second argument.
>>> +__git_ls_files_helper ()
>>> +{
>>> + # NOTE: $2 is not quoted in order to support multiple options
>>> + cd "$1" && git ls-files --exclude-standard $2
>>> +} 2>/dev/null
>>
>> I think this redirection is correct but a bit tricky;
>
> It's not tricky: it is POSIX:
I know that. It is an instance of "Even it is in POSIX, we may want
to refrain using it, because some shells get it wrong, and it is
easy to work it around".
>> effect during the execution of the { block } (in other words, it is
>> not about squelching errors during the function definition).
>
> What do you mean by "squelching"?
Silencing, not showing the end user. Sending to /dev/null.
> I have added tcsh to the sh list, but it fails with:
> Badly placed ()'s.
tcsh (and csh) are not even in the Bourne shell family and is not
expected to be able to run any non trivial POSIX shell scripts. The
completion script for it does not dot-source this but instead lets
bash read it, so it is fine.
>> It however may affect zsh, which does seem to dot-source this file.
>> Perhaps zsh completion may have to be rewritten in a similar way as
>> tcsh completion is done (i.e. does not dot-source this file but ask
>> bash to do the heavy-lifting).
>
> Ok, I was wrong on assuming all modern shells were POSIX compliant.
Shells in csh family will never be, and being non-POSIX is not a
crime. It only matters when such a shell is allowed to dot-source
this script, and this script uses constructs that such a shell does
not understand.
> I will change the code to use a nested {} group.
>
>> This function seems to be always called in an subshell (e.g. as an
>> upstream of a pipeline), so the "cd" may be harmless, but don't you
>> need to disable CDPATH while doing this?
>
> I don't know.
The caller of this function figures out the value of $subdirname,
and calls you; your "cd $subdirname" may not go to ./$subdirname as
you expect, but to the $subdirname directory under one of the
directories listed in CDPATH, before running ls-tree or ls-files.
^ permalink raw reply
* Re: [PATCH v5] git-completion.bash: add support for path completion
From: Junio C Hamano @ 2013-01-13 22:46 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git, szeder, felipe.contreras, peff
In-Reply-To: <50F15CB9.5090603@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
>> + # Skip "git" (first argument)
>> + for ((i=1; i < ${#words[@]}; i++)); do
>> + word="${words[i]}"
>> +
>> + case "$word" in
>> + --)
>
> Sorry, I have incorrectly (again) indented the case labels.
> I have now configured my editor to correctly indent this.
Yeah, thanks for spotting.
I wouldn't worry *too* much about the style in this script at this
point, though. It uses a style on its own that is totally different
from the rest of the system (e.g. "[" instead of "test", semicolon
in "if ...; then", etc.) and it probably is better to emulate the
surrounding code, and leave the style "fixes" to a separate topic,
if we want to (as a contrib/ material that is not POSIX but bash
specific, I do not know if that is even worth it).
>> + # Good; we can assume that the following are only non
>> + # option arguments.
>> + ((c = 0))
>> + ;;
>
> Here I was thinking to do something like this (not tested):
>
> -*)
> if [ -n ${2-} ]; then
> # Assume specified git command only
> # accepts simple options
> # (without arguments)
> ((c = 0))
>
> Since git mv only accepts simple options, this will make the use of '--'
> not required.
Unless you have a file whose name begins with a dash, perhaps?
^ permalink raw reply
* Re: [PATCH] tests: turn on test-lint-shell-syntax by default
From: Junio C Hamano @ 2013-01-13 22:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Torsten Bögershausen, git
In-Reply-To: <20130113173207.GC5973@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Hi,
>
> Torsten Bögershausen wrote:
>
>> - /^\s*[^#]\s*which\s/ and err 'which is not portable (please use type)';
>> + /^\s*[^#]\s*which\s+[-a-zA-Z0-9]+$/ and err 'which is not portable (please use type)';
>
> Hmm. Neither the old version nor the new one matches what seem to
> be typical uses of 'which', based on a quick code search:
>
> if which sl >/dev/null 2>&1
> then
> sl -l
> ...
> fi
>
> or
>
> if test -x "$(which sl 2>/dev/null)"
> then
> sl -l
> ...
> fi
Yes, these two misuses are what we want it to trigger on, so the
test is very easy to trigger and produce a false positive, but does
not trigger on what we really want to catch.
That does not sound like a good benefit/cost ratio to me.
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Junio C Hamano @ 2013-01-13 22:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Michael Haggerty, Eric S. Raymond, git, Chris Rorvick
In-Reply-To: <20130112182649.GC4624@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Michael Haggerty wrote:
>
>> Regarding your claim that "within a few months the Perl git-cvsimport is
>> going to cease even pretending to work": It might be that the old
>> git-cvsimport will stop working *for people who upgrade to cvsps 3.x*.
>> But it is not realistic to expect people to synchronize their git and
>> cvsps version upgrades. It is even quite possible that this or that
>> Linux distribution will package incompatible versions of the two packages.
>
> Moreover, I feel an obligation to point the following out:
>
> In a hypothetical world where cvsps 3.x simply breaks "git cvsimport"
> it is likely that some distributions would just stick to the existing
> cvsps and not upgrade to 3.x. Maybe that's a wrong choice, but that's
> a choice some would make. An even more likely outcome in that
> hypothetical world is that they would ship it renamed to something
> like "cvsps3" alongside the existing cvsps. Or they could rename the
> old version to "cvsps2". If we were the last holdout, we could even
> bundle it as compat/cvsps.
>
> So please do not act as though the cvsps upgrade is a crisis that we
> need to break ourselves for at threat of no longer working at all.
> The threat doesn't hold water.
>
> Luckily you have already written patches to make "git cvsimport" work
> with cvsps 3.x, and through your work you are making a better
> argument: "The new cvsimport + cvsps will work better, at least for
> some users, than the old tool."
>
> Just don't pretend you have the power to force a change for a less
> sensible reason than that!
After a quick survey of various distros, I think it is very unlikely
that we will see "distros move on to newer cvsps, leaving cvsimport
broken" situation. If anything, it is more like "distros decide to
ignore the new cvsps, until it is made to work with cvsimport" [*1*].
I think it is probably sensible to rename the current cvsimport to
cvsimport-2, write a small wrapper git-cvsimport.sh which is
something like this:
----- >8 -----
#!/bin/sh
if test -z "$GIT_CVSPS_VERSION"
then
case "$(cvsps -h 2>&1 | grep 'cvsps version')" in
2.*)
GIT_CVSPS_VERSION=2
;;
3.*)
GIT_CVSPS_VERSION=3
;;
esac
fi
if test -z "$GIT_CVSPS_VERSION"
then
echo >&2 "No supported cvsps available"
exit 1
fi
exec git cvsimport-$GIT_CVSPS_VERSION "$@"
----- 8< -----
and put Eric's one as git-cvsimport-3 (after ripping out the code to
fallback to the old cvsimport). The longer term trend will be to
move away from cvsimport-2, as it is unlikely cvsps-2.x will gain
improvements, if any; keeping fallback code outside cvsimport-3 will
be a better first step in the healthier long term code evolution.
We will keep the current t96xx series of tests, and have them export
GIT_CVSPS_VERSION=2 at the beginning, protect them with test prereq
that requires presence of cvsps 2.x; this will still make sure that
the current cvsimport users will not see any regressions.
Eric's one should be polished enough to produce good results on the
simpler sample CVS histories t96xx deal with soonish if not right
now, so we can use a method similar to how we shared tests between
blame and annotate while both were _different_ implementations to
make sure the newer blame did not inroduce regression by running the
same set of tests. Where the result _ought_ to differ, we should
also add tests that work only with the new cvsimport, of course.
I could help getting the ball rolling on this, if everybody agrees
that the above is a sensible direction to go, given the real world
constraints of distro inertia.
Agreed?
[References]
*1* Fedora, Debian and Ubuntu do not even have cvsps 3.x in their
bleeding edges, OpenBSD and NetBSD do not seem to have it either,
and Gentoo and ArchLinux have the cvsps 3.x blocked due to
incompatiblity.
http://pkgs.fedoraproject.org/cgit/cvsps.git/
http://packages.debian.org/search?keywords=cvsps
http://packages.ubuntu.com/search?keywords=cvsps
http://packages.gentoo.org/package/dev-vcs/cvsps
https://bugs.gentoo.org/show_bug.cgi?id=450424
https://bugs.archlinux.org/task/33363?project=1&cat%5B0%5D=2&string=cvsps
^ permalink raw reply
* [PATCH] t0050: mark TC merge (case change) as success
From: Torsten Bögershausen @ 2013-01-13 20:38 UTC (permalink / raw)
To: git; +Cc: tboegi
The test "merge (case change)" passes on a case ignoring file system
Use test_expect_success to remove the "known breakage vanished"
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 78816d9..ccd685d 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -77,7 +77,7 @@ $test_case 'rename (case change)' '
'
-$test_case 'merge (case change)' '
+test_expect_success 'merge (case change)' '
rm -f CamelCase &&
rm -f camelcase &&
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH] t0050: mark TC merge (case change) as success
From: Torsten Bögershausen @ 2013-01-13 20:38 UTC (permalink / raw)
To: git; +Cc: tboegi
The test "merge (case change)" passes on a case ignoring file system
Use test_expect_success to remove the "known breakage vanished"
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 78816d9..ccd685d 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -77,7 +77,7 @@ $test_case 'rename (case change)' '
'
-$test_case 'merge (case change)' '
+test_expect_success 'merge (case change)' '
rm -f CamelCase &&
rm -f camelcase &&
--
1.8.0.197.g5a90748
^ permalink raw reply related
* Re: git list files
From: Jeff King @ 2013-01-13 20:10 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Стойчо Слепцов,
git, Jakub Narębski, Matthieu Moy
In-Reply-To: <20130113175602.GD5973@elie.Belkin>
On Sun, Jan 13, 2013 at 09:56:02AM -0800, Jonathan Nieder wrote:
> > lets, say the equivalent of the $ls -d b* within git.git root directory
> > would look like:
> >
> > ----------------
> > 98746061 jrnieder 2010-08-12 17:11 Standardize-do-.-while-0-style base85.c
> > c43cb386 pclouds 2012-10-26 22:53 Move-estimate_bisect_steps-to-li bisect.c
> > efc7df45 pclouds 2012-10-26 22:53 Move-print_commit_list-to-libgit bisect.h
> > 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.c
> > 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.h
> > ebcfa444 gitster 2012-07-23 20:56 Merge-branch-jn-block-sha1 block-sha1
>
> You might like Peff's or Jakub's tree blame script. The newest version
> I can find is
>
> http://thread.gmane.org/gmane.comp.version-control.git/168323
As far as I recall, that script works. However, I have a pure-C
blame-tree implementation that is much faster, which may also be of
interest. I need to clean up and put a few finishing touches on it to
send it to the list, but it has been in production at GitHub for a few
months. You can find it here:
git://github.com/peff/git jk/blame-tree
It's built on the regular diff traversal, just like the perl script you
linked, but doing it all in-process makes things fast. I also added a
"--max-depth" parameter for diff, so you can do:
git blame-tree --max-depth=1 -- Documentation
to recurse into the Documentation subdir, but not go into its
subdirectories. One of the things I need to clean up is that my counting
of --max-depth is different from that used by "git grep", and we would
probably want reconcile that.
-Peff
^ permalink raw reply
* Re: [PATCH] archive-tar: fix sanity check in config parsing
From: Jeff King @ 2013-01-13 20:00 UTC (permalink / raw)
To: René Scharfe; +Cc: git discussion list, Junio C Hamano
In-Reply-To: <50F2F1E9.1040700@lsrfire.ath.cx>
On Sun, Jan 13, 2013 at 06:42:01PM +0100, René Scharfe wrote:
> When parsing these config variable names, we currently check that
> the second dot is found nine characters into the name, disallowing
> filter names with a length of five characters. Additionally,
> git archive crashes when the second dot is omitted:
>
> $ ./git -c tar.foo=bar archive HEAD >/dev/null
> fatal: Data too large to fit into virtual memory space.
>
> Instead we should check if the second dot exists at all, or if
> we only found the first one.
Eek. Thanks for finding it. Your fix is obviously correct.
> --- a/archive-tar.c
> +++ b/archive-tar.c
> @@ -335,7 +335,7 @@ static int tar_filter_config(const char *var, const char *value, void *data)
> if (prefixcmp(var, "tar."))
> return 0;
> dot = strrchr(var, '.');
> - if (dot == var + 9)
> + if (dot == var + 3)
> return 0;
For the curious, the original version of the patch[1] read:
+ if (prefixcmp(var, "tarfilter."))
+ return 0;
+ dot = strrchr(var, '.');
+ if (dot == var + 9)
+ return 0;
and when I shortened the config section to "tar" in a re-roll of the
series, I missed the corresponding change to the offset.
-Peff
[1] http://thread.gmane.org/gmane.comp.version-control.git/175785/focus=175858
^ permalink raw reply
* Re: git list files
From: Стойчо Слепцов @ 2013-01-13 19:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20130113175602.GD5973@elie.Belkin>
thanks alot, Jonathan,
I'll try to search through those scripts.
Blind.
2013/1/13 Jonathan Nieder <jrnieder@gmail.com>:
> Hi,
>
> Стойчо Слепцов wrote:
>
>> lets, say the equivalent of the $ls -d b* within git.git root directory
>> would look like:
>>
>> ----------------
>> 98746061 jrnieder 2010-08-12 17:11 Standardize-do-.-while-0-style base85.c
>> c43cb386 pclouds 2012-10-26 22:53 Move-estimate_bisect_steps-to-li bisect.c
>> efc7df45 pclouds 2012-10-26 22:53 Move-print_commit_list-to-libgit bisect.h
>> 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.c
>> 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.h
>> ebcfa444 gitster 2012-07-23 20:56 Merge-branch-jn-block-sha1 block-sha1
>
> You might like Peff's or Jakub's tree blame script. The newest version
> I can find is
>
> http://thread.gmane.org/gmane.comp.version-control.git/168323
>
> If you use it, let us know how it goes.
>
> Thanks for some food for thought,
> Jonathan
^ permalink raw reply
* Re: git list files
From: Стойчо Слепцов @ 2013-01-13 19:16 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqhaml9pr3.fsf@grenoble-inp.fr>
not really,
ls-tree provides the hash of blobs and trees,
what I am searching for is"the last commit"who introduced the blob or tree.
but, hey, thanks for the answer!
Blind
2013/1/13 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Стойчо Слепцов <stoycho.sleptsov@gmail.com> writes:
>
>> Hi,
>>
>> I was searching for some git- command to provide me a list of files
>> (in a git directory), same as ls,
>> but showing information from the last commit of the file instead.
>>
>> lets, say the equivalent of the $ls -d b* within git.git root directory
>> would look like:
>
> git ls-tree HEAD
>
> ?
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Mark Levedahl @ 2013-01-13 18:58 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Jason Pyeron, git, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
In-Reply-To: <CALxABCavvW77djKQnbQsjCBcahmMfrP24SDz609NG-94_ifZ9Q@mail.gmail.com>
On 01/11/2013 03:17 PM, Alex Riesen wrote:
> On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
>> This short discussion on GitHub (file git-compat-util.h) might be relevant:
>>
>> https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
>>
>> The change suggested there (to remove an inclusion of windows.h in
>> git-compat-util.h) might simplify the solution a little. Might even
>> remove the need for auto-configuration in Makefile (worked for me).
> Just to be clear, the change is this:
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 4a1979f..780a919 100644
> --- 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 <windows.h>
> -#endif
> -
> #include <unistd.h>
> #include <stdio.h>
> #include <sys/stat.h>
>
That change alone seems fine, no apparent change building on current
cygwin. However, with that change the build still fails if
CYGWIN_V15_WIN32API is defined, so unless someone can show the
compilation works on cygwin1.5 WITHOUT defining CYGWIN_V15_WIN32API this
change does not help. I do not have an older installation available, so
cannot test. Frankly, assuming you can compile with that macro defined,
I would suggest leaving well enough alone - an unsupported configuration
is unsupported :^)
Mark
^ permalink raw reply
* Re: git list files
From: Jonathan Nieder @ 2013-01-13 17:56 UTC (permalink / raw)
To: Стойчо Слепцов
Cc: git, Jeff King, Jakub Narębski, Matthieu Moy
In-Reply-To: <CAGL0X-rfrwtbtdN7O0=iMhVRYv1m0_czW8zmgT5QA3irkaeu5Q@mail.gmail.com>
Hi,
Стойчо Слепцов wrote:
> lets, say the equivalent of the $ls -d b* within git.git root directory
> would look like:
>
> ----------------
> 98746061 jrnieder 2010-08-12 17:11 Standardize-do-.-while-0-style base85.c
> c43cb386 pclouds 2012-10-26 22:53 Move-estimate_bisect_steps-to-li bisect.c
> efc7df45 pclouds 2012-10-26 22:53 Move-print_commit_list-to-libgit bisect.h
> 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.c
> 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.h
> ebcfa444 gitster 2012-07-23 20:56 Merge-branch-jn-block-sha1 block-sha1
You might like Peff's or Jakub's tree blame script. The newest version
I can find is
http://thread.gmane.org/gmane.comp.version-control.git/168323
If you use it, let us know how it goes.
Thanks for some food for thought,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/8] git_remote_helpers: Force rebuild if python version changes
From: John Keeping @ 2013-01-13 17:52 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Eric S. Raymond, Felipe Contreras, Sverre Rabbelier
In-Reply-To: <20130113171402.GA1307@padd.com>
On Sun, Jan 13, 2013 at 12:14:02PM -0500, Pete Wyckoff wrote:
> john@keeping.me.uk wrote on Sun, 13 Jan 2013 16:26 +0000:
>> On Sat, Jan 12, 2013 at 06:30:44PM -0500, Pete Wyckoff wrote:
>> > john@keeping.me.uk wrote on Sat, 12 Jan 2013 19:23 +0000:
>> >> 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.
>> >[..]
>> >> diff --git a/git_remote_helpers/Makefile b/git_remote_helpers/Makefile
>> >[..]
>> >> +py_version=$(shell $(PYTHON_PATH) -c \
>> >> + 'import sys; print("%i.%i" % sys.version_info[:2])')
>> >> +
>> >> all: $(pysetupfile)
>> >> - $(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) build
>> >> + $(QUIET)test "$$(cat GIT-PYTHON_VERSION 2>/dev/null)" = "$(py_version)" || \
>> >> + flags=--force; \
>> >> + $(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) build $$flags
>> >> + $(QUIET)echo "$(py_version)" >GIT-PYTHON_VERSION
>> >
>> > Can you depend on ../GIT-PYTHON-VARS instead? It comes from
>> > 96a4647 (Makefile: detect when PYTHON_PATH changes, 2012-12-18).
>> > It doesn't check version, just path, but hopefully that's good
>> > enough. I'm imagining a rule that would do "clean" if
>> > ../GIT-PYTHON-VARS changed, then build without --force.
>>
>> I was trying to keep the git_remote_helpers directory self contained. I
>> can't see how to depend on ../GIT-PYTHON-VARS in a way that is as simple
>> as this and keeps "make -C git_remote_helpers" working in a clean tree.
>>
>> Am I missing something obvious here?
>
> Not if it wants to stay self-contained; you're right.
>
> I'm not thrilled with how git_remote_helpers/Makefile always
> runs setup.py, and always generates PYLIBDIR, and now always
> invokes python a third time to see if its version changed.
I don't think PYLIBDIR will be calculated unless it's used ('=' not
':=' means its a deferred variable).
I wonder if the version check should move into setup.py - it would be
just as easy to check the file there and massage sys.args, although
possibly not as neat.
John
^ permalink raw reply
* [PATCH] archive-tar: fix sanity check in config parsing
From: René Scharfe @ 2013-01-13 17:42 UTC (permalink / raw)
To: git discussion list; +Cc: Jeff King, Junio C Hamano
git archive supports passing generated tar archives through filter
commands like gzip. Additional filters can be set up using the
configuration variables tar.<name>.command and tar.<name>.remote.
When parsing these config variable names, we currently check that
the second dot is found nine characters into the name, disallowing
filter names with a length of five characters. Additionally,
git archive crashes when the second dot is omitted:
$ ./git -c tar.foo=bar archive HEAD >/dev/null
fatal: Data too large to fit into virtual memory space.
Instead we should check if the second dot exists at all, or if
we only found the first one.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive-tar.c | 2 +-
t/t5000-tar-tree.sh | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index d1cce46..093d10e 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -335,7 +335,7 @@ static int tar_filter_config(const char *var, const char *value, void *data)
if (prefixcmp(var, "tar."))
return 0;
dot = strrchr(var, '.');
- if (dot == var + 9)
+ if (dot == var + 3)
return 0;
name = var + 4;
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index e7c240f..3fbd366 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -212,7 +212,8 @@ test_expect_success 'git-archive --prefix=olde-' '
test_expect_success 'setup tar filters' '
git config tar.tar.foo.command "tr ab ba" &&
git config tar.bar.command "tr ab ba" &&
- git config tar.bar.remote true
+ git config tar.bar.remote true &&
+ git config tar.invalid baz
'
test_expect_success 'archive --list mentions user filter' '
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 0/8] Initial support for Python 3
From: John Keeping @ 2013-01-13 17:35 UTC (permalink / raw)
To: Pete Wyckoff
Cc: git, Eric S. Raymond, Felipe Contreras, Sverre Rabbelier,
Sebastian Morr
In-Reply-To: <20130113164045.GA30371@padd.com>
On Sun, Jan 13, 2013 at 11:40:45AM -0500, Pete Wyckoff wrote:
> john@keeping.me.uk wrote on Sun, 13 Jan 2013 00:41 +0000:
>> On Sat, Jan 12, 2013 at 06:43:04PM -0500, Pete Wyckoff wrote:
>> > Can you give me some hints about the byte/unicode string issues
>> > in git-p4.py? There's really only one place that does:
>> >
>> > p4 = subprocess.Popen("p4 -G ...")
>> > marshal.load(p4.stdout)
>> >
>> > If that's the only issue, this might not be too paniful.
>>
>> The problem is that what gets loaded there is a dictionary (encoded by
>> p4) that maps byte strings to byte strings, so all of the accesses to
>> that dictionary need to either:
>>
>> 1) explicitly call encode() on a string constant
>> or 2) use a byte string constant with a "b" prefix
>>
>> Or we could re-write the dictionary once, which handles the keys... but
>> some of the values are also used as strings and we can't handle that as
>> a one-off conversion since in other places we really do want the byte
>> string (think content of binary files).
>>
>> Basically a thorough audit of all access to variables that come from p4
>> would be needed, with explicit decode()s for authors, dates, etc.
>
> Your auto-conversion snippet in the follow-up mail would work
> fine for most keys and values. A few perforce docs and some
> playing around convince me that it is mostly utf-8, except for
> file data for particular types.
>
> I'd still rather handle each command separately, and think about
> the conversions, to do it right in the long run.
I sent that on the assumption that the same key would have similar
semantics wherever its used, but I don't use git-p4 or know much about
perforce.
It would be interesting to know whether there is any likelihood of p4
gaining a Python 3 output mode (since the documentation currently say
not to use "p4 -G" with Python 3). If it does then I would assume that
it will make a sensible choice about unicode/bytes such that the
existing git-p4 would Just Work with only a small change to the
invocation of p4 to add the new argument.
>> > I hesitated to take Sebastian's changes due to the huge number of
>> > print() lines, but maybe a 2to3 approach would make that aspect
>> > of python3 support not too onerous.
>>
>> I think we'd want to change to print() eventually and having a single
>> codebase for 2 and 3 would be nicer for development, but I think we need
>> to be able to say "no one is using Python 2.5 or earlier" before we can
>> do that and I'm not sure we're there yet. From where we are at the
>> moment I think 2to3 is a good answer, particularly where we're already
>> using distutils to generate a release image.
>
> Agreed. The 2to3 diff is large but straightforward. But these
> p4 -G interface errors require a lot of thought and work. I'm
> not too eager to work on this yet.
Fair enough. As I don't use git-p4, it's not something I intend to
tackle either (given the scale of the changes involved).
Given the minimal scope of the changes needed for everything else, I
sent this series wondering whether it's sensible to move forward on the
basis of "Python scripts except git-p4 work with Python 3. You must use
Python 2 if you want to use git-p4".
John
^ 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