* git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-25 16:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: Fabian Seoane
Hi,
I would like to export our whole git repository to patches, and then
reconstruct it again from scratch. Following the man page of "git
fast-export":
$ git clone git://git.sympy.org/sympy-full-history-20081023.git
$ cd sympy-full-history-20081023
$ git fast-export --all --export-marks=marks > patches
$ cd ..
$ mkdir sympy-new
$ cd sympy-new
$ git init
$ git fast-import --export-marks=marks < ../sympy-full-history-20081023/patches
git-fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects: 25000
Total objects: 21355 ( 144 duplicates )
blobs : 8009 ( 0 duplicates 4529 deltas)
trees : 10627 ( 144 duplicates 9189 deltas)
commits: 2719 ( 0 duplicates 0 deltas)
tags : 0 ( 0 duplicates 0 deltas)
Total branches: 21 ( 26 loads )
marks: 1048576 ( 10728 unique )
atoms: 726
Memory total: 2880 KiB
pools: 2098 KiB
objects: 781 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 33554432
pack_report: core.packedGitLimit = 268435456
pack_report: pack_used_ctr = 40706
pack_report: pack_mmap_calls = 2791
pack_report: pack_open_windows = 1 / 2
pack_report: pack_mapped = 26177739 / 35513414
---------------------------------------------------------------------
However, the repository is very different to the original one. It
contains only 191 patches:
$ git log --pretty=oneline | wc -l
191
and it only contains couple files. Compare this with the original repository:
$ git log --pretty=oneline | wc -l
2719
What am I doing wrong? Is there some other way to do it? I also tried
"git format-patch" and "git am" and that almost works, only it changes
hashes. Is there some way to tell "git am" to preserve the hash?
Thanks,
Ondrej
^ 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 16:30 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: gitster, git
In-Reply-To: <492C24D4.1010306@oak.homeunix.org>
Marcel M. Cary schrieb:
> Any tips on how to follow the reference
> 7vk5sly3h9.fsf@assigned-by-dhcp.cox.net in the first url above? It
> looks to be about performance. Message-Id seems to not be indexed for
> searching.
http://mid.gmane.org/7vk5sly3h9.fsf@assigned-by-dhcp.cox.net
-- Hannes
^ 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 16:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <492BA998.5050106@viscovery.net>
Johannes Sixt wrote:
> 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.
To be clear, as mentioned here:
http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88573
I'm not talking about a situation where the symlink is in the working
tree pointing outwards. I'm talking about a symlink outside pointing
in. And as mentioned later in that thread, the --work-tree workaround
doesn't actually work.
One new thing I have to add is that the reason --show-cdup prints a
correct path but pull fails is because it's the *shell* who
misinterprets the path. So telling git rev-parse where the work-tree is
helps nothing. It already knows.
http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88581
So far I've seen no response to the idea, which Yves mentions, about
trying to restrict the absolute path behavior to times when bash would
interpret the "../" incorrectly.
Nor have I seen a response to the idea of correcting the shell's
behavior in cd_to_toplevel, for example by adding a "cd `pwd`", and I
don't really understand the scenario where this would be a performance
concern; I think I haven't found a particular discussion that several
people have referenced. Perhaps I should prepare a patch for that so I
can verify that it works as I expect and so we have something more
concrete to discuss?
Any tips on how to follow the reference
7vk5sly3h9.fsf@assigned-by-dhcp.cox.net in the first url above? It
looks to be about performance. Message-Id seems to not be indexed for
searching.
Marcel
^ permalink raw reply
* [PATCH] Invoke "gc --auto" from git commit
From: Jean-Luc Herren @ 2008-11-25 16:15 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
This feature was lost during the port of git commit to C.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
---
builtin-commit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 591d16b..209805b 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -947,6 +947,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
struct commit_list *parents = NULL, **pptr = &parents;
struct stat statbuf;
int allow_fast_forward = 1;
+ const char *argv_gc_auto[] = { "gc", "--auto", NULL };
git_config(git_commit_config, NULL);
@@ -1068,6 +1069,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
"not exceeded, and then \"git reset HEAD\" to recover.");
rerere();
+ run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
run_hook(get_index_file(), "post-commit", NULL);
if (!quiet)
print_summary(prefix, commit_sha1);
--
1.6.0.4
^ permalink raw reply related
* Re: French git user
From: Christian MICHON @ 2008-11-25 15:41 UTC (permalink / raw)
To: Jean-Francois Veillette; +Cc: devel, git
In-Reply-To: <C10BF28F-3466-4908-A5ED-6FB68FBEC3A2@yahoo.ca>
On Tue, Nov 25, 2008 at 2:38 PM, Jean-Francois Veillette
<jean_francois_veillette@yahoo.ca> wrote:
> 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
>
you'll need to ask Nicolas. what I did was to provide feedback to his
slides only (done).
it's up to him to share his work or not.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Kristian Høgsberg @ 2008-11-25 15:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491DE6CC.6060201@op5.se>
On Fri, 2008-11-14 at 21:59 +0100, Andreas Ericsson wrote:
> I've been working quite a lot on git -> libgit2 code moving,
> but the licensing stuff is a bit depressing, as I can't know
> if the work I'm doing is for nothing or not.
>
> The license decided for libgit2 is "GPL with gcc exception".
> Those who are OK with relicensing their contributions under
> that license for the purpose of libgit2, can you please say
> so?
>
> I'm planning on writing a tool for this that will have "ok",
> "not ok" and "ask-each-patch" as options.
>
> The list of people whose position I know is rather short.
> Please correct me if you're on it and would like not to be.
> Junio C. Hamano ask
> Johannes Schindelin ok
> Shawn O. Pearce ok
> Andreas Ericsson ok
> Pierre Habouzit ok
> Brian Gernhardt ok
>
>
> I've put everyone who "owns" more than 500 lines of code
> on the bcc list, figuring your permission is important
> but that you don't want the hundreds (well, one can hope)
> of emails from people saying "ok". The list of major owners
> was generated with "git showners *.c" in a worktree from
> the next branch of git.git.
You're welcome to use any of the code I've written under the GPL +
exception license, though most of it is probably not that useful, as
it's mostly porting shell commands to builtins. I'm very happy to see
this effort start up, as I've been tempted to do something similar
myself :)
cheers,
Kristian
^ 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
* 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
* 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: 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
* 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: 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 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: 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: 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: 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
* 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: 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
* 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: [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: 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
* 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: 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
* 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: [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
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