* [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 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 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 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
* 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
* 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
* 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: [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
* 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
* 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/3] Move git_version_string to help.c before diff changes
From: Junio C Hamano @ 2012-02-10 17:58 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, pclouds, Michael J Gruber
In-Reply-To: <1328891972-23695-2-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> 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.
But what is wrong about that?
If you are making the termio related code reusable and sharable by turning
the static "term_columns()" in help.o into an external symbol, there is no
reason that termio related function, which is now useful outside the
context of giving help, must stay in help.c where its life happened to
have started. In fact, "tell me how wide the terminal is" does not belong
to something called "help subsystem", no?
Wouldn't a new file, term.c or something, be a lot more suitable home for
the function you will be reusing from diff and other parts of the system?
^ permalink raw reply
* Re: A note on modern git plus ancient meld ("wrong number of arguments")
From: Jonathan Nieder @ 2012-02-10 17:59 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: David Aguilar, Jeff Epler, git, Charles Bailey
In-Reply-To: <CAHGBnuPBDO=tnoDFGOcGz4nZh9O_A803STmj7KALLuhwgf=hCg@mail.gmail.com>
Hi,
Sebastian Schuberth wrote:
> 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 ...
They are widely supported in POSIX-style shells. See [1] and
Documentation/CodingGuidelines:
- We use POSIX compliant parameter substitutions and avoid bashisms;
namely:
- We use ${parameter-word} and its [-=?+] siblings, and their
colon'ed "unset or null" form.
- We use ${parameter#word} and its [#%] siblings, and their
doubled "longest matching" form.
A good way to catch these things is to try with dash or posh, which
are a little less full-featured than bash and ksh.
Thanks for looking it over.
Jonathan
[1] http://pubs.opengroup.org/onlinepubs/9699919799/
Search for "sh -".
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Theodore Tso @ 2012-02-10 18:00 UTC (permalink / raw)
To: Matthieu Moy
Cc: Theodore Tso, Junio C Hamano, Clemens Buchacher, ftpadmin,
Petr Onderka, git
In-Reply-To: <vpqbop6tyj6.fsf@bauges.imag.fr>
On Feb 10, 2012, at 11:59 AM, Matthieu Moy wrote:
>
> 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.
I think that's a great idea.
I used to use that service quite a lot, so I'd be willing to push the tar balls
to kernel.org, since I have PGP key set up for kernel.org uploads (so do
other people, and if someone else wants to do it, I'm happy to let them get
all the glory :-) Most of the infrastructure to do this has been implemented,
except for the part where the tar ball gets unpacked in the correct directory.
This would satisfy the security concerns, and it wouldn't be hard, but it would
require some implementation work. Anyone have some perl hacking time to
take a look at:
git://git.kernel.org/pub/scm/utils/kup/kup.git
… and add a "UNPACK pathanme" to the kup-server file, and work with the
sysadmins at kernel.org to get it reviewed and accepted?
-- Ted
^ permalink raw reply
* git svn problem
From: Serhat Sevki Dincer @ 2012-02-10 18:15 UTC (permalink / raw)
To: git
Hi,
I am using git-svn (1.7.4.1-3 on ubuntu) to get a project. It has two
svn repositories, apparently disjoint. First half is at
http://svn.plone.org/svn/plone/plone.app.locales, and the continuation
at http://svn.plone.org/svn/collective/plone.app.locales
How can i get a nice linear git-svn repository? the second one is the
new location of the project. I am only interested in the trunks btw.
Thanks..
^ 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 18:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uq2shwg.fsf@alter.siamese.dyndns.org>
On Fri, 10 Feb 2012, Junio C Hamano wrote:
> 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?
No, the above example callsite says "Do I need to fill either 'age' or
'age_string'", and is followed by actually filling this info.
Currently the code flow WRT. project information goes like this:
git_get_projects_list()
# this fills some of project info; what is filled depends on whether
# $projects_list is a file with list of project or directory to scan
filter_forks_from_projects_list()
# this does not use project info
fill_project_list_info()
# this fills all the rest of project info on reduced list
search_projects_list(<search data>)
# this uses some of project info
After 2/5 the code goes like this:
git_get_projects_list()
# this fills some of project info; what is filled depends on whether
# $projects_list is a file with list of project or directory to scan
filter_forks_from_projects_list()
# this does not use project info
fill_project_list_info(<search data>)
# this fills the rest of project info required for search on reduced list
search_projects_list(<search data>)
# this uses some of project info
fill_project_list_info()
# this fills all the rest of project info on further reduced list
If @fill_only is empty, it means for fill_project_list_info to fill
all the data, if it is not empty it means that those fields needs to
be filled.
The code of fill_project_list_info goes like this
if (do we need to fill 'age' or 'age_string'?) {
fill 'age' and 'age_string'
}
if (do we need to fill 'desc_long' or 'descr'?) {
fill 'descr_long' and 'descr'
}
if (we are interested in 'ctags' &&
do we need to fill 'ctags'?) {
fill 'ctags'
}
...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 0/3 v2] diff --stat: use the real terminal width
From: Junio C Hamano @ 2012-02-10 18:24 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, pclouds, Michael J Gruber
In-Reply-To: <1328891972-23695-1-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> - style fixes
I think I still saw at least one malformatted multi-line comments in this
round, though (I stopped looking after I saw one, so there may be others).
> - 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
Hmm.
This is what we have in the documentation.
--stat[=<width>[,<name-width>[,<count>]]]::
Generate a diffstat. You can override the default
output width for 80-column terminal by `--stat=<width>`.
The width of the filename part can be controlled by
giving another width to it separated by a comma.
Naïvely, one would expect that a "use the real terminal width" series
would be only to learn the width of the terminal and tweak its hardcoded
default "80" to that width, and change nothing else, leaving the default
for name-width to "50", which still can be overridable if needed.
But the reason somebody wants to have a wider width is more often not
because they want to see longer bars, but because they want to see long
names without truncation, so in retrospect, the order the "--stat=" option
takes its values is inconvenient. Users would more often want to tinker
with name-width than width because the latter can be auto-detected.
Which is a bit unfortunate.
In any case, the above needs to be updated to describe what the updated
logic does. Do you have documentation updates in the series?
Judging from what you wrote in the above, the updated logic is, instead of
the "naïve" version:
- auto-detect, if possible, to set the default "width" to COLUMNS instead
of hardcoded 80; and
- instead of using hardcoded 50, use width-40 as the default as the
default "name-width".
But if that is what is going on, shouldn't your "40" be "30" to retain
backward compatibility for people who work on 80-column terminals?
Or is there something more complex going on that you are not describing
here?
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Junio C Hamano @ 2012-02-10 18:35 UTC (permalink / raw)
To: Дилян Палаузов
Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <4F34EF9D.8030509@aegee.org>
Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
>>> What I am wondering is there are systems that need to include the header,
>>> but locale_charset() does not live in /lib/libcharset.a, in which case we
>>> cannot make HAVE_LIBCHARSET_H imply use of -lcharset.
>
> I do not understand this. If you want to use a function from
> libcharset, you have to use both #include <libcharset.h> and
> -lcharset.
You are mistaken.
The only constraint is that you have to "#include <libcharset.h>" and need
to link with the library that has locale_charset() defined. Does everybody
has that function in -lcharset, or a system you do not know have it in some
other library?
For example, Msysgit part defines HAVE_LIBCHARSET_H but it apparently does
not need -lcharset. It could be that the port is incomplete, but another
possibility is that perhaps the function is in part of libc and does not
even need -lcharset passed to the linker.
If you look at our Makefile, you see "On this platform foo() can be
obtained by linking with -lfoo, but on this other platform you need to
link with -lbar" gotchas around some libraries (e.g. ssl/crypto), and I am
wondering if this function has a similar issue.
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Konstantin Ryabitsev @ 2012-02-10 18:55 UTC (permalink / raw)
To: Theodore Tso
Cc: Matthieu Moy, Junio C Hamano, Clemens Buchacher, ftpadmin,
Petr Onderka, git
In-Reply-To: <FC56A942-EE70-48B7-A2D3-CF53A189A55E@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]
On Fri, 2012-02-10 at 13:00 -0500, Theodore Tso wrote:
> This would satisfy the security concerns, and it wouldn't be hard, but it would
> require some implementation work. Anyone have some perl hacking time to
> take a look at:
>
> git://git.kernel.org/pub/scm/utils/kup/kup.git
>
> … and add a "UNPACK pathanme" to the kup-server file, and work with the
> sysadmins at kernel.org to get it reviewed and accepted?
I have a few comments off the top of my head:
1. "kup rm" will need to be modified, as it currently only allows
deleting things that have a matching signature. The alternative
is for UNPACK to create a foo.tar.manifest file that will be
consulted upon "kup rm" to clean up any unpacked contents upon
the deletion of the source archive. Note, that there are many,
many gotchas with this solution -- e.g. .manifest should
probably contain checksums, too, as there are bound to be
conditions when two tarballs reference the same files, and you
want to make sure that you delete files matching the contents of
the old tarball, not the newer one, etc.
2. I would suggest that UNPACK ignores any directory structure in
the archive, and only copies over files matching a restricted
set of extensions (.html, .txt, .jpg, .png) into the same dir as
the original tarball. Basically, untar into a temporary
directory, then find any files matching the above set of
extensions, copy them into another temporary location, force
permissions to 0644, and then move them into the final "live"
location in the same dir with the tarball (with the
corresponding .manifest, if that solution used). There should be
logic to make sure that we never overwrite any files that have a
matching .sign file.
3. There should be some support to ensure that the unpack process
is terminated if unpacked content size reaches a certain limit,
or if it is taking too long to complete.
Best regards,
--
Konstantin Ryabitsev
Systems Administrator, Kernel.org
Montréal, Québec
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 665 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-10 18:55 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, gitster, peff
In-Reply-To: <CACsJy8DVXCLb50Vd0fTU+yNP2q7Gkcr88muHuzxq1jhfJW5Q9w@mail.gmail.com>
On Fri, Feb 10, 2012 at 01:34:26PM +0700, Nguyen Thai Ngoc Duy wrote:
>On Fri, Feb 10, 2012 at 2:43 AM, Tom Grennan <tmgrennan@gmail.com> wrote:
>> Please see the following patch which filters the tag list of "!" prefaced
>> patterns. If this is deemed desirable and correct, I'll resubmit with updated
>> documentation and unit tests.
>
>git-branch, git-tag and git-for-each-ref are in the same family. I
>think it's good to that all three commands share things, like this
>pattern matching.
Yes, git-branch and git-tag could now use a common match_patterns() but
git-for-each-ref needs some rearranging; as will: git-describe,
git-replace, git-ls-remote, git-name-rev, and git-show-branch.
If we pursue this, it may be best to first add match_patterns() to ./refs.[ch]
then incrementally modify these builtin commands to use it.
>About the '!' for exclusion, maybe it's better to move from fnmatch()
>as matching machinery to pathspec. Then when git learns negative
>pathspec [1], we have this feature for free.
>
>[1] http://thread.gmane.org/gmane.comp.version-control.git/189645/focus=190072
I have to study this more. I'm not sure that --exclude has precedence
over matches. It also looks like this would require a lot more change to
the above.
Thanks,
TomG
^ permalink raw reply
* Re: [PATCH] Remove empty ref directories while reading loose refs
From: Junio C Hamano @ 2012-02-10 19:09 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Michael Haggerty
In-Reply-To: <1328891127-17150-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> 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.
That reads as a very poorly phrased excuse for not solving the problem at
the right location. Compared to all the codepaths that want to resolve
ref, delete_ref() is run much less often, and it is where the problem you
are solving (i.e. directories that have just become unnecessary are not
removed) originates, no?
Wouldn't it be just the matter of replacing two unlink_or_warn() calls in
delete_ref(), one for cleaning refs/ hierarchy and the other for cleaning
logs/ hierarcy, with a new helper that calls unlink_or_warn() and then
tries rmdir going upwards until it hits the limit, perhaps using a helper
function that refactors dir.c::remove_path() that takes an extra parameter
telling it where to stop?
^ permalink raw reply
* Re: [RFD] Rewriting safety - warn before/when rewriting published history
From: Jakub Narebski @ 2012-02-10 19:38 UTC (permalink / raw)
To: Johan Herland; +Cc: Philip Oakley, git
In-Reply-To: <CALKQrge821x7OoSekkWw7vUjP642jhbE0D9oWPcCxuuTXOqQHA@mail.gmail.com>
On Tue, 7 Feb 2012, Johan Herland wrote:
> (we are pretty much in violent agreement, so I will only comment where
> I find it necessary)
So now comes the hard part: actually implementing (well, designing and
implementing) prototypes for 'secret' trait and 'public' trait...
> On Tue, Feb 7, 2012 at 15:31, Jakub Narebski <jnareb@gmail.com> wrote:
> > Also, when thinking about different scenarios of why one would like to
> > mark commit as 'secret', we might want to be able to mark commit as
> > secret / unpublishable with respect to _subset_ of remotes, so e.g.
> > I am prevented from accidentally publishing commits marked as 'secret'
> > to public repository, or to CI/QA repository, but I can push (perhaps
> > with warning) to group repository, together with 'secret'-ness state
> > of said commit...
> >
> > ... though it wouldn't be as much 'secret' as 'confidential' ;-)
>
> Another way to achieve this would be to have a config flag to control
> whether Git checks for the 'secret' flag before pushing. This config
> flag could be set at the system/user level (to enable/disable the
> feature as a whole), at the repo level (to enable/disable it in a
> given repo), at the remote level (to enable/disable it on a given
> repo), and finally at the branch level (to enable-disable it for a
> given branch (and its upstream)). Thus you could have a .git/config
> that looked like this:
>
> [core]
> refusePushSecret = true
>
> [remote "foo"]
> refusePushSecret = false
> url = ...
> fetch = ...
>
> [branch "baz"]
> remote = foo
> merge = refs/heads/baz
> refusePushSecret = true
>
> This config would:
>
> - refuse to push 'secret' commits from branch 'baz'
> (branch.baz.refusePushSecret == true)
>
> - but allow to push other branches with 'secret' commits to remote
> 'foo' (remote.foo.refusePushSecret == false)
>
> - but refuse to push 'secret' commits to other remotes
> (core.refusePushSecret == true)
>
> (The order of precedence would be: branch config > remote config >
> repo config > user config > system config > default when unset)
You read my mind.
> I am unsure whether the 'secret'-ness of a commit should follow across
> the push, but if you do (assuming we store the 'secret' flag using
> git-notes) this is simply a matter of synchronizing the
> refs/notes/secret to the same remote.
I think it should, so that 'secret' commit would not escape by accident
via a group secret repository.
What makes it hard (I think) is that we would prefer to transfer
'secret'-ness only for pushed commits. That might be problem for notes
based implementation of 'secret' annotation and 'secret'-ness transfer...
though I guess knowing that there exist 'secret' commit with given SHA1
which we do not have and should not have is not much breach of
confidentiality. Still...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: how to determine oldest supported version of git
From: Junio C Hamano @ 2012-02-10 19:42 UTC (permalink / raw)
To: git; +Cc: Neal Kreitzinger
In-Reply-To: <7v8vkktt6y.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Neal Kreitzinger" <neal@rsss.com> writes:
>
>> What is the best way for me (a git user) to determine what is currently
>> the oldest supported version of git (the oldest version still getting
>> bugfixes)? IOW, when can I tell that my version of git is no longer
>> supported?
>
> "A note from the maintainer" only promises that the latest major release
> (as of this writing, 1.7.9) gets regular maintenance releases until the
> next major release happens.
>
> When queuing a fix to an old bug, however, I try to build a topic branch
> for that fix from as old an release as practical, in order to make sure
> that older maintenance tracks could benefit, and I do give updates for
> older maintenance tracks when able (but no promises).
> ...
> One cycle of major release development is expected to last between 8 to 10
> weeks, so keeping two stale maintenance tracks in addition to the latest
> maintenance track alive would roughly translate to 6 months shelf life for
> an ancient release.
Having said all that, I am starting to doubt what the point of all
this is.
Maybe I am being slow to come to this realization after having done this
for all these years, but Git is not like the Linux kernel, where hundreds
of companies maintain their own internal forks, e.g. out of tree drivers,
filesystem tweaks or scheduler tweaks, all tied to a specific version of
the internal API that is a rapidly moving target and cannot afford to
adjust to the bleeding edge. Also our strict no regression policy means
that it is not like an option --foo in one version of Git changes its
meaning from X to Y across version boundaries, and even if on rare
occasions we need to introduce incompatibilities to improve the system, we
give enough advance warning and execute careful migration plans to ensure
that third-parties can keep up, and the "fix at the oldest branch and
merge upwards" policy means fixes to important bugs will be in all the
maintenance tracks, including the 'master' version.
So in practical terms, once 1.7.9 is out, there is *no* practical reason
for anybody to use 1.7.8.x or anything older. The only two things people
are gaining by sticking to an older version are that (1) they do not have
a way to use new features, and that (2) they get fixes that are less
rigorously tested, because the testing happens mostly in the context of
the 'next' branch and then subsequently in the 'master' branch, and fixes
cooked in these two contexts may have unintended consequences that will
never be discovered until they are merged down to the older maintenance
tracks.
If we only released the feature releases without _any_ maintenance
releases, distros no longer have an excuse to stick to older maintenance
tracks ("For the upcoming Zesty Zebra LTS, Git will stay at 1.7.7.x and
never updated to any newer major version.") This in turn removes the need
for the third-party tools that support wider Git ecosystem to worry about
their users who are kept on very stale versions of Git by distros, because
any reasonably maintained distro will not pin their users to an ancient
version of Git. If we can change the distro's idea of what constitutes a
release of Git that is on a single maintenance track from the current
"1.7.7.3 and newer, but not anything that does not begin with 1.7.7." to
"1.7.9 and newer, but not anything that does not begin with 1.7.", that
would be a major win, I would imagine.
And dropping the maintenance tracks for older major releases may be a good
first step in that right direction.
With that in mind, the real answer to the original question in this thread
may be "the oldest supported version is the current one. stay at the
latest major release, in other words, do not even ask that question".
Thoughts?
^ 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 19:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202101917.52908.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> If @fill_only is empty, it means for fill_project_list_info to fill
> all the data, if it is not empty it means that those fields needs to
> be filled.
That is exactly what I am questioning. Do you need "I need all these
fields to be present" and "I will fill these other fields" (which is what
@fill_only is about, no?) that is different from the former?
> The code of fill_project_list_info goes like this
>
> if (do we need to fill 'age' or 'age_string'?) {
> fill 'age' and 'age_string'
> }
> if (do we need to fill 'desc_long' or 'descr'?) {
> fill 'descr_long' and 'descr'
> }
> if (we are interested in 'ctags' &&
> do we need to fill 'ctags'?) {
> fill 'ctags'
> }
> ...
Exactly. Why do you need @fill_only at all? If you are interested in
ctags and you want to make sure ctags is available, the question you want
to ask the helper function is "Does the project structure already have
ctags field?". Why does the helper function needs to know anything else?
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Junio C Hamano @ 2012-02-10 19:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Clemens Buchacher, ftpadmin, Petr Onderka, git
In-Reply-To: <vpqbop6tyj6.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 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?
It would probably be possible, but I do not have that much time and
patience to sign 600+ files in the preformatted HTML tree one-by-one and
upload them using kup.
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Dilyan Palauzov @ 2012-02-10 19:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vipjer0yn.fsf@alter.siamese.dyndns.org>
Hello,
on my system locale_charset is included in libiconv as local symbol
and thus linking with -liconv is not sufficient.
nm /usr/lib64/libiconv.so.2.5.1 | grep locale
0000000000012694 t locale_charset
whereas in libcharset the symbol is global:
nm /usr/lib64/libcharset.so.1 |grep locale
0000000000000c50 T locale_charset
looking at libiconv-1.4/lib/Makefile.in there is written
SOURCES = $(srcdir)/iconv.c $(srcdir)/../libcharset/lib/localcharset.c
$(srcdir)/relocatable.c
OBJECTS = iconv.lo localcharset.lo relocatable.lo
$(OBJECTS_EXP_@WOE32DLL@) $(OBJECTS_RES_@WOE32@)
libiconv.la : $(OBJECTS)
$(LIBTOOL_LINK) $(CC) $(LDFLAGS) $(CFLAGS) -o libiconv.la
-rpath $(libdir) -version-info $(LIBICONV_VERSION_INFO) -no-undefined
$(OBJECTS)
this means, that libiconv.la includes $(OBJECTS) and thus
libiconv-1.4/libcharset/lib/localecharset.c .
In libiconv-1.4/libcharset/lib/localecharset.c is written
#ifdef STATIC
STATIC
#endif
const char *
locale_charset (void) { ...}
and the preliminary localcharset.o still has locale_charset as global symbol:
libiconv-1.14/lib/.libs # nm localcharset.o |grep locale
0000000000000000 T locale_charset
Digging further, in libiconv-1.4/include/iconv.h some functions are
prefixed with LIBICONV_DLL_EXPORTED , which is the same as
#define LIBICONV_DLL_EXPORTED
__attribute__((__visibility__("default"))) , all the rest including
locale_charset is compiled with
__attribute__((__visibility__("hidden"))), and hence locale_charset is
not exported from libiconv.
Greetings
Dilian
----- Message from Дилян Палаузов <dilyan.palauzov@aegee.org> ---------
Date: Fri, 10 Feb 2012 02:29:24 +0100
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
Subject: 1.7.9, libcharset missing from EXTLIBS
To: git@vger.kernel.org
> Hello,
>
> git 1.7.9 makes use of libcharset and /Makefile contains:
>
> ifdef HAVE_LIBCHARSET_H
> BASIC_CFLAGS += -DHAVE_LIBCHARSET_H
> endif
>
> when building git-daemon., the compiler reports
> make V=1
> cc -I. -DUSE_LIBPCRE -pthread -DHAVE_PATHS_H -DHAVE_LIBCHARSET_H
> -DHAVE_DEV_TTY -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o
> git-daemon -L/usr/lib64 -L/lib64 daemon.o libgit.a xdiff/lib.a
> -lpcre -lz -liconv -lcrypto -pthread
> /tmp/ccvPEthi.ltrans0.ltrans.o: In function `main':
> ccvPEthi.ltrans0.o:(.text.startup+0x59): undefined reference to
> `locale_charset'
> collect2: ld returned 1 exit status
> make: *** [git-daemon] Error 1
>
>
> 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
>
> Със здраве
> Дилян
----- End message from Дилян Палаузов <dilyan.palauzov@aegee.org> -----
^ 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