* [PATCH 5/9 v5] commit: add "bisect_replace_all" prototype to "commit.h"
From: Christian Couder @ 2008-11-24 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 2 +-
commit.h | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 693023f..1b18c65 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -637,7 +637,7 @@ static int bisect_replace(const char *refname, const unsigned char *sha1,
return 0;
}
-static void bisect_replace_all(void)
+void bisect_replace_all(void)
{
for_each_replace_ref(bisect_replace, NULL);
}
diff --git a/commit.h b/commit.h
index 3a7b06a..a0ec2a0 100644
--- a/commit.h
+++ b/commit.h
@@ -144,4 +144,6 @@ static inline int single_parent(struct commit *commit)
struct commit_list *reduce_heads(struct commit_list *heads);
+void bisect_replace_all(void);
+
#endif /* COMMIT_H */
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* [PATCH 6/9 v5] merge-base: add "--bisect-replace" option to use fixed up revs
From: Christian Couder @ 2008-11-24 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, H. Peter Anvin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-merge-base.txt | 6 +++++-
builtin-merge-base.c | 8 +++++++-
t/t6035-bisect-replace.sh | 7 +++++++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
index 2f0c525..2a41e33 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -8,7 +8,7 @@ git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
-'git merge-base' [--all] <commit> <commit>...
+'git merge-base' [--all] [--bisect-replace] <commit> <commit>...
DESCRIPTION
-----------
@@ -32,6 +32,10 @@ OPTIONS
--all::
Output all merge bases for the commits, instead of just one.
+--bisect-replace::
+ Use fixed up history from "refs/replace/bisect/*" refs when
+ computing merge bases.
+
DISCUSSION
----------
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 03fc1c2..6e58660 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -46,9 +46,13 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
struct commit **rev;
int rev_nr = 0;
int show_all = 0;
+ int bisect_replace = 0;
struct option options[] = {
- OPT_BOOLEAN('a', "all", &show_all, "outputs all common ancestors"),
+ OPT_BOOLEAN('a', "all", &show_all,
+ "outputs all common ancestors"),
+ OPT_BOOLEAN(0, "bisect-replace", &bisect_replace,
+ "use revs from 'refs/replace/bisect/*' refs"),
OPT_END()
};
@@ -56,6 +60,8 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, options, merge_base_usage, 0);
if (argc < 2)
usage_with_options(merge_base_usage, options);
+ if (bisect_replace)
+ bisect_replace_all();
rev = xmalloc(argc * sizeof(*rev));
while (argc-- > 0)
rev[rev_nr++] = get_commit_reference(*argv++);
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index bc07206..8fe7cc5 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -137,6 +137,13 @@ test_expect_success '"git rev-list --bisect-replace" works' '
test_cmp rev_list.expect rev_list.output
'
+test_expect_success '"git merge-base --bisect-replace" works' '
+ hash=$(git merge-base --all --bisect-replace $HASH7 $HASHFIX3) &&
+ test "$hash" = "$HASHFIX3" &&
+ hash=$(git merge-base --all --bisect-replace $HASH7 $HASH3) &&
+ test "$hash" = "$HASH1"
+'
+
#
#
test_done
--
1.5.6.1.1657.g6a50
^ permalink raw reply related
* Re: How to hide a git repository?
From: Heikki Orsila @ 2008-11-25 0:37 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <962463.96236.qm@web37905.mail.mud.yahoo.com>
On Mon, Nov 24, 2008 at 04:32:58PM -0800, Gary Yang wrote:
>
> We have two repositories, one is /pub/git/dev/linux/kernel, another
> is /pub/git/pub/linux/kernel. The /pub/git/pub/linux/kernel is open to
> public for people to download released code. /pub/git/dev/linux/kernel
> is used for our development. We would like to hide
> /pub/git/dev/linux/kernel from public. How to do it?
Tell "git daemon" only to publish /pub/git/pub/linux/kernel.
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply
* Re: How to hide a git repository?
From: Gary Yang @ 2008-11-25 1:40 UTC (permalink / raw)
To: Heikki Orsila; +Cc: git
In-Reply-To: <20081125003758.GA6115@zakalwe.fi>
How to tell "git daemon" only to publish /pub/git/pub/linux/kernel ?
--- On Mon, 11/24/08, Heikki Orsila <shdl@zakalwe.fi> wrote:
> From: Heikki Orsila <shdl@zakalwe.fi>
> Subject: Re: How to hide a git repository?
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: git@vger.kernel.org
> Date: Monday, November 24, 2008, 4:37 PM
> On Mon, Nov 24, 2008 at 04:32:58PM -0800, Gary Yang wrote:
> >
> > We have two repositories, one is
> /pub/git/dev/linux/kernel, another
> > is /pub/git/pub/linux/kernel. The
> /pub/git/pub/linux/kernel is open to
> > public for people to download released code.
> /pub/git/dev/linux/kernel
> > is used for our development. We would like to hide
> > /pub/git/dev/linux/kernel from public. How to do it?
>
> Tell "git daemon" only to publish
> /pub/git/pub/linux/kernel.
>
> --
> Heikki Orsila
> heikki.orsila@iki.fi
> http://www.iki.fi/shd
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: How to hide a git repository?
From: Gary Yang @ 2008-11-25 2:16 UTC (permalink / raw)
To: git
In-Reply-To: <962463.96236.qm@web37905.mail.mud.yahoo.com>
Do I have to create two git servers? One is for public to download the released code. For example: gitpub.mycompany.com:/pub/linux/kernel. gitpub.mycompany.com is accessible to public. Another is for internal development. For example: gitdev.mycompany.com:/dev/linux/kernel. gitdev.mycompany.com is only accessible to our development team. I push code from gitdev.mycompany.com:/dev/linux/kernel to gitpub.mycompany.com:/publinux/kernel once we completed our development. Is this the only way to do it?
--- On Mon, 11/24/08, Gary Yang <garyyang6@yahoo.com> wrote:
> From: Gary Yang <garyyang6@yahoo.com>
> Subject: How to hide a git repository?
> To: git@vger.kernel.org
> Date: Monday, November 24, 2008, 4:32 PM
> We have two repositories, one is /pub/git/dev/linux/kernel,
> another is /pub/git/pub/linux/kernel. The
> /pub/git/pub/linux/kernel is open to public for people to
> download released code. /pub/git/dev/linux/kernel is used
> for our development. We would like to hide
> /pub/git/dev/linux/kernel from public. How to do it?
>
> Why we want to hide /pub/git/dev/linux/kernel from public?
> We work on our development at /pub/git/dev/linux/kernel. We
> push our released code to /pub/git/pub/linux/kernel from
> /pub/git/dev/linux/kernel once we completed our development.
> We do not want people to download code from
> /pub/git/dev/linux/kernel since it is not stable.
>
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: How to hide a git repository?
From: Bruno Cesar Ribas @ 2008-11-25 3:58 UTC (permalink / raw)
To: Gary Yang; +Cc: Heikki Orsila, git
In-Reply-To: <940723.36955.qm@web37906.mail.mud.yahoo.com>
On Mon, Nov 24, 2008 at 05:40:22PM -0800, Gary Yang wrote:
> How to tell "git daemon" only to publish /pub/git/pub/linux/kernel ?
$ man git-daemon
<snip>
It verifies that the directory has the magic file
"git-daemon-export-ok", and it will refuse to export any git directory
that hasn´t explicitly been marked for export this way (unless the
--export-all parameter is specified). If you pass some directory paths
as git-daemon arguments, you can further restrict the offers to a
whitelist comprising of those.
</snip>
Hope this helps
>
>
> --- On Mon, 11/24/08, Heikki Orsila <shdl@zakalwe.fi> wrote:
>
> > From: Heikki Orsila <shdl@zakalwe.fi>
> > Subject: Re: How to hide a git repository?
> > To: "Gary Yang" <garyyang6@yahoo.com>
> > Cc: git@vger.kernel.org
> > Date: Monday, November 24, 2008, 4:37 PM
> > On Mon, Nov 24, 2008 at 04:32:58PM -0800, Gary Yang wrote:
> > >
> > > We have two repositories, one is
> > /pub/git/dev/linux/kernel, another
> > > is /pub/git/pub/linux/kernel. The
> > /pub/git/pub/linux/kernel is open to
> > > public for people to download released code.
> > /pub/git/dev/linux/kernel
> > > is used for our development. We would like to hide
> > > /pub/git/dev/linux/kernel from public. How to do it?
> >
> > Tell "git daemon" only to publish
> > /pub/git/pub/linux/kernel.
> >
> > --
> > Heikki Orsila
> > heikki.orsila@iki.fi
> > http://www.iki.fi/shd
> > --
> > To unsubscribe from this list: send the line
> > "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Bruno Ribas - ribas@c3sl.ufpr.br
http://www.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br
^ permalink raw reply
* Re: [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-11-25 5:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: gitster, git
In-Reply-To: <m31vx3l94x.fsf@localhost.localdomain>
> But that is contrary to the _name_ of option. It is --show-cdup, as
> in "show cd up". And I think your change will break a few scripts.
>
> I think you should use "git rev-parse --work-tree" for full path
> to working directory:
>
> --show-cdup
> When the command is invoked from a subdirectory, show the path
> of the top-level directory relative to the current directory
> (typically a sequence of "../", or an empty string).
Jakub,
Yes, I agree, there is a risk in breaking scripts that rely on the "../"
format. That's the "substantial change" I was alluding. Here's how I
arrived at that choice. I considered these fixes:
(a) add some shell code to cd_to_toplevel to find the canonical pwd and
interpret --show-cdup output from there
(b) make a new option (--work-tree would be a good name) to print the
canonical work tree path, and leave --show-cdup as it is. Then
change cd_to_toplevel and/or git pull to use the new option
(c) change --show-cdup to print the canonical work tree path, even
though it's not entirely consistent with the name of the option
The main reason I avoided (a), even though that "cd" is what violated my
expecations, is because I didn't want to have to re-implement code to
check whether each path component is a symlink. (Now I see that "cd
`/bin/pwd` might be a more concise fix.)
The reason I avoided (b) is because, to make all of git work for me, I
expected to have to change several calling scripts. (Now that I look, I
see only three calls to --show-cdup in the git codebase to change.)
Even so, third-party scripts that I might want to use in the future
would not immediately be changed.
Option (c) keeps the change small and isolated and makes it effective
everywhere. The documentation, while perhaps in need of update given my
patch, doesn't promise to always return zero or more "../". Also,
there's a branch branch of the --show-cdup code (that I can't seem to
exercise) that the result of get_git_work_tree(), which might not be
zero or more "../".
Would you suggest pursuing option (a)? I wonder whether there are
languages other than shell that might suffer from the same problem of
keeping an internal PWD variable of some sort, or perhaps there are
shell scripts out there that call --show-cdup directly instead of
calling cd_to_toplevel.
Do you think it would be less likely to break existing scripts if I
restrict the (c) behavior to when getenv("PWD") doesn't match the
starting getcwd()? (I'm not sure yet whether that's a reliable way to
detect the symlink scenario, but it seems to work with bash.)
Marcel
^ permalink raw reply
* Re: [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-11-25 5:54 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, gitster, git
In-Reply-To: <49290203.7060808@op5.se>
> AFAIR, it was introduced to make test-builds of really large projects in
> really deep directories with a ton of symlinks leading to the path work a
> lot faster.
Andreas,
I see value in keeping Git very fast. That is, after all, why I chose
Git over Mercurial. Do you know where that discussion was, if was in
the archives? I found these reasons to avoid absolute paths in the git
archives:
* paths with more components are slower to work with (in the context of
add and diff, which deal with many many paths)
* absolute paths may exceed PATH_MAX while relative ones didn't
* getcwd() will fail if parent directories are not executable, or on
some platforms, if parent directories are not readable
My impression is that the performance issue is probably not significant
for cd_to_toplevel since it's not in a tight inner loop, and dito for
other potential callers of --show-cdup. The PATH_MAX seems to be a
restriction elsewhere in the code already.
Even if there were a scenario that put --show-cdup in a tight loop, I
wonder whether current implementation provides much performance benefit,
at least when bash is the calling language: bash seems to make the
relative path absolute anyway inside the "cd" builtin.
The commit (5f94c730) that introduces that code doesn't mention
performance. It compares to:
git rev-parse --show-prefix | sed -e 's|[^/][^/]*|..|g'
I also noticed that this failure case with "--show-cdup" in a symlinked
directory has come up more than once before.
http://marc.info/?l=git&m=122452534912000&w=2
http://marc.info/?l=git&m=121613416212958&w=2
https://kerneltrap.org/mailarchive/git/2007/4/25/244653/thread
Marcel
^ permalink raw reply
* Re: How to hide a git repository?
From: Nicolas Morey-Chaisemartin @ 2008-11-25 6:15 UTC (permalink / raw)
To: garyyang6; +Cc: git
In-Reply-To: <900638.56188.qm@web37904.mail.mud.yahoo.com>
I guess you could export the public one through git daemon and/or your
web server, and access your private tree through SSH.
This way you ensure only authentificated people will be able to clone
your private tree.
---
Nicolas Morey-Chaisemartin
Gary Yang a écrit :
> Do I have to create two git servers? One is for public to download the released code. For example: gitpub.mycompany.com:/pub/linux/kernel. gitpub.mycompany.com is accessible to public. Another is for internal development. For example: gitdev.mycompany.com:/dev/linux/kernel. gitdev.mycompany.com is only accessible to our development team. I push code from gitdev.mycompany.com:/dev/linux/kernel to gitpub.mycompany.com:/publinux/kernel once we completed our development. Is this the only way to do it?
>
>
> --- On Mon, 11/24/08, Gary Yang <garyyang6@yahoo.com> wrote:
>
>
>> From: Gary Yang <garyyang6@yahoo.com>
>> Subject: How to hide a git repository?
>> To: git@vger.kernel.org
>> Date: Monday, November 24, 2008, 4:32 PM
>> We have two repositories, one is /pub/git/dev/linux/kernel,
>> another is /pub/git/pub/linux/kernel. The
>> /pub/git/pub/linux/kernel is open to public for people to
>> download released code. /pub/git/dev/linux/kernel is used
>> for our development. We would like to hide
>> /pub/git/dev/linux/kernel from public. How to do it?
>>
>> Why we want to hide /pub/git/dev/linux/kernel from public?
>> We work on our development at /pub/git/dev/linux/kernel. We
>> push our released code to /pub/git/pub/linux/kernel from
>> /pub/git/dev/linux/kernel once we completed our development.
>> We do not want people to download code from
>> /pub/git/dev/linux/kernel since it is not stable.
>>
>>
>>
>>
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line
>> "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* French git user
From: Nicolas Morey-Chaisemartin @ 2008-11-25 6:21 UTC (permalink / raw)
To: git
Hello everyone,
I've been given the task to prepare an introduction on Git for my
company, as lots of people are interested by Git, and I'm one of the
most advanced user, as I started using git about 2 or 3 weeks ago...
Due to my lack of experience, and not wanting to taught wrong things,
I'm looking for one or more good french git user/developper to give a
quick look to my slides, and tell me if I went wrong somewhere.
Thanks in advance
Nicolas Morey-Chaisemartin
^ permalink raw reply
* Re: French git user
From: Christian MICHON @ 2008-11-25 6:38 UTC (permalink / raw)
To: devel; +Cc: git
In-Reply-To: <492B9985.10103@morey-chaisemartin.com>
On Tue, Nov 25, 2008 at 7:21 AM, Nicolas Morey-Chaisemartin
<devel@morey-chaisemartin.com> wrote:
> Hello everyone,
>
> I've been given the task to prepare an introduction on Git for my
> company, as lots of people are interested by Git, and I'm one of the
> most advanced user, as I started using git about 2 or 3 weeks ago...
> Due to my lack of experience, and not wanting to taught wrong things,
> I'm looking for one or more good french git user/developper to give a
> quick look to my slides, and tell me if I went wrong somewhere.
>
> Thanks in advance
>
> Nicolas Morey-Chaisemartin
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I can do that for you, no pb ;-)
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir
From: Andreas Ericsson @ 2008-11-25 6:50 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: Jakub Narebski, gitster, git
In-Reply-To: <492B9321.8090706@oak.homeunix.org>
Marcel M. Cary wrote:
>> AFAIR, it was introduced to make test-builds of really large projects in
>> really deep directories with a ton of symlinks leading to the path work a
>> lot faster.
>
> Andreas,
>
> I see value in keeping Git very fast. That is, after all, why I chose
> Git over Mercurial. Do you know where that discussion was, if was in
> the archives? I found these reasons to avoid absolute paths in the git
> archives:
>
> * paths with more components are slower to work with (in the context of
> add and diff, which deal with many many paths)
> * absolute paths may exceed PATH_MAX while relative ones didn't
> * getcwd() will fail if parent directories are not executable, or on
> some platforms, if parent directories are not readable
>
> My impression is that the performance issue is probably not significant
> for cd_to_toplevel since it's not in a tight inner loop, and dito for
> other potential callers of --show-cdup. The PATH_MAX seems to be a
> restriction elsewhere in the code already.
>
The performance issue does not come from cd_to_toplevel itself, but from
its callers. That is, if scripts start to use absolute paths from *other*
tight loops, that's when we hit a problem.
> Even if there were a scenario that put --show-cdup in a tight loop, I
> wonder whether current implementation provides much performance benefit,
> at least when bash is the calling language: bash seems to make the
> relative path absolute anyway inside the "cd" builtin.
>
> The commit (5f94c730) that introduces that code doesn't mention
> performance. It compares to:
>
> git rev-parse --show-prefix | sed -e 's|[^/][^/]*|..|g'
>
>
> I also noticed that this failure case with "--show-cdup" in a symlinked
> directory has come up more than once before.
> http://marc.info/?l=git&m=122452534912000&w=2
> http://marc.info/?l=git&m=121613416212958&w=2
> https://kerneltrap.org/mailarchive/git/2007/4/25/244653/thread
>
I can imagine. However, --show-cdup has a different use too. It's nifty
for printing relative paths from commands running inside a subdirectory
of the repository. If you need the absolute path to the root of the repo,
I'd suggest you add "--show-absolute-path" instead.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir
From: Johannes Sixt @ 2008-11-25 7:30 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: gitster, git
In-Reply-To: <1227389614-10946-1-git-send-email-marcel@oak.homeunix.org>
Marcel M. Cary schrieb:
> * Change "git rev-parse --show-cdup" to print a full path instead of
> a series of "../" when it prints anything
http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88562
I don't see that you bring in any new arguments.
-- Hannes
^ permalink raw reply
* Re: Hello All and Seeking Information
From: Pete Harlan @ 2008-11-25 7:57 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0811240828y61e7bfecka1cacdd37865a4e8@mail.gmail.com>
Tim Visher wrote:
> there are some issues that I can't wrap my head around, such as how
> you can guarantee that all developers are working on the same
> code-base without a central repo.
You can have a central repo that represents the official lines of
development (branches, but "official" branches), and each developer
has local copies of those branches so they can compare their own work
against them.
If you don't have a central repo, then the developers can keep local
copies of other developers' branches when they're interested in them,
and compare their work against those.
Using the git project as an example, when you clone from
git://git.kernel.org/pub/scm/git/git.git you will find "remote
branches" origin/master, origin/maint, etc. They're stored locally in
your repo; the name "remote" only refers to the fact that at one time
(when you last cloned or fetched) they corresponded to branches in the
origin repo. You can list your copies of these branches with "git
branch -r". You can freshen them to agree with the origin with "git
fetch origin".
Your local branches ("local" referring to the fact that they exist
_only_ locally), listed by "git branch", are what you develop on.
After you do "git fetch", you can compare your local branches against
your copies of the remote branches to see if the remote repo has new
work you haven't yet incorporated into your local branches. You can
also compare against them to see if you have work they don't.
So each developer can compare what they have against what others have,
and keep things in sync as much as they wish to (and no more), fairly
easily.
--Pete
^ permalink raw reply
* inted problems when upgrading to 1.6.0.4
From: Luis Gutierrez @ 2008-11-25 9:29 UTC (permalink / raw)
To: git
Hi All,
At my company we have been using git for the past months, and except for
a few people, everyone is happy with it. Last week, we discovered that
the mac version of git was misbehaving (v1.5.6.4), but upgrading the
client to the latest one (v1.6.0.4) fixed the issue. Fearing consistency
issue between version, I decided to update the version of the central
repository (ie, the place were people can go and synchronize their code)
on a RHEL4 box from 1.5.6.4 to 1.6.0.4.
went to my git directory, pulled, checkout v1.6.0.4, and compiled with
'make --prefix=/usr/loca/ all' and installed with the same comamnd.
xinted dameon was restarted and then all hell broke loose.
All push/pull/clone operations were failing with the dreaded 'fatal: The
remote end hung up unexpectedly'. After a few tests, this is what I found:
- I can clone/pull/push if I do it through ssh (ie, git clone
ssh://server/project)
- I can clone/pull/push if I start git daemon on the command line through
git daemon --syslog --verbose --export-all
--base-path=/vol0/git/projects --verbose --reuseaddr
But the way I had setup git, through xinetd is broken.
This is my current xinetd config:
service git
{
disable = yes
socket_type = stream
wait = no
user = git
type = UNLISTED
protocol = tcp
log_on_failure += USERID
port = 9418
server = /usr/local/bin/git
server_args = daemon --inetd --syslog --verbose --export-all
--base-path=/vol0/git/projects --allow-override=uploadpack
}
And I'm getting the following errors:
> git clone git://romanticism/tutorial tutorial.git
Initialized empty Git repository in /tmp/tutorial.git/.git/
fatal: protocol error: bad line length character
before adding the --allow-override=uploadpack I was getting this:
> git clone git://romanticism/tutorial tutorial.git
Initialized empty Git repository in /tmp/tutorial.git/.git/
fatal: The remote end hung up unexpectedly
Since the error appeared after the upgrade, it seems likely it is either
a but, or something change regarding inte/xinetd, but I can't find any
documentation about changes here.
Any help will be appreciated.
Luis Gutierrez
^ permalink raw reply
* Re: inted problems when upgrading to 1.6.0.4
From: Arafangion @ 2008-11-25 10:20 UTC (permalink / raw)
To: Luis Gutierrez; +Cc: git
In-Reply-To: <492BC56A.6040506@xmos.com>
On Tue, 2008-11-25 at 09:29 +0000, Luis Gutierrez wrote:
<snip>
> All push/pull/clone operations were failing with the dreaded 'fatal: The
> remote end hung up unexpectedly'. After a few tests, this is what I found:
>
> - I can clone/pull/push if I do it through ssh (ie, git clone
> ssh://server/project)
> - I can clone/pull/push if I start git daemon on the command line through
> git daemon --syslog --verbose --export-all
> --base-path=/vol0/git/projects --verbose --reuseaddr
>
> But the way I had setup git, through xinetd is broken.
I'm just guessing, as I'm too new to the git world to respond with more
expertise, but I will suggest that perhaps your problem is that your
$PATH is different with the xinitd configuration as contrasted with your
ssh configuration, as the locations of the git binaries could be
different.
^ permalink raw reply
* Re: inted problems when upgrading to 1.6.0.4
From: Johannes Sixt @ 2008-11-25 10:14 UTC (permalink / raw)
To: Luis Gutierrez; +Cc: git
In-Reply-To: <492BC56A.6040506@xmos.com>
Luis Gutierrez schrieb:
> At my company we have been using git for the past months, and except for
> a few people, everyone is happy with it. Last week, we discovered that
> the mac version of git was misbehaving (v1.5.6.4), but upgrading the
> client to the latest one (v1.6.0.4) fixed the issue. Fearing consistency
> issue between version, I decided to update the version of the central
> repository (ie, the place were people can go and synchronize their code)
> on a RHEL4 box from 1.5.6.4 to 1.6.0.4.
> went to my git directory, pulled, checkout v1.6.0.4, and compiled with
> 'make --prefix=/usr/loca/ all' and installed with the same comamnd.
It's not necessarily the cause of your problems, but didn't make install
warn you:
!! You have installed git-* commands to new gitexecdir.
!! Old version git-* commands still remain in bindir.
!! Mixing two versions of Git will lead to problems.
!! Please remove old version commands in bindir now.
Did you do as you were told?
-- Hannes
^ permalink raw reply
* Re: inted problems when upgrading to 1.6.0.4
From: Brian Foster @ 2008-11-25 10:36 UTC (permalink / raw)
To: Luis Gutierrez; +Cc: git
In-Reply-To: <492BC56A.6040506@xmos.com>
On Tuesday 25 November 2008 10:29:14 Luis Gutierrez wrote:
>[ ... ]
> This is my current xinetd config:
> service git
> {
> disable = yes
> socket_type = stream
> wait = no
> user = git
> type = UNLISTED
> protocol = tcp
> log_on_failure += USERID
> port = 9418
> server = /usr/local/bin/git
> server_args = daemon --inetd --syslog --verbose --export-all --base-path=/vol0/git/projects --allow-override=uploadpack
> }
In the past I also had a problem when git was installed
in /usr/local/bin and git-daemon was launched from xinetd.
I don't recall the details now, but believe all the obvious
suspects (conflicting git installation, /usr/local/bin not
in PATH, mis-installed/mis-configured git, et al.) seemed Ok.
In any case, I debugged the problem by adding:
env += GIT_TRACE=/tmp/LOG-git-daemon
to the xinetd config. I suggest trying that and seeing
what the logfile contains.
cheers!
-blf-
p.s. In my case, *using the information in the logfile*,
I eventually worked-around it by adding
‘--exec-path=/usr/local/bin’ to the ‘server_args’.
I never did work out exactly what was going wrong (this
was with a self-built git v1.5.5 on CentOS release 5).
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: inted problems when upgrading to 1.6.0.4
From: Arafangion @ 2008-11-25 10:54 UTC (permalink / raw)
To: Luis Gutierrez; +Cc: git
In-Reply-To: <492BCFA0.5030708@xmos.com>
On Tue, 2008-11-25 at 10:12 +0000, Luis Gutierrez wrote:
> Arafangion wrote:
> > On Tue, 2008-11-25 at 09:29 +0000, Luis Gutierrez wrote:
> > <snip>
> >
> > > All push/pull/clone operations were failing with the dreaded 'fatal: The
> > > remote end hung up unexpectedly'. After a few tests, this is what I found:
> > >
> > > - I can clone/pull/push if I do it through ssh (ie, git clone
> > > ssh://server/project)
> > > - I can clone/pull/push if I start git daemon on the command line through
> > > git daemon --syslog --verbose --export-all
> > > --base-path=/vol0/git/projects --verbose --reuseaddr
> > >
> > > But the way I had setup git, through xinetd is broken.
> > >
> >
> > I'm just guessing, as I'm too new to the git world to respond with more
> > expertise, but I will suggest that perhaps your problem is that your
> > $PATH is different with the xinitd configuration as contrasted with your
> > ssh configuration, as the locations of the git binaries could be
> > different.
> >
> >
> I've tried that, they are the same:
>
> # which git
> /usr/local/bin/git
What about the other git-* commands?
>
^ permalink raw reply
* Re: inted problems when upgrading to 1.6.0.4
From: Luis Gutierrez @ 2008-11-25 10:54 UTC (permalink / raw)
To: Arafangion; +Cc: git
In-Reply-To: <1227610459.3222.4.camel@therock.nsw.bigpond.net.au>
Arafangion wrote:
> On Tue, 2008-11-25 at 10:12 +0000, Luis Gutierrez wrote:
>
>> Arafangion wrote:
>>
>>> On Tue, 2008-11-25 at 09:29 +0000, Luis Gutierrez wrote:
>>> <snip>
>>>
>>>
>>>> All push/pull/clone operations were failing with the dreaded 'fatal: The
>>>> remote end hung up unexpectedly'. After a few tests, this is what I found:
>>>>
>>>> - I can clone/pull/push if I do it through ssh (ie, git clone
>>>> ssh://server/project)
>>>> - I can clone/pull/push if I start git daemon on the command line through
>>>> git daemon --syslog --verbose --export-all
>>>> --base-path=/vol0/git/projects --verbose --reuseaddr
>>>>
>>>> But the way I had setup git, through xinetd is broken.
>>>>
>>>>
>>> I'm just guessing, as I'm too new to the git world to respond with more
>>> expertise, but I will suggest that perhaps your problem is that your
>>> $PATH is different with the xinitd configuration as contrasted with your
>>> ssh configuration, as the locations of the git binaries could be
>>> different.
>>>
>>>
>>>
>> I've tried that, they are the same:
>>
>> # which git
>> /usr/local/bin/git
>>
>
> What about the other git-* commands?
>
>
This is what I have now:
ls /usr/local/bin/git*
git git-cvsserver gitk git-receive-pack git-shell
git-upload-archive git-upload-pack
it seems.. a lot less than it used to be, but then again, perhaps this
is why the git-* commands were deprecated?
--
* Luis Gutierrez | * XMOS Semiconductor <http://www.xmos.com>
Venturers House, King Street, Bristol BS1 4PB, UK
^ permalink raw reply
* Re: inted problems when upgrading to 1.6.0.4
From: Arafangion @ 2008-11-25 11:14 UTC (permalink / raw)
To: Luis Gutierrez; +Cc: git
In-Reply-To: <492BD951.1010200@xmos.com>
On Tue, 2008-11-25 at 10:54 +0000, Luis Gutierrez wrote:
<snip>
> This is what I have now:
> ls /usr/local/bin/git*
> git git-cvsserver gitk git-receive-pack git-shell
> git-upload-archive git-upload-pack
> it seems.. a lot less than it used to be, but then again, perhaps this
> is why the git-* commands were deprecated?
As Johannes Sixt mentioned, they have been moved from the bindir to the
new gitexecdir.
^ permalink raw reply
* Re: inted problems when upgrading to 1.6.0.4
From: Johannes Sixt @ 2008-11-25 11:04 UTC (permalink / raw)
To: Luis Gutierrez; +Cc: git
In-Reply-To: <492BC56A.6040506@xmos.com>
Luis Gutierrez schrieb:
> This is my current xinetd config:
> service git
> {
> disable = yes
Remove this line.
-- Hannes
^ permalink raw reply
* URGENT CONFIRMATION
From: aiids @ 2008-11-25 11:08 UTC (permalink / raw)
To: payagency4
URGENT CONFIRMATION
Kindly send your reply to this claim agent e-mail: trustgroupagent9@netscape.net
This e-mail is to notify you that your Email Address attached to a Serial Number(6601187) has won an Award Sum of us$ 2,000,000.00 (Dollars Only) In an email award lucky day lotto held on 2008.
Please contact Mr.Pieter Vaart, the claim agent officer through Contact agent e-mail: trustgroupagent9@netscape.net
phone. Contact phone: 0031-6111-464-78, Remember all winning must be claimed not later than 15Th of December 2008
Ref NO,{MBV0001171TW)Batch NO,BBG8790/123CQ
Lucky NO,QAR4040/987AK,Ticket No,fxa4567/871Ea
Mrs.irena Versloot,lotto award coordinator.
Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv
^ permalink raw reply
* Re: French git user
From: Jean-Francois Veillette @ 2008-11-25 13:38 UTC (permalink / raw)
To: Christian MICHON; +Cc: devel, git
In-Reply-To: <46d6db660811242238q4bc919a6l12bfd9a38639e46e@mail.gmail.com>
I'll probably need to do the same here (Montréal, Qc), so if you can
share your slides (or else), that would be nice.
Merci ! (thanks),
- jfv
Le 08-11-25 à 01:38, Christian MICHON a écrit :
> On Tue, Nov 25, 2008 at 7:21 AM, Nicolas Morey-Chaisemartin
> <devel@morey-chaisemartin.com> wrote:
>> Hello everyone,
>>
>> I've been given the task to prepare an introduction on Git for my
>> company, as lots of people are interested by Git, and I'm one of the
>> most advanced user, as I started using git about 2 or 3 weeks ago...
>> Due to my lack of experience, and not wanting to taught wrong things,
>> I'm looking for one or more good french git user/developper to give a
>> quick look to my slides, and tell me if I went wrong somewhere.
>>
>> Thanks in advance
>>
>> Nicolas Morey-Chaisemartin
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> I can do that for you, no pb ;-)
>
> --
> Christian
> --
> http://detaolb.sourceforge.net/, a linux distribution for Qemu with
> Git inside !
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* jgit, MutableInteger vs AtomicInteger
From: Vasyl Vavrychuk @ 2008-11-25 13:54 UTC (permalink / raw)
To: git
Hi,
I've just started browsing jgit sources and an obvious question arise.
I didn't found such question in mail list and decided to ask the community.
I don't see reason behind creating own mutable integer container because we
have java.util.concurrent.atomic.AtomicInteger with methods
public final int get()
public final void set(int i)
And that is what we want.
Regards,
V. V.
^ 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