* Re: GIT Error issue
From: Martin Langhoff @ 2006-04-19 21:53 UTC (permalink / raw)
To: Shyamal Sadanshio; +Cc: git
In-Reply-To: <3857255c0604190416j62abeae8va164896c5100f6ee@mail.gmail.com>
If you are using Debian or a derivative, just do
apt-get install git-core
which will remove the 'git' package (GNU Interactive Tools) and
install the git SCM. On RPM systems, probably
yum install git-core
will do the trick.
cheers,
martin
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Junio C Hamano @ 2006-04-19 21:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604182108070.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 18 Apr 2006, Junio C Hamano wrote:
>>
>> A small fry in the ointment. What should the parts that are
>> output with --name-only say for such a diff?
>
> I have no idea, I have to say ;)
Another small one ;-). Bare blobs do not have modes, so diffcore
needs to be told "do not bother comparing mode for this pair".
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Junio C Hamano @ 2006-04-19 21:43 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87acah6zk6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> But this does introduce an unfortunate semantic clash with the
> existing git-resolve, (which is an automated merge tool of some sort).
> I don't know much about the existing git-resolve, but a recent thread
> suggests it is a non-useful relic and people shouldn't be using it.
It is useful in a quick-and-dirty way, but does the same thing
as 'git merge -s resolve' and that is why people discussed
about removing it. It has semantics quite different from
update-index, so I'd ignore the synonym part of your
discussion.
Time for a quick raise-hand. Does anybody still use 'git
resolve'? Maybe we could remove it by 1.4?
> It would be nice if the complementary operations of manually
> resolving and unresolving a merge conflict had complementary command
> names.
True. I considered two other possibilities.
* "git unmerge", because it creates unmerged index entries, and
* "git update-index --unmerge", because this is just a special
kind of updates to the index file.
> ... For example, it might also complain if it notices
> conflict markers in the file. That seems like it would be a useful
> convenience.
Since you should compile test the merge result before going
anywhere, and the primary target of git is to manage sources, it
might not matter in most of the case, but for non-sources and non
compiled languages, that certainly is an issue.
When it _does_ matter, you can have a customized pre-commit hook
to look for the conflict markers, like this:
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 43d3b6e..723a9ef 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -61,6 +61,9 @@ perl -e '
if (/^\s* /) {
bad_line("indent SP followed by a TAB", $_);
}
+ if (/^(?:[<>=]){7}/) {
+ bad_line("unresolved merge conflict", $_);
+ }
}
}
exit($found_bad);
As usual, you can defeat the check with "git commit --no-verify"
for unlikely false matches.
> That's not much guidance for a new user that perhaps is only used to
> "git commit -a" and "git pull" that usually works. Without getting too
> verbose, this might be improved with something like:
>
> Automatic merge failed; fix conflicts by hand, then commit the result
That should be an easy patch ;-).
diff --git a/git-merge.sh b/git-merge.sh
index 78ab422..b834e79 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -335,5 +335,5 @@ Conflicts:
then
git-rerere
fi
- die "Automatic merge failed; fix up by hand"
+ die "Automatic merge failed; fix conflicts and then commit the result."
fi
^ permalink raw reply related
* Re: Support "git cmd --help" syntax
From: Jakub Narebski @ 2006-04-19 21:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0604151402470.3701@g5.osdl.org>
Linus Torvalds wrote:
> [...] You can always get the usage
> message with "git commit --huh?", so it's not like you've lost anything.
Or "git commit --usage".
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Carl Worth @ 2006-04-19 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu08p72sn.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]
On Wed, 19 Apr 2006 13:01:28 -0700, Junio C Hamano wrote:
>
> This is an attempt to address the issue raised on #git channel
> recently by Carl Worth.
...
> With git-unresolve <paths>..., the versions from our branch and
> their branch for specified blobs are placed in stage #2 and
> stage #3, without touching the working tree files. This gives
> you the combined diff back for easier review, along with
> "diff --ours" and "diff --theirs".
Thanks. This looks quite interesting.
The name of git-unresolve seems reasonable on its own. In fact,
git-merge already uses "resolve" to describe manual conflict
resolution. For example:
echo "Using the $best_strategy to prepare resolving by hand."
But this does introduce an unfortunate semantic clash with the
existing git-resolve, (which is an automated merge tool of some sort).
I don't know much about the existing git-resolve, but a recent thread
suggests it is a non-useful relic and people shouldn't be using it.
It would be nice if the complementary operations of manually
resolving and unresolving a merge conflict had complementary command
names. Would it be feasible to cop-opt the git-resolve name as a
synonym for update-index? (I certainly wouldn't mind a shorter name
for that operation.)
In fact, git-resolve could even go beyond being a synonym for
update-index. For example, it might also complain if it notices
conflict markers in the file. That seems like it would be a useful
convenience, (and no functionality would be robbed, since update-index
would still be available for anyone who needs to commit content that
looks like conflict markers).
Another thing I've been meaning to suggest soon is better output for
when an automatic merge fails. Currently, the final message is:
Automatic merge failed; fix up by hand
That's not much guidance for a new user that perhaps is only used to
"git commit -a" and "git pull" that usually works. Without getting too
verbose, this might be improved with something like:
Automatic merge failed; fix conflicts by hand, then commit the result
In addition, if git-commit is run with unmerged files, it could also
provide some extra guidance. Perhaps something like this, (just after
the list of "needs merge" files mentioned by git-update-index):
Fix any conflicts in these files, then git-resolve each and commit again
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] sha1_name.c: no need to include diff.h; tree-walk.h will do.
From: Linus Torvalds @ 2006-04-19 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wvt8hdb.fsf@assigned-by-dhcp.cox.net>
On Wed, 19 Apr 2006, Junio C Hamano wrote:
>
> * Just a clean-up, comes on top of the one that returns mode
> from get_tree_entry().
Ack (along with the mode addition).
However, since the function is now no longer private to the SHA1 name
lookup, I wonder if it might not be more logically put into "tree-walk.c"
instead of "sha1_name.c".
Just a thought.
Linus
^ permalink raw reply
* [RFC/PATCH] Add git-unresolve <paths>...
From: Junio C Hamano @ 2006-04-19 20:01 UTC (permalink / raw)
To: git; +Cc: Carl Worth
This is an attempt to address the issue raised on #git channel
recently by Carl Worth.
After a conflicted automerge, "git diff" shows a combined diff
to give you how the tentative automerge result differs from
what came from each branch. During a complex merge, it is
tempting to be able to resolve a few paths at a time, mark
them "I've dealt with them" with git-update-index to unclutter
the next "git diff" output, and keep going. However, when the
final result does not compile or otherwise found to be a
mismerge, the workflow to fix the mismerged paths suddenly
changes to "git diff HEAD -- path" (to get a diff from our
HEAD before merging) and "git diff MERGE_HEAD -- path" (to get
a diff from theirs), and it cannot show the combined anymore.
With git-unresolve <paths>..., the versions from our branch and
their branch for specified blobs are placed in stage #2 and
stage #3, without touching the working tree files. This gives
you the combined diff back for easier review, along with
"diff --ours" and "diff --theirs".
One thing it does not do is to place the base in stage #1; this
means "diff --base" would behave differently between the run
immediately after a conflicted three-way merge, and the run
after an update-index by mistake followed by a git-unresolve.
We could theoretically run merge-base between HEAD and
MERGE_HEAD to find which tree to place in stage #1, but
reviewing "diff --base" is not that useful so....
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* comes on top of the previous two "extended sha1" cleanups.
.gitignore | 1
Makefile | 3 +
cache.h | 1
sha1_name.c | 6 +-
unresolve.c | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 151 insertions(+), 5 deletions(-)
diff --git a/.gitignore b/.gitignore
index b5959d6..1e4ba7b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -111,6 +111,7 @@ git-tag
git-tar-tree
git-unpack-file
git-unpack-objects
+git-unresolve
git-update-index
git-update-ref
git-update-server-info
diff --git a/Makefile b/Makefile
index 8aed3af..85938c0 100644
--- a/Makefile
+++ b/Makefile
@@ -165,7 +165,8 @@ PROGRAMS = \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \
- git-describe$X git-merge-tree$X git-blame$X git-imap-send$X
+ git-describe$X git-merge-tree$X git-blame$X git-imap-send$X \
+ git-unresolve$X
BUILT_INS = git-log$X
diff --git a/cache.h b/cache.h
index 69801b0..a5f1eb3 100644
--- a/cache.h
+++ b/cache.h
@@ -235,6 +235,7 @@ #define DEFAULT_ABBREV 7
extern int get_sha1(const char *str, unsigned char *sha1);
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
+extern int get_tree_entry(const unsigned char *, const char *, unsigned char *, unsigned *);
extern int read_ref(const char *filename, unsigned char *sha1);
extern const char *resolve_ref(const char *path, unsigned char *sha1, int);
extern int create_symref(const char *git_HEAD, const char *refs_heads_master);
diff --git a/sha1_name.c b/sha1_name.c
index 7ad20b5..68b1275 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -450,8 +450,6 @@ static int get_sha1_1(const char *name,
return get_short_sha1(name, len, sha1, 0);
}
-static int get_tree_entry(const unsigned char *, const char *, unsigned char *, unsigned *);
-
static int find_tree_entry(struct tree_desc *t, const char *name, unsigned char *result, unsigned *mode)
{
int namelen = strlen(name);
@@ -487,13 +485,13 @@ static int find_tree_entry(struct tree_d
return -1;
}
-static int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned char *sha1, unsigned *mode)
+int get_tree_entry(const unsigned char *ent_sha1, const char *name, unsigned char *sha1, unsigned *mode)
{
int retval;
void *tree;
struct tree_desc t;
- tree = read_object_with_reference(tree_sha1, tree_type, &t.size, NULL);
+ tree = read_object_with_reference(ent_sha1, tree_type, &t.size, NULL);
if (!tree)
return -1;
t.buf = tree;
diff --git a/unresolve.c b/unresolve.c
new file mode 100644
index 0000000..14655f7
--- /dev/null
+++ b/unresolve.c
@@ -0,0 +1,145 @@
+#include "cache.h"
+
+static const char unresolve_usage[] =
+"git-unresolve <paths>...";
+
+static struct cache_file cache_file;
+static unsigned char head_sha1[20];
+static unsigned char merge_head_sha1[20];
+
+static struct cache_entry *read_one_ent(const char *which,
+ unsigned char *ent, const char *path,
+ int namelen, int stage)
+{
+ unsigned mode;
+ unsigned char sha1[20];
+ int size;
+ struct cache_entry *ce;
+
+ if (get_tree_entry(ent, path, sha1, &mode)) {
+ error("%s: not in %s branch.", path, which);
+ return NULL;
+ }
+ if (mode == S_IFDIR) {
+ error("%s: not a blob in %s branch.", path, which);
+ return NULL;
+ }
+ size = cache_entry_size(namelen);
+ ce = xcalloc(1, size);
+
+ memcpy(ce->sha1, sha1, 20);
+ memcpy(ce->name, path, namelen);
+ ce->ce_flags = create_ce_flags(namelen, stage);
+ ce->ce_mode = create_ce_mode(mode);
+ return ce;
+}
+
+static int unresolve_one(const char *path)
+{
+ int namelen = strlen(path);
+ int pos;
+ int ret = 0;
+ struct cache_entry *ce_2 = NULL, *ce_3 = NULL;
+
+ /* See if there is such entry in the index. */
+ pos = cache_name_pos(path, namelen);
+ if (pos < 0) {
+ /* If there isn't, either it is unmerged, or
+ * resolved as "removed" by mistake. We do not
+ * want to do anything in the former case.
+ */
+ pos = -pos-1;
+ if (pos < active_nr) {
+ struct cache_entry *ce = active_cache[pos];
+ if (ce_namelen(ce) == namelen &&
+ !memcmp(ce->name, path, namelen)) {
+ fprintf(stderr,
+ "%s: skipping still unmerged path.\n",
+ path);
+ goto free_return;
+ }
+ }
+ }
+
+ /* Grab blobs from given path from HEAD and MERGE_HEAD,
+ * stuff HEAD version in stage #2,
+ * stuff MERGE_HEAD version in stage #3.
+ */
+ ce_2 = read_one_ent("our", head_sha1, path, namelen, 2);
+ ce_3 = read_one_ent("their", merge_head_sha1, path, namelen, 3);
+
+ if (!ce_2 || !ce_3) {
+ ret = -1;
+ goto free_return;
+ }
+ if (!memcmp(ce_2->sha1, ce_3->sha1, 20) &&
+ ce_2->ce_mode == ce_3->ce_mode) {
+ fprintf(stderr, "%s: identical in both, skipping.\n",
+ path);
+ goto free_return;
+ }
+
+ remove_file_from_cache(path);
+ if (add_cache_entry(ce_2, ADD_CACHE_OK_TO_ADD)) {
+ error("%s: cannot add our version to the index.", path);
+ ret = -1;
+ goto free_return;
+ }
+ if (!add_cache_entry(ce_3, ADD_CACHE_OK_TO_ADD))
+ return 0;
+ error("%s: cannot add their version to the index.", path);
+ ret = -1;
+ free_return:
+ free(ce_2);
+ free(ce_3);
+ return ret;
+}
+
+static void read_head_pointers(void)
+{
+ if (read_ref(git_path("HEAD"), head_sha1))
+ die("Cannot read HEAD -- no initial commit yet?");
+ if (read_ref(git_path("MERGE_HEAD"), merge_head_sha1)) {
+ fprintf(stderr, "Not in the middle of a merge.\n");
+ exit(0);
+ }
+}
+
+int main(int ac, char **av)
+{
+ int i;
+ int err = 0;
+ int newfd;
+
+ if (ac < 2)
+ usage(unresolve_usage);
+
+ git_config(git_default_config);
+
+ /* Read HEAD and MERGE_HEAD; if MERGE_HEAD does not exist, we
+ * are not doing a merge, so exit with success status.
+ */
+ read_head_pointers();
+
+ /* Otherwise we would need to update the cache. */
+ newfd= hold_index_file_for_update(&cache_file, get_index_file());
+ if (newfd < 0)
+ die("unable to create new cachefile");
+
+ if (read_cache() < 0)
+ die("cache corrupted");
+
+ for (i = 1; i < ac; i++) {
+ char *arg = av[i];
+ err |= unresolve_one(arg);
+ }
+ if (err)
+ die("Error encountered; index not updated.");
+
+ if (active_cache_changed) {
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_index_file(&cache_file))
+ die("Unable to write new cachefile");
+ }
+ return 0;
+}
--
1.3.0.g2c4a
^ permalink raw reply related
* [PATCH] sha1_name.c: no need to include diff.h; tree-walk.h will do.
From: Junio C Hamano @ 2006-04-19 20:01 UTC (permalink / raw)
To: git
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Just a clean-up, comes on top of the one that returns mode
from get_tree_entry().
sha1_name.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 35e8dfb..7ad20b5 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -3,7 +3,7 @@ #include "tag.h"
#include "commit.h"
#include "tree.h"
#include "blob.h"
-#include "diff.h"
+#include "tree-walk.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
--
1.3.0.g2c4a
^ permalink raw reply related
* [PATCH] sha1_name.c: prepare to make get_tree_entry() reusable from others.
From: Junio C Hamano @ 2006-04-19 20:01 UTC (permalink / raw)
To: git
Make the mode information extracted from the tree available.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This comes on top of the extended SHA1 expression sha1:path
patch Linus did.
sha1_name.c | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 0cd1139..35e8dfb 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -450,18 +450,17 @@ static int get_sha1_1(const char *name,
return get_short_sha1(name, len, sha1, 0);
}
-static int get_tree_entry(const unsigned char *, const char *, unsigned char *);
+static int get_tree_entry(const unsigned char *, const char *, unsigned char *, unsigned *);
-static int find_tree_entry(struct tree_desc *t, const char *name, unsigned char *result)
+static int find_tree_entry(struct tree_desc *t, const char *name, unsigned char *result, unsigned *mode)
{
int namelen = strlen(name);
while (t->size) {
const char *entry;
const unsigned char *sha1;
int entrylen, cmp;
- unsigned mode;
- sha1 = tree_entry_extract(t, &entry, &mode);
+ sha1 = tree_entry_extract(t, &entry, mode);
update_tree_entry(t);
entrylen = strlen(entry);
if (entrylen > namelen)
@@ -477,18 +476,18 @@ static int find_tree_entry(struct tree_d
}
if (name[entrylen] != '/')
continue;
- if (!S_ISDIR(mode))
+ if (!S_ISDIR(*mode))
break;
if (++entrylen == namelen) {
memcpy(result, sha1, 20);
return 0;
}
- return get_tree_entry(sha1, name + entrylen, result);
+ return get_tree_entry(sha1, name + entrylen, result, mode);
}
return -1;
}
-static int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned char *sha1)
+static int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned char *sha1, unsigned *mode)
{
int retval;
void *tree;
@@ -498,7 +497,7 @@ static int get_tree_entry(const unsigned
if (!tree)
return -1;
t.buf = tree;
- retval = find_tree_entry(&t, name, sha1);
+ retval = find_tree_entry(&t, name, sha1, mode);
free(tree);
return retval;
}
@@ -510,6 +509,7 @@ static int get_tree_entry(const unsigned
int get_sha1(const char *name, unsigned char *sha1)
{
int ret;
+ unsigned unused;
prepare_alt_odb();
ret = get_sha1_1(name, strlen(name), sha1);
@@ -518,7 +518,8 @@ int get_sha1(const char *name, unsigned
if (cp) {
unsigned char tree_sha1[20];
if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1);
+ return get_tree_entry(tree_sha1, cp+1, sha1,
+ &unused);
}
}
return ret;
--
1.3.0.g2c4a
^ permalink raw reply related
* Re: Default refspec for branches
From: Josh Boyer @ 2006-04-19 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bg9bgsz.fsf@assigned-by-dhcp.cox.net>
On 4/19/06, Junio C Hamano <junkio@cox.net> wrote:
> "Josh Boyer" <jwboyer@gmail.com> writes:
>
> > Is there a way to change the default refspec that git pull uses on a
> > per branch basis?
>
> No.
>
> But it is a _very_ reasonable thing people would want to be able
> to. Please look at the last entry in:
>
> Subject: Recent unresolved issues
> Date: Fri, 14 Apr 2006 02:31:36 -0700
> Message-ID: <7v64lcqz9j.fsf@assigned-by-dhcp.cox.net>
Hm, ok.
I'd offer to work on that, but I have a bit of a learning curve in
front of me before I could make something useful. If others beat me
to it, I certainly wouldn't mind ;)
josh
^ permalink raw reply
* Re: Default refspec for branches
From: Junio C Hamano @ 2006-04-19 17:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: git
In-Reply-To: <625fc13d0604190558tf0e8b69n5f5a830a3131f1d4@mail.gmail.com>
"Josh Boyer" <jwboyer@gmail.com> writes:
> Is there a way to change the default refspec that git pull uses on a
> per branch basis?
No.
But it is a _very_ reasonable thing people would want to be able
to. Please look at the last entry in:
Subject: Recent unresolved issues
Date: Fri, 14 Apr 2006 02:31:36 -0700
Message-ID: <7v64lcqz9j.fsf@assigned-by-dhcp.cox.net>
^ permalink raw reply
* git log: don't do merge diffs by default
From: Linus Torvalds @ 2006-04-19 17:20 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
I personally prefer "ignore_merges" to be on by default, because quite
often the merge diff is distracting and not interesting. That's true both
with "-p" and with "--stat" output.
If you want output from merges, you can trivially use the "-m", "-c" or
"--cc" flags to tell that you're interested in merges, which also tells
the diff generator what kind of diff to do (for --stat, any of the three
will do, of course, but they differ for plain patches or for
--patch-with-stat).
This trivial patch just removes the two lines that tells "git log" not to
ignore merges. It will still show the commit log message, of course, due
to the "always_show_header" part.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git.c b/git.c
index 0be14bb..40b7e42 100644
--- a/git.c
+++ b/git.c
@@ -331,8 +331,6 @@ static int cmd_log(int argc, const char
init_revisions(&rev);
rev.always_show_header = 1;
rev.diffopt.recursive = 1;
- rev.combine_merges = 1;
- rev.ignore_merges = 0;
return cmd_log_wc(argc, argv, envp, &rev);
}
^ permalink raw reply related
* Allow "git repack" users to specify repacking window/depth
From: Linus Torvalds @ 2006-04-19 17:05 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
.. but don't even bother documenting it. I don't think any normal person
is supposed to ever really care, but it simplifies testing when you want
to use the "git repack" wrapper rather than forcing you to use the core
programs (which already do support the window/depth arguments, of course).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git-repack.sh b/git-repack.sh
index a5d349f..7a72c2c 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -7,7 +7,7 @@ USAGE='[-a] [-d] [-f] [-l] [-n] [-q]'
. git-sh-setup
no_update_info= all_into_one= remove_redundant=
-local= quiet= no_reuse_delta=
+local= quiet= no_reuse_delta= extra=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -17,6 +17,8 @@ do
-q) quiet=-q ;;
-f) no_reuse_delta=--no-reuse-delta ;;
-l) local=--local ;;
+ --window=*) extra="$extra $1" ;;
+ --depth=*) extra="$extra $1" ;;
*) usage ;;
esac
shift
@@ -40,7 +42,7 @@ case ",$all_into_one," in
find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
;;
esac
-pack_objects="$pack_objects $local $quiet $no_reuse_delta"
+pack_objects="$pack_objects $local $quiet $no_reuse_delta $extra"
name=$(git-rev-list --objects --all $rev_list 2>&1 |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
exit 1
^ permalink raw reply related
* Re: git-daemon memory usage, disconnection.
From: Linus Torvalds @ 2006-04-19 15:49 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1145460469.11909.25.camel@pmac.infradead.org>
On Wed, 19 Apr 2006, David Woodhouse wrote:
> On Wed, 2006-04-19 at 07:59 -0700, Linus Torvalds wrote:
> > Well, you've probably got two issues:
> >
> > - it looks like you aren't packing your archives (which explains why the
> > disk accesses are horrid, which in turn explains the "D" part).
>
> Hm, good point. They're fairly new trees -- I had foolishly assumed that
> they would at least start off packed. That isn't the case though --
> perhaps it should be? Did the original clone receive a pack on the wire
> and then _split_ it?
For old versions of git, yes.
> If the tools would automatically pack when the number of unpacked
> objects reaches a threshold, that would be useful.
Well, packing is still best done in the background: you don't generally
want the tools to just stop for a minute to repack while you're doing
something. You'd normally want to do a cron run at 4AM or something, see
if there is lots to pack, and repack that.
The one exception is probably a large conversion process (from CVS, SVN,
whatever). The conversion process itself probably takes ages, and it will
be even slower if it were to keep the potentially huge result unpacked all
the time.
But for normal ops, you really don't want to repack synchronously.
> Since this repo is only available through git:// and git+ssh:// URLs, I
> can safely use git-repack's '-a -d' options, right?
Yes.
> I'll do 'git-repack -l' nightly and 'git-repack -a -d -l' weekly -- does
> that seem sane?
Absolutely. The one exception might be trees that really don't change very
much (which is quite common), so you might make it conditional on seeing
if there are _any_ objects at all in .git/objects/00/, for example. Not
that repack will be very expensive, but still..
> Well, it does that with SIGALRM happening periodically, theoretically
> for the purpose of providing progress output. Perhaps we could do a
> getpeername() or something else to check on the output fd each time?
Yes, that's possibly a good idea. Of course, for git-rev-list, it's just a
pipe, and it's hard to do that check at least portably. On Linux, doing a
"poll()" on a pipe for writing, with newer kernels you'll get a POLLERR if
the other side has hung up, but that's by no means portable.
(On some other systems, doing a zero-sized write() _might_ do it, but at
least Linux will happily say "ok, wrote 0 bytes" even if the other end
isn't listening).
And git-rev-list isn't doing the SIGALARM anyway.
In other words, to do this, we'd have to change send-pack to use the
revision library. Which, as mentioned, is worth-while anyway, but it's not
totally trivial.
Linus
^ permalink raw reply
* Re: git-daemon memory usage, disconnection.
From: David Woodhouse @ 2006-04-19 15:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604190749160.3701@g5.osdl.org>
On Wed, 2006-04-19 at 07:59 -0700, Linus Torvalds wrote:
> Well, you've probably got two issues:
>
> - it looks like you aren't packing your archives (which explains why the
> disk accesses are horrid, which in turn explains the "D" part).
Hm, good point. They're fairly new trees -- I had foolishly assumed that
they would at least start off packed. That isn't the case though --
perhaps it should be? Did the original clone receive a pack on the wire
and then _split_ it?
If the tools would automatically pack when the number of unpacked
objects reaches a threshold, that would be useful.
Since this repo is only available through git:// and git+ssh:// URLs, I
can safely use git-repack's '-a -d' options, right?
I'll do 'git-repack -l' nightly and 'git-repack -a -d -l' weekly -- does
that seem sane?
> For a git server, you _really_ want all trees to be mostly packed, or
> you want absolutely tons of memory (and 256kB is definitely not "tons"
> as far as git is concerned).
>
> Well, the way things work under UNIX, you normally don't notice that the
> other end isn't interested until you try to write, and you get a "nobody
> is listening". And sadly, the packing stuff does most (not all) of the
> heavy lifting before it can even start to write things out.
Well, it does that with SIGALRM happening periodically, theoretically
for the purpose of providing progress output. Perhaps we could do a
getpeername() or something else to check on the output fd each time?
--
dwmw2
^ permalink raw reply
* Re: git-daemon memory usage, disconnection.
From: Linus Torvalds @ 2006-04-19 14:59 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1145452967.13200.92.camel@pmac.infradead.org>
On Wed, 19 Apr 2006, David Woodhouse wrote:
>
> I'm running git-daemon from xinetd and it seems a little greedy...
>
> Cpu(s): 2.7% us, 6.4% sy, 0.0% ni, 1.7% id, 87.7% wa, 1.4% hi, 0.0% si
> Mem: 253680k total, 250076k used, 3604k free, 568k buffers
> Swap: 500960k total, 500864k used, 96k free, 24696k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 31232 nobody 18 0 155m 29m 7224 D 1.3 11.9 0:25.56 git-rev-list
> 30743 nobody 18 0 179m 29m 9480 D 0.7 11.9 0:42.60 git-rev-list
> 31277 nobody 18 0 147m 28m 7476 D 2.6 11.4 0:20.90 git-rev-list
> 30314 nobody 18 0 233m 26m 7696 D 0.0 10.6 1:20.24 git-rev-list
> 30612 nobody 18 0 204m 23m 7432 D 1.3 9.4 0:59.19 git-rev-list
> 30574 nobody 18 0 190m 20m 7608 D 0.3 8.3 0:50.77 git-rev-list
> 30208 nobody 18 0 140m 14m 7632 D 0.3 5.9 0:15.23 git-pack-object
Well, you've probably got two issues:
- it looks like you aren't packing your archives (which explains why the
disk accesses are horrid, which in turn explains the "D" part).
For a git server, you _really_ want all trees to be mostly packed, or
you want absolutely tons of memory (and 256kB is definitely not "tons"
as far as git is concerned).
- git-rev-list won't notice that there is nobody listening until it gets
a EPIPE, and it won't get an EPIPE until it actually outputs something,
and it won't output anything until it is largely done traversing the
tree..
> Now, this wouldn't be _so_ bad if there were only two of them running.
> The clients for the other four have actually given up and disconnected
> long ago, but git-daemon doesn't seem to have reacted to that.
Well, the way things work under UNIX, you normally don't notice that the
other end isn't interested until you try to write, and you get a "nobody
is listening". And sadly, the packing stuff does most (not all) of the
heavy lifting before it can even start to write things out.
That said, I should probably take a look at git-rev-list --objects memory
usage once again. It's neve rbeen exactly "lean" (and it can't really be:
it does end up needing the total object list in memory for a full clone,
and with something like the kernel, that's about 250 _thousand_ objects).
We should probably also make send-pack.c use the nice revision library,
because right now it's doing that pipe to git-rev-list for no good reason.
Linus
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Petr Baudis @ 2006-04-19 14:48 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20060419142131.GD4104@tumblerings.org>
Hi,
Dear diary, on Wed, Apr 19, 2006 at 04:21:31PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> said that...
> On Wed, Apr 19, 2006 at 11:49:16AM +0200, Petr Baudis wrote:
> > Dear diary, on Wed, Apr 19, 2006 at 07:36:40AM CEST, I got a letter
> > where Zack Brown <zbrown@tumblerings.org> said that...
> > > When I do something like
> > > cg-clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
> > >
> > > The first few lines of output are:
> > >
> > > defaulting to local storage area
> > > warning: templates not found /home/zbrown/share/git-core/templates/
> > > /home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
> > > /home/zbrown/git/cogito/cg-clone: line 148: .git/info/cg-fetch-initial: No such file or directory
> > >
> > > The rest of the process seems to go without incident. However, when I look
> > > at the repository I see:
> > >
> > > $ ls -A
> > > .git ___
> > > $
> >
> > Could you please list the contents of the .git subdirectory? It seems
> > that git-init-db did not create the .git/info subdirectory.
>
> 07:19:57 [zbrown] ~/git/trees/tmp/git/.git$ ls -F
> total 28
> 4 HEAD 4 branches/ 4 config 4 index 4 info/ 4 objects/ 4 refs/
hmm, could you please do this just after running git-init-db in an
empty directory? I just realized cg-fetch will mkdir -p the .git/info/
directory.
If the .git/info/ directory would be there after git-init-db, I
couldn't explain the
/home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
error. If the .git/info/ directory is not there after git-init-db,
either it is somehow broken in git-1.3.0, or it belongs to a much older
git version.
> 07:18:38 [zbrown] ~$ which git-init-db
> /home/zbrown/git/git//git-init-db
> 07:18:52 [zbrown] ~$ which git
> /home/zbrown/git/git//git
It might be a good idea to compare the ctimes.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [RFC] get_sha1() shorthands for blob/tree objects
From: Linus Torvalds @ 2006-04-19 14:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <4445F1B0.4060105@op5.se>
On Wed, 19 Apr 2006, Andreas Ericsson wrote:
>
> Except that you'll have to explicitly state HEAD:pathname:with:colon, or does
> it try finding a file with the argument verbatim first?
If you have a pathname:with:colon and you _just_ want to use it as a
pathname, you'd do one of either:
- use "--" to separate the pathnames from the revision info. That always
works.
- even without the "--", if the first part of the pathname:with:colon (ie
the "pathname" part) cannot be looked up as a SHA1 tag, then the
pathname:with:colon is left alone and seen as a normal file.
So "--" is always the dis-ambiguator. But it almost certainly will never
be needed.
Linus
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Zack Brown @ 2006-04-19 14:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060419094916.GD27689@pasky.or.cz>
Hi Petr,
On Wed, Apr 19, 2006 at 11:49:16AM +0200, Petr Baudis wrote:
> Dear diary, on Wed, Apr 19, 2006 at 07:36:40AM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> said that...
> > When I do something like
> > cg-clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
> >
> > The first few lines of output are:
> >
> > defaulting to local storage area
> > warning: templates not found /home/zbrown/share/git-core/templates/
> > /home/zbrown/git/cogito/cg-clone: line 137: .git/info/cg-fetch-earlydie: No such file or directory
> > /home/zbrown/git/cogito/cg-clone: line 148: .git/info/cg-fetch-initial: No such file or directory
> >
> > The rest of the process seems to go without incident. However, when I look
> > at the repository I see:
> >
> > $ ls -A
> > .git ___
> > $
>
> Could you please list the contents of the .git subdirectory? It seems
> that git-init-db did not create the .git/info subdirectory.
07:19:57 [zbrown] ~/git/trees/tmp/git/.git$ ls -F
total 28
4 HEAD 4 branches/ 4 config 4 index 4 info/ 4 objects/ 4 refs/
>
> I suspect that something went wrong with your installation and in fact
> you are using much older git version. Check git --version and if `which
> git-init-db` corresponds to `which git`.
07:11:13 [zbrown] ~$ git --version
git version 1.3.0.g2473-dirty
07:18:38 [zbrown] ~$ which git-init-db
/home/zbrown/git/git//git-init-db
07:18:52 [zbrown] ~$ which git
/home/zbrown/git/git//git
07:18:54 [zbrown] ~$
I assume the "-dirty" in the version number means it thinks I've made some
changes, but I really haven't. Maybe the repo got corrupted somehow.
Be well,
Zack
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> Right now I am having amnesia and deja-vu at the same time. I think
> I have forgotten this before.
--
Zack Brown
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Zack Brown @ 2006-04-19 14:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5feawel.fsf@assigned-by-dhcp.cox.net>
On Tue, Apr 18, 2006 at 11:53:38PM -0700, Junio C Hamano wrote:
> Zack Brown <zbrown@tumblerings.org> writes:
>
> > What is going on? I'm completely unable to clone a repository.
>
> I have no idea how cg-* is broken, so I'll let Pasky answer
> that, but I suspect your git installation is broken.
>
> > If I try
> > "git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git",
> > I get this error: "git: 'clone' is not a git-command", and it prints a usage
> > page, but "clone" is listed on that usage page.
>
> That sounds intersting. Although rsync is deprecated for a long
> time and git:// is the preferred transport, I do not get "is not
> a git-command" error. Are you installing things correctly?
I think so. I was able to reproduce this behavior using the tarballs that are
used to start out a new user with git and cogito; as well as with the latest
version in the repository.
But I also thought the rsync deprecation was not really true. Wasn't that
discussed here recently? I thought the conclusion was that folks *wanted*
to deprecate it, but at the moment it was still the best way to accomplish
certain things.
>
> For example, as the first paragraph of INSTALL says, if you
> override prefix= from the make command line, you need to do so
> consistently when you build and when you install.
>
> What do these command say?
>
> $ git --exec-path
> $ ls -l "`git --exec-path`/git-clone"
22:07:05 [zbrown] ~$ git --exec-path
/home/zbrown/bin
07:10:34 [zbrown] ~$ ls -l "`git --exec-path`/git-clone"
ls: /home/zbrown/bin/git-clone: No such file or directory
Does that mean it's looking in /home/zbrown/bin for the git binaries? That's
weird. I have /home/zbrown/git/git and /home/zbrown/git/cogito in my $PATH
specifically to hold those executables. There's no git stuff in
/home/zbrown/bin.
Be well,
Zack
>
--
Zack Brown
^ permalink raw reply
* git-daemon memory usage, disconnection.
From: David Woodhouse @ 2006-04-19 13:22 UTC (permalink / raw)
To: git
I'm running git-daemon from xinetd and it seems a little greedy...
Cpu(s): 2.7% us, 6.4% sy, 0.0% ni, 1.7% id, 87.7% wa, 1.4% hi, 0.0% si
Mem: 253680k total, 250076k used, 3604k free, 568k buffers
Swap: 500960k total, 500864k used, 96k free, 24696k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31232 nobody 18 0 155m 29m 7224 D 1.3 11.9 0:25.56 git-rev-list
30743 nobody 18 0 179m 29m 9480 D 0.7 11.9 0:42.60 git-rev-list
31277 nobody 18 0 147m 28m 7476 D 2.6 11.4 0:20.90 git-rev-list
30314 nobody 18 0 233m 26m 7696 D 0.0 10.6 1:20.24 git-rev-list
30612 nobody 18 0 204m 23m 7432 D 1.3 9.4 0:59.19 git-rev-list
30574 nobody 18 0 190m 20m 7608 D 0.3 8.3 0:50.77 git-rev-list
30208 nobody 18 0 140m 14m 7632 D 0.3 5.9 0:15.23 git-pack-object
Now, this wouldn't be _so_ bad if there were only two of them running.
The clients for the other four have actually given up and disconnected
long ago, but git-daemon doesn't seem to have reacted to that.
--
dwmw2
^ permalink raw reply
* Default refspec for branches
From: Josh Boyer @ 2006-04-19 12:58 UTC (permalink / raw)
To: git
Is there a way to change the default refspec that git pull uses on a
per branch basis? I know that you can create .git/remotes/<foo> and
do 'git pull <foo>' to pull from whatever is listed in there, but that
isn't quite what I'm looking for.
What I'd like to be able to do is create a branch and have 'git pull'
simply pull from the remote tree. I tried listing multiple refspecs
in .git/remotes/origin, but git didn't seem to like that.
For example, I clone Linus' tree. Then I create a branch called mtd.
When I'm working in that branch, I want 'git pull' to pull from
git://git.infradead.org/mtd-2.6.git.
Any ideas?
josh
^ permalink raw reply
* Re: GIT Error issue
From: Erik Mouw @ 2006-04-19 11:21 UTC (permalink / raw)
To: Shyamal Sadanshio; +Cc: git
In-Reply-To: <3857255c0604190416j62abeae8va164896c5100f6ee@mail.gmail.com>
On Wed, Apr 19, 2006 at 04:46:57PM +0530, Shyamal Sadanshio wrote:
> I am newbie to GIT and facing some problem with the GIT usage. I am
> trying to clone a repository at www.linux-mips.org with the
> following command, I get error message as below:
>
> **************************************************************************
> [root@sshyamal git-tutorial]# git clone
> git://ftp.linux-mips.org/pub/scm/linux-malta.git linux-malta.git
> git: warning: invalid extra options ignored
>
> GNU Interactive Tools 4.3.20 (i686-pc-linux-gnu), 12:39:46 Apr 18 2006
> GIT is free software; you can redistribute it and/or modify it under the
> terms of the GNU General Public License as published by the Free
> Software
> Foundation; either version 2, or (at your option) any later version.
> Copyright (C) 1993-1999 Free Software Foundation, Inc.
> Written by Tudor Hulubei and Andrei Pitis, Bucharest, Romania
>
> git: fatal error: `chdir' failed: permission denied.
You're using the wrong GIT. Remove the GNU Interactive Tools and use
git from kernel.org.
> ***************************************************************************
>
> I am exercising this command in root mode.
There is absolutely zero reason to run git as root.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: GIT Error issue
From: Krzysiek Pawlik @ 2006-04-19 11:20 UTC (permalink / raw)
To: Shyamal Sadanshio; +Cc: git
In-Reply-To: <3857255c0604190416j62abeae8va164896c5100f6ee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
Shyamal Sadanshio wrote:
> **************************************************************************
> [root@sshyamal git-tutorial]# git clone
> git://ftp.linux-mips.org/pub/scm/linux-malta.git linux-malta.git
> git: warning: invalid extra options ignored
>
> GNU Interactive Tools 4.3.20 (i686-pc-linux-gnu), 12:39:46 Apr 18 2006
^ ^ ^
Use git - the content manager, not interactive tools. Use full path to
git executable.
--
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: GIT Error issue
From: Sam Ravnborg @ 2006-04-19 11:20 UTC (permalink / raw)
To: Shyamal Sadanshio; +Cc: git
In-Reply-To: <3857255c0604190416j62abeae8va164896c5100f6ee@mail.gmail.com>
On Wed, Apr 19, 2006 at 04:46:57PM +0530, Shyamal Sadanshio wrote:
> Hi,
>
> I am newbie to GIT and facing some problem with the GIT usage. I am
> trying to clone a repository at www.linux-mips.org with the
> following command, I get error message as below:
>
> **************************************************************************
> [root@sshyamal git-tutorial]# git clone
> git://ftp.linux-mips.org/pub/scm/linux-malta.git linux-malta.git
> git: warning: invalid extra options ignored
>
> GNU Interactive Tools 4.3.20 (i686-pc-linux-gnu), 12:39:46 Apr 18 2006
You are running the wrong git.
The git you are running are the "GNU Interactive Tools" and not git from
the git-suite.
Fix - uninstall "GNU Interactive Tools"
Sam
^ 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