* 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: 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: 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: 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
* 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: 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
* 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: 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
* 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: [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
* 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
* [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: 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
* 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: [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: 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
* 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: [PATCH] git-svnimport symlink support
From: Junio C Hamano @ 2006-04-20 6:54 UTC (permalink / raw)
To: smurf; +Cc: git, Martin Langhoff, Herbert Valerio Riedel
In-Reply-To: <20060420061546.GF15270@smurf.noris.de>
Thanks all.
^ permalink raw reply
* Re: [PATCH] git-svnimport symlink support
From: smurf @ 2006-04-20 6:15 UTC (permalink / raw)
To: Martin Langhoff
Cc: Junio C Hamano, Karl Hasselström, Martin Langhoff,
Herbert Valerio Riedel, git
In-Reply-To: <46a038f90604181716t3d04ec95u92401858736fa6dc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
Hi,
Martin Langhoff:
> On 4/18/06, Junio C Hamano <junkio@cox.net> wrote:
> > Karl, Martin, Smurf, Comments?
>
> +1 but bear in mind that I am not learned in the ways of the SVN specials...
>
Neither am I, but if it seems to work -- *shrug*.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] diff --stat: do not drop rename information.
From: Junio C Hamano @ 2006-04-20 3:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* In git.git itself, with and without this patch:
$ git-diff-tree --stat -M ba580ae
ba580aeafb52921025de1efe1c50db34393f9907
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
$ git-diff-tree --stat -M ba580ae
ba580aeafb52921025de1efe1c50db34393f9907
Makefile | 2 +-
diff.c => diff-lib.c | 0
2 files changed, 1 insertions(+), 1 deletions(-)
Since renames are rare, I think this is a good change. We
might want to do the same for "apply --stat" as well.
diff-lib.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 81 insertions(+), 17 deletions(-)
9ea8da8f01d7fb2159a81edba9e5e7885e6b616e
diff --git a/diff-lib.c b/diff-lib.c
index 0a832c3..86d1417 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -201,7 +201,8 @@ struct diffstat_t {
int nr;
int alloc;
struct diffstat_file {
- char *name;
+ char *name_a;
+ char *name_b;
unsigned is_unmerged:1;
unsigned is_binary:1;
unsigned int added, deleted;
@@ -209,7 +210,8 @@ struct diffstat_t {
};
static struct diffstat_file *diffstat_add(struct diffstat_t *diffstat,
- const char *name)
+ char *name_a,
+ char *name_b)
{
struct diffstat_file *x;
x = xcalloc(sizeof (*x), 1);
@@ -219,7 +221,10 @@ static struct diffstat_file *diffstat_ad
diffstat->alloc * sizeof(x));
}
diffstat->files[diffstat->nr++] = x;
- x->name = strdup(name);
+ x->name_a = strdup(name_a);
+ if (name_b)
+ name_b = strdup(name_b);
+ x->name_b = name_b;
return x;
}
@@ -234,6 +239,54 @@ static void diffstat_consume(void *priv,
x->deleted++;
}
+static char *find_common_pfx(const char *a, const char *b)
+{
+ const char *old = a;
+ const char *new = b;
+ char *name = NULL;
+ int common_length;
+ int len_a = strlen(a);
+ int len_b = strlen(b);
+
+ /* Find common prefix */
+ while (1) {
+ const char *slash_old, *slash_new;
+ slash_old = strchr(old, '/');
+ slash_new = strchr(new, '/');
+ if (!slash_old ||
+ !slash_new ||
+ slash_old - old != slash_new - new ||
+ memcmp(old, new, slash_new - new))
+ break;
+ old = slash_old + 1;
+ new = slash_new + 1;
+ }
+ /* a thru old is the common prefix, and old and new
+ * through the end of names are renames.
+ * Either give
+ * common{suffix-a => suffix-b}
+ * or
+ * name-a => name-b
+ * whichever is shorter.
+ */
+ common_length = (old - a);
+ /*
+ int squashed_len = (len_a + len_b - common_length + 6);
+ int separate_len = (len_a + len_b) + 4;
+ */
+ if (common_length < 2) {
+ /* no point squashing */
+ name = xmalloc(len_a + len_b + 5);
+ sprintf(name, "%s => %s", a, b);
+ }
+ else {
+ name = xmalloc(len_a + len_b - common_length + 7);
+ sprintf(name, "%.*s{%s => %s}",
+ common_length, a, old, new);
+ }
+ return name;
+}
+
static const char pluses[] = "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++";
static const char minuses[]= "----------------------------------------------------------------------";
@@ -249,8 +302,15 @@ static void show_stats(struct diffstat_t
for (i = 0; i < data->nr; i++) {
struct diffstat_file *file = data->files[i];
-
- len = strlen(file->name);
+ char *name = file->name_a;
+ if (file->name_b && strcmp(name, file->name_b)) {
+ name = find_common_pfx(name, file->name_b);
+ if (name != file->name_a) {
+ free(file->name_a);
+ file->name_a = name;
+ }
+ }
+ len = strlen(name);
if (max_len < len)
max_len = len;
@@ -261,7 +321,7 @@ static void show_stats(struct diffstat_t
}
for (i = 0; i < data->nr; i++) {
- char *name = data->files[i]->name;
+ char *name = data->files[i]->name_a;
int added = data->files[i]->added;
int deleted = data->files[i]->deleted;
@@ -269,7 +329,7 @@ static void show_stats(struct diffstat_t
char *qname = xmalloc(len + 1);
quote_c_style(name, qname, NULL, 0);
free(name);
- data->files[i]->name = name = qname;
+ data->files[i]->name_a = name = qname;
}
/*
@@ -305,6 +365,8 @@ static void show_stats(struct diffstat_t
printf(" %s%-*s | Unmerged\n", prefix, len, name);
goto free_diffstat_file;
}
+ else if (data->files[i]->name_b)
+ ;
else if (added + deleted == 0) {
total_files--;
goto free_diffstat_file;
@@ -325,7 +387,8 @@ static void show_stats(struct diffstat_t
len, name, added + deleted,
add, pluses, del, minuses);
free_diffstat_file:
- free(data->files[i]->name);
+ free(data->files[i]->name_a);
+ free(data->files[i]->name_b);
free(data->files[i]);
}
free(data->files);
@@ -424,14 +487,15 @@ static void builtin_diff(const char *nam
return;
}
-static void builtin_diffstat(const char *name_a, const char *name_b,
- struct diff_filespec *one, struct diff_filespec *two,
- struct diffstat_t *diffstat)
+static void builtin_diffstat(char *name_a, char *name_b,
+ struct diff_filespec *one,
+ struct diff_filespec *two,
+ struct diffstat_t *diffstat)
{
mmfile_t mf1, mf2;
struct diffstat_file *data;
- data = diffstat_add(diffstat, name_a ? name_a : name_b);
+ data = diffstat_add(diffstat, name_a, name_b);
if (!one || !two) {
data->is_unmerged = 1;
@@ -992,10 +1056,10 @@ static void run_diff(struct diff_filepai
}
static void run_diffstat(struct diff_filepair *p, struct diff_options *o,
- struct diffstat_t *diffstat)
+ struct diffstat_t *diffstat)
{
- const char *name;
- const char *other;
+ char *name;
+ char *other;
if (DIFF_PAIR_UNMERGED(p)) {
/* unmerged */
@@ -1374,7 +1438,7 @@ static void diff_flush_patch(struct diff
}
static void diff_flush_stat(struct diff_filepair *p, struct diff_options *o,
- struct diffstat_t *diffstat)
+ struct diffstat_t *diffstat)
{
if (diff_unmodified_pair(p))
return;
@@ -1559,7 +1623,7 @@ void diff_flush(struct diff_options *opt
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
flush_one_pair(p, DIFF_FORMAT_DIFFSTAT, options,
- diffstat);
+ diffstat);
}
show_stats(diffstat);
free(diffstat);
--
1.3.0.g6057
^ permalink raw reply related
* Re: using git on flash media
From: Josh Boyer @ 2006-04-20 0:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Tweed, git
In-Reply-To: <Pine.LNX.4.64.0604191651110.3701@g5.osdl.org>
On 4/19/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 20 Apr 2006, David Tweed wrote:
> >
> > What I'm basically checking is that it doesn't, I dunno, rewrite files
> > so frequently that on a modern flash drive it would wear out the entire
> > drive unreasonably quickly.
>
> The largely write-once nature of git should mean that the only files that
> get rewritten a lot are
> - the directories get rewritten to, since git creates new objects at a
> reasonable pace
> - the branch references get rewritten.
>
> In general, I'd say that git probably does less writing than most other
> SCM's are likely to do.
>
> That said, when you say "modern flash drive", I really suspect you
> shouldn't care deeply any more. Modern flash devices can be rewritten a
> lot more than old ones could (by an order of magnitude or more), and they
> almost always have wear levelling in hw, making it even less of an issue
> (but if they don't, your biggest issue will be that you should use a
> filesystem that does it for you).
Finding one that claims to have HW wear leveling is still hard, so you
can never really tell.
> That said, if you want to be safe, I think flash memory card vendors
> guarantee only up to 10,000 write cycles (and it used to be much less).
>
> That's _complete_ rewrites, though, which is more than just a single
> sector write. They tend to guarantee 100,000 single-sector re-writes (ie
> more like the "directory update" things when you create a new object).
When talking about flash, it's the erase cycles that are counted.
Most NOR chips guarantee 100,000 erase cycles per eraseblock. NAND
chips, which are what most flash drives use, can vary between 10,000 -
100,000 erases depending on the technology used.
> And assuming you'd count one commit as one "total rewrite" (which sounds
> unlikely - but it's certainly more than one sector - I don't know what
> they consider a total rewrite when they make up their numbers), that
A "total rewrite" is simply something that causes an eraseblock to be
erased. That can vary alot, but it essentially boils down to needing
to write new data to a location in an eraseblock that has already been
written to.
> implies that to be really safe, you shouldn't do more than 10,000 commits
> before you replace your flash. Quite frankly, I suspect that's _way_ more
> conservative than you should be, but hey, since you asked..
To be really conservative, just don't do it ;). Most flash drives
don't allow access to the raw flash chips, so while you can use
something like JFFS2 on them still, the benefits of that are somewhat
lost since you never really know what is going on underneath.
> One rule: NEVER mount your flash with the "sync" option, and use "noatime"
> to avoid unnecessary inode access time updates (that's especially true for
Right.
josh
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Junio C Hamano @ 2006-04-20 0:33 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87r73t2jd3.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Thanks for the careful explanation.
You're welcome. You owe me a patch that typo-fixes and
pretty-prints my message, and drop it somewhere in
Documentation/howto hierarchy for future reference ;-).
> So there's the final piece I'd like here. I think "git status -a -v"
> should provide a multi-parent diff when merging, as should "git status
> -v" after manually doing an update-index while merging.
I'll keep that in mind, but honestly I am not very interested in
that particular use case, if only because you can already do
that by committing, and running "git show".
If you do not like how the resulting merge commit looks like, we
have "git commit --amend" and "git reset --hard HEAD^" for you
already.
I (or Linus) _may_ end up doing "git diff tree1 tree2 tree3..."
as part of the planned diff rewrite, but that would be only
if/when doing things in such a generic way is not much more
trouble than the current "we only do one of index-vs-files,
tree-vs-index, tree-vs-files-via-index or tree-vs-tree and
nothing else" model.
^ permalink raw reply
* Re: using git on flash media
From: Linus Torvalds @ 2006-04-20 0:23 UTC (permalink / raw)
To: David Tweed; +Cc: git
In-Reply-To: <20060419233125.89318.qmail@web86912.mail.ukl.yahoo.com>
On Thu, 20 Apr 2006, David Tweed wrote:
>
> What I'm basically checking is that it doesn't, I dunno, rewrite files
> so frequently that on a modern flash drive it would wear out the entire
> drive unreasonably quickly.
The largely write-once nature of git should mean that the only files that
get rewritten a lot are
- the directories get rewritten to, since git creates new objects at a
reasonable pace
- the branch references get rewritten.
In general, I'd say that git probably does less writing than most other
SCM's are likely to do.
That said, when you say "modern flash drive", I really suspect you
shouldn't care deeply any more. Modern flash devices can be rewritten a
lot more than old ones could (by an order of magnitude or more), and they
almost always have wear levelling in hw, making it even less of an issue
(but if they don't, your biggest issue will be that you should use a
filesystem that does it for you).
That said, if you want to be safe, I think flash memory card vendors
guarantee only up to 10,000 write cycles (and it used to be much less).
That's _complete_ rewrites, though, which is more than just a single
sector write. They tend to guarantee 100,000 single-sector re-writes (ie
more like the "directory update" things when you create a new object).
And assuming you'd count one commit as one "total rewrite" (which sounds
unlikely - but it's certainly more than one sector - I don't know what
they consider a total rewrite when they make up their numbers), that
implies that to be really safe, you shouldn't do more than 10,000 commits
before you replace your flash. Quite frankly, I suspect that's _way_ more
conservative than you should be, but hey, since you asked..
10,000 commits is actually a fair number. The kernel has gotten 25,000 in
a year, but the kernel is a pretty active and large project. I suspect
that 10,000 commits is quite a lot of years for most projects.
One rule: NEVER mount your flash with the "sync" option, and use "noatime"
to avoid unnecessary inode access time updates (that's especially true for
git, where archive atimes aren't interesting, but it's usually a good idea
for flash in general). Otherwise you'll get normal accesses ending up
doign "writes" too and writes will do a lot more of them, and the above
"one commit = one rewrite" rule-of-thumb is suddenly not at all
conservative.
Btw, backups are still good. Flash or no flash, and whether you're very
conservative in your flash usage or not.
Linus
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Carl Worth @ 2006-04-20 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzeh3ypu.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On Wed, 19 Apr 2006 16:57:49 -0700, Junio C Hamano wrote:
>
> I suspect this is just a misunderstanding caused by insufficient
> explanation, so let's try this a bit differently.
Junio,
Thanks for the careful explanation.
> With the patch applied (or use "next" branch I'll be pushing out
> shortly), let's try the core-tutorial example up to the point
> where we need to make a merge commit and get conflict.
Heh. We dropped back to the identical example with our
crossed-in-flight messages.
> But later (much later) we find out that there was something
> wrong with this hand-resolve and now we would want to fix it.
> The new command, "git unresolve" is designed to help us exactly
> in this situation:
Yes. And this was in fact the question I had asked in IRC. How to get
the diff again when I realize the file I updated is wrong.
And as you point out, git-unresolve does just the trick here.
The question I asked in my latest message is basically just "Shouldn't
there be a way to get the diff from the several parents to the
index?". That's slightly different, but it is the functionality I was
looking for when I was trying to recover from my update-of-botched-merge.
And its useful separately as part of the pre-commit-review I've said I
always want to be able to do, (and as you designed "git status -v" to
provide).
So there's the final piece I'd like here. I think "git status -a -v"
should provide a multi-parent diff when merging, as should "git status
-v" after manually doing an update-index while merging.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] Add git-unresolve <paths>...
From: Carl Worth @ 2006-04-20 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk69l5gi1.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]
On Wed, 19 Apr 2006 15:48:22 -0700, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
>
> > Meanwhile, I still think it's worth re-considering the original
> > problem.
>
> Maybe you are misunderstanding something in a major way,...
It's possible, but it's also possible I'm just failing to express
myself clearly.
> > After a failed merge, I get a multi-parent diff from "git
> > diff". However, after updating the index, I can't find any way to get
> > multi-parent diffs anymore.
>
> ... and that is exactly what this "unmerge to re-populate higher
> order stages" does. The multi-parent diff you have been looking
> at failed merge _is_ generated by comparing the higher order
> stages and your working tree file.
But unmerging puts my index back into a not-ready-to-commit state,
right? If so, then that's what I don't like from this proposal.
> > I'd still like to be able to do that, even when I know that what I
> > have in the index is good, and I don't want to undo it.
>
> You cannot it have both ways. Either you want to have the unmerged
> entries (so that you *can* view the combined diff), or you do
> not want to have them (then you obviously cannot view the
> combined diff between the working tree file and these stages).
I don't understand. Why would the entire diff operation have to happen
inside the index? As soon as I'm done with the merge commit I can do
"git show" and see a multi-parent diff. That doesn't have to muck with
my index, does it?
By, example, (using the merge from the git tutorial), just before
updating the index I get a lovely multi-parent diff:
$ git diff
diff --cc hello
index 06fa6a2,cc44c73..0000000
--- a/hello
+++ b/hello
@@@ -1,3 -1,3 +1,4 @@@
Hello World
It's a new day for git
+Play, play, play
+ Work, work, work
then I can update the index:
$ git update-index hello
and at this point I know I can see a single-parent diff before
committing:
$ git diff --cached
diff --git a/hello b/hello
index 06fa6a2..8798bdc 100644
--- a/hello
+++ b/hello
@@ -1,3 +1,4 @@
Hello World
It's a new day for git
Play, play, play
+Work, work, work
But what I want to do instead is at this point get the multi-parent
diff.
Finally, after I commit, it's easy to get multi-parent diff again:
$ git commit -m "Resolved merge conflict"
$ PAGER= git show
commit 547599946cf5dfb04af804e9d5451beb17662dca
Merge: 35e0e9b... 698ac13...
Author: Carl Worth <cworth@raht.cworth.org>
Date: Wed Apr 19 16:51:55 2006 -0700
Resolved merge conflict
diff --cc hello
index 06fa6a2,cc44c73..8798bdc
--- a/hello
+++ b/hello
@@@ -1,3 -1,3 +1,4 @@@
Hello World
It's a new day for git
+Play, play, play
+ Work, work, work
So why can't I get that same result before committing without changing
my index?
If the answer is that current implementation doesn't provide for that,
(that is, it provides either an in-index multi-diff for files in
multiple stages, OR it provides a multi-parent diff for a multi-parent
commit object), then that's fine. But that doesn't seem like any
fundamental limitation preventing what I'd like to have.
Am I making more sense now? Or am I still missing something?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ 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