* Re: What's cooking in git.git (Jan 2012, #08; Tue, 31)
From: Junio C Hamano @ 2012-02-10 4:09 UTC (permalink / raw)
To: git; +Cc: tbushnell, tytso, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vsjijs9rq.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> It turns out that this series, as a side effect, fixes a long-standing bug
> that the --branch option cannot be used with the --mirror option.
>
> I am tempted to merge it also to 1.7.9.1 maintenance track. The issue is
> minor (you can always clone with --mirror and then switch the branch with
> "checkout") and it does not look like it warrants further backpointing to
> 1.7.8 and older releases, though.
>
> Comments and/or objections?
Replying to myself.
Regardless of "'refs/heads/$branch' is not found because we do not look
for in the right place" issue, shouldn't the use of the --mirror without
the --bare option forbidden or at least warned about?
Cloning as --mirror, with a working tree with a current branch, would mean
the next fetch would directly try to update it by overwriting. We do pass
the --update-head-ok from pull, so "git pull" in such a repository should
be "sort of" safe, as long as the repository is never used to create its
own commits on whatever local branches set to be overwritten by --mirror,
but still I have this gut feeling that such an arrangement should at least
be discouraged.
Comments and/or opinions?
^ permalink raw reply
* Re: Git, Builds, and Filesystem Type
From: Hilco Wijbenga @ 2012-02-10 4:04 UTC (permalink / raw)
To: Martin Fick; +Cc: Git Users
In-Reply-To: <14de0389-6497-4e74-baa5-129b0c1560a3@email.android.com>
On 9 February 2012 18:08, Martin Fick <mfick@codeaurora.org> wrote:
>>That would be quite
>>tricky. I have a group of some 60 projects, each with their own
>>"target" directory which would have to be mounted on tmpfs. And the
>>"target" directory is created by Maven, not by me. Not to mention that
>>I shut down my computer at the end of the day. :-)
>
> Sounds like a laptop? Hibernate?
No, a regular desktop that I shut down every night. It makes quite a
bit of noise and I would rather not waste power.
>>I think I would prefer a somewhat more persistent solution. I
>>certainly have enough space for a very big swap partition. So the
>>whole of ~/my-project would fit on tmpfs. I'm just not sure about
>>making it persistent at the end of the day.
>
> Link your .git dir to a persistent location.
I don't think that would help all that much. I would still lose
anything I had not committed or stashed. And I would still have to
rebuild every day.
Perhaps something together with unionfs? I'll think about it.
^ permalink raw reply
* Re: [PATCH 2/2] ctype: implement islower/isupper macro
From: Junio C Hamano @ 2012-02-10 4:03 UTC (permalink / raw)
To: 김남형; +Cc: git
In-Reply-To: <4F3481CD.5010303@lge.com>
김남형 <namhyung.kim@lge.com> writes:
> 2012-02-10 11:17 AM, Junio C Hamano wrote:
>> Namhyung Kim <namhyung.kim@lge.com> writes:
>>
>>> The git-compat-util.h provides various ctype macros but lacks those two
>>> (along with others). Add them.
>>
>> Isn't that because we do not use them ourselves? Uses in compat/ do not
>> count, and judging from the way it is used in compat/fnmatch/fnmatch.c,
>> the implementation of sane_iscase() might be overly protective.
>>
>> What problem are you trying to solve?
>
> There's no problem. In fact, these patches come from perf as it uses a
> copy of git code in this part.
Kim-ssi, the above is something I would have like to see in your first
message.
> If you don't
> think it's worth applying I'm fine with dropping it.
I never said these patches are worthless.
I just was wondering what the motivation behind them were. If you are
involved in maintaining Perf, and if it wants to keep its own forked copy
as close as ours, that is a good enough justification, as long as the
additions we do not use ourselves is still reasonably done.
^ permalink raw reply
* Re: nested git repos (not submodules)
From: Andrew Ardill @ 2012-02-10 3:47 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <jh1vo3$7af$1@dough.gmane.org>
> Thanks in advance for any feedback.
My understanding was that such a configuration is essentially tracking
the same set of files in two different git repositories. The location
of the .git is not important, I could just as easily set the working
directory of any git repository to be a folder tracked by another
repository.
My concerns would be based primarily on the different repositories
trying to act on the same files at the same time. Ignoring the
sub-folder completely within the encompassing repository would avoid
that, however you might have use cases that prohibit that.
Out of interest, what itch are you scratching by using this model?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: A note on modern git plus ancient meld ("wrong number of arguments")
From: David Aguilar @ 2012-02-10 2:42 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <20120209191742.GA20703@unpythonic.net>
On Thu, Feb 9, 2012 at 11:17 AM, Jeff Epler <jepler@unpythonic.net> wrote:
> I note this just in case it helps someone else track down a similar
> problem, not because I think any change needs to be made to git, as a
> version of meld new enough to not be affected by this problem is 5 years
> old.
>
> At $DAYJOB, I recently encountered a problem after upgrading from (don't
> laugh) git 1.7.1 to 1.7.8.3: one developer stated that meld failed to
> run, instead displaying the error 'Wrong number of arguments (Got 5)'.
>
> We determined that this user was running a very old version of meld
> (1.1.1) from his home directory, as opposed to the also very old system
> version of meld (1.1.5). It turns out that the check added in
> f61bd9c mergetools/meld: Use '--output' when available
> fails on meld 1.1.1, leading git to incorrectly believe the --output
> flag is supporrted:
> $ meld-1.1.1 --output /dev/null --help >/dev/null 2>&1; echo $?
> 0 # i.e., detected as supported
> The test as written gives the correct ("not supported") result with meld
> 1.1.5:
> $ meld-1.1.5 --output /dev/null --help >/dev/null 2>&1; echo $?
> 2 # i.e., detected as supported
>
> so if you encounter the message 'Wrong number of arguments (Got 5)' from
> meld, then check whether you have an ancient version of meld. If for
> some reason you can't upgrade to at least 1.1.5, maybe you'd find the
> following configuration flags useful:
> [merge]
> tool = ancientmeld
> [mergetool "ancientmeld"]
> cmd = meld-1.1.1 \"$LOCAL\" \"$MERGED\" \"$REMOTE\"
We originally used the --output test so that we wouldn't have to check
for a specific version. Does your meld support `meld --version`, and
what does it output?
I'm thinking that maybe we should just try and parse the version
number since it seems like we cannot depend on ancient meld's return
code.
Thanks Jeff. I'll see what we can do about it.
--
David
^ permalink raw reply
* nested git repos (not submodules)
From: Neal Kreitzinger @ 2012-02-10 2:34 UTC (permalink / raw)
To: git
In the worktree of a particular git repo, the user has made a subdir
(worktree/subdir) of the worktree (worktree/.git) its own repo
(worktree/subdir/.git). Is there a danger of worktree/.git and
worktree/subdir/.git crossing wires? Are literally nested git repos (whose
worktrees are in turn tracked as subdirs by upper-level git repo(s)) a
supported/valid model in regards to git.git (NOT git-addons)?
Symptomatically, I have observed the following so far:
(1) worktree/.git is "ignoring" (or unaware of) worktree/subdir/.git because
it is treating subdir/ as if subdir/.git wasn't there and is not listing
subdir/.git as untracked. I'm not sure if this is an unintended side-effect
of git ignoring .git(s) automatically, or if having subdir/.git's (w/out
having them defined as submodules) is an expected
(reasonable/sane/recommended) model for git.git users.
(2) running git commands with pwd=worktree/subdir/ acts upon
worktree/subdir/.git (subdir/ is regarded as the toplevel of subdir/.git as
opposed to a subdir of worktree/.git) and is seemingly oblivious to
worktree.git.
I suspect submodules is the "correct" way to implement the effect of nested
git repos. That being said, this literal nested git repo is a temporary
band-aid and I don't expect it to be propogated, but I do have to deal
(react) with it in the meantime. I'm thinking I can manage that and deal
with annoyances as they arise, unless there are any unseen landmines I'm not
aware of. Please advise.
(I also wouldn't be surprised to hear that this is exactly how submodules
really first started in theory or practice.)
Thanks in advance for any feedback.
v/r,
neal
^ permalink raw reply
* Re: [PATCH 2/2] ctype: implement islower/isupper macro
From: 김남형 @ 2012-02-10 2:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwr7vsa8j.fsf@alter.siamese.dyndns.org>
Hello,
2012-02-10 11:17 AM, Junio C Hamano wrote:
> Namhyung Kim <namhyung.kim@lge.com> writes:
>
>> The git-compat-util.h provides various ctype macros but lacks those two
>> (along with others). Add them.
>
> Isn't that because we do not use them ourselves? Uses in compat/ do not
> count, and judging from the way it is used in compat/fnmatch/fnmatch.c,
> the implementation of sane_iscase() might be overly protective.
>
> What problem are you trying to solve?
>
There's no problem. In fact, these patches come from perf as it uses a copy of
git code in this part. So I didn't check it's really needed for git too, but
just hoped it'd be helpful someday. If you don't think it's worth applying I'm
fine with dropping it.
Thanks,
Namhyung
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #08; Tue, 31)
From: Junio C Hamano @ 2012-02-10 2:27 UTC (permalink / raw)
To: git; +Cc: tbushnell, tytso, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vlion3tr5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> What's cooking in git.git (Jan 2012, #08; Tue, 31)
> --------------------------------------------------
> ...
> [Graduated to "master"]
>
> * nd/clone-detached (2012-01-24) 12 commits
> (merged to 'next' on 2012-01-26 at 7b0cc8a)
> + clone: fix up delay cloning conditions
> (merged to 'next' on 2012-01-23 at bee31c6)
> + push: do not let configured foreign-vcs permanently clobbered
> (merged to 'next' on 2012-01-23 at 9cab64e)
> + clone: print advice on checking out detached HEAD
> + clone: allow --branch to take a tag
> + clone: refuse to clone if --branch points to bogus ref
> + clone: --branch=<branch> always means refs/heads/<branch>
> + clone: delay cloning until after remote HEAD checking
> + clone: factor out remote ref writing
> + clone: factor out HEAD update code
> + clone: factor out checkout code
> + clone: write detached HEAD in bare repositories
> + t5601: add missing && cascade
>
> "git clone" learned to detach the HEAD in the resulting repository when
> the source repository's HEAD does not point to a branch.
It turns out that this series, as a side effect, fixes a long-standing bug
that the --branch option cannot be used with the --mirror option.
I am tempted to merge it also to 1.7.9.1 maintenance track. The issue is
minor (you can always clone with --mirror and then switch the branch with
"checkout") and it does not look like it warrants further backpointing to
1.7.8 and older releases, though.
Comments and/or objections?
^ permalink raw reply
* Re: fatal: Unable to find remote helper for 'https'
From: David Barr @ 2012-02-10 2:25 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Nickolai Leschov, git
In-Reply-To: <CALUzUxq=5iJJNcXH-Xg1htZzGFVT4f5WQS=dy4k7Y_mRemXMSw@mail.gmail.com>
On Fri, Feb 10, 2012 at 11:25 AM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Have you installed libcurl4-(gnutls|openssl)-dev? You'll need to
> choose between gnutls and openssl for the underlying ssl
> implementation.
>
> --
> Cheers,
> Ray Chuan
>
>
> On Fri, Feb 10, 2012 at 5:51 AM, Nickolai Leschov <nleschov@gmail.com> wrote:
>> Hello,
>>
>> I have compiled git 1.7.9 from source on Ubuntu 9.04 and I get the following
>> message when cloning a git repo:
>>
>> fatal: Unable to find remote helper for 'https'
>>
>> I get this message when I try to use https; or similar one for http. Only
>> cloning via git:// protocol works. My system is Ubuntu 9.04 i386. git 1.7.9 and
>> two previous versions I tried all exhibit this problem. I have uninstalled the
>> git that comes in Ubuntu repositories and build from source instead because I
>> need a newer version.
>>
>> How can I make git work on that system?
>>
>> I have another system with Ubuntu 11.04 i386 and it there git 1.7.4.1 (from
>> repositories) doesn't exhibit such problem.
>>
>> Best regards,
>>
>> Nickolai Leschov
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
You might be interested in the git PPA:
https://launchpad.net/~git-core/+archive/ppa
I noticed that there is no Jaunty package for git 1.7.9, so I asked
the maintainer about it.
"Jaunty is long past EOL, and I don't think the PPA builders still
work with it. You can try the hardy or lucid builds."
- andersk
--
Hope this helps,
David Barr
^ permalink raw reply
* Re: [PATCH 2/2] ctype: implement islower/isupper macro
From: Junio C Hamano @ 2012-02-10 2:17 UTC (permalink / raw)
To: Namhyung Kim; +Cc: git
In-Reply-To: <1328840011-19028-2-git-send-email-namhyung.kim@lge.com>
Namhyung Kim <namhyung.kim@lge.com> writes:
> The git-compat-util.h provides various ctype macros but lacks those two
> (along with others). Add them.
Isn't that because we do not use them ourselves? Uses in compat/ do not
count, and judging from the way it is used in compat/fnmatch/fnmatch.c,
the implementation of sane_iscase() might be overly protective.
What problem are you trying to solve?
^ permalink raw reply
* Re: 1.7.9, libcharset missing from EXTLIBS
From: Junio C Hamano @ 2012-02-10 2:13 UTC (permalink / raw)
To: Дилян Палаузов
Cc: git
In-Reply-To: <4F3472F4.4060605@aegee.org>
Дилян Палаузов <dilyan.palauzov@aegee.org> writes:
> Hello,
>
> 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
Thanks.
What platform is this? Is there a guarantee that any and all system that
use "#include <libcharset.h>" has to link with "-lcharset"?
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.
^ permalink raw reply
* [PATCH 2/2] ctype: implement islower/isupper macro
From: Namhyung Kim @ 2012-02-10 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1328840011-19028-1-git-send-email-namhyung.kim@lge.com>
The git-compat-util.h provides various ctype macros but lacks those two
(along with others). Add them.
Signed-off-by: Namhyung Kim <namhyung.kim@lge.com>
---
git-compat-util.h | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 8f3972c..d3f8f17 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -463,6 +463,8 @@ static inline int has_extension(const char *filename, const char *ext)
#undef isdigit
#undef isalpha
#undef isalnum
+#undef islower
+#undef isupper
#undef tolower
#undef toupper
extern unsigned char sane_ctype[256];
@@ -478,6 +480,8 @@ extern unsigned char sane_ctype[256];
#define isdigit(x) sane_istest(x,GIT_DIGIT)
#define isalpha(x) sane_istest(x,GIT_ALPHA)
#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
+#define islower(x) sane_iscase(x, 1)
+#define isupper(x) sane_iscase(x, 0)
#define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL | GIT_REGEX_SPECIAL)
#define tolower(x) sane_case((unsigned char)(x), 0x20)
@@ -491,6 +495,17 @@ static inline int sane_case(int x, int high)
return x;
}
+static inline int sane_iscase(int x, int lower)
+{
+ if (!sane_istest(x, GIT_ALPHA))
+ return 0;
+
+ if (lower)
+ return (x & 0x20) != 0;
+ else
+ return (x & 0x20) == 0;
+}
+
static inline int strtoul_ui(char const *s, int base, unsigned int *result)
{
unsigned long ul;
--
1.7.9
^ permalink raw reply related
* [PATCH 1/2] ctype.c only wants git-compat-util.h
From: Namhyung Kim @ 2012-02-10 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The implementation of sane ctype macros only depends on symbols in
git-compat-util.h not cache.h
Signed-off-by: Namhyung Kim <namhyung.kim@lge.com>
---
ctype.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ctype.c b/ctype.c
index b5d856f..af722f9 100644
--- a/ctype.c
+++ b/ctype.c
@@ -3,7 +3,7 @@
*
* No surprises, and works with signed and unsigned chars.
*/
-#include "cache.h"
+#include "git-compat-util.h"
enum {
S = GIT_SPACE,
--
1.7.9
^ permalink raw reply related
* Re: Git, Builds, and Filesystem Type
From: Martin Fick @ 2012-02-10 2:08 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi1O10XeROv+sQRwAAVQ0PneMZTOaEfny-Oz2Sp+=z+aiA@mail.gmail.com>
>I found [1]. Is that sort of what you had in mind
yes
>That would be quite
>tricky. I have a group of some 60 projects, each with their own
>"target" directory which would have to be mounted on tmpfs. And the
>"target" directory is created by Maven, not by me. Not to mention that
>I shut down my computer at the end of the day. :-)
Sounds like a laptop? Hibernate?
>I think I would prefer a somewhat more persistent solution. I
>certainly have enough space for a very big swap partition. So the
>whole of ~/my-project would fit on tmpfs. I'm just not sure about
>making it persistent at the end of the day.
Link your .git dir to a persistent location.
Benchmark it first so you know how much hassle it may be worth. If it isn't worth it, xfs or brtfs will likely not be worth it either,
-Martin
Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum
^ permalink raw reply
* 1.7.9, libcharset missing from EXTLIBS
From: Дилян Палаузов @ 2012-02-10 1:29 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
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
Със здраве
Дилян
[-- Attachment #2: dilyan_palauzov.vcf --]
[-- Type: text/x-vcard, Size: 381 bytes --]
begin:vcard
fn;quoted-printable:=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=
=D0=B2
n;quoted-printable;quoted-printable:=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2;=D0=94=D0=B8=D0=BB=D1=8F=D0=BD
email;internet:dilyan.palauzov@aegee.org
tel;home:+49-721-94193270
tel;cell:+49-162-4091172
note:sip:8372@aegee.org
version:2.1
end:vcard
^ permalink raw reply
* Re: Git, Builds, and Filesystem Type
From: Hilco Wijbenga @ 2012-02-10 1:25 UTC (permalink / raw)
To: Martin Fick; +Cc: Git Users
In-Reply-To: <201202091634.36563.mfick@codeaurora.org>
On 9 February 2012 15:34, Martin Fick <mfick@codeaurora.org> wrote:
> On Thursday, February 09, 2012 04:24:47 pm Hilco Wijbenga
> wrote:
>> On 9 February 2012 13:53, Martin Fick
> <mfick@codeaurora.org> wrote:
>> > On Thursday, February 09, 2012 02:23:18 pm Hilco
>> > Wijbenga
>> >
>> > wrote:
>> >> For the record, our (Java) project is quite small.
>> >> It's 43MB (source and images) and the entire
>> >> directory tree after building is about 1.6GB (this
>> >> includes all JARs downloaded by Maven). So we're not
>> >> talking TBs of data.
>> >>
>> >> Any thoughts on which FSs to include in my tests? Or
>> >> simply which FS might be more appropriate?
>> >
>> > tmpfs is probably fastest hands down if you can use it
>> > (even if you have to back it by swap).
>>
>> I don't have quite that much RAM. :-)
>
> But I am sure that you have that much disk space which you
> can allocate to swap, if not you already couldn't build it.
> And tmpfs swapping is still likely faster than a persistent
> FS (it will not need to block on syncs). If you are
> benchmarking, it is likely worth you effort since that will
> probably mark the upper performance bound,
I found [1]. Is that sort of what you had in mind? That would be quite
tricky. I have a group of some 60 projects, each with their own
"target" directory which would have to be mounted on tmpfs. And the
"target" directory is created by Maven, not by me. Not to mention that
I shut down my computer at the end of the day. :-)
I think I would prefer a somewhat more persistent solution. I
certainly have enough space for a very big swap partition. So the
whole of ~/my-project would fit on tmpfs. I'm just not sure about
making it persistent at the end of the day.
[1] http://code.google.com/p/chromium/wiki/LinuxFasterBuilds
^ permalink raw reply
* Re: Git, Builds, and Filesystem Type
From: Hilco Wijbenga @ 2012-02-10 1:11 UTC (permalink / raw)
To: Luke Diamand; +Cc: Git Users
In-Reply-To: <CAE5ih7_NkyJ6vGbyoKvQy65LFK3-zkXi79Xd6+3Si8DyUi47JQ@mail.gmail.com>
On 9 February 2012 15:24, Luke Diamand <luke@diamand.org> wrote:
> On Thu, Feb 9, 2012 at 9:23 PM, Hilco Wijbenga <hilco.wijbenga@gmail.com>
> wrote:
>>
>> Hi all,
>>
>> I'm thinking about trying out different filesystems over the weekend
>> to see if, say, BTRFS or XFS is faster when using Git and running our
>> build.
>>
>> Currently, I'm using ReiserFS and it's not like it's not working. I'm
>> very pleased with ReiserFS but after seeing talks about BTRFS and XFS
>> I'm curious if another (newer) FS is better suited to our specific
>> environment. Anything to make the build a little faster. :-)
>>
>> For the record, our (Java) project is quite small. It's 43MB (source
>> and images) and the entire directory tree after building is about
>> 1.6GB (this includes all JARs downloaded by Maven). So we're not
>> talking TBs of data.
>>
>> Any thoughts on which FSs to include in my tests? Or simply which FS
>> might be more appropriate?
>
>
> Do people still use reiserfs? I thought development on that pretty much
> stopped years ago. And reiser4 never made it into the kernel. Read the wiki
> page for why.
As I said, reiserfs works fine so I see no need to replace it. I'm not
a big fan of ext3 (I've run out of inodes too many times) and I simply
haven't tried ext4. Apparently, it has some architectural problems but
I'm no expert.
> ext4, FTW!
>
> But whatever you use, you might find that the core.preloadindex config
> option helps. It certainly does for NFS.
I would like to think that my local hard drive has no latency issues?
Would this really be worthwhile even if I do not use some sort of
distributed FS?
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Neal Kreitzinger @ 2012-02-10 1:04 UTC (permalink / raw)
To: Petr Onderka; +Cc: git
In-Reply-To: <CAPyqok3USqMxm0gNf_T9vnCoicp9XSwpWUCYJ8jh79h=V_UuOA@mail.gmail.com>
On 2/7/2012 6:28 AM, Petr Onderka wrote:
> since the hacking of kernel.org, the online version of git
> documentation [1] is not available. I realize that I can use local
> version of the documentation and there is also at least one mirror
> [2]. But I think it's very useful to have an "official" version of the
> documentation online. And, more importantly, there is now lots of dead
> links all over the Internet to the kernel.org version of the
> documentation.
>
> Can someone with the ability to do so restore the documentation at the
> old location?
>
Additional info:
http://article.gmane.org/gmane.comp.version-control.git/185302
v/r,
neal
^ permalink raw reply
* Re: [PATCH 4/4] diff --stat: use most of the space for file names
From: Junio C Hamano @ 2012-02-10 0:55 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1328831921-27272-5-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
> ---
> diff.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index 8406a0d..6220190 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1343,7 +1343,8 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
> }
>
> width = options->stat_width ? options->stat_width : term_columns();
> - name_width = options->stat_name_width ? options->stat_name_width : 50;
> + name_width = options->stat_name_width ? options->stat_name_width
> + : term_columns() - 20; /* the graph defaults to 20 columns */
Why? Isn't 80-50 = 30?
^ permalink raw reply
* Re: [PATCH 3/4] diff --stat: use the real terminal width
From: Junio C Hamano @ 2012-02-10 0:54 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1328831921-27272-4-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> 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.
>
> The output is still not optimal, because too many columns are devoted
> to +- output, and not enough to filenames, but this is a policy
> question, changed in next commit.
>
> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
> ---
> diff.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index 7e15426..8406a0d 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"
> @@ -1341,7 +1342,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
> line_prefix = msg->buf;
> }
>
> - width = options->stat_width ? options->stat_width : 80;
> + width = options->stat_width ? options->stat_width : term_columns();
The output from "git format-patch" shouldn't be affected at all by the
width of the terminal the patch sender happened to have used when the
command was run when the user did not explicitly ask a custom width by
giving a --stat-width command line option.
How do you prevent regression to the command in this series?
^ permalink raw reply
* Re: Merging only a subdirectory from one branch to the other
From: Neal Kreitzinger @ 2012-02-10 0:51 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <CAHVO_90MQamw7oB8ry5YBEWSnRnxDZvQ4ApVuuv4AYR6VRuXSw@mail.gmail.com>
On 2/7/2012 3:38 AM, Howard Miller wrote:
> I have a branch with a particular subdirectory tree. The tree has a
> lot of history. However, all the history for that subdirectory is
> exclusive to it (no commits changed anything outside it). I now need
> to merge that subdirectory into a completely different branch without
> loosing any history. I think git-read-tree might have something to do
> with it but I don't understand the help file at all. Any help
> appreciated.
>
Does the 'subtree merge' described in this link do what you want:
http://progit.org/book/ch6-7.html
(I can't say I've actually tried it myself, yet.)
v/r,
neal
^ permalink raw reply
* Re: [PATCH 2/4] help.c: make term_columns() cached and export it
From: Junio C Hamano @ 2012-02-10 0:50 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, gitster, Michael J Gruber
In-Reply-To: <1328831921-27272-3-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> diff --git a/help.c b/help.c
> index bc15066..75b8d4b 100644
> --- a/help.c
> +++ b/help.c
> @@ -5,26 +5,41 @@
> #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.
> + */
Just a style.
/*
* We format multi-line
* comment block like
* this.
*/
> +static int term_columns_cache;
> +
> +/* Return cached value (iff set) or $COLUMNS (iff 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");
> - int n_cols;
> + if (term_columns_cache)
> + return term_columns_cache;
>
> - if (col_string && (n_cols = atoi(col_string)) > 0)
> - return n_cols;
> + {
> + char *col_string = getenv("COLUMNS");
> + int n_cols;
> +
> + if (col_string && (n_cols = atoi(col_string)) > 0)
> + return (term_columns_cache = n_cols);
> + }
I can see the justification for the existing one inside the #ifdef below,
but why do you need the extra scope above?
We tend to avoid assignment as a part of another expression. The old code
already violates that convention, but please do not make it worse by
introducing three new ones.
^ permalink raw reply
* Re: [PATCH 1/4] Move git_version_string to help.c in preparation for diff changes
From: Junio C Hamano @ 2012-02-10 0:46 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek; +Cc: git, Michael J Gruber
In-Reply-To: <1328831921-27272-2-git-send-email-zbyszek@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> git_version_string is declared in builtins.h, but lived in git.c.
>
> When diff.c starts to use functions from help.c, linking against
> libgit.a will fail, unless git.o containing git_version_string is
> linked too.
Sorry, it is unclear what you mean by the above, nor why you need this
change in the first place. The resulting diff.o will certainly linked to
git.o as it does not have its own "main()" at all. And builtins.h is a
perfect place to declare things that are for the use of built-in commands
like implementations of diff family of commands, as they all are linked
into git.o (namely the commands[] array in handle_internal_command()) to
be usable.
What am I missing from between the lines of your log message?
^ permalink raw reply
* Re: fatal: Unable to find remote helper for 'https'
From: Tay Ray Chuan @ 2012-02-10 0:25 UTC (permalink / raw)
To: Nickolai Leschov; +Cc: git
In-Reply-To: <loom.20120209T224147-400@post.gmane.org>
Have you installed libcurl4-(gnutls|openssl)-dev? You'll need to
choose between gnutls and openssl for the underlying ssl
implementation.
--
Cheers,
Ray Chuan
On Fri, Feb 10, 2012 at 5:51 AM, Nickolai Leschov <nleschov@gmail.com> wrote:
> Hello,
>
> I have compiled git 1.7.9 from source on Ubuntu 9.04 and I get the following
> message when cloning a git repo:
>
> fatal: Unable to find remote helper for 'https'
>
> I get this message when I try to use https; or similar one for http. Only
> cloning via git:// protocol works. My system is Ubuntu 9.04 i386. git 1.7.9 and
> two previous versions I tried all exhibit this problem. I have uninstalled the
> git that comes in Ubuntu repositories and build from source instead because I
> need a newer version.
>
> How can I make git work on that system?
>
> I have another system with Ubuntu 11.04 i386 and it there git 1.7.4.1 (from
> repositories) doesn't exhibit such problem.
>
> Best regards,
>
> Nickolai Leschov
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* (unknown),
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber
Hi,
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 fourth patch also changes the partitioning of
available columns to dedicate more space to file names.
^ 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