* Re: git-send-pack SIGSEGV..
From: Linus Torvalds @ 2007-06-15 17:26 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706150949300.5848@iabervon.org>
On Fri, 15 Jun 2007, Daniel Barkalow wrote:
>
> Your analysis of the failure was right, though. I reproduced it, and this
> fixes it for me:
>
> --- cut here ---
> Author: Daniel Barkalow <barkalow@iabervon.org>
> Date: Fri Jun 15 10:22:37 2007 -0400
>
> Fix pushing to a pattern with no dst
>
> Refspecs with no colons are left with no dst value, because they are
> interepreted differently for fetch and push. For push, they mean to
> reuse the src side. Fix this for patterns.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
And in case anybody cares, I've also verified it, so here's an
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
in case Junio didn't already apply it.
Linus
^ permalink raw reply
* Re: Newbie questions about moving around repositories
From: Ed Schofield @ 2007-06-15 17:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0706150718t2382648aw25959844f52c5c02@mail.gmail.com>
On 6/15/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 6/15/07, Ed Schofield <edschofield@gmail.com> wrote:
> > 1. I would like to move my repository (including all branches) from
> > directory A to a directory B on a different filesystem.
> > [snip]
>
> Just copy it.
> [snip]
> ... but fix that .git/objects/info/alternates files in the repos left to
> point to the new location of the moved directory.
Thanks, Alex! Changing this and .git/branches/origin worked a treat.
-- Ed
^ permalink raw reply
* Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh
From: Raimund Bauer @ 2007-06-15 15:54 UTC (permalink / raw)
To: Kevin Green; +Cc: Julian Phillips, git
In-Reply-To: <20070615154000.GK14677@menevado.ms.com>
On Fri, 2007-06-15 at 11:40 -0400, Kevin Green wrote:
> I'm thinking I like the env var idea much more though. I can just export it
> in my shell and it works in both cases. I could of course alias the commands
> so I don't have to keep typing it everytime, but that's more painful still...
do 'git config --help' and check the options
remote.<name>.receivepack
remote.<name>.uploadpack
> --Kevin
--
best regards
Ray
^ permalink raw reply
* Re: git-repack made my pack 317x larger...
From: Nicolas Pitre @ 2007-06-15 15:53 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20070615145433.22970.qmail@science.horizon.com>
On Fri, 15 Jun 2007, linux@horizon.com wrote:
> >> Uh... what happened? It's not a full kernel clone, but it's a lot more
> >> objects than I expected. Where did all the extra objects come from?
>
> > Maybe you want to add -l as well to your git-repack invocation.
>
> Ah. Thank you. Indeed, this is another example of git documentation
> disease. git-repack refers to git-pack-objects, which gives a very
> technical explanation of what it does, but nowhere is it mentioned that
> list of objects suppled to git-pack-object's stdin includes objects
> borrowed from alternates.
At some point it is necessary for people like you who are not so
intimate with the packing code, and therefore to whom this doesn't look
obvious, to raise those issues, and ideally provide patches.
> Given that "git-repack -f" is a not uncommon command, could I suggest
> that the default is wrong, and there should be a special flag for
> "suck in alternates, so this repository is no longer dependent
> on any others".
Well, I tend to disagree here. I don't think using -f _should_ be that
common. It is a really expensive operation and you usualy should have a
good reason to use it.
> Mentally, git-repack is a "reduce space consumption" command, not an
> increase one. Having to remember that this repository uses alternates
> and add an extra flag to avoid having a space explosion is distinctly
> annoying.
Why don't you use git-gc then? Its mental model and actual
implementation is really about reducing space, maybe even more than
git-repack is, and it does call git-repack with -l.
Nicolas
^ permalink raw reply
* Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh
From: Kevin Green @ 2007-06-15 15:40 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706151628180.31972@reaper.quantumfyre.co.uk>
On 06/15/07 11:30:12, Julian Phillips wrote:
> On Fri, 15 Jun 2007, Kevin Green wrote:
>
> >
> > Hi,
> >
> > I've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the
> > standard location. This leads to a failure on trying to find the git binaries
> > on the remote end. I've looked through the archives and didn't come across
> > any similar discussions. Please point me there if I've missed something...
>
> from the git-pull manpage:
>
> --upload-pack <upload-pack>
> When given, and the repository to fetch from is handled by
> git-fetch-pack, --exec=<upload-pack> is passed to the command
> to specify non-default path for the command run on the other
> end.
>
> and git-pull:
>
> --receive-pack=<git-receive-pack>
> Path to the git-receive-pack program on the remote end.
> Sometimes useful when pushing to a remote repository over ssh,
> and you do not have the program in a directory on the default
> $PATH.
Thanks!
I did completely miss this when I went through the manpage...
I'm thinking I like the env var idea much more though. I can just export it
in my shell and it works in both cases. I could of course alias the commands
so I don't have to keep typing it everytime, but that's more painful still...
--Kevin
^ permalink raw reply
* Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh
From: Julian Phillips @ 2007-06-15 15:30 UTC (permalink / raw)
To: Kevin Green; +Cc: git
In-Reply-To: <20070615150351.GH14677@menevado.ms.com>
On Fri, 15 Jun 2007, Kevin Green wrote:
>
> Hi,
>
> I've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the
> standard location. This leads to a failure on trying to find the git binaries
> on the remote end. I've looked through the archives and didn't come across
> any similar discussions. Please point me there if I've missed something...
from the git-pull manpage:
--upload-pack <upload-pack>
When given, and the repository to fetch from is handled by
git-fetch-pack, --exec=<upload-pack> is passed to the command
to specify non-default path for the command run on the other
end.
and git-pull:
--receive-pack=<git-receive-pack>
Path to the git-receive-pack program on the remote end.
Sometimes useful when pushing to a remote repository over ssh,
and you do not have the program in a directory on the default
$PATH.
--
Julian
---
To be or not to be.
-- Shakespeare
To do is to be.
-- Nietzsche
To be is to do.
-- Sartre
Do be do be do.
-- Sinatra
^ permalink raw reply
* Re: StGIT vs. guilt: What's the difference?
From: Catalin Marinas @ 2007-06-15 14:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Steven Grimm, 'git'
In-Reply-To: <20070615030542.GA30110@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> wrote:
> On 2007-06-14 14:55:54 -0700, Steven Grimm wrote:
>
>> I've asked this on IRC a couple times and nobody seemed to have a
>> good answer, so: These two tools seem like they are solving the same
>> general problem using similar approaches. They are both under active
>> development. In what areas is each of them stronger than the other?
>> Why would one choose to use one of them instead of the other?
>
> I have never had a close look at guilt, but from what I remember it
> stores patches as plain old plaintext patches (corrections to this
> statement welcome). StGIT uses git's object database.
I haven't tried quilt either but, if it uses plain text patches, the
disadvantage might be the losing of the three-way merge when pushing a
patch onto the stack. The solution is to remember which commit the
patch applies to, switch the tree, apply the patch and merge with
HEAD.
Are the guilt patches accessible as commit objects at the top of the
stack?
StGIT might have some more features as it is older but I see a lot of
development is going on with guilt. Another difference is that StGIT
is written in Python and guilt uses shell scripts (some people don't
like the dependency on Python).
I would welcome such a discussion (so please keep me cc'ed) as we can
share the experience with various issues.
--
Catalin
^ permalink raw reply
* Re: git-repack made my pack 317x larger...
From: Benjamin Sergeant @ 2007-06-15 15:10 UTC (permalink / raw)
To: linux@horizon.com; +Cc: nico, git
In-Reply-To: <20070615145433.22970.qmail@science.horizon.com>
> (I might complan a little less if git-repack would take -adlf rather
> than insisting on -a -d -l -f. Is that a deliberate choice or has just
> nobody stepped up to revamp the option parsing?)
getopt is our friend, indeed.
(http://www.hmug.org/man/1/getopt.php)
The following code fragment shows how one might process the arguments for
a command that can take the options -a and -b, and the option -o, which
requires an argument.
args=`getopt abo: $*`
# you should not use `getopt abo: "$@"` since that would parse
# the arguments differently from what the set command below does.
if [ $? != 0 ]
then
echo 'Usage: ...'
exit 2
fi
set -- $args
# You cannot use the set command with a backquoted getopt directly,
# since the exit code from getopt would be shadowed by those of set,
# which is zero by definition.
for i
do
case "$i"
in
-a|-b)
echo flag $i set; sflags="${i#-}$sflags";
shift;;
-o)
echo oarg is "'"$2"'"; oarg="$2"; shift;
shift;;
--)
shift; break;;
esac
done
echo single-char flags: "'"$sflags"'"
echo oarg is "'"$oarg"'"
This code will accept any of the following as equivalent:
cmd -aoarg file file
cmd -a -o arg file file
cmd -oarg -a file file
cmd -a -oarg -- file file
^ permalink raw reply
* [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh
From: Kevin Green @ 2007-06-15 15:03 UTC (permalink / raw)
To: git
Hi,
I've run into a problem pushing/pulling where we don't (READ: can't) have git installed in the
standard location. This leads to a failure on trying to find the git binaries
on the remote end. I've looked through the archives and didn't come across
any similar discussions. Please point me there if I've missed something...
I wanted to introduce a commandline arg, similar to what rsync does, call it
--git-path=PATH, where a user can specify the location of git on the remote
end.
After tracking through what really is happening with a git pull, I realized
that a change like that is pretty intrusive and is not just a simple addition
to the ssh handling code, i.e. we'll need to push that arg through all the sh
scripts, etc...
I settled on allowing an env var to be exported, GIT_REMOTE_PATH which a user
can set to the path of git on the remote end.
I want to open up the discussion on whether this is the best way forward or if
there's another way I've missed.
Here's the patch that introduces this new feature:
--- cut here ---
Author: Kevin Green <Kevin.Green@morganstanley.com>
Date: Fri, 15 Jun 2007 10:51:21 -0400
Fix assumption that git is installed in a standard place on the remote end ssh
Introduce env var GIT_REMOTE_PATH which a user can set to the known remote path of
git during a push or pull through PROTO_SSH.
Signed-off-by: Kevin Green <Kevin.Green@morganstanley.com>
---
connect.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/connect.c b/connect.c
index 7fab9c0..ee15a8a 100644
--- a/connect.c
+++ b/connect.c
@@ -560,7 +560,13 @@ pid_t git_connect(int fd[2], char *url, const char *prog, int flags)
char *posn = command;
int size = MAX_CMD_LEN;
int of = 0;
+ const char *git_remote_path;
+ git_remote_path = getenv("GIT_REMOTE_PATH");
+ if (git_remote_path) {
+ of |= add_to_string(&posn, &size, git_remote_path, 0);
+ of |= add_to_string(&posn, &size, "/", 0);
+ }
of |= add_to_string(&posn, &size, prog, 0);
of |= add_to_string(&posn, &size, " ", 0);
of |= add_to_string(&posn, &size, path, 1);
--
1.5.2.1
^ permalink raw reply related
* Re: git-repack made my pack 317x larger...
From: linux @ 2007-06-15 14:54 UTC (permalink / raw)
To: linux, nico; +Cc: git
In-Reply-To: <alpine.LFD.0.99.0706150935530.5651@xanadu.home>
>> Uh... what happened? It's not a full kernel clone, but it's a lot more
>> objects than I expected. Where did all the extra objects come from?
> Maybe you want to add -l as well to your git-repack invocation.
Ah. Thank you. Indeed, this is another example of git documentation
disease. git-repack refers to git-pack-objects, which gives a very
technical explanation of what it does, but nowhere is it mentioned that
list of objects suppled to git-pack-object's stdin includes objects
borrowed from alternates.
Of course, reading the description of git-rev-list --objects, you might
get the impression, but it's not exactly hugely obvious.
Given that "git-repack -f" is a not uncommon command, could I suggest
that the default is wrong, and there should be a special flag for
"suck in alternates, so this repository is no longer dependent
on any others".
Mentally, git-repack is a "reduce space consumption" command, not an
increase one. Having to remember that this repository uses alternates
and add an extra flag to avoid having a space explosion is distinctly
annoying.
(I might complan a little less if git-repack would take -adlf rather
than insisting on -a -d -l -f. Is that a deliberate choice or has just
nobody stepped up to revamp the option parsing?)
^ permalink raw reply
* Re: git-send-pack SIGSEGV..
From: Daniel Barkalow @ 2007-06-15 14:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vr6od92nj.fsf@assigned-by-dhcp.pobox.com>
On Thu, 14 Jun 2007, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> >> I *suspect* it's due to the refspec pattern matching changes Daniel did,
> >> but again - I haven't actually debugged it any deeper.
> >
> > I am officially recuperating from an operation I had today, so I
> > cannot really take a deep look at this.
> >
> > I think what is going wrong is that struct refspec for pattern
> > match that is parsed by parse_ref_spec does not have ->dst
> > component filled for "refs/tags/*" refspec, but match_refs()
> > does not check if pat->dst is NULL, in which case it should
> > reuse pat->src value.
> >
> > Incidentally I have other remote.c fixes queued in 'next'. I
> > haven't yet checked if I (accidentally) fixed this already.
>
> Completely untested, but this may fix it.
>
> I suspect this has an side effect of allowing
>
> fetch = refs/heads/*
>
> to mean the same thing as
>
> fetch = refs/heads/*:refs/heads/*
>
> which is suitable for a bare mirroring repository, but I do not
> think of any downside, so it might be Ok.
>
> But that is something from a person who was under anesthesia a
> few hours ago, so you should take it with a big grain of salt ;-)
Yeah, that's not right; "push = refs/heads/*" works like that, but
"fetch = refs/heads/*" puts them in MERGE_HEAD without storing them
anywhere, unlike "fetch = refs/heads/*:refs/heads/*". That's why I didn't
just copy the left side to the right side, which is what the old parsing
code did: what you're going to do with the refspec determines how you
interpret a missing rhs. So it needs to be the code that uses the refspec
that handles this case.
Your analysis of the failure was right, though. I reproduced it, and this
fixes it for me:
--- cut here ---
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Fri Jun 15 10:22:37 2007 -0400
Fix pushing to a pattern with no dst
Refspecs with no colons are left with no dst value, because they are
interepreted differently for fetch and push. For push, they mean to
reuse the src side. Fix this for patterns.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
diff --git a/remote.c b/remote.c
index 6121416..c860740 100644
--- a/remote.c
+++ b/remote.c
@@ -546,10 +546,11 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
}
if (pat) {
- dst_name = xmalloc(strlen(pat->dst) +
+ const char *dst_side = pat->dst ? pat->dst : pat->src;
+ dst_name = xmalloc(strlen(dst_side) +
strlen(src->name) -
strlen(pat->src) + 2);
- strcpy(dst_name, pat->dst);
+ strcpy(dst_name, dst_side);
strcat(dst_name, src->name + strlen(pat->src));
} else
dst_name = xstrdup(src->name);
^ permalink raw reply related
* Re: Newbie questions about moving around repositories
From: Alex Riesen @ 2007-06-15 14:18 UTC (permalink / raw)
To: Ed Schofield; +Cc: git
In-Reply-To: <1b5a37350706150652y7710c380l79e785cba8f6b02e@mail.gmail.com>
On 6/15/07, Ed Schofield <edschofield@gmail.com> wrote:
> 1. I would like to move my repository (including all branches) from
> directory A to a directory B on a different filesystem. Can I use
> git-clone for this? It seems that git-clone creates remote-tracking
> branches, but I want to keep all of the branches as local branches so
> I can remove the original repository.
Just copy it.
> 2. I can't just move the entire directory A, because I get
>
> Error in startup script: error: object directory
> A/../A-cvs-git/.git/objects does not exist; check
> .git/objects/info/alternates
... but fix that .git/objects/info/alternates files in the repos left to
point to the new location of the moved directory.
> I think I originally created the repository by cloning from my
> A-cvs-git/ directory with git-clone --shared, but I don't quite
> remember. So I suppose I want a way to stop using the alternates
> mechanism and make my repository self-contained in one directory. Is
> this possible?
git repack -f, and remove the alternates, probably.
Otherwise you can just copy .git/objects directory into all
related repos, remove alternates there and you're free.
> Will I then be free to move the directory?
Yes
^ permalink raw reply
* Newbie questions about moving around repositories
From: Ed Schofield @ 2007-06-15 13:52 UTC (permalink / raw)
To: git
Hi all,
I've recently started using git to manage my own patchsets for a
public CVS repository that I don't have write access to. I have a
couple of newbie questions, please:
1. I would like to move my repository (including all branches) from
directory A to a directory B on a different filesystem. Can I use
git-clone for this? It seems that git-clone creates remote-tracking
branches, but I want to keep all of the branches as local branches so
I can remove the original repository.
2. I can't just move the entire directory A, because I get
Error in startup script: error: object directory
A/../A-cvs-git/.git/objects does not exist; check
.git/objects/info/alternates
I think I originally created the repository by cloning from my
A-cvs-git/ directory with git-clone --shared, but I don't quite
remember. So I suppose I want a way to stop using the alternates
mechanism and make my repository self-contained in one directory. Is
this possible? Will I then be free to move the directory?
I'd appreciate any advice!
-- Ed
^ permalink raw reply
* Re: git-repack made my pack 317x larger...
From: Nicolas Pitre @ 2007-06-15 13:39 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20070615085057.5706.qmail@science.horizon.com>
On Fri, 15 Jun 2007, linux@horizon.com wrote:
> > ~/tmp$ git clone --reference /usr/src/linux -n hwmon-2.6.old hwmon-2.6
> > Initialized empty Git repository in /home/linux/tmp/hwmon-2.6/.git/
> > remote: Generating pack...
> > remote: Done counting 124 objects.
> > remote: Deltifying 124 objects...
> > remote: 100% (124/124) done
> > Indexing 124 objects...
> > remote: Total 124 (delta 83), reused 97 (delta 75)
> > 100% (124/124) done
> > Resolving 83 deltas...
> > 100% (83/83) done
> > ~/tmp$ rm -rf hwmon-2.6.olf
> > ~/tmp$ cd hwmon-2.6
> > ~/tmp/hwmon-2.6$ ls -l .git/objects/pack/
> > total 168
> > -r--r--r-- 1 linux users 4040 Jun 15 03:44 pack-e4de475aa6c82099b4a4a8f6f410dcc316c7cf19.idx
> > -r--r--r-- 1 linux users 161548 Jun 15 03:44 pack-e4de475aa6c82099b4a4a8f6f410dcc316c7cf19.pack
>
> Much better! But since that's only a few objects, let's repack them even tighter...
>
> > ~/tmp/hwmon-2.6$ git-repack -a -d -f --window=50
> > Generating pack...
> > Done counting 18090 objects.
> > Deltifying 18090 objects...
> > 100% (18090/18090) done
> > Writing 18090 objects...
> > 100% (18090/18090) done
> > Total 18090 (delta 2465), reused 7876 (delta 0)
> > Pack pack-1af4ab6620f71733f17b16d69a89b6741e2c7fe3 created.
> > Removing unused objects 100%...
> > Done.
> > ~/tmp/hwmon-2.6$ ls -l .git/objects/pack/
> > total 50620
> > -r--r--r-- 1 linux users 435224 Jun 15 04:00 pack-1af4ab6620f71733f17b16d69a89b6741e2c7fe3.idx
> > -r--r--r-- 1 linux users 51333891 Jun 15 04:00 pack-1af4ab6620f71733f17b16d69a89b6741e2c7fe3.pack
>
> Uh... what happened? It's not a full kernel clone, but it's a lot more
> objects than I expected. Where did all the extra objects come from?
Maybe you want to add -l as well to your git-repack invocation.
Nicolas
^ permalink raw reply
* [PATCH/RFH] pp_header(): work around possible memory corruption
From: Johannes Schindelin @ 2007-06-15 12:19 UTC (permalink / raw)
To: git, gitster
add_user_info() possibly adds way more than just the commit header line.
In fact, it sometimes needs so much more space that there is a buffer
overrun, leading to an ugly crash. For example, the date is printed in its
own line, and usually takes up more space than the equivalent Unix epoch.
So, for good measure, add 80 characters (a full line) to the allocated
space, in addition to the header line length.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I have no idea if 80 is a good value, and if other places
need an equivalent fix up, too.
But I needed this patch in a hurry...
commit.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/commit.c b/commit.c
index f778bf4..03436b1 100644
--- a/commit.c
+++ b/commit.c
@@ -997,7 +997,7 @@ static void pp_header(enum cmit_fmt fmt,
len = linelen;
if (fmt == CMIT_FMT_EMAIL)
len = bound_rfc2047(linelen, encoding);
- ALLOC_GROW(*buf_p, *ofs_p + len, *space_p);
+ ALLOC_GROW(*buf_p, *ofs_p + len + 80, *space_p);
dst = *buf_p + *ofs_p;
*ofs_p += add_user_info("Author", fmt, dst,
line + 7, dmode, encoding);
@@ -1008,7 +1008,7 @@ static void pp_header(enum cmit_fmt fmt,
len = linelen;
if (fmt == CMIT_FMT_EMAIL)
len = bound_rfc2047(linelen, encoding);
- ALLOC_GROW(*buf_p, *ofs_p + len, *space_p);
+ ALLOC_GROW(*buf_p, *ofs_p + len + 80, *space_p);
dst = *buf_p + *ofs_p;
*ofs_p += add_user_info("Commit", fmt, dst,
line + 10, dmode, encoding);
^ permalink raw reply related
* Re: Feature request: thin checkout
From: Johannes Sixt @ 2007-06-15 10:44 UTC (permalink / raw)
To: git
In-Reply-To: <20070615085346.8027.qmail@science.horizon.com>
linux@horizon.com wrote:
> Wouldn't it be nice if there were a way to tell git-update-index and
> git-checkout index that certain directories are not in the working
> directory, but don't worry. Just pretend they exist and match the index.
>
> Then I could mark much of arch/* as "don't bother" and save a pile of
> disk space per working directory.
Currently, directories are not registered in the index. For this reason,
empty directories cannot be versioned. One day, will want to support
this, and for this purpose, directories must also be registered in the
index. Once this infrastructure is in place, the "don't bother" flag
will be a no-brainer, methinks.
-- Hannes
^ permalink raw reply
* Re: [CORRECTED PATCH] Introduce file with the common default build-time items.
From: Eygene Ryabinkin @ 2007-06-15 10:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Shawn O. Pearce
In-Reply-To: <46723C9F.4EE044F9@eudaptics.com>
Johannes, good day.
Fri, Jun 15, 2007 at 09:15:43AM +0200, Johannes Sixt wrote:
> Eygene Ryabinkin wrote:
> > OK, let us wait for the other's reaction. May be you're right and
> > it doesn't worth it. But I always felt that if I can change something
> > by changing it only in one place, then it worth it. Otherwise I
> > should remember all places where it is used and this leads to errors.
> > But maybe the 'wish' and 'tclsh' are not worth it.
>
> Huh? This "one place" already exists. Its name is 'config.mak'. I have
> this in it:
>
> TCL_PATH=tclsh84
> TCLTK_PATH=wish84
config.mak is a bit different: it is not used by the configure when
it sets the default TCL_PATH. But ok, I feel that my change is not
very good, since two of you already disliked it. Please, don't
waste your time on it anymore.
--
Eygene
^ permalink raw reply
* Re: Feature request: thin checkout
From: Rogan Dawes @ 2007-06-15 9:49 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20070615085346.8027.qmail@science.horizon.com>
linux@horizon.com wrote:
> Git packs so well that it's very common for the unpacked source to be much
> larger than the history in .git. The linux-kernel archive is a prime example.
>
> I've also started using git-svn (awesome tool, BTW) and have discovered
> the impressive disk space costs associated with SVN's tags/ directories
> if I actually want to download the full history.
>
> If you have multiple cloned repositories on one system, git can share
> the history, but the working directory problem is exacerbated.
> (Disk is cheap, but the RAM to cache it is limited.)
>
> This got me thinking...
> Wouldn't it be nice if there were a way to tell git-update-index and
> git-checkout index that certain directories are not in the working
> directory, but don't worry. Just pretend they exist and match the index.
>
I think that update-index is able to do (some of) this already:
$ man git-update-index
SYNOPSIS
git-update-index
[--cacheinfo <mode> <object> <file>]*
--cacheinfo <mode> <object> <path>
Directly insert the specified info into the index.
USING --CACHEINFO OR --INFO-ONLY
--cacheinfo is used to register a file that is not in the current
working directory. This is useful for minimum-checkout merging.
To pretend you have a file with mode and sha1 at path, say:
$ git-update-index --cacheinfo mode sha1 path
--info-only is used to register files without placing them in the
object database. This is useful for status-only repositories.
Both --cacheinfo and --info-only behave similarly: the index is
updated
but the object database isn't. --cacheinfo is useful when the
object is
in the database but the file isn't available locally. --info-only is
useful when the file is available, but you do not wish to update the
object database.
At any rate, it looks like some of the infrastructure is existing
already, even if the complete solution doesn't exist.
I *guess* it might even be as simple as maintaining a list of
"uncheckedout files with mode and sha" in the .git directory, and
merging that with what has actually been checked out when updating the
index.
i.e.
$ git checkout master:src/drivers
Get the <tree> object for master. Step through each entry. If the
requested path falls under the entry, recurse into it, checking out the
required files, otherwise write the <tree/file> info into
.git/partialcheckout.
Hack, hack, hack in src/drivers.
When you want to check what part of the tree is dirty, check if
.git/partialcheckouts exists. If it does, read through each entry,
comparing them to the index. Then, for the entries that are not in
partialcheckout, but are in the index, actually go to the filesystem to
check stat for each file.
Not quite sure how to handle something like:
$ git checkout master:src/drivers/scsi
$ git checkout master:src/drivers/usb
I guess one would have to trim entries from .git/partialcheckout as they
are actually fully checked out.
Rogan
^ permalink raw reply
* Feature request: thin checkout
From: linux @ 2007-06-15 8:53 UTC (permalink / raw)
To: git; +Cc: linux
Git packs so well that it's very common for the unpacked source to be much
larger than the history in .git. The linux-kernel archive is a prime example.
I've also started using git-svn (awesome tool, BTW) and have discovered
the impressive disk space costs associated with SVN's tags/ directories
if I actually want to download the full history.
If you have multiple cloned repositories on one system, git can share
the history, but the working directory problem is exacerbated.
(Disk is cheap, but the RAM to cache it is limited.)
This got me thinking...
Wouldn't it be nice if there were a way to tell git-update-index and
git-checkout index that certain directories are not in the working
directory, but don't worry. Just pretend they exist and match the index.
Then I could mark much of arch/* as "don't bother" and save a pile of
disk space per working directory.
This would be a little bit annoying if I tried to merge two branches with
conflicts in a "masked" part of the tree (well, it would create the index
entries, but I'd have no way to resolve the conflict), but I think that's
a matter of Don't Do That.
A slightly more flexible (but confusing?) option would be to mark parts
of the tree as "don't commit deletion". That is, within named sections
of the tree:
- Missing files in the working directory are assumed unchanged from
the index. (Perhaps unless you explicitly git-add them.)
- Files that don't already exist aren't checked out from the index.
(Unless explicitly named in a git-checkout operation.)
... but you could have a "selective checkout" in some directories.
E.g. in the kernel, you could include a stub Makefile, but omit
the .c files for file systems you don't need.
(And if we're really sneaky, teach the linux kernel Makefile how to check
out code when features are enabled. That would address a longstanding
complaint about the size of the linux kernel source tree. It's a
bit trickier than default make rules for getting <foo> from RCS/foo,v
because got doesn't provide a signle file that make(1) can look for,
but something's probably possible.)
That could also handle merges... the "check out the file with conflict
markers" operation could be unconditional if there are conflicts.
The multiple-git-repositories issue could be handled by hard-linking
the working directory files together (assuming your editor knows how to
unlink when changing them) using information easily available in the
index files. Git could even detect and complain if a two files that
mismatched their index entries were hard-linked together.
But for the git-svn case where you have a tags/ directory full of old
copies of files, hard-linking is of limited use if most files changed
between tags. Here, just being able to say "don't bother populating
that part of the working directory" would be very nice.
Does this make sense to anyone else?
^ permalink raw reply
* git-repack made my pack 317x larger...
From: linux @ 2007-06-15 8:50 UTC (permalink / raw)
To: git; +Cc: linux
I was grabbing a copy of the hwmon-2.6 git tree to play with:
> ~/tmp$ git-clone git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git
> Initialized empty Git repository in /home/linux/tmp/hwmon-2.6/.git/
> remote: Generating pack...
> remote: Done counting 496311 objects.
> remote: Deltifying 496311 objects.
> remote: 100% (496311/496311) done
> Indexing 496311 objects...
> remote: Total 496311 (delta 400999), reused 496151 (delta 400839)
> 100% (496311/496311) done
> Resolving 400999 deltas...
> 100% (400999/400999) done
> Checking 22409 files out...
> 100% (22409/22409) done
> ~/tmp$ ls -l hwmon-2.6/git/objects/pack
> -r--r--r-- 1 linux users 11912528 Jun 15 03:35 pack-d4ec0478f7530345ff466805ab4fe63efc9251df.idx
> -r--r--r-- 1 linux users 166721991 Jun 15 03:35 pack-d4ec0478f7530345ff466805ab4fe63efc9251df.pack
Then I noticed that it's a Linux kernel... oops!
Sorry for wasting the network bandwidth, but I can save myself
the disk space.
> ~/tmp$ rm -r hwmon-2.6/*
> ~/tmp$ mv hwmon-2.6 hwmon-2.6.old
> ~/tmp$ git clone --reference /usr/src/linux -n hwmon-2.6.old hwmon-2.6
> Initialized empty Git repository in /home/linux/tmp/hwmon-2.6/.git/
> remote: Generating pack...
> remote: Done counting 124 objects.
> remote: Deltifying 124 objects...
> remote: 100% (124/124) done
> Indexing 124 objects...
> remote: Total 124 (delta 83), reused 97 (delta 75)
> 100% (124/124) done
> Resolving 83 deltas...
> 100% (83/83) done
> ~/tmp$ rm -rf hwmon-2.6.olf
> ~/tmp$ cd hwmon-2.6
> ~/tmp/hwmon-2.6$ ls -l .git/objects/pack/
> total 168
> -r--r--r-- 1 linux users 4040 Jun 15 03:44 pack-e4de475aa6c82099b4a4a8f6f410dcc316c7cf19.idx
> -r--r--r-- 1 linux users 161548 Jun 15 03:44 pack-e4de475aa6c82099b4a4a8f6f410dcc316c7cf19.pack
Much better! But since that's only a few objects, let's repack them even tighter...
> ~/tmp/hwmon-2.6$ git-repack -a -d -f --window=50
> Generating pack...
> Done counting 18090 objects.
> Deltifying 18090 objects...
> 100% (18090/18090) done
> Writing 18090 objects...
> 100% (18090/18090) done
> Total 18090 (delta 2465), reused 7876 (delta 0)
> Pack pack-1af4ab6620f71733f17b16d69a89b6741e2c7fe3 created.
> Removing unused objects 100%...
> Done.
> ~/tmp/hwmon-2.6$ ls -l .git/objects/pack/
> total 50620
> -r--r--r-- 1 linux users 435224 Jun 15 04:00 pack-1af4ab6620f71733f17b16d69a89b6741e2c7fe3.idx
> -r--r--r-- 1 linux users 51333891 Jun 15 04:00 pack-1af4ab6620f71733f17b16d69a89b6741e2c7fe3.pack
Uh... what happened? It's not a full kernel clone, but it's a lot more
objects than I expected. Where did all the extra objects come from?
^ permalink raw reply
* Re: [PATCH guilt] make guilt use standard POSIX shell
From: Derek Fawcus @ 2007-06-15 8:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Josef Jeff Sipek, git
In-Reply-To: <11818254621527-git-send-email-madcoder@debian.org>
On Thu, Jun 14, 2007 at 02:50:55PM +0200, Pierre Habouzit wrote:
> This patch series makes guilt be able to work with a standard posix shell.
>
> This has been tested with bash, zsh, dash and posh acting as /bin/sh.
Well if you want to try with a 'real' bourne shell, there is always the
heirloom sh or the v7 shell...
http://heirloom.sourceforge.net/sh.html
http://www.collyer.net/who/geoff/v7sh.tar
http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/
DF
^ permalink raw reply
* Re: [RFT] Format our Documentation/ with both AsciiDoc 7 & 8
From: Pierre Habouzit @ 2007-06-15 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stefan Richter
In-Reply-To: <7vfy4t915f.fsf@assigned-by-dhcp.pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
On Thu, Jun 14, 2007 at 11:34:20PM -0700, Junio C Hamano wrote:
> It turns out that the attribute definition we have had for a
> long time to hide "^" character from AsciiDoc 7 was not honored
> by AsciiDoc 8 even under "-a asciidoc7compatible" mode.
>
> Also the double colon at the end of definition list term needs
> to be attached to the term, without a whitespace. After this
> minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with
> compatibility mode seems to produce reasonably good results.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * This is "Request for Test" to people who reported problems
> formatting our documentation with asciidoc 8. To format with
> Asciidoc 8, you would need to say something like:
>
> $ make ASCIIDOC8=YesPlease doc
sadly, it does not fixes the issue I reported with git-pull.1 (e.g.)
that reads:
<refspec>
The canonical format of a <refspec> parameter is ?<src>:<dst>; that
whereas it should be:
<refspec>
The canonical format of a <refspec> parameter is +?<src>:<dst>; that
But I've not seen any serious or even noticeable regression here.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-send-pack SIGSEGV..
From: Alex Riesen @ 2007-06-15 7:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List, Daniel Barkalow
In-Reply-To: <7vr6od92nj.fsf@assigned-by-dhcp.pobox.com>
On 6/15/07, Junio C Hamano <gitster@pobox.com> wrote:
> --- a/remote.c
> +++ b/remote.c
> @@ -252,6 +252,8 @@ static struct refspec *parse_ref_spec
> ep = gp;
> }
> rs[i].src = xstrndup(sp, ep - sp);
> + if (rs[i].pattern && !rs[i].dst)
> + rs[i].dst = xstrdup(rs[i].src);
It may be possible to just reuse rs[i].src - there is no deallocation
of refspecs anywhere nor are src or dst detached from refspec
(which may be bad, but probably is covered in libification effort).
^ permalink raw reply
* Re: [CORRECTED PATCH] Introduce file with the common default build-time items.
From: Johannes Sixt @ 2007-06-15 7:15 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <20070615054002.GD3779@void.codelabs.ru>
Eygene Ryabinkin wrote:
> OK, let us wait for the other's reaction. May be you're right and
> it doesn't worth it. But I always felt that if I can change something
> by changing it only in one place, then it worth it. Otherwise I
> should remember all places where it is used and this leads to errors.
> But maybe the 'wish' and 'tclsh' are not worth it.
Huh? This "one place" already exists. Its name is 'config.mak'. I have
this in it:
TCL_PATH=tclsh84
TCLTK_PATH=wish84
-- Hannes
^ permalink raw reply
* Re: [PATCH] Documentation/gitmodules: fix asciidoc
From: Lars Hjemli @ 2007-06-15 7:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sam Vilain, Junio C Hamano, git
In-Reply-To: <20070615034915.GE18491@spearce.org>
On 6/15/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> > ---
> > I was getting documentation build errors without this
>
> Yea, I got doc build errors today too from `next`
This is my bad, sorry about that.
Have you tested the patch in
<11817720703159-git-send-email-hjemli@gmail.com> /
http://article.gmane.org/gmane.comp.version-control.git/50135 ?
--
larsh
^ 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