* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Sam Vilain @ 2008-07-08 21:24 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Shawn O. Pearce, Miklos Vajna, Johannes Schindelin, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <200807080227.43515.jnareb@gmail.com>
Jakub Narebski wrote:
> 1. GitTorrent (???)
>
> Student: Joshua Roys
> Mentor: Sam Vilain
>
> There was short thread of me asking about project
> http://thread.gmane.org/gmane.comp.version-control.git/83611
> where I got gittorrent mailing list (no activity at least according to
> list archive http://lists.utsl.gen.nz/pipermail/gittorrent/) and URL
> for project repo / gitweb... which is currently down, so I cannot check
> if there is anything here.
>
> What is the status of this project, please?
>
> http://www.codinghorror.com/blog/archives/001134.html ("Don't Got Dark")
>
Hi, thanks for your interest. I don't know when it was you checked - it
may have been during a brief network outage our admins needed to do
(unfortunately utsl.gen.nz is on a grace-and-favour service arrangement
with its hosts, Catalyst), but the gitweb
(http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent) is currently running, and
I hope you can see the current activity.
I announced before that I would be sending an update shortly after the
mid-term deadline, and I still plan on doing this. Please be patient
and wait until that happens in a week or so.
Cheers,
Sam.
^ permalink raw reply
* git submodules or, how do we share code between unrelated projects?
From: Jan Wielemaker @ 2008-07-08 21:11 UTC (permalink / raw)
To: Git Mailing List
Hi,
I'm looking at git-submodule, but I start to get the impression it is old
CVS jargon that brought me there.
We are two open source projects creating implementations of the Prolog
language. One (SWI-Prolog) is under GIT, the other (YAP) is under CVS
but will move to git if this helps.
We want to start sharing some developments. I guess for each (unrelated)
library we wish to share we must create a git repo, right? Now we
generally need compatibility patches to make this shared code run
on both systems and we need some way to get this code into the main
repo of both systems, such that a clone of the repo of a system gets
you the shared library.
I guess GIT must be perfect for this, but I'm a bit unsure on the
proper setup of the workflow. Is there a project that has something
similar established and has guidelines how to manage this?
Cheers --- Jan
^ permalink raw reply
* Re: [PATCH] bash: offer only paths after '--'
From: Junio C Hamano @ 2008-07-08 20:21 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Johannes Schindelin, Shawn O. Pearce, Eric Raible,
Git Mailing List
In-Reply-To: <20080708165614.GB8224@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> Hope that I got the commit message right (;
It was very readable. Thanks.
> +__git_has_doubledash ()
> +{
> + local c=1
> + while [ $c -lt $COMP_CWORD ]; do
> + if [ "--" = "${COMP_WORDS[c]}" ]; then
> + return 0
> + fi
> + c=$((++c))
This assignment is somewhat curious, although it should work as expected
either way ;-)
Shawn?
^ permalink raw reply
* Re: error: unlink(.git/refs/remotes/origin/testbranch) failed: was remote does not support deleting refs
From: Junio C Hamano @ 2008-07-08 20:04 UTC (permalink / raw)
To: Jeff King; +Cc: Dmitry Potapov, Martin, git
In-Reply-To: <20080708040801.GA7186@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It is harmless, but it still feels a little wrong to scare the user with
> that message, especially since "Failed to delete" is ambiguous; it looks
> like the main operation, deleting the remote ref, failed. But it didn't;
> the operation that failed was something not even explicitly asked for.
>
> How about this cleanup:
Ack.
^ permalink raw reply
* [StGit PATCH] Test "stg status" with -M in stgit.diff-opts
From: Karl Hasselström @ 2008-07-08 19:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Jon Smirl
In-Reply-To: <20080708195508.25030.46828.stgit@yoghurt>
It used to fail, before the recent merge of the -O/--diff-opts
removal, since the default value of that option was taken from
stgit.diff-opts and passed on to stgit.git.tree_status() which
couldn't handle it.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t0002-status.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/t/t0002-status.sh b/t/t0002-status.sh
index 5e1e8ca..86ff419 100755
--- a/t/t0002-status.sh
+++ b/t/t0002-status.sh
@@ -186,4 +186,10 @@ test_expect_success 'Status after renaming a file' '
test_cmp expected.txt output.txt
'
+test_expect_success 'Status after renaming a file (with rename detection)' '
+ git config stgit.diff-opts -M &&
+ stg status > output.txt &&
+ test_cmp expected.txt output.txt
+'
+
test_done
^ permalink raw reply related
* [StGit PATCH] stg status rename fix (safe+experimental)
From: Karl Hasselström @ 2008-07-08 19:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Jon Smirl
In-Reply-To: <20080708122502.GA8838@diana.vm.bytemark.co.uk>
This is just a patch to make sure the bug is gone; the bugfix consists
of a merge of the updated stable branch.
Both safe and experimental at git://repo.or.cz/stgit/kha.git has said
merge, and this test.
---
Karl Hasselström (1):
Test "stg status" with -M in stgit.diff-opts
t/t0002-status.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH 2/2] Don't allow extra diff options with "stg status"
From: Karl Hasselström @ 2008-07-08 19:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Jon Smirl
In-Reply-To: <20080708195214.24866.61663.stgit@yoghurt>
The only extra diff options (given either with -O/--diff-opts) that
would affect "stg status" were -C and -M, and those made it crash
because it couldn't handle them. So remove those options.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/status.py | 16 +++-------------
stgit/git.py | 9 ++++++---
t/t0002-status.sh | 5 -----
3 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/stgit/commands/status.py b/stgit/commands/status.py
index 20614b0..94d0b57 100644
--- a/stgit/commands/status.py
+++ b/stgit/commands/status.py
@@ -59,22 +59,18 @@ options = [make_option('-m', '--modified',
make_option('-x', '--noexclude',
help = 'do not exclude any files from listing',
action = 'store_true'),
- make_option('-O', '--diff-opts',
- help = 'options to pass to git-diff'),
make_option('--reset',
help = 'reset the current tree changes',
action = 'store_true')]
def status(files = None, modified = False, new = False, deleted = False,
- conflict = False, unknown = False, noexclude = False,
- diff_flags = []):
+ conflict = False, unknown = False, noexclude = False):
"""Show the tree status
"""
cache_files = git.tree_status(files,
unknown = (not files),
- noexclude = noexclude,
- diff_flags = diff_flags)
+ noexclude = noexclude)
filtered = (modified or new or deleted or conflict or unknown)
if filtered:
@@ -116,11 +112,5 @@ def func(parser, options, args):
resolved_all()
git.reset()
else:
- if options.diff_opts:
- diff_flags = options.diff_opts.split()
- else:
- diff_flags = []
-
status(args, options.modified, options.new, options.deleted,
- options.conflict, options.unknown, options.noexclude,
- diff_flags = diff_flags)
+ options.conflict, options.unknown, options.noexclude)
diff --git a/stgit/git.py b/stgit/git.py
index 8e6bdf4..35579d4 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -192,6 +192,9 @@ def ls_files(files, tree = 'HEAD', full_name = True):
'Some of the given paths are either missing or not known to GIT'
def parse_git_ls(output):
+ """Parse the output of git diff-index, diff-files, etc. Doesn't handle
+ rename/copy output, so don't feed it output generated with the -M
+ or -C flags."""
t = None
for line in output.split('\0'):
if not line:
@@ -205,7 +208,7 @@ def parse_git_ls(output):
t = None
def tree_status(files = None, tree_id = 'HEAD', unknown = False,
- noexclude = True, verbose = False, diff_flags = []):
+ noexclude = True, verbose = False):
"""Get the status of all changed files, or of a selected set of
files. Returns a list of pairs - (status, filename).
@@ -252,7 +255,7 @@ def tree_status(files = None, tree_id = 'HEAD', unknown = False,
# specified when calling the function (i.e. report all files) or
# files were specified but already found in the previous step
if not files or files_left:
- args = diff_flags + [tree_id]
+ args = [tree_id]
if files_left:
args += ['--'] + files_left
for t, fn in parse_git_ls(GRun('diff-index', '-z', *args).raw_output()):
@@ -268,7 +271,7 @@ def tree_status(files = None, tree_id = 'HEAD', unknown = False,
# function (i.e. report all files) or files were specified but
# already found in the previous step
if not files or files_left:
- args = list(diff_flags)
+ args = []
if files_left:
args += ['--'] + files_left
for t, fn in parse_git_ls(GRun('diff-files', '-z', *args).raw_output()):
diff --git a/t/t0002-status.sh b/t/t0002-status.sh
index 69c29a0..a030739 100755
--- a/t/t0002-status.sh
+++ b/t/t0002-status.sh
@@ -182,9 +182,4 @@ test_expect_success 'Status after renaming a file' '
diff -u expected.txt output.txt
'
-test_expect_failure 'Status after renaming a file (with rename detection)' '
- stg status --diff-opts=-M > output.txt &&
- diff -u expected.txt output.txt
-'
-
test_done
^ permalink raw reply related
* [StGit PATCH 0/2] stg status rename fix (stable)
From: Karl Hasselström @ 2008-07-08 19:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Jon Smirl
In-Reply-To: <20080708122502.GA8838@diana.vm.bytemark.co.uk>
This fixes the bug on the stable branch. (stgit.diff-opts doesn't
exist there, so it's less of an issue, but still.)
Also available at
git://repo.or.cz/stgit/kha.git safe
---
Karl Hasselström (2):
Don't allow extra diff options with "stg status"
Test "stg status" with renames
stgit/commands/status.py | 16 +++-------------
stgit/git.py | 9 ++++++---
t/t0002-status.sh | 11 +++++++++++
3 files changed, 20 insertions(+), 16 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH 1/2] Test "stg status" with renames
From: Karl Hasselström @ 2008-07-08 19:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Jon Smirl
In-Reply-To: <20080708195214.24866.61663.stgit@yoghurt>
Currently, it only works if -M is not passed to git diff-files, so the
second of the two tests fails.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t0002-status.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t0002-status.sh b/t/t0002-status.sh
index 43e1ca0..69c29a0 100755
--- a/t/t0002-status.sh
+++ b/t/t0002-status.sh
@@ -171,4 +171,20 @@ test_expect_success 'Status of disappeared newborn' '
diff -u expected.txt output.txt
'
+cat > expected.txt <<EOF
+A fay
+D fie
+EOF
+test_expect_success 'Status after renaming a file' '
+ git rm foo/bar &&
+ git mv fie fay &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+test_expect_failure 'Status after renaming a file (with rename detection)' '
+ stg status --diff-opts=-M > output.txt &&
+ diff -u expected.txt output.txt
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase
From: Brian Gernhardt @ 2008-07-08 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vmykstc1h.fsf@gitster.siamese.dyndns.org>
On Jul 8, 2008, at 3:23 PM, Junio C Hamano wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-
>> rebase.txt
>> index f3459c7..37382c4 100644
>> --- a/Documentation/git-rebase.txt
>> +++ b/Documentation/git-rebase.txt
>> @@ -26,7 +26,8 @@ of commits that would be shown by `git log
>> <upstream>..HEAD`.
>>
>> The current branch is reset to <upstream>, or <newbase> if the
>> --onto option was supplied. This has the exact same effect as
>> -`git reset --hard <upstream>` (or <newbase>).
>> +`git reset --hard <upstream>` (or <newbase>). This includes setting
>> +ORIG_HEAD to the pre-rebase tip of the branch.
>>
>> The commits that were previously saved into the temporary area are
>> then reapplied to the current branch, one by one, in order. Note that
>
> I found the above "This includes" part very hard to understand ---
> it took
> me three re-reads to connect "This" and "the exact same effect". Is
> it
> just me?
I thought it perfectly easy to understand. ;-) But of course, I
wrote it. I also wrote it immediately after reading the git-reset
manual, which is why I phrased it that way. On a fresh read, it's
less obvious.
> I wonder if this is easier to understand:
>
> The current branch is reset to <upstream>, or <newbase> if the
> --onto option was supplied. This has the exact same effect as
> `git reset --hard <upstream>` (or <newbase>). ORIG_HEAD is set
> to point at the tip of the branch before this resetting
> happens.
I might say "before the reset" instead of "before this resetting
happens", as I find the latter slightly awkward. But that's a minor nit
~~ Brian
^ permalink raw reply
* Re: [PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase
From: Junio C Hamano @ 2008-07-08 19:23 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1215490342-46590-1-git-send-email-benji@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index f3459c7..37382c4 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -26,7 +26,8 @@ of commits that would be shown by `git log <upstream>..HEAD`.
>
> The current branch is reset to <upstream>, or <newbase> if the
> --onto option was supplied. This has the exact same effect as
> -`git reset --hard <upstream>` (or <newbase>).
> +`git reset --hard <upstream>` (or <newbase>). This includes setting
> +ORIG_HEAD to the pre-rebase tip of the branch.
>
> The commits that were previously saved into the temporary area are
> then reapplied to the current branch, one by one, in order. Note that
I found the above "This includes" part very hard to understand --- it took
me three re-reads to connect "This" and "the exact same effect". Is it
just me?
I wonder if this is easier to understand:
The current branch is reset to <upstream>, or <newbase> if the
--onto option was supplied. This has the exact same effect as
`git reset --hard <upstream>` (or <newbase>). ORIG_HEAD is set
to point at the tip of the branch before this resetting happens.
^ permalink raw reply
* Re: GiT and CentOS 5.2
From: Junio C Hamano @ 2008-07-08 19:23 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <49523.216.185.71.22.1215539200.squirrel@webmail.harte-lyne.ca>
"James B. Byrne" <byrnejb@harte-lyne.ca> writes:
> OS = CentOS-5.2
> perl = 5.8.8
>
> I get git from the yum repository at kernel.org. Up until the most recent
> update I had no problems. Now I am getting these dependency errors:
>
> Error: Missing Dependency: libcurl.so.4 is needed by package git
> Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by
> package perl-Git
> Error: Missing Dependency: libc.so.6(GLIBC_2.7) is needed by package git
> Error: Missing Dependency: libexpat.so.1 is needed by package git
> Error: Missing Dependency: libcrypto.so.7 is needed by package git
As described in the announcement for 1.5.6.2, the machine at kernel.org I
cut x86_64 RPM on switched to FC9 early this month, and I updated my
personal bochs installation to FC9 to be consistent for producing i386
RPMs.
By the way, these RPMs are not in any way official. I have been guessing
(without even bothering to confirm) that even for FC, distro people do not
use the RPM packages I have at kernel.org, but they build and distribute
their own to their users. I could stop generating these RPMs, in other
words, but I've been doing this forever and they are still produced as
courtesy, even though I am not a FC user myself.
You could send a preconfigured CentOS 5.2 box to me and ask me to produce
yet another set of RPMs. The release procedure already takes long enough
time out of my git day, however, and I doubt I can afford the time to do
so in practice, without reducing the time I spend on other git activities
such as reviewing and accepting changes from others or writing patches
myself.
People on other platforms like Debian, Macintosh, and Windows (Cygwin and
Msys) generate their own packages from the official tarballs and
distribute the result to help other users on their platforms. Perhaps you
and other CentOS users can get together and do the same to help each
other? That would be a great help to the community.
Thanks.
^ permalink raw reply
* Re: [Fwd: Re: GiT and CentOS 5.2]
From: James B. Byrne @ 2008-07-08 19:15 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490807081158v5acb6e6co670597d5e08db6c1@mail.gmail.com>
On Tue, July 8, 2008 14:58, Jay Soffian wrote:
> You could of course answer this yourself. Download the latest RPM, rpm
> --nodeps or rpm2cpio it and see if it works.
>
> But from the looks of it, the git binary links against libraries not
> on your system and it will not work.
Yes, it appears so. Having just converted our projects from subversion to
git I am reluctant to beat my brains out trying to maintain yet another
moving target that is, in the end, only a support tool. The most recent
GiT source builds without complaint on my development system so the
dependencies are purely build environment artifacts and are not
substantive. This change to the rpm build platform is unfortunate for me
since I now lose a very convenient update process and have to choose
between rebuilding at each release or stabilizing at 1.5.6.1.
Nonetheless, I will no doubt live through this... Sigh.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
^ permalink raw reply
* Re: [Fwd: Re: GiT and CentOS 5.2]
From: Jakub Narebski @ 2008-07-08 19:12 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <50493.216.185.71.22.1215543081.squirrel@webmail.harte-lyne.ca>
"James B. Byrne" <byrnejb@harte-lyne.ca> writes:
> On Tue, July 8, 2008 14:37, Mike Hommey wrote:
> >
> > This only means the rpms in the yum repository at kernel.org were built
> > on a system more recent than yours, and that run-time dependencies (as
> > opposed to build dependencies) require some libraries to be newer than
> > what your system provides.
>
> I understand the meaning of the error messages. What I am asking is
> whether or not any of these dependencies is substantive. If they are then
> I am stuck at the immediately previous release of Git. If not then I have
> the option to either build from source or force an rpm update. If I force
> then I can no long use yum but at least I have the applicate managed by
> rpm. If I build from source then I lose that as well.
>
> So, my question still remains: are these dependencies only artifacts of
> the build environment or do they supply actual features that the latest
> release of Git depends upon and which are not available in the earlier
> version of the software?
They are artifact of the build environment (which picks up the
libraries that they are here); till 1.5.6.1 I have compiled git
and used git succesfully on Fedora Core 4 based dostribution
(Aurox 11.1).
I am now compiling[1] 1.5.6.2, and so far don't have any problems
(now it is at building documentation; it would be nice to be
able to use pre-build documentation from SRPM).
[1] $ rpmbuild --rebuild git-1.5.6.2-1.fc9.src.rpm
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [Fwd: Re: GiT and CentOS 5.2]
From: Jay Soffian @ 2008-07-08 18:58 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <50493.216.185.71.22.1215543081.squirrel@webmail.harte-lyne.ca>
On Tue, Jul 8, 2008 at 2:51 PM, James B. Byrne <byrnejb@harte-lyne.ca> wrote:
> So, my question still remains: are these dependencies only artifacts of
> the build environment or do they supply actual features that the latest
> release of GiT depends upon and which are not available in the earlier
> version of the software?
You could of course answer this yourself. Download the latest RPM, rpm
--nodeps or rpm2cpio it and see if it works.
But from the looks of it, the git binary links against libraries not
on your system and it will not work.
j.
^ permalink raw reply
* [Fwd: Re: GiT and CentOS 5.2]
From: James B. Byrne @ 2008-07-08 18:51 UTC (permalink / raw)
To: git
On Tue, July 8, 2008 14:37, Mike Hommey wrote:
>
> This only means the rpms in the yum repository at kernel.org were built
> on a system more recent than yours, and that run-time dependencies (as
> opposed to build dependencies) require some libraries to be newer than
> what your system provides.
I understand the meaning of the error messages. What I am asking is
whether or not any of these dependencies is substantive. If they are then
I am stuck at the immediately previous release of GiT. If not then I have
the option to either build from source or force an rpm update. If I force
then I can no long use yum but at least I have the applicate managed by
rpm. If I build from source then I lose that as well.
So, my question still remains: are these dependencies only artifacts of
the build environment or do they supply actual features that the latest
release of GiT depends upon and which are not available in the earlier
version of the software?
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
^ permalink raw reply
* Re: GiT and CentOS 5.2
From: Jay Soffian @ 2008-07-08 18:51 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <49523.216.185.71.22.1215539200.squirrel@webmail.harte-lyne.ca>
On Tue, Jul 8, 2008 at 1:46 PM, James B. Byrne <byrnejb@harte-lyne.ca> wrote:
> OS = CentOS-5.2
> perl = 5.8.8
>
> I get git from the yum repository at kernel.org. Up until the most recent
> update I had no problems. Now I am getting these dependency errors:
>
> Error: Missing Dependency: libcurl.so.4 is needed by package git
> Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by
> package perl-Git
> Error: Missing Dependency: libc.so.6(GLIBC_2.7) is needed by package git
> Error: Missing Dependency: libexpat.so.1 is needed by package git
> Error: Missing Dependency: libcrypto.so.7 is needed by package git
>
>
> Are these dependencies actually meaningful? By that I mean, are there
> features used in the latest release of GiT that depend upon features of
> GLIBC 2.7 that are not part of glibc-2.5? Similarly, are there features
> of curl used in the latest git that are not present or work differently in
> curl 7.15.2? Ditto for OpenSSL and libxpat.
>
> I would like to stay current with git but I cannot if these dependencies
> are actually required.
Junio switched to FC9 for building the git RPMs on kernel.org recently.
Probably the best thing to do if you want a CentOS 5.x RPM is to grab
the source tgz and build the RPM yourself. :-(
There are quite a few build-time dependencies, but those are easy to
take care of with yum.
j.
^ permalink raw reply
* Re: GiT and CentOS 5.2
From: Mike Hommey @ 2008-07-08 18:37 UTC (permalink / raw)
To: James B. Byrne; +Cc: git
In-Reply-To: <49523.216.185.71.22.1215539200.squirrel@webmail.harte-lyne.ca>
On Tue, Jul 08, 2008 at 01:46:40PM -0400, James B. Byrne wrote:
> OS = CentOS-5.2
> perl = 5.8.8
>
> I get git from the yum repository at kernel.org. Up until the most recent
> update I had no problems. Now I am getting these dependency errors:
>
> Error: Missing Dependency: libcurl.so.4 is needed by package git
> Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by
> package perl-Git
> Error: Missing Dependency: libc.so.6(GLIBC_2.7) is needed by package git
> Error: Missing Dependency: libexpat.so.1 is needed by package git
> Error: Missing Dependency: libcrypto.so.7 is needed by package git
>
>
> Are these dependencies actually meaningful? By that I mean, are there
> features used in the latest release of GiT that depend upon features of
> GLIBC 2.7 that are not part of glibc-2.5? Similarly, are there features
> of curl used in the latest git that are not present or work differently in
> curl 7.15.2? Ditto for OpenSSL and libxpat.
This only means the rpms in the yum repository at kernel.org were built
on a system more recent than yours, and that run-time dependencies (as
opposed to build dependencies) require some libraries to be newer than
what your system provides.
Mike
^ permalink raw reply
* GiT and CentOS 5.2
From: James B. Byrne @ 2008-07-08 17:46 UTC (permalink / raw)
To: git
OS = CentOS-5.2
perl = 5.8.8
I get git from the yum repository at kernel.org. Up until the most recent
update I had no problems. Now I am getting these dependency errors:
Error: Missing Dependency: libcurl.so.4 is needed by package git
Error: Missing Dependency: perl(:MODULE_COMPAT_5.10.0) is needed by
package perl-Git
Error: Missing Dependency: libc.so.6(GLIBC_2.7) is needed by package git
Error: Missing Dependency: libexpat.so.1 is needed by package git
Error: Missing Dependency: libcrypto.so.7 is needed by package git
Are these dependencies actually meaningful? By that I mean, are there
features used in the latest release of GiT that depend upon features of
GLIBC 2.7 that are not part of glibc-2.5? Similarly, are there features
of curl used in the latest git that are not present or work differently in
curl 7.15.2? Ditto for OpenSSL and libxpat.
I would like to stay current with git but I cannot if these dependencies
are actually required.
Regards,
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
^ permalink raw reply
* [PATCH] Git.pm: Add remote_refs() git-ls-remote frontend
From: Petr Baudis @ 2008-07-08 17:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch also converts the good ole' git-remote.perl to use it.
It is otherwise used in the repo.or.cz machinery and I guess other
scripts might find it useful too.
Unfortunately,
git-ls-remote --heads .
is subtly different from
git-ls-remote . refs/heads/
(since the second matches anywhere in the string, not just at the
beginning) so we have to provide interface for both.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
This is resend after another year. ;-)
contrib/examples/git-remote.perl | 5 +--
perl/Git.pm | 56 +++++++++++++++++++++++++++++++++++++-
2 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/contrib/examples/git-remote.perl b/contrib/examples/git-remote.perl
index b30ed73..36bd54c 100755
--- a/contrib/examples/git-remote.perl
+++ b/contrib/examples/git-remote.perl
@@ -129,10 +129,7 @@ sub update_ls_remote {
return if (($harder == 0) ||
(($harder == 1) && exists $info->{'LS_REMOTE'}));
- my @ref = map {
- s|^[0-9a-f]{40}\s+refs/heads/||;
- $_;
- } $git->command(qw(ls-remote --heads), $info->{'URL'});
+ my @ref = map { s|refs/heads/||; $_; } keys %{$git->remote_refs($info->{'URL'}, [ 'heads' ])};
$info->{'LS_REMOTE'} = \@ref;
}
diff --git a/perl/Git.pm b/perl/Git.pm
index 97e61ef..d99e778 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -56,7 +56,8 @@ require Exporter;
@EXPORT_OK = qw(command command_oneline command_noisy
command_output_pipe command_input_pipe command_close_pipe
command_bidi_pipe command_close_bidi_pipe
- version exec_path hash_object git_cmd_try);
+ version exec_path hash_object git_cmd_try
+ remote_refs);
=head1 DESCRIPTION
@@ -668,6 +669,59 @@ sub get_color {
return $color;
}
+=item remote_refs ( REPOSITORY [, GROUPS [, REFGLOBS ] ] )
+
+This function returns a hashref of refs stored in a given remote repository.
+The hash is in the format C<refname =\> hash>. For tags, the C<refname> entry
+contains the tag object while a C<refname^{}> entry gives the tagged objects.
+
+C<REPOSITORY> has the same meaning as the appropriate C<git-ls-remote>
+argument; either an URL or a remote name (if called on a repository instance).
+C<GROUPS> is an optional arrayref that can contain 'tags' to return all the
+tags and/or 'heads' to return all the heads. C<REFGLOB> is an optional array
+of strings containing a shell-like glob to further limit the refs returned in
+the hash; the meaning is again the same as the appropriate C<git-ls-remote>
+argument.
+
+This function may or may not be called on a repository instance. In the former
+case, remote names as defined in the repository are recognized as repository
+specifiers.
+
+=cut
+
+sub remote_refs {
+ my ($self, $repo, $groups, $refglobs) = _maybe_self(@_);
+ my @args;
+ if (ref $groups eq 'ARRAY') {
+ foreach (@$groups) {
+ if ($_ eq 'heads') {
+ push (@args, '--heads');
+ } elsif ($_ eq 'tags') {
+ push (@args, '--tags');
+ } else {
+ # Ignore unknown groups for future
+ # compatibility
+ }
+ }
+ }
+ push (@args, $repo);
+ if (ref $refglobs eq 'ARRAY') {
+ push (@args, @$refglobs);
+ }
+
+ my @self = $self ? ($self) : (); # Ultra trickery
+ my ($fh, $ctx) = Git::command_output_pipe(@self, 'ls-remote', @args);
+ my %refs;
+ while (<$fh>) {
+ chomp;
+ my ($hash, $ref) = split(/\t/, $_, 2);
+ $refs{$ref} = $hash;
+ }
+ Git::command_close_pipe(@self, $fh, $ctx);
+ return \%refs;
+}
+
+
=item ident ( TYPE | IDENTSTR )
=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
^ permalink raw reply related
* Re: [PATCH] bash: offer only paths after '--'
From: Eric Raible @ 2008-07-08 17:46 UTC (permalink / raw)
To: git
In-Reply-To: <20080708165614.GB8224@neumann>
SZEDER Gábor <szeder <at> ira.uka.de> writes:
>
> Many git commands use '--' to separate subcommands, options, and refs
> from paths. However, the programmable completion for several of these
> commands does not respect the '--', and offer subcommands, options, or
> refs after a '--', although only paths are permitted. e.g. 'git bisect
I like this change, but how about also offering a plain '--' as one
of the completion choices as a way of reminding newbies that the
command in question is one of the ones that takes filenames after
all options?
^ permalink raw reply
* git-svn dcommit and setting svn properties
From: Tim Prouty @ 2008-07-08 17:30 UTC (permalink / raw)
To: git
Hi,
My internal subversion repository has a pre-commit script that
requires the svn:mime-type and svn:eol-style properties to be set on
any new file before it can be added to the repository. If these
properties aren't set, the commit fails. When using git-svn dcommit
to commit a patch that adds a new file, the dcommit also fails with
the error below. I have added auto-props rules in my ~/.subversion/
config file to automatically set these properties based on file
extension, so an svn commit doesn't require explicitly setting them.
I tried adding the --config-dir=~/.subversion option to the dcommit
command, but it didn't seem to make a difference.
Is there any way to set these properties or consult subversion auto-
props so that git-svn knows how to set them during the dcommit? Would
it be difficult to add this capability if it doesn't already exist?
Example command and subsequent error:
# git-svn dcommit --verbose --config-dir=~/.subversion
Committing to https://svn/repo/foo ...
A bar.c
A repository hook failed: MERGE request failed on '/repo/foo': 'pre-
commit' hook failed with error output:
/svnrepo/hooks/check-mime-type.pl:
foo/bar.c : svn:mime-type is not set
Every added file must have the svn:mime-type property set. In
addition text files must have the svn:eol-style property set.
For binary files try running
svn propset svn:mime-type application/octet-stream path/of/file
For text files try
svn propset svn:mime-type text/plain path/of/file
svn propset svn:eol-style native path/of/file
You may want to consider uncommenting the auto-props section
in your ~/.subversion/config file. Read the Subversion book
(http://svnbook.red-bean.com/), Chapter 7, Properties section,
Automatic Property Setting subsection for more help.
at /usr/bin/git-svn line 461
Thanks!
-Tim
^ permalink raw reply
* Re: [take 2] revision parsing made incremental
From: Linus Torvalds @ 2008-07-08 17:41 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster, peff, Johannes.Schindelin
In-Reply-To: <1215523175-28436-1-git-send-email-madcoder@debian.org>
On Tue, 8 Jul 2008, Pierre Habouzit wrote:
>
> The series passes the testsuite, has no know blanks issues, and is
> pushed to my public repository.
Ack. Looks good to me.
Linus
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Jakub Narebski @ 2008-07-08 17:31 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, git, Christian Couder, Daniel Barkalow
In-Reply-To: <20080708163430.GK6726@leksak.fem-net>
Hi!
On Wed, 8 July 2008, Stephan Beyer wrote:
> Jakub Narebski wrote:
>> Stephan Beyer wrote:
>>>
>>> It is taking the commit message from the commit in the "From <commit> .*"
>>> line, does *not* change it in any way and then applies the changes using
>>> threeway merge.
>>
>> Not exactly. "git am --rebasing" still tries to first just *apply*
>> the patch, then (I think) it falls back on blob-id based 3way merge.
>
> That's of course totaly right and what I've meant, but unfortunately not
> what I've written ;-)
>
>>> Keeping that in mind what about dealing with --rebasing like that:
>>> if --rebasing is given, git am simply generates
>>> pick <commit>
>>> lines, instead of
>>> patch -3 -k <msg>
>>> as it is now (and this is not enough, as it seems).
>>
>> It is not.
>>
>> Nevertheless it would be I think better for ordinary patch based rebase
>> to fall back not on git-am 3way merge, but on cherry-pick based merge
>> (i.e. on pick).
>
> Hmm, if I get you right you _partly_ agree with me in choosing "pick" for
> am --rebasing... But cherry-pick should only be chosen if a simple git-apply
> failed first. Right?
Right.
> I just got another idea which could easily be done and perhaps is the
> right thing :)
> Generating
> patch -C <commit> -3 <file>
>
> This takes authorship and message from <commit> and does the usual
> threeway-fallback behavior.
>
> What do you think?
Very good idea (I have proposed something similar either here on in
another thread). It would avoid some unnecessary "marshalling" and
"unmarshalling" which is needed to transfer commit message [unchanged]
through git-format-patch -> git-am pipeline, namely putting first
paragraph into subject line, generating then parsing RFC-2822 date,
using quoted printable encoding for first paragraph / subject header
(I think).
It would be still better to fallback to _pick_, not "git am --3way",
as the latter IIRC use _shortened_ _blob_ identifiers for pre- and
post-image to find common ancestor (merge base) for 3way merge.
Which is not necessary as we can find merge base and base commits
easier.
--
Jakub Narebski
Poland
^ permalink raw reply
* [HACK] gitweb: Support hiding of chosen repositories from project list
From: Petr Baudis @ 2008-07-08 16:56 UTC (permalink / raw)
To: git
This makes it possible to hide certain repository from project list
(while still keeping it accessible, so it's not just an inverse of
export-ok). By default the file that needs to be created in the
repository is '.hide'.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I used this for something at repo.or.cz, but it is actually lying around
unused in my patch queue now; before removing it, I'm going to archive it on
the mailing list, maybe someone will find it useful.
Makefile | 2 ++
gitweb/gitweb.perl | 11 +++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 3314dd6..b7c7f42 100644
--- a/Makefile
+++ b/Makefile
@@ -195,6 +195,7 @@ GITWEB_SITENAME =
GITWEB_PROJECTROOT = /pub/git
GITWEB_PROJECT_MAXDEPTH = 2007
GITWEB_EXPORT_OK =
+GITWEB_HIDE_REPO = .hide
GITWEB_STRICT_EXPORT =
GITWEB_BASE_URL =
GITWEB_LIST =
@@ -1130,6 +1131,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
-e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
-e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
+ -e 's|++GITWEB_HIDE_REPO++|$(GITWEB_HIDE_REPO)|g' \
-e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
-e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
-e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3b02d87..7ad0faa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -90,6 +90,11 @@ our $default_projects_order = "project";
# (only effective if this variable evaluates to true)
our $export_ok = "++GITWEB_EXPORT_OK++";
+# hide repository from the list if this file exists
+# (the repository is still accessible, just not shown in the project list)
+# (only effective if this variable evaulates to true)
+our $hide_repo = "++GITWEB_HIDE_REPO++";
+
# only allow viewing of repositories also shown on the overview page
our $strict_export = "++GITWEB_STRICT_EXPORT++";
@@ -1796,7 +1801,8 @@ sub git_get_projects_list {
# we check related file in $projectroot
if ($check_forks and $subdir =~ m#/.#) {
$File::Find::prune = 1;
- } elsif (check_export_ok("$projectroot/$filter/$subdir")) {
+ } elsif ((!$hide_repo or ! -e "$projectroot/$filter/$subdir/$hide_repo")
+ and check_export_ok("$projectroot/$filter/$subdir")) {
push @list, { path => ($filter ? "$filter/" : '') . $subdir };
$File::Find::prune = 1;
}
@@ -1846,7 +1852,8 @@ sub git_get_projects_list {
next PROJECT;
}
}
- if (check_export_ok("$projectroot/$path")) {
+ if ((!$hide_repo or ! -e "$projectroot/$path/$hide_repo")
+ and check_export_ok("$projectroot/$path")) {
my $pr = {
path => $path,
owner => to_utf8($owner),
^ permalink raw reply related
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