* Branch metainformation
From: Jakub Narebski @ 2006-04-20 7:39 UTC (permalink / raw)
To: git
It seems that ever so often there is question posted on this list on which
the answer is to add '+' in 'pu' branch 'Pull:' line. I think that it is
not a good policy to have puller to remember which branches can be
fast-forwarded, and which needs to be merged. It should be an information
set and stored by person managing the branch (pullee), as some kind of
metainformation for the branch (like description and optional signature is
for tags).
Perhaps then there would be a place for short, one-line description of the
branch...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Branch metainformation
From: Johannes Schindelin @ 2006-04-20 9:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e27dqv$u6f$1@sea.gmane.org>
Hi,
On Thu, 20 Apr 2006, Jakub Narebski wrote:
> It seems that ever so often there is question posted on this list on which
> the answer is to add '+' in 'pu' branch 'Pull:' line. I think that it is
> not a good policy to have puller to remember which branches can be
> fast-forwarded, and which needs to be merged. It should be an information
> set and stored by person managing the branch (pullee), as some kind of
> metainformation for the branch (like description and optional signature is
> for tags).
>
> Perhaps then there would be a place for short, one-line description of the
> branch...
I have an alternative in my private repository: When git-pull/git-fetch
are called with "-S <nick>", then the current URL is set as URL for that
shorthand, and the rest is *added* as Pull line.
However, this all depends on my (rejected) patch to move the remotes
information into the config file.
I have not backported the "-S" feature to the non-config remotes,
since I 1) do not need it myself, and 2) am wary that it is not that easy
to ensure data integrity by shell-scripting.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff --stat: do not drop rename information.
From: Johannes Schindelin @ 2006-04-20 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmig3o7r.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 19 Apr 2006, Junio C Hamano wrote:
> When a verbatim rename or copy is detected, we did not show
> anything on the "diff --stat" for the filepair. This makes it
> to show the rename information.
Makes sense. This also shows deletes and adds as "bla/bla => /dev/null"
and "/dev/null => bla/bla", right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff --stat: do not drop rename information.
From: Junio C Hamano @ 2006-04-20 10:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0604201138130.9099@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ... This also shows deletes and adds as "bla/bla => /dev/null"
> and "/dev/null => bla/bla", right?
Dunno. It's still essentially your code ;-).
The usual "diffstat" does not do that, but it might be useful.
Another thing that could be done is to fold in mode change
information (usually people care only about chmod +/-x).
^ permalink raw reply
* Re: Branch metainformation
From: Junio C Hamano @ 2006-04-20 10:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0604201131240.9099@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, this all depends on my (rejected) patch to move the remotes
> information into the config file.
You seem to keep saying rejected, but IIRC you did not finish it
IOW the patch was not ready to be merged. I do not recall, for
example, reading the part that touches git-parse-remote or
git-fetch to read from the config, but it was a long time ago
and my recollection is vague.
While we are talking about per branch property, some issues
raised on the list (and #git) recently would be helped by a
convention (and perhaps some core side support) for per-branch
property. Here is a short list.
+ When I am on branch X, I would want "git pull" to pull
(i.e. fetch and merge) from repository Y, not always "origin".
+ When I am on branch X, I would want "git push" to push to
repository Y (we do not even use "origin" as the default for
push).
+ This branch is not to be rebased (you could do this using
custom pre-rebase hook but having a standard "branch property"
would make it easy for such a hook to decide.
- Do not merge and base your work on this branch -- this is
"view only" and unstable (e.g. "pu" in git.git).
If we were to do a remote to config reorganization (for that we
need a migration plan and a period that we support both), the
per-branch configuration should be designed to support at least
the commonly asked ones.
^ permalink raw reply
* [PATCH] colored diff.
From: Junio C Hamano @ 2006-04-20 10:18 UTC (permalink / raw)
To: git
With configuration option diff.usecolor, this colorizes the diff
output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I am not happy with the initialization, especially the part
that calls git_config(git_diff_config) from git.c, and I am
not that interested in this myself, but some people seem to
like colors, so this will be in "pu" for now.
cache.h | 3 +-
diff-lib.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------
diff.h | 2 +
git.c | 3 +-
| 17 ++++++----
5 files changed, 104 insertions(+), 22 deletions(-)
diff --git a/cache.h b/cache.h
index 69801b0..e6aa297 100644
--- a/cache.h
+++ b/cache.h
@@ -169,7 +169,6 @@ extern int trust_executable_bit;
extern int assume_unchanged;
extern int only_use_symrefs;
extern int warn_ambiguous_refs;
-extern int diff_rename_limit_default;
extern int shared_repository;
extern const char *apply_default_whitespace;
@@ -359,6 +358,6 @@ extern int receive_unpack_pack(int fd[2]
extern int receive_keep_pack(int fd[2], const char *me, int quiet);
/* pager.c */
-extern void setup_pager(void);
+extern int setup_pager(void);
#endif /* CACHE_H */
diff --git a/diff-lib.c b/diff-lib.c
index 0a832c3..86a2561 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -12,7 +12,8 @@ #include "xdiff-interface.h"
static int use_size_cache;
-int diff_rename_limit_default = -1;
+static int diff_rename_limit_default = -1;
+static int diff_use_color = 0;
int git_diff_config(const char *var, const char *value)
{
@@ -20,10 +21,31 @@ int git_diff_config(const char *var, con
diff_rename_limit_default = git_config_int(var, value);
return 0;
}
-
+ if (!strcmp(var, "diff.usecolor")) {
+ diff_use_color = git_config_bool(var, value);
+ return 0;
+ }
return git_default_config(var, value);
}
+static const char *diff_colors[] = {
+ "\033[0;0m",
+ "\033[1;35m",
+ "\033[1;31m",
+ "\033[1;34m",
+};
+
+void diff_setup_colors(void)
+{
+ static int inited;
+ if (!inited) {
+ if (diff_use_color && !isatty(1))
+ diff_use_color = 0;
+ inited++;
+ git_config(git_diff_config);
+ }
+}
+
static char *quote_one(const char *str)
{
int needlen;
@@ -176,23 +198,61 @@ static int fill_mmfile(mmfile_t *mf, str
}
struct emit_callback {
+ struct xdiff_emit_state xm;
+ int nparents;
const char **label_path;
};
-static int fn_out(void *priv, mmbuffer_t *mb, int nbuf)
+enum color_diff {
+ DIFF_PLAIN = 0,
+ DIFF_METAINFO = 1,
+ DIFF_FILE_OLD = 2,
+ DIFF_FILE_NEW = 3,
+};
+
+static void color_diff(enum color_diff ix)
+{
+ diff_setup_colors();
+ if (diff_use_color)
+ fputs(diff_colors[ix], stdout);
+}
+
+static void fn_out_consume(void *priv, char *line, unsigned long len)
{
int i;
struct emit_callback *ecbdata = priv;
-
if (ecbdata->label_path[0]) {
+ color_diff(DIFF_METAINFO);
printf("--- %s\n", ecbdata->label_path[0]);
+ color_diff(DIFF_METAINFO);
printf("+++ %s\n", ecbdata->label_path[1]);
ecbdata->label_path[0] = ecbdata->label_path[1] = NULL;
}
- for (i = 0; i < nbuf; i++)
- if (!fwrite(mb[i].ptr, mb[i].size, 1, stdout))
- return -1;
- return 0;
+
+ /* This is not really necessary for now because
+ * this codepath only deals with two-way diffs.
+ */
+ for (i = 0; i < len && line[i] == '@'; i++)
+ ;
+ if (2 <= i && i < len && line[i] == ' ') {
+ ecbdata->nparents = i - 1;
+ color_diff(DIFF_METAINFO);
+ }
+ else if (len < ecbdata->nparents)
+ color_diff(DIFF_PLAIN);
+ else {
+ int nparents = ecbdata->nparents;
+ int color = DIFF_PLAIN;
+ for (i = 0; i < nparents && len; i++) {
+ if (line[i] == '-')
+ color = DIFF_FILE_OLD;
+ else if (line[i] == '+')
+ color = DIFF_FILE_NEW;
+ }
+ color_diff(color);
+ }
+ fwrite(line, len, 1, stdout);
+ color_diff(DIFF_PLAIN);
}
struct diffstat_t {
@@ -359,25 +419,37 @@ static void builtin_diff(const char *nam
b_two = quote_two("b/", name_b);
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
+
+ color_diff(DIFF_METAINFO);
printf("diff --git %s %s\n", a_one, b_two);
if (lbl[0][0] == '/') {
/* /dev/null */
+ color_diff(DIFF_METAINFO);
printf("new file mode %06o\n", two->mode);
- if (xfrm_msg && xfrm_msg[0])
+ if (xfrm_msg && xfrm_msg[0]) {
+ color_diff(DIFF_METAINFO);
puts(xfrm_msg);
+ }
}
else if (lbl[1][0] == '/') {
+ color_diff(DIFF_METAINFO);
printf("deleted file mode %06o\n", one->mode);
- if (xfrm_msg && xfrm_msg[0])
+ if (xfrm_msg && xfrm_msg[0]) {
+ color_diff(DIFF_METAINFO);
puts(xfrm_msg);
+ }
}
else {
if (one->mode != two->mode) {
+ color_diff(DIFF_METAINFO);
printf("old mode %06o\n", one->mode);
+ color_diff(DIFF_METAINFO);
printf("new mode %06o\n", two->mode);
}
- if (xfrm_msg && xfrm_msg[0])
+ if (xfrm_msg && xfrm_msg[0]) {
+ color_diff(DIFF_METAINFO);
puts(xfrm_msg);
+ }
/*
* we do not run diff between different kind
* of objects.
@@ -385,6 +457,7 @@ static void builtin_diff(const char *nam
if ((one->mode ^ two->mode) & S_IFMT)
goto free_ab_and_return;
if (complete_rewrite) {
+ color_diff(DIFF_PLAIN);
emit_rewrite_diff(name_a, name_b, one, two);
goto free_ab_and_return;
}
@@ -403,7 +476,9 @@ static void builtin_diff(const char *nam
xdemitcb_t ecb;
struct emit_callback ecbdata;
+ memset(&ecbdata, 0, sizeof(ecbdata));
ecbdata.label_path = lbl;
+ ecbdata.nparents = 0;
xpp.flags = XDF_NEED_MINIMAL;
xecfg.ctxlen = 3;
xecfg.flags = XDL_EMIT_FUNCNAMES;
@@ -413,12 +488,14 @@ static void builtin_diff(const char *nam
xecfg.ctxlen = strtoul(diffopts + 10, NULL, 10);
else if (!strncmp(diffopts, "-u", 2))
xecfg.ctxlen = strtoul(diffopts + 2, NULL, 10);
- ecb.outf = fn_out;
+ ecb.outf = xdiff_outf;
ecb.priv = &ecbdata;
+ ecbdata.xm.consume = fn_out_consume;
xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
}
free_ab_and_return:
+ color_diff(DIFF_PLAIN);
free(a_one);
free(b_two);
return;
diff --git a/diff.h b/diff.h
index 52fff66..7cb5708 100644
--- a/diff.h
+++ b/diff.h
@@ -168,4 +168,6 @@ #define DIFF_STATUS_FILTER_BROKEN 'B'
extern const char *diff_unique_abbrev(const unsigned char *, int);
+extern void diff_setup_colors(void);
+
#endif /* DIFF_H */
diff --git a/git.c b/git.c
index 40b7e42..6742de7 100644
--- a/git.c
+++ b/git.c
@@ -290,7 +290,8 @@ static int cmd_log_wc(int argc, const ch
die("unrecognized argument: %s", argv[1]);
prepare_revision_walk(rev);
- setup_pager();
+ if (!setup_pager())
+ diff_setup_colors();
while ((commit = get_revision(rev)) != NULL) {
log_tree_commit(rev, commit);
free(commit->buffer);
--git a/pager.c b/pager.c
index b063353..1fb7103 100644
--- a/pager.c
+++ b/pager.c
@@ -10,26 +10,29 @@ static void run_pager(const char *pager)
execlp(pager, pager, NULL);
}
-void setup_pager(void)
+/* Returns 0 if the caller can assume the output stream
+ * is like a terminal (either bare terminal or a pager.
+ */
+int setup_pager(void)
{
pid_t pid;
int fd[2];
const char *pager = getenv("PAGER");
if (!isatty(1))
- return;
+ return 1;
if (!pager)
pager = "less";
else if (!*pager || !strcmp(pager, "cat"))
- return;
+ return 0;
if (pipe(fd) < 0)
- return;
+ return -1;
pid = fork();
if (pid < 0) {
close(fd[0]);
close(fd[1]);
- return;
+ return -1;
}
/* return in the child */
@@ -37,7 +40,7 @@ void setup_pager(void)
dup2(fd[1], 1);
close(fd[0]);
close(fd[1]);
- return;
+ return 0;
}
/* The original process turns into the PAGER */
@@ -45,7 +48,7 @@ void setup_pager(void)
close(fd[0]);
close(fd[1]);
- setenv("LESS", "-S", 0);
+ setenv("LESS", "-RS", 0);
run_pager(pager);
exit(255);
}
^ permalink raw reply related
* Re: Branch metainformation
From: Johannes Schindelin @ 2006-04-20 11:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtdkzh1u.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 20 Apr 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, this all depends on my (rejected) patch to move the remotes
> > information into the config file.
>
> You seem to keep saying rejected, but IIRC you did not finish it
I had another impression: people seemed less than enthusiastic about it.
But maybe I misunderstood, and only the automatic rewriting part was
disliked. I'll try to find time to clean the patch and resend it...
> While we are talking about per branch property, some issues
> raised on the list (and #git) recently would be helped by a
> convention (and perhaps some core side support) for per-branch
> property. Here is a short list.
>
> + When I am on branch X, I would want "git pull" to pull
> (i.e. fetch and merge) from repository Y, not always "origin".
>
> + When I am on branch X, I would want "git push" to push to
> repository Y (we do not even use "origin" as the default for
> push).
>
> + This branch is not to be rebased (you could do this using
> custom pre-rebase hook but having a standard "branch property"
> would make it easy for such a hook to decide.
>
> - Do not merge and base your work on this branch -- this is
> "view only" and unstable (e.g. "pu" in git.git).
>
> If we were to do a remote to config reorganization (for that we
> need a migration plan and a period that we support both), the
> per-branch configuration should be designed to support at least
> the commonly asked ones.
Hmm. ATM the syntax I use is
[remote.company]
url = company.com:gits/daproject
pull = origin
push = master
Some bits of your wishes could be written as
[branch.pu]
rebase = no
pull = company
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] colored diff.
From: Thomas Glanzmann @ 2006-04-20 11:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsjczh1k.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
* Junio C Hamano <junkio@cox.net> [060420 12:22]:
> With configuration option diff.usecolor, this colorizes the diff
> output.
I use a long time the following combination, which served me and a few
others very well:
bourne shell function:
BLACK="^[[0;30m"
RED="^[[0;31m"
GREEN="^[[0;32m"
YELLO="^[[0;33m"
BLUE="^[[0;34m"
PURPLE="^[[0;35m"
CYAN="^[[0;36m"
WHITE="^[[0;37m"
END="^[[0m"
REVERSE="^[[7m"
cdiff()
{
cat $1 | \
sed -e " \
s/^\(diff-tree\)\(.*\)/\1${RED}\2${END}/; \
s/^+.*/$RED&$END/; \
s/^-.*/$BLUE&$END/; \
s/^@.*/$GREEN&$END/; \
s/^Date.*/$RED&$END/; \
s/^Author.*/$RED&$END/; \
" | less -R -i -p "^diff-tree"
# This would highlight manpages but the last line clashes with cdiff
# --tg 00:52 05-05-26
#s/^[A-Z]\+[A-Z ]\+$/$RED&$END/; \
#s/[A-Z]\+([0-9])/$RED&$END/g; \
# s/\W--\?[0-9a-zA-Z=-]\+/$BLUE&$END/g; \
}
# with 'n' you simply jump to the next commit
# with 'N' to the previous
git-whatchanged -p | cdiff
screenshot: http://wwwcip.informatik.uni-erlangen.de/~sithglan/shot.png
Thanks for the enegery you put in git,
Thomas
^ permalink raw reply
* t1001-read-tree-m-2way.sh failed
From: Sven Verdoolaege @ 2006-04-20 13:01 UTC (permalink / raw)
To: git
*** t1001-read-tree-m-2way.sh ***
* FAIL 1: setup
echo frotz >frotz &&
echo nitfol >nitfol &&
cat bozbar-old >bozbar &&
echo rezrov >rezrov &&
echo yomin >yomin &&
git-update-index --add nitfol bozbar rezrov &&
treeH=`git-write-tree` &&
echo treeH $treeH &&
git-ls-tree $treeH &&
cat bozbar-new >bozbar &&
git-update-index --add frotz bozbar --force-remove rezrov &&
git-ls-files --stage >M.out &&
treeM=`git-write-tree` &&
echo treeM $treeM &&
git-ls-tree $treeM &&
git-diff-tree $treeH $treeM
* ok 2: 1, 2, 3 - no carry forward
* ok 3: 4 - carry forward local addition.
* ok 4: 5 - carry forward local addition.
* ok 5: 6 - local addition already has the same.
* ok 6: 7 - local addition already has the same.
* ok 7: 8 - conflicting addition.
* ok 8: 9 - conflicting addition.
* ok 9: 10 - path removed.
* ok 10: 11 - dirty path removed.
* ok 11: 12 - unmatching local changes being removed.
* ok 12: 13 - unmatching local changes being removed.
* ok 13: 14 - unchanged in two heads.
* ok 14: 15 - unchanged in two heads.
* ok 15: 16 - conflicting local change.
* ok 16: 17 - conflicting local change.
* ok 17: 18 - local change already having a good result.
* ok 18: 19 - local change already having a good result, further modified.
* ok 19: 20 - no local change, use new tree.
* ok 20: 21 - no local change, dirty cache.
* ok 21: 22 - local change cache updated.
* ok 22: DF vs DF/DF case setup.
* ok 23: DF vs DF/DF case test.
* failed 1 among 23 test(s)
skimo
^ permalink raw reply
* Re: t1001-read-tree-m-2way.sh failed
From: Andreas Ericsson @ 2006-04-20 13:10 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20060420130121.GO11428MdfPADPa@greensroom.kotnet.org>
Platform?
Architecture?
git version?
Keyboard color?
This report is missing lots of info. Fill in the missing parts and
someone will almost certainly be able to help you.
Sven Verdoolaege wrote:
> *** t1001-read-tree-m-2way.sh ***
> * FAIL 1: setup
> echo frotz >frotz &&
> echo nitfol >nitfol &&
> cat bozbar-old >bozbar &&
> echo rezrov >rezrov &&
> echo yomin >yomin &&
> git-update-index --add nitfol bozbar rezrov &&
> treeH=`git-write-tree` &&
> echo treeH $treeH &&
> git-ls-tree $treeH &&
>
> cat bozbar-new >bozbar &&
> git-update-index --add frotz bozbar --force-remove rezrov &&
> git-ls-files --stage >M.out &&
> treeM=`git-write-tree` &&
> echo treeM $treeM &&
> git-ls-tree $treeM &&
> git-diff-tree $treeH $treeM
> * failed 1 among 23 test(s)
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* 1.3.0 creating bigger packs than 1.2.3
From: Shawn Pearce @ 2006-04-20 13:36 UTC (permalink / raw)
To: git
Apparently I have created a repository which v1.2.3 packs about 50%
smaller than 'next' does:
v1.2.3 (tag):
60M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
1.2.3.gf3a4 (an older 'next'):
128M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
1.3.0.rc4.g8060 (a fairly recent 'next'):
118M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
Repeated packing with 1.3.0.rc4.g8060 doesn't seem to change the
size of the pack file, its pretty consistent at 118M.
Given that disk is pretty cheap these days I'm not concerned about
the 2x increase but thought I'd let folks know that the packing
improvements in 1.3.0 seem to have taken a small step backwards
with regards to this particular dataset.
I can make the repository available if somebody wants to look at it.
--
Shawn.
^ permalink raw reply
* Re: t1001-read-tree-m-2way.sh failed
From: Sven Verdoolaege @ 2006-04-20 13:53 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4447882F.8080304@op5.se>
On Thu, Apr 20, 2006 at 03:10:07PM +0200, Andreas Ericsson wrote:
> Keyboard color?
I think "beige" comes closest.
In any case, it turns out that apparently make was confused
by the rename from diff.c to diff-lib.c.
After a make clean, everything was ok.
skimo
^ permalink raw reply
* Plain view on image in tree in gitweb results in binary output in browser
From: Pander @ 2006-04-20 13:57 UTC (permalink / raw)
To: git
Hi all,
Plain and head view on an image in a tree in gitweb results in binary
output in browser. One gets numbered lines with exotic characters.
Is it suppose to be like this in gitweb would it be better to, according
to the mime type of the file, show the actual image in the plain or head
view?
Is this configurable or a feature request?
Regards,
Pander
^ permalink raw reply
* Re: 1.3.0 creating bigger packs than 1.2.3
From: Linus Torvalds @ 2006-04-20 14:47 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060420133640.GA31198@spearce.org>
On Thu, 20 Apr 2006, Shawn Pearce wrote:
> Apparently I have created a repository which v1.2.3 packs about 50%
> smaller than 'next' does:
>
> v1.2.3 (tag):
> 60M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
>
> 1.2.3.gf3a4 (an older 'next'):
> 128M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
>
> 1.3.0.rc4.g8060 (a fairly recent 'next'):
> 118M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
>
> Repeated packing with 1.3.0.rc4.g8060 doesn't seem to change the
> size of the pack file, its pretty consistent at 118M.
First try "git repack -a -d f", where the "-f" is the magic one.
Without the -f, git repack will re-use old pack information, which is much
much faster, but not as space-efficient.
If that doesn't help, it might be time to look at the actual repo, but try
that first.
Linus
^ permalink raw reply
* Re: GIT Error issue
From: Shyamal Sadanshio @ 2006-04-20 14:58 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90604191453q567192b0l9a35d50f96f8705d@mail.gmail.com>
Thanks a lot for the pointer!
It worked now!!
Thanks and Regards,
Shyamal
On 4/20/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> 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: GIT Error issue
From: Shyamal Sadanshio @ 2006-04-20 15:02 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20060419112135.GA24807@harddisk-recovery.com>
Hi,
Yes, I had installed a wrong GIT.
Thanks it worked now!
However, with a http protocol instead of git and rsync because of
firewall issue, I guess!
Thanks and Regards,
Shyamal
On 4/19/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
> 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: 1.3.0 creating bigger packs than 1.2.3
From: Shawn Pearce @ 2006-04-20 15:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604200745550.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Thu, 20 Apr 2006, Shawn Pearce wrote:
>
> > Apparently I have created a repository which v1.2.3 packs about 50%
> > smaller than 'next' does:
> >
> > v1.2.3 (tag):
> > 60M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
> >
> > 1.2.3.gf3a4 (an older 'next'):
> > 128M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
> >
> > 1.3.0.rc4.g8060 (a fairly recent 'next'):
> > 118M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
> >
> > Repeated packing with 1.3.0.rc4.g8060 doesn't seem to change the
> > size of the pack file, its pretty consistent at 118M.
>
> First try "git repack -a -d f", where the "-f" is the magic one.
>
> Without the -f, git repack will re-use old pack information, which is much
> much faster, but not as space-efficient.
>
> If that doesn't help, it might be time to look at the actual repo, but try
> that first.
So with 1.3.0.g56c1 "git repack -a -d -f" did worse:
Total 46391, written 46391 (delta 6649), reused 39742 (delta 0)
129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
I just tried -f on v1.2.3 and it did slightly better then before:
Total 46391, written 46391 (delta 6847), reused 38012 (delta 0)
59M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
--
Shawn.
^ permalink raw reply
* Re: 1.3.0 creating bigger packs than 1.2.3
From: Linus Torvalds @ 2006-04-20 16:07 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060420150315.GB31198@spearce.org>
On Thu, 20 Apr 2006, Shawn Pearce wrote:
>
> So with 1.3.0.g56c1 "git repack -a -d -f" did worse:
>
> Total 46391, written 46391 (delta 6649), reused 39742 (delta 0)
> 129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
>
> I just tried -f on v1.2.3 and it did slightly better then before:
>
> Total 46391, written 46391 (delta 6847), reused 38012 (delta 0)
> 59M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
Interesting. The bigger packs do generate fewer deltas, but they don't
seem to be _that_ much fewer. And the deltas themselves certainly
shouldn't be bigger.
It almost sounds like there's a problem with choosing what to delta
against, not necessarily a delta algorithm problem. Although that sounds a
bit strange, because I wouldn't have thought we actually changed the
packing algorithm noticeably since 1.2.3.
Hmm. Doing "gitk v1.2.3.. -- pack-objects.c" shows that I was wrong. Junio
did the "hash basename and direname a bit differently" thing, which would
appear to change the "find objects to delta against" a lot. That could be
it.
You could try to revert that change:
git revert eeef7135fed9b8784627c4c96e125241c06c65e1
which needs a trivial manual fixup (remove the conflict entirely:
everything between the "<<<<" and ">>>>>" lines should go), and see if
that's it.
You can also try to see if
git repack -a -d -f --window=50
makes for a better pack (at the cost of a much slower repack). It makes
git try more objects to delta against, and can thus hide a bad sort order.
Junio, any other suggestions?
Linus
^ permalink raw reply
* Re: 1.3.0 creating bigger packs than 1.2.3
From: Nicolas Pitre @ 2006-04-20 16:09 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060420133640.GA31198@spearce.org>
On Thu, 20 Apr 2006, Shawn Pearce wrote:
> Given that disk is pretty cheap these days I'm not concerned about
> the 2x increase but thought I'd let folks know that the packing
> improvements in 1.3.0 seem to have taken a small step backwards
> with regards to this particular dataset.
2x is a huge regression.
> I can make the repository available if somebody wants to look at it.
Please.
Nicolas
^ permalink raw reply
* Re: 1.3.0 creating bigger packs than 1.2.3
From: Shawn Pearce @ 2006-04-20 16:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604200857460.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 20 Apr 2006, Shawn Pearce wrote:
> >
> > So with 1.3.0.g56c1 "git repack -a -d -f" did worse:
> >
> > Total 46391, written 46391 (delta 6649), reused 39742 (delta 0)
> > 129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
> >
> > I just tried -f on v1.2.3 and it did slightly better then before:
> >
> > Total 46391, written 46391 (delta 6847), reused 38012 (delta 0)
> > 59M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
Oddly enough repacking the v1.2.3 pack using 1.3.0.g56c1 created an
even smaller pack ("git-repack -a -d"):
Total 46391, written 46391 (delta 8253), reused 44985 (delta 6847)
49M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
and repacking again with "git-repack -a -d" chopped another 1M:
Total 46391, written 46391 (delta 8258), reused 46386 (delta 8253)
48M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pac
but then adding -f definately gives us the 2x explosion again:
Total 46391, written 46391 (delta 6649), reused 37894 (delta 0)
129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
> Interesting. The bigger packs do generate fewer deltas, but they don't
> seem to be _that_ much fewer. And the deltas themselves certainly
> shouldn't be bigger.
>
> It almost sounds like there's a problem with choosing what to delta
> against, not necessarily a delta algorithm problem. Although that sounds a
> bit strange, because I wouldn't have thought we actually changed the
> packing algorithm noticeably since 1.2.3.
>
> Hmm. Doing "gitk v1.2.3.. -- pack-objects.c" shows that I was wrong. Junio
> did the "hash basename and direname a bit differently" thing, which would
> appear to change the "find objects to delta against" a lot. That could be
> it.
>
> You could try to revert that change:
>
> git revert eeef7135fed9b8784627c4c96e125241c06c65e1
>
> which needs a trivial manual fixup (remove the conflict entirely:
> everything between the "<<<<" and ">>>>>" lines should go), and see if
> that's it.
Whoa. I did that revert and fixup on top of 'next'. The pack
from "git-repack -a -d -f" is now even larger due to even less
delta reuse:
Total 46391, written 46391 (delta 5148), reused 39565 (delta 0)
171M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
> You can also try to see if
>
> git repack -a -d -f --window=50
>
> makes for a better pack (at the cost of a much slower repack). It makes
> git try more objects to delta against, and can thus hide a bad sort order.
With --window=50 on 'next' (without the revert'):
Total 46391, written 46391 (delta 6666), reused 39723 (delta 0)
129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
For added measure I tried --window=100 and 500 with pretty much
the same result (slightly higher delta but still a 129M pack).
--
Shawn.
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Zack Brown @ 2006-04-20 16:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060419144827.GX27631@pasky.or.cz>
Hi Petr,
On Wed, Apr 19, 2006 at 04:48:27PM +0200, Petr Baudis wrote:
> 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
> > >
> > > 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.
You're right, the "info" directory is not there if I just run git-init-db in an
empty 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.
I just downloaded the latest versions of git and cogito from kernel.org:
cogito-0.17.2 and git-1.3.0; put their directories in my path, and ran "make" on
both of them. There's no other version in my path.
I see the same behavior: git-init-db does not create the .git/info directory.
>
> > 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.
09:46:55 [zbrown] ~/git/trees$ "ls" -ltc `which git; which git-init-db`
-rwxrwxr-x 2 zbrown zbrown 452312 Apr 20 09:44 /home/zbrown/git/git//git
-rwxrwxr-x 1 zbrown zbrown 235282 Apr 20 09:43 /home/zbrown/git/git//git-init-db
09:47:29 [zbrown] ~/git/trees$
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: 1.3.0 creating bigger packs than 1.2.3
From: Linus Torvalds @ 2006-04-20 17:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Git Mailing List, Nicolas Pitre
In-Reply-To: <20060420164351.GB31738@spearce.org>
On Thu, 20 Apr 2006, Shawn Pearce wrote:
>
> Oddly enough repacking the v1.2.3 pack using 1.3.0.g56c1 created an
> even smaller pack ("git-repack -a -d"):
That's "normal". Repacking without -f will always pack _more_, never less.
So a different packing algorithm can only improve (of course, usually not
by a huge margin, and it quickly diminishes).
> but then adding -f definately gives us the 2x explosion again:
>
> Total 46391, written 46391 (delta 6649), reused 37894 (delta 0)
> 129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
Right. Doing the -f will discard any old packing info, so if the new
packing algorithm has problems (and it obviously does), then using -f will
show them.
> > You could try to revert that change:
> >
> > git revert eeef7135fed9b8784627c4c96e125241c06c65e1
>
> Whoa. I did that revert and fixup on top of 'next'. The pack
> from "git-repack -a -d -f" is now even larger due to even less
> delta reuse:
Ok, so that wasn't it, and the new sort order is superior.
That means that it probably _is_ the delta changes themselves (probably
commit c13c6bf7 "diff-delta: bound hash list length to avoid O(m*n)
behavior". You can try
git revert c13c6bf7
to see if that's it. Although Nico already showed interest, and if you
make the archive available to him, he's sure to figure it out.
> With --window=50 on 'next' (without the revert'):
>
> Total 46391, written 46391 (delta 6666), reused 39723 (delta 0)
> 129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
Yeah, that didn't do much. Slightly more deltas than without, but not a
lot, and it didn't matter much size-wise.
You can try "--depth=50" (slogan: more "hot delta on delta action"), but
it's looking less and less like a delta selection issue, and more and more
like the deltas themselves are deproved.
Linus
^ permalink raw reply
* Re: 1.3.0 creating bigger packs than 1.2.3
From: Junio C Hamano @ 2006-04-20 17:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604200954440.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> You can try "--depth=50" (slogan: more "hot delta on delta action"), but
> it's looking less and less like a delta selection issue, and more and more
> like the deltas themselves are deproved.
I do not think I have time to look into this today until late
night, but one thing I noticed is that trying to delta more
things sometimes tend to produce bigger result X-<.
At the end of pack-objects.c::find_deltas(), there is a code
that is commented out, which is remnant from a failed
experiment. What it tried to do was to avoid placing an object
whose delta depth is already window-size back into the
candidates list, which means the next object gets compared with
one object more than otherwise would be (the extra one being the
oldest one in the window -- which might not produce better delta
than the maxed out one, but the delta with the maxed out one
would not be used anyway). The result was noticeably worse
overall packsize with more deltified objects.
We might be better off favoring compressed undeltified
representation over deltified representation a bit more
aggressively. Currently we allow delta as big as half the
uncompressed size minus 20-byte overhead or something like that;
tweaking that limit might show improvements.
^ permalink raw reply
* Re: 1.3.0 creating bigger packs than 1.2.3
From: Shawn Pearce @ 2006-04-20 17:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Nicolas Pitre
In-Reply-To: <Pine.LNX.4.64.0604200954440.3701@g5.osdl.org>
I just spent some time bisecting this issue and it looks like the
following change by Junio may be the culprit:
commit 1d6b38cc76c348e2477506ca9759fc241e3d0d46
Author: Junio C Hamano <junkio@cox.net>
Date: Wed Feb 22 22:10:24 2006 -0800
pack-objects: use full pathname to help hashing with "thin" pack.
This uses the same hashing algorithm to the "preferred base
tree" objects and the incoming pathnames, to group the same
files from different revs together, while spreading files with
the same basename in different directories.
Signed-off-by: Junio C Hamano <junkio@cox.net>
:100644 100644 af3bdf5d358b8a47ed23bcb7e9721e956eb59d60 3a16b7e4ce25ec05c64817dfd92dd9d517ab9dd3 M pack-objects.c
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 20 Apr 2006, Shawn Pearce wrote:
> >
> > Oddly enough repacking the v1.2.3 pack using 1.3.0.g56c1 created an
> > even smaller pack ("git-repack -a -d"):
>
> That's "normal". Repacking without -f will always pack _more_, never less.
> So a different packing algorithm can only improve (of course, usually not
> by a huge margin, and it quickly diminishes).
>
> > but then adding -f definately gives us the 2x explosion again:
> >
> > Total 46391, written 46391 (delta 6649), reused 37894 (delta 0)
> > 129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
>
> Right. Doing the -f will discard any old packing info, so if the new
> packing algorithm has problems (and it obviously does), then using -f will
> show them.
>
> > > You could try to revert that change:
> > >
> > > git revert eeef7135fed9b8784627c4c96e125241c06c65e1
> >
> > Whoa. I did that revert and fixup on top of 'next'. The pack
> > from "git-repack -a -d -f" is now even larger due to even less
> > delta reuse:
>
> Ok, so that wasn't it, and the new sort order is superior.
>
> That means that it probably _is_ the delta changes themselves (probably
> commit c13c6bf7 "diff-delta: bound hash list length to avoid O(m*n)
> behavior". You can try
>
> git revert c13c6bf7
>
> to see if that's it. Although Nico already showed interest, and if you
> make the archive available to him, he's sure to figure it out.
>
> > With --window=50 on 'next' (without the revert'):
> >
> > Total 46391, written 46391 (delta 6666), reused 39723 (delta 0)
> > 129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
>
> Yeah, that didn't do much. Slightly more deltas than without, but not a
> lot, and it didn't matter much size-wise.
>
> You can try "--depth=50" (slogan: more "hot delta on delta action"), but
> it's looking less and less like a delta selection issue, and more and more
> like the deltas themselves are deproved.
>
> Linus
--
Shawn.
^ permalink raw reply
* Re: cg-clone produces "___" file and no working tree
From: Junio C Hamano @ 2006-04-20 17:36 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20060420164908.GA540@tumblerings.org>
Zack Brown <zbrown@tumblerings.org> writes:
> I just downloaded the latest versions of git and cogito from kernel.org:
> cogito-0.17.2 and git-1.3.0; put their directories in my path, and ran "make" on
> both of them. There's no other version in my path.
Earlier, you were having this symptom:
>> 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?
If that is the case, you did not just (quote) "and ran "make"".
You must have run "make frotz=xyzzy target", but you did not mention
what frotz, xyzzy and target were.
> 09:46:55 [zbrown] ~/git/trees$ "ls" -ltc `which git; which git-init-db`
> -rwxrwxr-x 2 zbrown zbrown 452312 Apr 20 09:44 /home/zbrown/git/git//git
> -rwxrwxr-x 1 zbrown zbrown 235282 Apr 20 09:43 /home/zbrown/git/git//git-init-db
So you are doing
make bindir=$HOME/git/git/ install
as the last step of your installation. I _strongly_ suspect
your breakage is caused because you did a make with different
configuration before that. That is, if you do this, that is
consistent with the symptom:
make
make bindir=$HOME/git/git/ gitexecdir=$HOME/git/git/ install
It probably would help if you did this:
make clean
make bindir=$HOME/git/git gitexecdir=$HOME/git/git/
make bindir=$HOME/git/git gitexecdir=$HOME/git/git/ install
As I said in a previous message, the first paragraph in INSTALL
file explains this.
^ 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