* git-citool
From: arttuladhar @ 2012-02-10 17:54 UTC (permalink / raw)
To: git
When I perform commit in /git-citoo/l, the git hooks doesn't run. But for the
same repository, git hooks runs fine while using
command line git commit -a.
I wanted to get template enforcement on the /git-citool/.
Anybody have idea on recompiling the git-gui from which git-citool gets run.
I know the git-gui is built on tcl and i have the source code but i have no
experience with tck and the recompile.
Thanks,
ART
--
View this message in context: http://git.661346.n2.nabble.com/git-citool-tp7273576p7273576.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Junio C Hamano @ 2012-02-10 17:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202101456.45944.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> (with either "..., 'owner', ..." or "..., [ 'owner' ], ..." for single-key
> filling), or
>
> if (project_info_needs_filled($pr, ['age', 'age_string'], \@fill_only) {
>
> Is it?
Whatever. I am not sure what @fill_only is needed for, if the name stands
for "only fill these fields, if this argument is empty". After all,
doesn't the above example callsite, without ", \@fill_only" at the end,
say "I am going to use age and age_string, so these two need to be filled"
already?
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-10 17:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202101555.20163.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 10 Feb 2012, Michał Kiedrowicz wrote:
> > Jakub Narebski <jnareb@gmail.com> wrote:
> > > Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> > >
> > > > The code that comares lines is based on
> > > > contrib/diff-highlight/diff-highlight, except that it works with
> > > > multiline changes too. It also won't highlight lines that are
> > > > completely different because that would only make the output unreadable.
> > > > Combined diffs are not supported but a following commit will change it.
> > >
> > > I was thinking that if gitweb were to support "diff refinement
> > > highlighting", it would either use one of *Diff* packages from CPAN,
> > > or "git diff --word-diff" output.
> >
> > I think highlighting inline and side-by-side diff outputs is
> > something different from "git diff --word-diff". I find it useful for
> > people who are used to these diff formats (i.e. me :).
>
> I was thinking about *using* "git diff --word-diff" for diff refinement
> highlighting of inline (unified) and side-by-side diff...
>
Then I must have misunderstood you.
> though having an option of showing word-diff would be I think a good
> idea in some cases, like e.g. documentation changes.
>
> > OTOH I'm not against using a dedicated package from CPAN. But I think
> > my approach is proven to work (I use contrib/diff-highlight as a
> > filter) and more lightweight (doesn't add another dependency to
> > gitweb). Moreover, adding support for some Diff package may be done
> > later, at any moment. It's just a matter of replacing one function
> > (format_rem_add_line()) with the one that uses Diff.
>
> O.K., if it is tested code, then all is good.
As I wrote, I haven't taken the code as-is (for example, original
code only works for oneline changes). But the general approach is the
same.
> Well, except the fact
> that I'm rather wary about adding more code to gitweb when it is still
> single monolithic script, rather than split into packages.
>
Yeah, jumping between 2k'th and 5k'th line isn't a great fun. Do you
have any roadmap how to split gitweb?
> Anyway, I'll try to review those patches soon. I like the refactoring
> work (that is from what I had chance to examine).
Thanks.
^ permalink raw reply
* AW: Project structure of .NET-Projects using git submodule or something different
From: Harald Heigl @ 2012-02-10 17:03 UTC (permalink / raw)
To: Jens.Lehmann; +Cc: git
In-Reply-To: <4F29A0BE.8000803@web.de>
Hi,
Just another question: What if your dependency is used in many projects?
For example if you use it in 10 projects it will be checked out 10 times.
Well you could always do a push (and a pull in all other 9 projects to not
forget them).
Ok 10 projects is quite much, but I sometimes have 2-4 projects in parallel
which sometimes use the same dependencies. (And change them in the projects
on demand)
I've thought about checking out the dependency only once and do hardlinking,
I've also read about the "git clone --shared", but with both methods I would
loose the advantage of using submodule and on the other side I don't know
exactly which problems could arise.
Could I just say that submodules would be checked out to a central location
or are there better possibilities?
I don't mind the disk space, I just wonder how to keep track if you have
some projects all using the same dependencies.
Thanks,
Harald
> -----Ursprüngliche Nachricht-----
> Von: Harald Heigl [mailto:Harald@heigl-online.at]
> Gesendet: Mittwoch, 01. Februar 2012 22:07
> An: 'git@vger.kernel.org'
> Betreff: AW: Project structure of .NET-Projects using git submodule or
> something different
>
> Hi, thanks for your answer!
>
> > -----Ursprüngliche Nachricht-----
> > Von: Jens Lehmann [mailto:Jens.Lehmann@web.de]
> > Gesendet: Mittwoch, 01. Februar 2012 21:30
> > An: Harald Heigl
> > Cc: git@vger.kernel.org
> > Betreff: Re: Project structure of .NET-Projects using git submodule or
> > something different
> >
> > Am 31.01.2012 23:41, schrieb Harald Heigl:
> > > Let's assume following Project structure (Dependencies and
> > Subdependencies
> > > are submodules and submodules of the submodules)
> > > Project
> > > Dependency 1
> > > Dependency 2
> > > Dependency 3
> > > Dependency 4
> > > Dependency 2
> > >
> > >
> > > The problem is if I want to build them I need to build 2+3, then 1, 4
and 2
> > > again and then the project. As you may see project 2 is a submodule of
> > > dependency 1 and also of project. I don't feel comfortable with this
> setup.
> > > What do you think?
> >
> > Hmm, we try to avoid that kind of setup as having checked out different
> > versions of the "Dependency 2" submodule could have rather surprising
> > effects. We get along really well with "Dependency 2" only being present
> > in the superproject and having "Dependency 1" reference that instead of
> > having its own copy (So we have submodules which are depending on
> having
> > other submodules right next to them). Then the superproject is
> responsible
> > for tying it all together.
>
> I think you're right, my first thoughts were that if I start a new project
I just
> "git submodule dependency1" and get all the required dependencies and
> the dependencies within the dependencies and so on ... .
> With your solution I "git submodule dependency1" and have to think about
> the dependencies it depends on. On the other hand we are just a small
> company and the number of submodules is not too big and the missing
> references in a new project would be easily identifiable, so ... .
>
> And if I want to checkout dependency 1 individually (for whatever reason),
I
> could still do something like this:
> SuperDependency1 (with solution-File)
> Dependency1 (as submodule)
> Dependency2 (dependency of dependency1 - as submodule)
> Dependency3 (dependency of dependency1 - as submodule)
>
> Thanks again, I see my concept causes some trouble ...
>
> Any other thoughts or other workflows with git or with tools build around
> git?
>
> Thanks again,
> Harald
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Matthieu Moy @ 2012-02-10 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, ftpadmin, Petr Onderka, git
In-Reply-To: <7vmx8rtu3e.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
>> Please restore access to the following files when possible. Some sites
>> are referencing those, including kernel.org itself:
>>
>> http://www.kernel.org/pub/software/scm/git/docs/git.html
>
> The pages reachable from this used to be living documents in that every
> time the 'master' branch was updated at k.org, automatically a server side
> hook script generated a new set of HTML pages and updated them.
Is it possible to have the static HTML uploaded from another machine,
not necessarily for each push, but e.g. for every release?
I don't think anyone cares about having the very latest documentation
there, but it would still be great to have an official place to point to
when writing documentation on the web about such or such command.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: User authentication in GIT
From: supadhyay @ 2012-02-10 16:57 UTC (permalink / raw)
To: git
In-Reply-To: <CAMK1S_i=QUxf1CPDwdDn0+2-7fL5xxMZ67rHvR63a-vU1uq39Q@mail.gmail.com>
Hi Sitaram,
Thanks for helping me by providing such a good link. Now, I am able to
understand how to manage the user in efficient way.
With that I have one question is- in my GIT server we already migrated our
source code (pilot testing) from CVS to GIT. We used user "GITAdmin" for
migration and though its for pilot testing only we use the home directory
for source code repository is /home/GITAdmin/migration/VVD.git.
now the question is, I install gitolie using the same user "GITAdmin" and on
the same path i.e. /home/GITAdmin. And when add repository from my
workstation (git add conf/glitolite.conf) , this added repositories
directory on the GIT server path /home/GITAdmin/repositories/MRB.git
Now my confusion is my existing source code repository directory path during
migration /home/GITAdmin/migration/<repository.git> and now through gitolite
I want to manage both users and repositories but through gitolite it add
repository in different path /home/GITAdmin/repositories/<repository.git>.
Can you please help how through gitolite I can add new repository on to the
same my exisitng migrated repository directory?
Thanks,
Suchi
--
View this message in context: http://git.661346.n2.nabble.com/User-authentication-in-GIT-tp7261349p7273350.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 3/3] diff --stat: use the real terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-10 16:39 UTC (permalink / raw)
To: git, gitster, pclouds; +Cc: Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328891972-23695-1-git-send-email-zbyszek@in.waw.pl>
Some projects (especially in Java), have long filename paths, with
nested directories or long individual filenames. When files are
renamed, the stat output can be almost useless. If the middle part
between { and } is long (because the file was moved to a completely
different directory), then most of the path would be truncated.
It makes sense to use the full terminal width.
If commits changing a lot of lines are displayed in a wide terminal
window (200 or more columns), and the +- graph uses the full width,
the output looks bad. Messages wrapped to about 80 columns are
interspersed with very long +- lines. It makes sense to limit the
width of the graph to a fixed value, even if more columns are
available. This fixed value is subjectively hard-coded to be 40
columns, but seems to work well for git.git and linux-2.6.git and
other repositories.
Three tests are added: the first one check that --stat output for a
long file name is the same as previously (the test should pass
independently of this patch). The last two check that --stat output
with a massive change uses only 40 columns for +- in graph output.
Those two tests are dependent on this patch.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
diff.c | 26 ++++++++++++++------------
t/t4014-format-patch.sh | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+), 12 deletions(-)
diff --git a/diff.c b/diff.c
index 84780fd..8176d74 100644
--- a/diff.c
+++ b/diff.c
@@ -7,6 +7,7 @@
#include "diffcore.h"
#include "delta.h"
#include "xdiff-interface.h"
+#include "help.h"
#include "color.h"
#include "attr.h"
#include "run-command.h"
@@ -1376,7 +1377,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
int i, len, add, del, adds = 0, dels = 0;
uintmax_t max_change = 0, max_len = 0;
int total_files = data->nr;
- int width, name_width, count;
+ int width, name_width, graph_width, count;
const char *reset, *add_c, *del_c;
const char *line_prefix = "";
int extra_shown = 0;
@@ -1390,8 +1391,9 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
line_prefix = msg->buf;
}
- width = options->stat_width ? options->stat_width : 80;
- name_width = options->stat_name_width ? options->stat_name_width : 50;
+ width = options->stat_width ? options->stat_width : term_columns();
+ name_width = options->stat_name_width ? options->stat_name_width
+ : width * 5/8; /* this gives 50 if not on tty */
count = options->stat_count ? options->stat_count : data->nr;
/* Sanity: give at least 5 columns to the graph,
@@ -1433,14 +1435,14 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
* 10 is for one blank at the beginning of the line plus
* " | count " between the name and the graph.
*
- * From here on, name_width is the width of the name area,
- * and width is the width of the graph area.
+ * From here name_width is the width of the name area,
+ * and graph_width is the width of the graph area.
+ * max_change is used to scale graph properly.
*/
name_width = (name_width < max_len) ? name_width : max_len;
- if (width < (name_width + 10) + max_change)
- width = width - (name_width + 10);
- else
- width = max_change;
+ graph_width = max_change < 40 ? max_change : 40;
+ if (width < (name_width + 10) + graph_width)
+ graph_width = width - (name_width + 10);
for (i = 0; i < count; i++) {
const char *prefix = "";
@@ -1497,9 +1499,9 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
adds += add;
dels += del;
- if (width <= max_change) {
- add = scale_linear(add, width, max_change);
- del = scale_linear(del, width, max_change);
+ if (graph_width <= max_change) {
+ add = scale_linear(add, graph_width, max_change);
+ del = scale_linear(del, graph_width, max_change);
}
fprintf(options->file, "%s", line_prefix);
show_name(options->file, prefix, name, len);
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 7dfe716..bd3002b 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -894,4 +894,44 @@ test_expect_success 'format patch ignores color.ui' '
test_cmp expect actual
'
+cat >expect <<'EOF'
+ ...aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | 1 +
+EOF
+name=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+test_expect_success 'format patch filename width is limited' "
+ > ${name} &&
+ git add ${name} &&
+ git commit -m message &&
+ echo a > ${name} &&
+ git commit -m message ${name} &&
+ git format-patch --stat --stdout -1 |
+ grep -m 1 aaaaa > actual &&
+ test_cmp expect actual
+"
+
+cat >expect <<'EOF'
+ abcd | 1000 ++++++++++++++++++++++++++++++++++++++++
+EOF
+test_expect_success 'format patch graph width is 40 columns' '
+ > abcd &&
+ git add abcd &&
+ git commit -m message &&
+ seq 1000 > abcd &&
+ git commit -m message abcd &&
+ git format-patch --stat --stdout -1 |
+ grep -m 1 abcd > actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'format patch ignores COLUMNS' '
+ > abcd &&
+ git add abcd &&
+ git commit -m message &&
+ seq 1000 > abcd &&
+ git commit -m message abcd &&
+ COLUMNS=200 git format-patch --stat --stdout -1 |
+ grep -m 1 abcd > actual &&
+ test_cmp expect actual
+'
+
test_done
--
1.7.9.263.g4be11.dirty
^ permalink raw reply related
* [PATCH 2/3] help.c: make term_columns() cached and export it
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-10 16:39 UTC (permalink / raw)
To: git, gitster, pclouds; +Cc: Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328891972-23695-1-git-send-email-zbyszek@in.waw.pl>
Since term_columns() will usually fail, when a pager is installed,
the cache is primed before the pager is installed. If a pager is not
installed, then the cache will be set on first use.
Conforms to The Single UNIX Specification, Version 2
(http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html#tag_002_003).
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
help.c | 37 +++++++++++++++++++++++++++++--------
help.h | 2 ++
| 5 +++++
3 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/help.c b/help.c
index bc15066..5d1cb1d 100644
--- a/help.c
+++ b/help.c
@@ -5,26 +5,47 @@
#include "help.h"
#include "common-cmds.h"
-/* most GUI terminals set COLUMNS (although some don't export it) */
-static int term_columns(void)
+/*
+ * Cache for term_columns() value. Set on first use or when
+ * installing a pager and replacing stdout.
+ */
+static int term_columns_cache;
+
+/*
+ * Return cached value (if set) or $COLUMNS (if set and positive) or
+ * ioctl(1, TIOCGWINSZ).ws_col (if positive) or 80.
+ *
+ * $COLUMNS even if set, is usually not exported, so
+ * the variable can be used to override autodection.
+ */
+int term_columns(void)
{
- char *col_string = getenv("COLUMNS");
+ char *col_string;
int n_cols;
- if (col_string && (n_cols = atoi(col_string)) > 0)
- return n_cols;
+ if (term_columns_cache)
+ return term_columns_cache;
+
+ col_string = getenv("COLUMNS");
+ if (col_string && (n_cols = atoi(col_string)) > 0) {
+ term_columns_cache = n_cols;
+ return term_columns_cache;
+ }
#ifdef TIOCGWINSZ
{
struct winsize ws;
if (!ioctl(1, TIOCGWINSZ, &ws)) {
- if (ws.ws_col)
- return ws.ws_col;
+ if (ws.ws_col) {
+ term_columns_cache = ws.ws_col;
+ return term_columns_cache;
+ }
}
}
#endif
- return 80;
+ term_columns_cache = 80;
+ return term_columns_cache;
}
void add_cmdname(struct cmdnames *cmds, const char *name, int len)
diff --git a/help.h b/help.h
index b6b12d5..880a4b4 100644
--- a/help.h
+++ b/help.h
@@ -29,4 +29,6 @@ extern void list_commands(const char *title,
struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
+extern int term_columns(void);
+
#endif /* HELP_H */
--git a/pager.c b/pager.c
index 975955b..e7032de 100644
--- a/pager.c
+++ b/pager.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include "sigchain.h"
+#include "help.h"
#ifndef DEFAULT_PAGER
#define DEFAULT_PAGER "less"
@@ -76,6 +77,10 @@ void setup_pager(void)
if (!pager)
return;
+ /* prime the term_columns() cache before it is too
+ * late and stdout is replaced */
+ (void) term_columns();
+
setenv("GIT_PAGER_IN_USE", "true", 1);
/* spawn the pager */
--
1.7.9.263.g4be11.dirty
^ permalink raw reply related
* [PATCH 1/3] Move git_version_string to help.c before diff changes
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-10 16:39 UTC (permalink / raw)
To: git, gitster, pclouds; +Cc: Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328891972-23695-1-git-send-email-zbyszek@in.waw.pl>
git_version_string lives in git.c. When diff.c starts to use functions
from help.c, which in turn use git_version_string, linking against
libgit.a will fail. This is because git_version_string is physically
located in git.o, and this object file is not part of libgit.a. One
option would be to add git.o to libgit.a, but git.o is biggish. The
second, better option is to move git_version_string to somewhere where
it'll become part of libgit.a. This variable is only used in a couple
of places, help.c being one of them, so it let's move
git_version_string from git.c to help.c. The git binary is linked with
help.o, so it is not affected by this move.
Without this change the next commit would fail with:
$ gcc -g -O0 -I. -DUSE_LIBPCRE -DHAVE_PATHS_H -DHAVE_DEV_TTY -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -DNO_MKSTEMPS -o git-daemon daemon.o libgit.a xdiff/lib.a -lpcre -lz -lcrypto -lpthread
libgit.a(help.o): In function `cmd_version':
/home/zbyszek/git/git/help.c:435: undefined reference to `git_version_string'
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
Makefile | 5 +++--
git.c | 2 --
help.c | 2 ++
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 4817157..ccafb95 100644
--- a/Makefile
+++ b/Makefile
@@ -1890,7 +1890,7 @@ strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
git.o: common-cmds.h
-git.sp git.s git.o: EXTRA_CPPFLAGS = -DGIT_VERSION='"$(GIT_VERSION)"' \
+git.sp git.s git.o: EXTRA_CPPFLAGS = \
'-DGIT_HTML_PATH="$(htmldir_SQ)"' \
'-DGIT_MAN_PATH="$(mandir_SQ)"' \
'-DGIT_INFO_PATH="$(infodir_SQ)"'
@@ -1899,7 +1899,8 @@ git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-help.sp help.o: common-cmds.h
+help.o: common-cmds.h
+help.sp help.o: EXTRA_CPPFLAGS = -DGIT_VERSION='"$(GIT_VERSION)"'
builtin/help.sp builtin/help.o: common-cmds.h
builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
diff --git a/git.c b/git.c
index 3805616..a24a0fd 100644
--- a/git.c
+++ b/git.c
@@ -256,8 +256,6 @@ static int handle_alias(int *argcp, const char ***argv)
return ret;
}
-const char git_version_string[] = GIT_VERSION;
-
#define RUN_SETUP (1<<0)
#define RUN_SETUP_GENTLY (1<<1)
#define USE_PAGER (1<<2)
diff --git a/help.c b/help.c
index cbbe966..bc15066 100644
--- a/help.c
+++ b/help.c
@@ -409,6 +409,8 @@ const char *help_unknown_cmd(const char *cmd)
exit(1);
}
+const char git_version_string[] = GIT_VERSION;
+
int cmd_version(int argc, const char **argv, const char *prefix)
{
printf("git version %s\n", git_version_string);
--
1.7.9.263.g4be11.dirty
^ permalink raw reply related
* [PATCH 0/3 v2] diff --stat: use the real terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-10 16:39 UTC (permalink / raw)
To: git, gitster, pclouds; +Cc: Michael J Gruber
In-Reply-To: <CACsJy8AQdz=uwDm+FOgcUB5JOi5U7w-W4w7yUPL6wd2FO-bArg@mail.gmail.com>
Hi,
this is version 2.
Changes:
- style fixes
- some tests for git-format-patch added
- patches 3 and 4 squashed together, since they touch the same lines
- graph width is limited to 40 columns, even if there's more space
- patch descriptions extended and cleared up
Description (modified):
this is a patch series to make 'git diff --stat' use full terminal
width instead of hard-coded 80 columns.
This is quite useful when working on projects with nested directory
structure, e.g. Java:
.../{ => workspace/tasks}/GetTaskResultAction.java | 10 +-
.../tasks}/RemoveAllAbortedTasksAction.java | 7 +-
.../tasks}/RemoveAllFailedTasksAction.java | 7 +-
is changed to display full paths if the terminal window is wide
enough.
Git usually uses the full terminal width automatically, so it should
do so with --stat too.
The "big" functional change in the patch series is
s/80/term_columns()/ in show_stats(). The partitioning of available
columns is changed to dedicate more space to file names and the number
of columns used for +- graph is limited.
^ permalink raw reply
* [PATCH] Remove empty ref directories while reading loose refs
From: Nguyễn Thái Ngọc Duy @ 2012-02-10 16:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael Haggerty,
Nguyễn Thái Ngọc Duy
Empty directories in $GIT_DIR/refs increases overhead at startup.
Removing a ref does not remove its parent directories even if it's the
only file left so empty directories will be hanging around.
pack-refs was taught of cleaning up empty directories in be7c6d4
(pack-refs: remove newly empty directories - 2010-07-06), but it only
checks parent directories of packed refs only. Already empty dirs are
left untouched.
This patch removes empty directories as we see while traversing
$GIT_DIR/refs and reverts be7c6d4 because it's no longer needed.
Some directories, even if empty, are not removed:
- refs: this one is needed to recognize a git repository
- refs/heads and refs/tags: these are created by init-db, people may
expect them to always be there
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I don't think the a few extra rmdir()s from time to time at startup
are going to cause any problems. Making delete_ref() delete empty
directories takes more effort and probably not worth it.
Of course this only works if people do not expect empty directories
to stay in $GIT_DIR/refs permanently. They now may need to put .keep
file in to keep parent directories from being removed. Would anyone
do that?
pack-refs.c | 32 --------------------------------
refs.c | 14 +++++++++++++-
t/t3210-pack-refs.sh | 6 ------
3 files changed, 13 insertions(+), 39 deletions(-)
diff --git a/pack-refs.c b/pack-refs.c
index f09a054..ec9e476 100644
--- a/pack-refs.c
+++ b/pack-refs.c
@@ -60,37 +60,6 @@ static int handle_one_ref(const char *path, const unsigned char *sha1,
return 0;
}
-/*
- * Remove empty parents, but spare refs/ and immediate subdirs.
- * Note: munges *name.
- */
-static void try_remove_empty_parents(char *name)
-{
- char *p, *q;
- int i;
- p = name;
- for (i = 0; i < 2; i++) { /* refs/{heads,tags,...}/ */
- while (*p && *p != '/')
- p++;
- /* tolerate duplicate slashes; see check_refname_format() */
- while (*p == '/')
- p++;
- }
- for (q = p; *q; q++)
- ;
- while (1) {
- while (q > p && *q != '/')
- q--;
- while (q > p && *(q-1) == '/')
- q--;
- if (q == p)
- break;
- *q = '\0';
- if (rmdir(git_path("%s", name)))
- break;
- }
-}
-
/* make sure nobody touched the ref, and unlink */
static void prune_ref(struct ref_to_prune *r)
{
@@ -99,7 +68,6 @@ static void prune_ref(struct ref_to_prune *r)
if (lock) {
unlink_or_warn(git_path("%s", r->name));
unlock_ref(lock);
- try_remove_empty_parents(r->name);
}
}
diff --git a/refs.c b/refs.c
index b8843bb..80ebba3 100644
--- a/refs.c
+++ b/refs.c
@@ -343,6 +343,12 @@ static void get_ref_dir(struct ref_cache *refs, const char *base,
struct dirent *de;
int baselen = strlen(base);
char *refname = xmalloc(baselen + 257);
+ int empty_dir = 1;
+
+ if (!strcmp(base, "refs") ||
+ !strcmp(base, "refs/heads") ||
+ !strcmp(base, "refs/tags"))
+ empty_dir = 0;
memcpy(refname, base, baselen);
if (baselen && base[baselen-1] != '/')
@@ -355,8 +361,12 @@ static void get_ref_dir(struct ref_cache *refs, const char *base,
int namelen;
const char *refdir;
- if (de->d_name[0] == '.')
+ if (de->d_name[0] == '.') {
+ if (de->d_name[1] != '.' || de->d_name[2])
+ empty_dir = 0;
continue;
+ }
+ empty_dir = 0;
namelen = strlen(de->d_name);
if (namelen > 255)
continue;
@@ -387,6 +397,8 @@ static void get_ref_dir(struct ref_cache *refs, const char *base,
}
free(refname);
closedir(dir);
+ if (empty_dir)
+ rmdir(path);
}
}
diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
index cd04361..5251740 100755
--- a/t/t3210-pack-refs.sh
+++ b/t/t3210-pack-refs.sh
@@ -60,12 +60,6 @@ test_expect_success 'see if git pack-refs --prune remove ref files' '
! test -f .git/refs/heads/f
'
-test_expect_success 'see if git pack-refs --prune removes empty dirs' '
- git branch r/s/t &&
- git pack-refs --all --prune &&
- ! test -e .git/refs/heads/r
-'
-
test_expect_success \
'git branch g should work when git branch g/h has been deleted' \
'git branch g/h &&
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: git status: small difference between stating whole repository and small subdirectory
From: Piotr Krukowiecki @ 2012-02-10 16:18 UTC (permalink / raw)
To: Git Mailing List; +Cc: Nguyen Thai Ngoc Duy
In-Reply-To: <CAA01Csr8FbvQ8uFvxX8_6i-hysin6JuaifVVC-yoLyoT0N5F4Q@mail.gmail.com>
On Fri, Feb 10, 2012 at 10:42 AM, Piotr Krukowiecki
<piotr.krukowiecki@gmail.com> wrote:
> Hi,
>
> I compared stating whole tree vs one small subdirectory, and I
> expected that for the subdirectory status will be very very fast.
> After all, it has only few files to stat. But it's not fast. Why?
>
>
> With cold cache (echo 3 | sudo tee /proc/sys/vm/drop_caches):
>
> $ time git status > /dev/null
> real 0m41.670s
> user 0m0.980s
> sys 0m2.908s
>
> $ time git status -- src/.../somedir > /dev/null
> real 0m17.380s
> user 0m0.748s
> sys 0m0.328s
>
>
> With warm cache:
>
> $ time git status > /dev/null
> real 0m0.792s
> user 0m0.404s
> sys 0m0.384s
>
> $ time git status -- src/.../somedir > /dev/null
> real 0m0.335s
> user 0m0.288s
> sys 0m0.048s
>
>
> Repository/dir stats:
>
> $ find * -type f | wc -l
> 127189
> $ du -shc * | grep total
> 2.2G total
>
> $ find src/.../somedir -type f | wc -l
> 55
> $ du -shc src/.../somedir | grep total
> 224K total
>
>
> $ git --version
> git version 1.7.9.rc0.10.gbeecc
I can't reproduce this behavior at the moment. 'status' on the
directory takes about 1.5s instead of 17s. status on whole repository
takes 27s.
This is my work repository, so it was changed today.
I'll get back to you when I can reproduce the problem again...
--
Piotr Krukowiecki
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jakub Narebski @ 2012-02-10 14:55 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <20120210151528.56145e0c@gmail.com>
On Fri, 10 Feb 2012, Michał Kiedrowicz wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> >
> > > The code that comares lines is based on
> > > contrib/diff-highlight/diff-highlight, except that it works with
> > > multiline changes too. It also won't highlight lines that are
> > > completely different because that would only make the output unreadable.
> > > Combined diffs are not supported but a following commit will change it.
> >
> > I was thinking that if gitweb were to support "diff refinement
> > highlighting", it would either use one of *Diff* packages from CPAN,
> > or "git diff --word-diff" output.
>
> I think highlighting inline and side-by-side diff outputs is
> something different from "git diff --word-diff". I find it useful for
> people who are used to these diff formats (i.e. me :).
I was thinking about *using* "git diff --word-diff" for diff refinement
highlighting of inline (unified) and side-by-side diff...
though having an option of showing word-diff would be I think a good
idea in some cases, like e.g. documentation changes.
> OTOH I'm not against using a dedicated package from CPAN. But I think
> my approach is proven to work (I use contrib/diff-highlight as a
> filter) and more lightweight (doesn't add another dependency to
> gitweb). Moreover, adding support for some Diff package may be done
> later, at any moment. It's just a matter of replacing one function
> (format_rem_add_line()) with the one that uses Diff.
O.K., if it is tested code, then all is good. Well, except the fact
that I'm rather wary about adding more code to gitweb when it is still
single monolithic script, rather than split into packages.
Anyway, I'll try to review those patches soon. I like the refactoring
work (that is from what I had chance to examine).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
From: Michael Haggerty @ 2012-02-10 14:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <4F158E99.2020906@alum.mit.edu>
On 01/17/2012 04:07 PM, Michael Haggerty wrote:
> On 12/14/2011 12:24 AM, Junio C Hamano wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> ... But there are so many calls to the
>>> for_each_ref*() family of functions that I wasn't able to determine
>>> exactly which should allow for extra refs and which shouldn't.
>>
>> Only the ones that follow add_extra_ref() in the control flow.
>>
>> builtin/clone.c adds them in setup_reference() to deal with --reference.
>> The objects known to be complete in these repositories we borrow from
>> need to be marked complete on our end (i.e. clone does not have to fetch)
>> and transport_fetch_refs() that eventually goes to fetch_refs_via_pack()
>> that calls fetch_pack() uses this information. All three for_each_ref()
>> calls in builtin/fetch-pack.c are about "what are the objects that we know
>> are complete?" and needs to pay attention to extra refs.
>>
>> Having said that, I have a slight suspicion that you might be able to
>> eliminate this one in clone. setup_reference() adds the reference
>> repository to the $GIT_DIR/objects/info/alternates, and the fetch logic
>> already knows to account for the refs in alternate repositories via
>> insert_alternate_refs() callchain.
>
> If I comment out the call from add_one_reference() to add_extra_ref()
> then I get a single failure, in t5700:
>
> not ok - 8 fetched no objects
> # ! grep "^want" "$U"
>
> So your suspicion does not seem to be borne out (at least not in the
> naivest form).
>
> Still studying...
I finally had some time to get back to this puzzle. It took me a while
to narrow down the problem, and I still don't understand it entirely.
It seems like Junio should be right that setup_reference() doesn't need
to add the alternate references to extra_refs. Indeed, if I remove the
call to add_extra_ref(), I see the alternate references being added to
ref_list via insert_one_alternate_ref(). However, in the context of
t5700, clone nevertheless sends "want" lines for one of those references
and test 8 fails. Something is screwy.
So how do the extra_refs prevent the "want" lines from being emitted?
It turns out that when the alternate refs *are* added as extra_refs,
then find_common() is not called at all. do_fetch_pack() calls
everything_local(), which returns true, and do_fetch_pack() skips over
the call to find_common().
So ISTM that there are two problems:
First problem: everything_local() seems to be either broken or used
incorrectly. I can't decide which because I don't know what its
semantics are *supposed* to be.
If everything_local() is trying to check that the references are all in
the local repository itself, then it is incorrect for clone to enter
alternates into extra_refs because everything_local() then mistakes them
for local.
If everything_local() is trying to check that the references are in the
local repository plus alternates, then it is incorrect that
everything_local() doesn't consider alternate references in its
determination. My guess is that this is the case, and that something
like the following might be the fix:
> ----------------------------- builtin/fetch-pack.c -----------------------------
> index 9500f35..4257a8d 100644
> @@ -581,6 +581,11 @@ static void filter_refs(struct ref **refs, int nr_match, char **match)
> *refs = newlist;
> }
>
> +static void mark_alternate_complete(const struct ref *ref, void *unused)
> +{
> + mark_complete(NULL, ref->old_sha1, 0, NULL);
> +}
> +
> static int everything_local(struct ref **refs, int nr_match, char **match)
> {
> struct ref *ref;
> @@ -609,6 +614,7 @@ static int everything_local(struct ref **refs, int nr_match, char **match)
>
> if (!args.depth) {
> for_each_ref(mark_complete, NULL);
> + for_each_alternate_ref(mark_alternate_complete, NULL);
> if (cutoff)
> mark_recent_complete_commits(cutoff);
> }
With this patch, then the full test suite passes even if I take out the
code that adds the alternate refs to extra_refs.
Second problem: it seems like the presence of alternate refs is not
suppressing the "want" lines for those refs in all cases. Strangely, in
the case of t5700, adding the two alternate refs to ref_list
insert_one_alternate_ref() causes the "want" line for one of them to be
suppressed, but not for the other.
Specifically: (without the above patch) I commented out the call to
add_extra_ref() in clone.c:add_one_reference(), then ran t5700 through
step 8 then aborted. insert_one_alternate_ref() was called four times:
insert_one_alternate_ref(ccc25a1f9655742174c93f48f616bea8ad0bc6ff)
insert_one_alternate_ref(ccc25a1f9655742174c93f48f616bea8ad0bc6ff)
insert_one_alternate_ref(5355551c5a927a2b6349505ada2da4bb702c0a49)
insert_one_alternate_ref(5355551c5a927a2b6349505ada2da4bb702c0a49)
(The duplication here seems strange.) However, UPLOAD_LOG still
contains "want" lines (2 of them!) for one of the commits:
#S
#E
#S
#S
#E
want 5355551c5a927a2b6349505ada2da4bb702c0a49 multi_ack_detailed
side-band-64k thin-pack ofs-delta
want 5355551c5a927a2b6349505ada2da4bb702c0a49
#E
The "5355551c" object corresponds to refs/remotes/origin/master in the
alternate object store:
$ (cd B; git for-each-ref)
ccc25a1f9655742174c93f48f616bea8ad0bc6ff commit refs/heads/master
5355551c5a927a2b6349505ada2da4bb702c0a49 commit refs/remotes/origin/HEAD
5355551c5a927a2b6349505ada2da4bb702c0a49 commit refs/remotes/origin/master
It seems to me that even in the absence of short-circuiting due to
everything_local() returning true, the presence of the alternate refs
should be suppressing the "want" lines for those references.
I have some patches that seem to work (and get rid of extra_refs
entirely, hurrah!), but I don't want to submit them until I understand
what the correct behavior is *supposed* to be.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Nguyen Thai Ngoc Duy @ 2012-02-10 14:37 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: Git Mailing List
In-Reply-To: <CAA01Csq+zVhRTjGqy1DJGK7o5wByd9ADsSim214T7Vkxmk+ykQ@mail.gmail.com>
On Fri, Feb 10, 2012 at 8:46 PM, Piotr Krukowiecki
<piotr.krukowiecki@gmail.com> wrote:
> On Fri, Feb 10, 2012 at 1:33 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> On Fri, Feb 10, 2012 at 4:42 PM, Piotr Krukowiecki
>> <piotr.krukowiecki@gmail.com> wrote:
>>> Hi,
>>>
>>> I compared stating whole tree vs one small subdirectory, and I
>>> expected that for the subdirectory status will be very very fast.
>>> After all, it has only few files to stat. But it's not fast. Why?
>>
>> Because stat'ing is not the only thing git-status does? In order to
>> find out staged changes, unstaged changes and untracked files, it has
>> to do the equivalence of "git diff --cached", "git diff" and "git
>> ls-files -o". I think copy detection is also enabled, which uses more
>> cycles.
>
> I believe copy detection is not done, neither for tracked nor untracked files.
> Rename detection is done for tracked files. In this case it should not
> matter, as there were no changes to the files.
>
> My point is, that for such small number of small files (55 files and
> 223KB), which had no changes at all, the status took a lot of time (17
> seconds) and doing status on whole repository which has more than
> 2000x files and 10000x data took only 2x more time.
>
> I don't think that the algorithm scales so well, so my guess is that
> 'status' is so inefficient for subdirectories (i.e. the "git status --
> dir" filter does not filter as much as it could).
I think the cost is in $GIT_DIR, not the working directory.
--
Duy
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-10 14:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m339aivn4z.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
>
> > The code that comares lines is based on
> > contrib/diff-highlight/diff-highlight, except that it works with
> > multiline changes too. It also won't highlight lines that are
> > completely different because that would only make the output unreadable.
> > Combined diffs are not supported but a following commit will change it.
>
> I was thinking that if gitweb were to support "diff refinement
> highlighting", it would either use one of *Diff* packages from CPAN,
> or "git diff --word-diff" output.
>
I think highlighting inline and side-by-side diff outputs is
something different from "git diff --word-diff". I find it useful for
people who are used to these diff formats (i.e. me :).
OTOH I'm not against using a dedicated package from CPAN. But I think
my approach is proven to work (I use contrib/diff-highlight as a
filter) and more lightweight (doesn't add another dependency to
gitweb). Moreover, adding support for some Diff package may be done
later, at any moment. It's just a matter of replacing one function
(format_rem_add_line()) with the one that uses Diff.
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-10 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcnftvb5.fsf@alter.siamese.dyndns.org>
On Fri, 10 Feb 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> On Fri, 10 Feb 2012, Junio C Hamano wrote:
>> ...
>>> That still does not answer the fundamental issues I had with the presented
>>> API: why does it take only a single $key (please re-read my "A, B and C"
>>> example), and what does that single $key intersecting with @fill_only have
>>> anything to do with "needs-filling"?
>>
>> project_info_needs_filling() in absence of @fill_only is just a thin
>> wrapper around "!defined $pr->{$key}", it checks for each key if it needs
>> to be filled.
>>
>> It is used like this
>>
>> if (project_info_needs_filled("A", "A, B, C")) {
>> fill A
>> }
>> if (project_info_needs_filled("B", "A, B, C")) {
>> fill B
>> }
>> ...
>>
>>> After all, that 'age' check actually wants to fill 'age' and 'age_string'
>>> in the project. [...]
Thanks for noticing that... though I think more important is that some
further command would mark only 'age_string' as needed, and
fill_project_list_info() wouldn't notice that it needs to run
git_get_last_activity() if it checks only 'age'.
>> It is not as much matter of API, as the use of checks in loop in
>> fill_project_list_info().
>>
>> What is now
>>
>> my (@activity) = git_get_last_activity($pr->{'path'});
>> unless (@activity) {
>> next PROJECT;
>> }
>> ($pr->{'age'}, $pr->{'age_string'}) = @activity;
>>
>> should be
>>
>> if (!defined $pr->{'age'} ||
>> !defined $pr->{'age_string'}) {
>> my (@activity) = git_get_last_activity($pr->{'path'});
>> unless (@activity) {
>> next PROJECT;
>> }
>> ($pr->{'age'}, $pr->{'age_string'}) = @activity;
>> }
>
> Huh? Compare that with what you wrote above "It is used like this". This
> is *NOT* using the API like that. The caller knows it wants both age and
> age-string, and if even one of them is missing, do the work to fill both.
>
> So why isn't the info-needs-filled API not checking _both_ with a single
> call? It is only because you designed the API to accept only a single $key
> instead of list of "here are what I care about".
Passing two lists as parameters is a bit harder and makes for more
complicated API.
So what you mean is that instead of proposed
if (project_info_needs_filled($pr, 'age', @fill_only) ||
project_info_needs_filled($pr, 'age_string', @fill_only) {
it should be
if (project_info_needs_filled($pr, 'age', 'age_string', \@fill_only) {
or
if (project_info_needs_filled($pr, ['age', 'age_string'], @fill_only) {
(with either "..., 'owner', ..." or "..., [ 'owner' ], ..." for single-key
filling), or
if (project_info_needs_filled($pr, ['age', 'age_string'], \@fill_only) {
Is it?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Piotr Krukowiecki @ 2012-02-10 13:46 UTC (permalink / raw)
To: Git Mailing List; +Cc: Nguyen Thai Ngoc Duy
In-Reply-To: <CACsJy8DnqYZ5CdZqbebWS4NS85mfwumyao0abeqDxMXrHhDELA@mail.gmail.com>
On Fri, Feb 10, 2012 at 1:33 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Fri, Feb 10, 2012 at 4:42 PM, Piotr Krukowiecki
> <piotr.krukowiecki@gmail.com> wrote:
>> Hi,
>>
>> I compared stating whole tree vs one small subdirectory, and I
>> expected that for the subdirectory status will be very very fast.
>> After all, it has only few files to stat. But it's not fast. Why?
>
> Because stat'ing is not the only thing git-status does? In order to
> find out staged changes, unstaged changes and untracked files, it has
> to do the equivalence of "git diff --cached", "git diff" and "git
> ls-files -o". I think copy detection is also enabled, which uses more
> cycles.
I believe copy detection is not done, neither for tracked nor untracked files.
Rename detection is done for tracked files. In this case it should not
matter, as there were no changes to the files.
My point is, that for such small number of small files (55 files and
223KB), which had no changes at all, the status took a lot of time (17
seconds) and doing status on whole repository which has more than
2000x files and 10000x data took only 2x more time.
I don't think that the algorithm scales so well, so my guess is that
'status' is so inefficient for subdirectories (i.e. the "git status --
dir" filter does not filter as much as it could).
> Profiling it should give you a good idea what parts cost most.
I'll try that later.
BTW by stating I meant using "status", not that it uses stat() or whatever.
--
Piotr Krukowiecki
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jakub Narebski @ 2012-02-10 13:23 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <1328865494-24415-7-git-send-email-michal.kiedrowicz@gmail.com>
Michał Kiedrowicz <michal.kiedrowicz@gmail.com> writes:
> The code that comares lines is based on
> contrib/diff-highlight/diff-highlight, except that it works with
> multiline changes too. It also won't highlight lines that are
> completely different because that would only make the output unreadable.
> Combined diffs are not supported but a following commit will change it.
I was thinking that if gitweb were to support "diff refinement
highlighting", it would either use one of *Diff* packages from CPAN,
or "git diff --word-diff" output.
--
Jakub Narębski
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Jakub Narebski @ 2012-02-10 13:15 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano,
Дилян Палаузов,
git
In-Reply-To: <CACBZZX45=mr=FMqFF+Pw4KPaDAtvs-ePLbFATpyFA93vSfZatw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 2012/2/10 Junio C Hamano <gitster@pobox.com>:
>> Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
>>> git 1.7.9 makes use of libcharset and /Makefile contains:
> >>
>>> ifdef HAVE_LIBCHARSET_H
>>> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>> endif
>>> ...
>>> and the problem is, that libcharset is not used when linking. To
>>> solve this, please replace the above extract from /Makefile with
>>>
>>> ifdef HAVE_LIBCHARSET_H
>>> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
>>> EXTLIBS += -lcharset
>>> endif
[....]
> I've had some similar (privately sent) bug reports about the i18n
> stuff from someone who built his own Linux distro.
>
> Basically we make assumptions that certain stuff will be in the C
> library on certain platforms, certain headers go with certain
> libraries etc.
>
> Evidently none of this can really be relied upon and we'd have to
> probe for each one if we wanted to make it reliable.
Well, there is always *optional* configure.ac to do detection;
"make configure; ./configure <options>" will generate config.mak.autogen
with appropriate options -- we can add autodetection if -lcharset
must be added.
--
Jakub Narębski
^ permalink raw reply
* Bulgarian translation of git
From: Alexander Shopov (Александър Шопов) @ 2012-02-10 12:26 UTC (permalink / raw)
To: git
Hello,
I am Alexander Shopov and would like to volunteer for the Bulgarian
translation of git po file if no one else is doing this.
How should I contribute it back?
Via this email list, via fork-push from github, or a patch?
Kind regards:
al_shopov
^ permalink raw reply
* Re: [PATCH 3/4] diff --stat: use the real terminal width
From: Nguyen Thai Ngoc Duy @ 2012-02-10 13:00 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <4F34FE9A.7020600@in.waw.pl>
2012/2/10 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>:
>> I tried this in the past and "git log -p" looked ugly on git.git
>> mainly because commit messages are still ~70 char long lines on my 279
>> char wide terminal. If this is project dependent, perhaps a config
>> key? Also the "50" below the changed line, maybe you want to change it
>> to 0.6 * width.
>
>
> Thanks for all the comments. I'll post a newer version, but I have two
> questions:
>
> I agree that making the output very wide with lots of +- is not very
> elegant. (E.g. 8f24a6323ece9be1bf1a04b4b5856112438337f2 has
> builtin/grep.c | 142 +++--------------------------------....--
> which doesn't look right.). So I think it would make sense to limit
> the graph part to something like 50 columns, even if there's more space.
> I believe that git.git would look fine with this change. There are some
> fairly long lines
> (t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master
> is 86 chars) but with 50 columns of graph the output would take 140 columns
> -- with the graph part slightly sticking out from the 80 column
> descriptions, but still not too ugly.
You also need to pay attention, not to exceed term_columns() because
of this dynamic name part. But the idea sounds good to me.
It would be even better if we had some heuristics to shorten
exceptionally long names with ellipsis, to keep the name part from
being overly stretched.
> Should I add a new option --stat-graph-width in analogy to
> --stat-name-width, or should this be hard-coded?
I don't know about other people, but I have no urge to change graph width.
--
Duy
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Nguyen Thai Ngoc Duy @ 2012-02-10 12:33 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: Git Mailing List
In-Reply-To: <CAA01Csr8FbvQ8uFvxX8_6i-hysin6JuaifVVC-yoLyoT0N5F4Q@mail.gmail.com>
On Fri, Feb 10, 2012 at 4:42 PM, Piotr Krukowiecki
<piotr.krukowiecki@gmail.com> wrote:
> Hi,
>
> I compared stating whole tree vs one small subdirectory, and I
> expected that for the subdirectory status will be very very fast.
> After all, it has only few files to stat. But it's not fast. Why?
Because stat'ing is not the only thing git-status does? In order to
find out staged changes, unstaged changes and untracked files, it has
to do the equivalence of "git diff --cached", "git diff" and "git
ls-files -o". I think copy detection is also enabled, which uses more
cycles.
Profiling it should give you a good idea what parts cost most.
--
Duy
^ permalink raw reply
* Re: Git performance results on a large repository
From: Nguyen Thai Ngoc Duy @ 2012-02-10 12:24 UTC (permalink / raw)
To: Christian Couder; +Cc: Joshua Redstone, git@vger.kernel.org
In-Reply-To: <CAP8UFD1RTa6+btjJrsfqjOOoCjebZBqK6xkPN7ZVLM04bHO9yw@mail.gmail.com>
On Fri, Feb 10, 2012 at 4:39 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> Hi,
>
> On Fri, Feb 10, 2012 at 8:12 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>>
>> All these involve unpack_trees(), which is full tree operation. The
>> bigger your worktree is, the slower it is. Another good reason to
>> split unrelated parts into separate repositories.
>
> Maybe having different "views" would be enough to make a smaller
> worktree and history, so that things are much faster for a developper?
>
> (I already suggested "views" based on "git replace" in this thread:
> http://thread.gmane.org/gmane.comp.version-control.git/177146/focus=177639)
That's more or less what I did with the subtree clone series [1] and
ended up doing narrow clone [2]. The only difference between the two
are how to handle partial worktree/index. The former uses git-replace
to seal any holes, the latter tackles at pathspec level and is
generally more elegant.
The worktree part from that work should be usable in full clone too. I
am reviving the series and going to repost it soon. Have a look [3] if
you are interested.
[1] http://thread.gmane.org/gmane.comp.version-control.git/152347
[2] http://thread.gmane.org/gmane.comp.version-control.git/155427
[3] https://github.com/pclouds/git/commits/narrow-clone
--
Duy
^ permalink raw reply
* Re: A note on modern git plus ancient meld ("wrong number of arguments")
From: Sebastian Schuberth @ 2012-02-10 11:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: David Aguilar, Jeff Epler, git, Charles Bailey
In-Reply-To: <20120210082106.GA7871@burratino>
On Fri, Feb 10, 2012 at 09:23, Jonathan Nieder <jrnieder@gmail.com> wrote:
> + meld_version=${meld_version#GNOME }
> + meld_version=${meld_version#* }
Hmm, I might be mistaken, but aren't these string operations
Bash-only? And AFAIK Git is striving for standard sh compatibility ...
--
Sebastian Schuberth
^ 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