* Re: git-checkout-index, flag ordering and --prefix kludgy handling
From: Linus Torvalds @ 2005-10-18 2:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzl7tv89.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Oct 2005, Junio C Hamano wrote:
>
> One reason I have not done nor said much about this was because
> I've been thinking about making the branch/refname more explicit
> on our command line.
Yes, I know it's ambigious at times, but it really is very convenient.
Usually we allow a "--" to say where a filename starts when it _is_
ambiguous.
However, you're right, we fail that at times. In particular, git-rev-parse
fails it.
Something like this?
Linus
---
diff --git a/rev-parse.c b/rev-parse.c
index 41b9dae..85230df 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -151,6 +151,12 @@ static void show_datestring(const char *
show(buffer);
}
+static void show_file(const char *arg)
+{
+ if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV))
+ show(arg);
+}
+
int main(int argc, char **argv)
{
int i, as_is = 0, verify = 0;
@@ -162,7 +168,7 @@ int main(int argc, char **argv)
char *dotdot;
if (as_is) {
- show(arg);
+ show_file(arg);
continue;
}
if (*arg == '-') {
@@ -282,9 +288,7 @@ int main(int argc, char **argv)
}
if (verify)
die("Needed a single revision");
- if ((filter & (DO_NONFLAGS|DO_NOREV)) ==
- (DO_NONFLAGS|DO_NOREV))
- show(arg);
+ show_file(arg);
}
show_default();
if (verify && revs_count != 1)
^ permalink raw reply related
* Re: Scribblings for a cogito/git tutorial
From: David Whistler @ 2005-10-18 2:28 UTC (permalink / raw)
To: git
In-Reply-To: <200510171504.j9HF4stb006164@laptop11.inf.utfsm.cl>
Horst von Brand <vonbrand <at> inf.utfsm.cl> writes:
>
> Comments, suggestions, patches are welcome!
>
> Repository of the script and supporting files is at
> <http://pincoya.inf.utfsm.cl/Script.git>
I can't read it. Seems to be a recursive trick.
Or did you mean to do that?
-d
^ permalink raw reply
* Re: git-checkout-index, flag ordering and --prefix kludgy handling
From: Junio C Hamano @ 2005-10-18 2:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510171814430.3369@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, I'd really like a "git checkout" that can do the per-file thing,
> instead of always using the equivalent of git-checkout-index with "-a".
>
> It's actually one of the few places where I still use the raw git
> commands, doing things like
>
> git-checkout-index -u -f filename
>
> and I suspect that a lot of people would prefer that
>
> git checkout filename
>
> would just do that. Instead, we error out ("no such branch"). Which
> isn't even what I want, and almost certainly not what most CVS users want
> (they're used to checking out individual files).
Yes, it has been on the TODO list for quite some time.
One reason I have not done nor said much about this was because
I've been thinking about making the branch/refname more explicit
on our command line.
Currently, we tell 'git-rev-parse' to tell refnames and other
non-flag parameters apart, which in practice does not result in
much confusion, but I think it is not quite right.
I used to have a local branch, only to fetch updates from
paulus, and naturally the branch was called 'gitk'. But we have
a file called gitk sitting at the top level of the tree, and
'git diff gitk gitk' was not really working as well as I would
have liked ('git diff heads/gitk gitk' should have worked, but I
do not think it did). Since then this forced me to rename the
branch to 'paulus' X-<.
On the other hand, if there is no ambiguity, I do not think
forcing people to always spell out '-r' like CVS or SVN do
is not necessary:
$ git diff -r master^^ -r master ;# two commits
$ git diff -r v0.99.8 ;# changes since that tag
$ git checkout -r master
$ git checkout -r master $filename
This checkout optionally taking filename is introducing one more
ambiguity, and I was reluctant to do so before deciding what to
do about other commands.
Another thing I was thinking was that this might be better
implemented as a separate command that can revert the working
tree file to an artibtrary tree-ish as well. So:
$ git xxxxxx --index file1 file2...
would do your 'git-checkout-index -f -u file1 file2...', while
$ git xxxxxx file1 file2...
would do an equivalent of:
git ls-tree HEAD file1 file2... |
sed -e 's/^\([0-7]*\) [^ ]* /\1 /' |
git-update-index --index-info
git-checkout-index -f -u file1 file2...
or even:
$ git xxxxxx HEAD^^ file1 file2...
would give you back file1 and file2 from two revs back. Of
course, to avoid ambiguities, the last one will be spelled as
$ git xxxxxx -r HEAD^^ file1 file2...
if people find that a separate command is cleaner.
Anyway, in the meantime...
------------
[PATCH] checking out individual files from index.
'git checkout filename1 filename2...' can be used to revert the
changes you made to files in the working tree to the version
recorded in the index file.
Signed-off-by: Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-checkout.sh b/git-checkout.sh
index 2c053a3..6af71a2 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -6,6 +6,7 @@ new=
force=
branch=
newbranch=
+
while [ "$#" != "0" ]; do
arg="$1"
shift
@@ -24,19 +25,28 @@ while [ "$#" != "0" ]; do
force=1
;;
*)
- rev=$(git-rev-parse --verify "$arg^0" 2>/dev/null) ||
- die "I don't know any '$arg'."
- if [ -z "$rev" ]; then
- echo "unknown flag $arg"
- exit 1
- fi
- if [ "$new" ]; then
- echo "Multiple revisions?"
- exit 1
- fi
- new="$rev"
- if [ -f "$GIT_DIR/refs/heads/$arg" ]; then
- branch="$arg"
+ if rev=$(git-rev-parse --verify "$arg^0" 2>/dev/null)
+ then
+ if [ -z "$rev" ]; then
+ echo "unknown flag $arg"
+ exit 1
+ fi
+ if [ "$new" ]; then
+ echo "Multiple revisions?"
+ exit 1
+ fi
+ new="$rev"
+ if [ -f "$GIT_DIR/refs/heads/$arg" ]; then
+ branch="$arg"
+ fi
+ else
+ # check out individual files from index
+ if test "$new" || test "$newbranch"
+ then
+ die "checkout and switch tree?"
+ fi
+ git-checkout-index -f -u "$arg" "$@"
+ exit $?
fi
;;
esac
Compilation finished at Mon Oct 17 19:08:29
^ permalink raw reply related
* Re: git-checkout-index, flag ordering and --prefix kludgy handling
From: Linus Torvalds @ 2005-10-18 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xwry88u.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Oct 2005, Junio C Hamano wrote:
>
> The patch looks good. Thanks.
Btw, I'd really like a "git checkout" that can do the per-file thing,
instead of always using the equivalent of git-checkout-index with "-a".
It's actually one of the few places where I still use the raw git
commands, doing things like
git-checkout-index -u -f filename
and I suspect that a lot of people would prefer that
git checkout filename
would just do that. Instead, we error out ("no such branch"). Which
isn't even what I want, and almost certainly not what most CVS users want
(they're used to checking out individual files).
Of course, in the generic case, that would require git-read-tree to take a
list of filenames (which would act as a "mask" for any activity against
the old index if one was loaded), but that's a pretty big thing. Even if
it's admittedly also potentially very useful too..
But even just a total special case (giving a filename would force the
checkout, no read-tree, no nothing, just force the old index contents)
might be acceptable and would only require some script hackery.
Linus
^ permalink raw reply
* Re: git-checkout-index, flag ordering and --prefix kludgy handling
From: Junio C Hamano @ 2005-10-18 0:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510171546580.3369@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Yeah, somebody should really fix the command line parsing.
>
> I think it's only git-checkout-index that _really_ needs fixing, since it
> has such a fragile thing right now.
Good to hear that you finally said it.
The patch looks good. Thanks.
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Nick Hengeveld @ 2005-10-17 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bmzzz30.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 17, 2005 at 01:08:03PM -0700, Junio C Hamano wrote:
> - a way for the user to say "unless I ask explicitly otherwise,
> do not bother me if the commits older than these ones are
> incomplete" -- an milder version of cauterizing commit chain
> via info/grafts.
>
> - a way for the user to say "this time I am explicitly
> overriding the above -- I am interested in older history".
>
> - change to fsck-objects, fetch- and probably upload-pack on
> the other end, and commit walkers to honor the above two.
That's how I interpreted the -c and -a command-line arguments to the
commit walkers. git-fetch calls them with -a but we've been using -t
to only follow the tree objects and it's been working great.
Perhaps that would be a good way for the commit walker to decide whether
to transfer a full pack file - it may not make sense if it wasn't told
to get history.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Linus Torvalds @ 2005-10-17 23:19 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Nick Hengeveld, git
In-Reply-To: <Pine.LNX.4.63.0510171830030.23242@iabervon.org>
On Mon, 17 Oct 2005, Daniel Barkalow wrote:
>
> Wouldn't "git fetch http://.../foo.git/ master^{tree}" do the right thing?
The pack pullers have trouble with anything that isn't commit-based,
because they do all the "figure out what we have in common" logic based on
the commit history.
So if you fetch a tree, it by definition doesn't _have_ any history, and
the pack pullers will always pack the whole tree. I think.
Linus
^ permalink raw reply
* Re: git-checkout-index, flag ordering and --prefix kludgy handling
From: Junio C Hamano @ 2005-10-17 22:58 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200510162114.27429.blaisorblade@yahoo.it>
Blaisorblade <blaisorblade@yahoo.it> writes:
> I already knew that git-checkout-cache -a -f is wrong. But I
> didn't know that
>
> git-checkout-index -a --prefix=/home/paolo/Uml/space.mnt/paolo/Linux-2.6.git/
>
> is.
> At least, this should be documented in the man page;...
How about a bit further clarification on top of what is there,
like this?
------------
[PATCH] clarify that '-a' is really special in checkout-index.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index 1ba6fb2..838059f 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -44,13 +44,15 @@ OPTIONS
--::
Do not interpret any more arguments as options.
-Note that the order of the flags matters:
+Note that the order of the flags matters for `-a` flag:
git-checkout-index -a -f file.c
will first check out all files listed in the cache (but not overwrite
any old ones), and then force-checkout `file.c` a second time (ie that
one *will* overwrite any old contents with the same filename).
+In other words, `-a` means "operate as if names of all files were
+given here, with the flags given up to this point."
Also, just doing "git-checkout-index" does nothing. You probably meant
"git-checkout-index -a". And if you want to force it, you want
^ permalink raw reply related
* Re: git-checkout-index, flag ordering and --prefix kludgy handling
From: Linus Torvalds @ 2005-10-17 22:58 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200510162114.27429.blaisorblade@yahoo.it>
On Sun, 16 Oct 2005, Blaisorblade wrote:
>
> I already knew that git-checkout-cache -a -f is wrong. But I didn't know that
>
> git-checkout-index -a --prefix=/home/paolo/Uml/space.mnt/paolo/Linux-2.6.git/
>
> is. It checks out the files in the cwd, then parses --prefix and does nothing
> there, as no name is specified.
Yeah, somebody should really fix the command line parsing.
I think it's only git-checkout-index that _really_ needs fixing, since it
has such a fragile thing right now.
Here's a totally untested patch. Do you want to test it?
It also makes it illegal to mix "-a" and explicit filenames, since the
semantics of that has now changed (before, the order of the filename and
the "-a" mattered. Now it no longer does. Better disallow it, than let
people maybe think they get something else that they do).
Danger, Will Robinson! Untested!
Linus
---
diff --git a/checkout-index.c b/checkout-index.c
index 9784532..dab3778 100644
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -87,8 +87,9 @@ static struct cache_file cache_file;
int main(int argc, char **argv)
{
- int i, force_filename = 0;
+ int i;
int newfd = -1;
+ int all = 0;
if (read_cache() < 0) {
die("invalid cache");
@@ -96,58 +97,70 @@ int main(int argc, char **argv)
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
- if (!force_filename) {
- if (!strcmp(arg, "-a")) {
- checkout_all();
- continue;
- }
- if (!strcmp(arg, "--")) {
- force_filename = 1;
- continue;
- }
- if (!strcmp(arg, "-f")) {
- state.force = 1;
- continue;
- }
- if (!strcmp(arg, "-q")) {
- state.quiet = 1;
- continue;
- }
- if (!strcmp(arg, "-n")) {
- state.not_new = 1;
- continue;
- }
- if (!strcmp(arg, "-u")) {
- state.refresh_cache = 1;
- if (newfd < 0)
- newfd = hold_index_file_for_update
- (&cache_file,
- get_index_file());
- if (newfd < 0)
- die("cannot open index.lock file.");
- continue;
- }
- if (!memcmp(arg, "--prefix=", 9)) {
- state.base_dir = arg+9;
- state.base_dir_len = strlen(state.base_dir);
- continue;
- }
- if (arg[0] == '-')
- usage(checkout_cache_usage);
- }
- if (state.base_dir_len) {
- /* when --prefix is specified we do not
- * want to update cache.
- */
- if (state.refresh_cache) {
- close(newfd); newfd = -1;
- rollback_index_file(&cache_file);
- }
- state.refresh_cache = 0;
+
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-a") || !strcmp(arg, "--all")) {
+ all = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-f") || !strcmp(arg, "--force")) {
+ state.force = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet")) {
+ state.quiet = 1;
+ continue;
}
+ if (!strcmp(arg, "-n") || !strcmp(arg, "--no-create")) {
+ state.not_new = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-u") || !strcmp(arg, "--index")) {
+ state.refresh_cache = 1;
+ if (newfd < 0)
+ newfd = hold_index_file_for_update
+ (&cache_file,
+ get_index_file());
+ if (newfd < 0)
+ die("cannot open index.lock file.");
+ continue;
+ }
+ if (!memcmp(arg, "--prefix=", 9)) {
+ state.base_dir = arg+9;
+ state.base_dir_len = strlen(state.base_dir);
+ continue;
+ }
+ if (arg[0] == '-')
+ usage(checkout_cache_usage);
+ break;
+ }
+
+ if (state.base_dir_len) {
+ /* when --prefix is specified we do not
+ * want to update cache.
+ */
+ if (state.refresh_cache) {
+ close(newfd); newfd = -1;
+ rollback_index_file(&cache_file);
+ }
+ state.refresh_cache = 0;
+ }
+
+ /* Check out named files first */
+ for ( ; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (all)
+ die("git-checkout-index: don't mix '--all' and explicit filenames");
checkout_file(arg);
}
+ if (all)
+ checkout_all();
+
if (0 <= newfd &&
(write_cache(newfd, active_cache, active_nr) ||
commit_index_file(&cache_file)))
^ permalink raw reply related
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Daniel Barkalow @ 2005-10-17 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nick Hengeveld, git
In-Reply-To: <7v3bmzzz30.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Oct 2005, Junio C Hamano wrote:
> Nick Hengeveld <nickh@reactrix.com> writes:
>
> > Gotcha - I'm still thinking in terms of content distribution, where
> > you only need a specific version of a tree to be available locally
> > and explicitly don't want to transfer history.
>
> In other words, you'd want to also support CVS-like "working
> tree has the specific version, and history is not kept here, but
> available on demand, possibly over the network" mode of
> operation. I'd say why not. We could aim to have "working tree
> has the specific version and partial history of recent versions,
> and the ancient history is available on demand, possibly over
> the network" mode of operation.
>
> It is somewhat different from the primary focus of what we have
> been doing, but I think it is a natural extension. The
> invariant is that once you have a ref pointing at a specific
> commit, everything reachable from it ought to be available to
> you.
Wouldn't "git fetch http://.../foo.git/ master^{tree}" do the right thing?
You get only the current tree, and write a ref to the tree instead of the
commit, maintaining the invariant. Of course, fetch.c needs a bit of work
so that it can fetch objects in the process of figuring out what the
refspec that it's really trying to fetch, but that should be simple
enough.
Of course, this really isolates you from the history, since you don't even
remember what the commit was that you've got the tree from, but that may
not be an issue in a pure content distribution setup. Also, a pack file of
a single tree isn't going to be terribly efficient, because pack files
mostly exploit the high similarity between different versions of the same
file.
My other idea is to have a file of things that you expect to be missing,
even though they are referenced, and where to expect to find them if
necessary. Then you could download the latest commit, mark its parents
(unless you have them) as known-missing, and write the ref.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-snapshot.sh
From: Johannes Schindelin @ 2005-10-17 22:21 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20051017220615.GG12774@schottelius.org>
Hi,
On Tue, 18 Oct 2005, Nico -telmich- Schottelius wrote:
> I really like to have a snapshot available from my sources in VCS.
>
> Therefore I wrote the attached script.
>
> git-tar-tree $(git-log | head -n1 | awk '{ print $2 }')
And why not "git-tar-tree HEAD"?
Ciao,
Dscho
^ permalink raw reply
* git-snapshot.sh
From: Nico -telmich- Schottelius @ 2005-10-17 22:06 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 327 bytes --]
Hello!
I really like to have a snapshot available from my sources in VCS.
Therefore I wrote the attached script.
Just wanted to send it, perhaps someone can use it.
Nico
--
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #1.2: git-snapshot.sh --]
[-- Type: application/x-sh, Size: 309 bytes --]
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* git-checkout-index, flag ordering and --prefix kludgy handling
From: Blaisorblade @ 2005-10-16 19:14 UTC (permalink / raw)
To: git
I already knew that git-checkout-cache -a -f is wrong. But I didn't know that
git-checkout-index -a --prefix=/home/paolo/Uml/space.mnt/paolo/Linux-2.6.git/
is. It checks out the files in the cwd, then parses --prefix and does nothing
there, as no name is specified.
Also, the SYNOPSIS of the man page is rather misleading:
git-checkout-index [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] [--] <file>...
seems to suggest that prefix can go after -f, how it's reasonable to do.
At least, this should be documented in the man page; but I think that fixing
this (via two getopt() invocations rather than one, the first for flags like
--prefix and the rest for actions) is probably a better thing to do.
Actually, given the audience, saying that "-a" and "filename" are both actions
(which are executed when seen on the command line) would be a better
explaination - and a reference to the "find" command (which behaves
similarly) would be worth.
However, find *does* accept "options" (like -maxdepth) in any cmd line place.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Messenger: chiamate gratuite in tutto il mondo
http://it.messenger.yahoo.com
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Junio C Hamano @ 2005-10-17 20:08 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051017174123.GI5509@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> Gotcha - I'm still thinking in terms of content distribution, where
> you only need a specific version of a tree to be available locally
> and explicitly don't want to transfer history.
In other words, you'd want to also support CVS-like "working
tree has the specific version, and history is not kept here, but
available on demand, possibly over the network" mode of
operation. I'd say why not. We could aim to have "working tree
has the specific version and partial history of recent versions,
and the ancient history is available on demand, possibly over
the network" mode of operation.
It is somewhat different from the primary focus of what we have
been doing, but I think it is a natural extension. The
invariant is that once you have a ref pointing at a specific
commit, everything reachable from it ought to be available to
you.
And we have extended the definition of "available" over time.
Initially, you needed to have individual objects, and then we
made it so they could live in packs, and now they could even be
borrowed from another repository via alternates. We currently
do not consider "lazily fetchable over the network" as
"available", but I do not object too much to that, as long as it
is an optional feature.
This probably is a post 1.0 item, though. Off the top of my
head, we would need:
- a way for the user to say "unless I ask explicitly otherwise,
do not bother me if the commits older than these ones are
incomplete" -- an milder version of cauterizing commit chain
via info/grafts.
- a way for the user to say "this time I am explicitly
overriding the above -- I am interested in older history".
- change to fsck-objects, fetch- and probably upload-pack on
the other end, and commit walkers to honor the above two.
Most of these can probably be done by existing info/grafts
mechanism, but even then definitely would need a nicer user
interface.
Once this is in place, range requests to pick data for
individual objects from packs residing on a remote HTTP server
would start to make sense.
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Daniel Barkalow @ 2005-10-17 19:13 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, git
In-Reply-To: <20051016213341.GF5509@reactrix.com>
On Sun, 16 Oct 2005, Nick Hengeveld wrote:
> On Sun, Oct 16, 2005 at 09:56:49AM -0700, Junio C Hamano wrote:
>
> > That's what the .idx file is for, except that after you fetch
> > the range, you may find you would need something else that the
> > object is delta against.
>
> Would it make sense to load the pack indexes for each base up front,
> and then fetch individual objects from a pack if they exist in one of
> a base's pack indexes? In such a case, it may not even make sense to
> try fetching the object directly first.
At the start, you have the option of either fetching the list of packs or
the object. There are three cases:
1) the object isn't available separately; we need to fetch the list of
packs to find it in a pack.
2) there aren't any new packs; we need to fetch the object individually.
3) the object is present both individually and in a pack.
(2) is more common than (1), because we don't repack every update. (3)
doesn't happen at all, currently, because we prune after packing. So it
makes most sense to try the object at once.
On the other hand, the parallel code should probably do both at the same
time, since it can, and it only causes notable latency, not bandwidth. We
probably also ought to speculatively get any new index files in parallel
with whatever else we're doing, since it is likely that we'll need some
pack at some point, and then we'll need all the index files to decide what
pack to get.
> What are the circumstances under which it makes more sense to fetch the
> whole pack rather than fetching individual objects from it?
I'm not sure there's a good way of deciding without a plan for what
conditions cause there to be a choice.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Strange differences in cogito on SPARC and i386
From: Horst von Brand @ 2005-10-17 19:06 UTC (permalink / raw)
To: git
git, cogito up to date everywhere.
I updated my linux-2.6.git trees on SPARC and i386 yesterday at almost the
same time, and I then noted that on the SPARC I'd get interrupted fetches
and stuff like:
[vonbrand@pincoya linux-2.6.git]$ cg-update
Recovering from a previously interrupted fetch...
15:04:56 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
Getting alternates list
progress: 10 objects, 24166 bytes
error: Empty reply from server (curl_result = 52, http_code = 0, sha1 = 0801ec7bf4953784f0f3279c1a80258ad29094d6)
Getting pack list
progress: 11 objects, 24873 bytes
error: Unable to find 0801ec7bf4953784f0f3279c1a80258ad29094d6 under http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Just started again each time, seems to work fine. On i386 the download goes
smoothly, no hickups. And there are /no/ updates while SPARC is working its
head off getting updates...
Then again, today on the SPARC it is getting several thousand objects (!),
while on i386 it was only a few dozen.
Some stupid pilot error? Got different mirrors between machines? Sounds
unlikely, as repeating the command (and presumably rotating between DNS
entries) makes no difference.
Just finished SPARCwise. Almost 10K objects for changes to 4 files?! Yes,
the files changed are the same on both machines.
Mistified...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
--j9HIKc4x028468.1129573238/inti.inf.utfsm.cl--
^ permalink raw reply
* Re: [PATCH] Some curl versions lack curl_easy_duphandle()
From: Johannes Schindelin @ 2005-10-17 18:54 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, git
In-Reply-To: <20051017180130.GJ5509@reactrix.com>
Hi,
On Mon, 17 Oct 2005, Nick Hengeveld wrote:
> On Sun, Oct 16, 2005 at 02:50:18PM -0700, Nick Hengeveld wrote:
>
> > Is that the correct version number? I've been using 7.10.6 and
> > curl_easy_duphandle() has been working fine.
>
> Apart from the version number question, this patch looks good.
Aaargh! Of course I was looking at the annotate output, which said Nov 9,
2004. But this is just the last change to the signature of the function!
So, AFAIK Sep 13, 2001, is the correct date, and 0x070900 is the version.
> Although I'm now wondering whether it makes sense to bother trying to
> use curl_easy_duphandle() at all and always use get_curl_handle()
> instead.
There might well be a substantial overhead involved. I haven't measured
it, but it seems reasonable to assume that duplicating a handle is
implemented using a shorter code path than creating a handle all over
again.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Some curl versions lack curl_easy_duphandle()
From: Nick Hengeveld @ 2005-10-17 18:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <20051016215018.GG5509@reactrix.com>
On Sun, Oct 16, 2005 at 02:50:18PM -0700, Nick Hengeveld wrote:
> Is that the correct version number? I've been using 7.10.6 and
> curl_easy_duphandle() has been working fine.
Apart from the version number question, this patch looks good. Although
I'm now wondering whether it makes sense to bother trying to use
curl_easy_duphandle() at all and always use get_curl_handle() instead.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Nick Hengeveld @ 2005-10-17 17:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe5o366d.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 17, 2005 at 01:21:14AM -0700, Junio C Hamano wrote:
> The assumption, which is the property the suggested packing
> strategy has, is that older objects that are needed to complete
> the history leading to the current tip are packed in those
> n-month/n-week packs, so if we do not have them we would likely
> be needing them, although we might not have walked that far back
> in history yet.
Gotcha - I'm still thinking in terms of content distribution, where
you only need a specific version of a tree to be available locally
and explicitly don't want to transfer history. In our case, using
packs doesn't make sense at the moment.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Scribblings for a cogito/git tutorial
From: Horst von Brand @ 2005-10-17 15:04 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff (CatalystIT)
I've also been asked around here for a cogito+git tutorial, to that end
I've made up a script that simulates several developers interacting.
Hacking around is simulated by patching, ed(1) scripts (merges don't turn
out the same diff every time), and plain copying new files in. I've set up
a GPG key with an empty passphrase (comment is "Experimental") to have
signed tags, etc. in a convenient manner. The idea is to create interesting
histories (for browsing) and show off the commands in a compact way. If
only there was a convenient way to run a strech of the (bash) script, look
at the results, and then resume...
Comments, suggestions, patches are welcome!
Repository of the script and supporting files is at
<http://pincoya.inf.utfsm.cl/Script.git>
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* How do I clear the directory cache
From: eschvoca @ 2005-10-17 14:20 UTC (permalink / raw)
To: git
Hi,
If I do a:
cg-commit
modifiy some files
cg-rm <modified files>
cg-add <a new file>
cg-rm <a unmodified file>
Then how do I get back and undo all of the cg-adds and cg-rms? I want
cg-status to show the the changes from my commit and my current
working tree.
Thanks.
e
^ permalink raw reply
* Re: cg-merge should use git-merge
From: Junio C Hamano @ 2005-10-17 9:26 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <46a038f90510170203ndee2b2bi913b62014614f68e@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Something like a manual merge that I could force to happen on command
>
> git-doarbitrarymergeontree -r fromtree:totree [ victimtree ]
>
That essentially is a simple one-liner:
git-read-tree -m -u fromtree HEAD totree
which is more or less what git-cherry-pick and git-revert do,
except fromtree always is totree^ in git-cherry-pick.
^ permalink raw reply
* Re: cygwin: t3200-branch.sh fails with "List form of pipe open not implemented at -e line 22."
From: Alex Riesen @ 2005-10-17 8:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr1peweu.fsf@assigned-by-dhcp.cox.net>
On 10/16/05, Junio C Hamano <junkio@cox.net> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> >> >The message comes from one of the hooks, which are executed even
> >> >though they never meant to, because cygwin apparently uses file
> >> >content or name to detect executability (on FAT).
>
> Is this one of the hooks we ship as examples? If so, that
> means worse brokenness than just test failing. It means that
> the hook is not usable in your environment.
>
> I presume it is this line in pre-commit sample hook:
>
> open $fh, "-|", qw(git-diff-index -p -M --cached HEAD);
>
> Is Perl on Cygwin incapable of handle this in general, or is it
> just what is on your machine being behind?
ActiveState's Windows port of Perl 5.8.6.
$ perl -e 'open $fh, "-|", qw(git-diff-index -p -M --cached HEAD)'
List form of pipe open not implemented at -e line 1.
I think it is not implemented because of Win32 lacking fork(2).
^ permalink raw reply
* Re: cg-merge should use git-merge
From: Junio C Hamano @ 2005-10-17 8:31 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <46a038f90510161744m7e95303eu8a9942363ffc58a6@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> - Junio, would you tolerate a flag for git-merge that says "don't
> autocommit even on cleanly merged"?
I'd *welcome* not just tolerate.
Currently both git-am and git-applypatch call git-merge-resolve
directly, but they should really be calling git-merge with user
supplied strategy with '-s' parameter. By bypassing git-merge,
they happen to get the "do not commit when you fall back on
3-way merge" semantics, but that is just by accident.
I have a plan to rewrite git-cherry-pick using git-format-patch
piped into git-am (I have not scripted it, but that is the
primary way I do cherry-picks these days), and being able to
customize what happens after merge by git-merge would probably
be useful there as well.
^ permalink raw reply
* Re: [kernel.org users] Re: auto-packing on kernel.org? please?
From: Junio C Hamano @ 2005-10-17 8:21 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051017060659.GH5509@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> To get a complete list of objects we do not have yet, fetch will need
> to walk all the trees first and then make another pass to process
> all the missing objects.
Notice I did not say "we do not have yet but we will need" -- I
just said "we do not have yet".
The assumption, which is the property the suggested packing
strategy has, is that older objects that are needed to complete
the history leading to the current tip are packed in those
n-month/n-week packs, so if we do not have them we would likely
be needing them, although we might not have walked that far back
in history yet.
The previous "packing strategy" picture was certainly too
simplified. Obviously we would not want to repack everything
every week for different periods all the way back -- we would
want to leave old huge pack untouched to help server side (and
mirroring), so instead of having a single "pack optimization
boundary", we would probably need some staggering as well for
archived material.
This is a revised example.
1yr -----
9mo --------
6mo ----------
3mo ------------------
1mo ------------
2wk --------
1wk ----
We keep track of "the current heads and tags" for each week.
Every week, we can do something like this:
- rotate the record, and create a new one:
mv .save/wk11 .save/wk12
mv .save/wk10 .save/wk11
mv .save/wk9 .save/wk10
...
mv .save/wk0 .save/wk1
find .git/refs -type f -print | xargs cat >.save/wk0
- prepare a pack to allow a single pack fetch to bring a
repository that had everything reachable from wk$N refs
up-to-date to the current, for selected recent weeks (say N=1,
2, 4, 12):
for N in 1 2 4 12
do
name=$(git-rev-list --objects \
$(sed -e 's/^/^/' .save/wk$N) \
$(cat .save/wk0) |
git-pack-object pack-) &&
mv pack-$name.* .git/objects/pack/.
done
remove the pack files that we created this way last week from
the repository (if the repository did not have any activity
during the last week we would have created the same set of
packs. make sure we do not remove them).
- except that, we keep the longest period (i.e. N=12 in this
example) one every N weeks (that's how 1yr, 9mo, 6mo packs in
the picture are kept).
This way, really old stuff (say, older than 3mo) will stay
intact and will not be repacked, so people reasonably up-to-date
(within 12 weeks in the example) need to fetch only one pack
(and unpacked objects since the last pack optimization), but
people without the ancient history need to go further back.
^ 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