headers
Piotr Krukowiecki | 10 Feb 10:42
Picon
Gravatar

git status: small difference between stating whole repository and small subdirectory

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michał Kiedrowicz | 10 Feb 10:18
Picon
Gravatar

[PATCH 0/8] gitweb: Highlight interesting parts of diff

Reading diff output is sometimes very hard, even if it's colored,
especially if lines differ only in few characters. This is often true when
a commit fixes a typo or renames some variables or functions.

This patch series teaches gitweb to highlight fragments that are different
between old and new line. This should mimic the same feature in Trac or
GitHub.

To achieve that, added and removed lines must be accumulated and compared.
The current code in print_sidebyside_diff_chunk() already does this, so
this patch series reuses it in commits:

  gitweb: Extract print_sidebyside_diff_lines()
  gitweb: Use print_diff_chunk() for both side-by-side and inline diffs

Next, HTML-formatting diff lines is pushed down to the place where they
are about to be printed. This is required because comparision must be
performened on raw git-diff output and not on HTML-formatted lines. This
is done in commits:

  gitweb: Move HTML-formatting diff line back to process_diff_line()
  gitweb: Push formatting diff lines to print_diff_chunk()
  gitweb: Format diff lines just before printing

The last three commits implement the advertised feature. They could be
squashed together but that would make them harder to review (I think).

  gitweb: Highlight interesting parts of diff
  gitweb: Use different colors to present marked changes
  gitweb: Highlight combined diffs
(Continue reading)

Permalink | Reply | 8 comments |
headers
Neal Kreitzinger | 10 Feb 03:34

nested git repos (not submodules)

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Namhyung Kim | 10 Feb 03:13

[PATCH 1/2] ctype.c only wants git-compat-util.h

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 <at> 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 | Reply | 5 comments |
headers
Дилян Палаузов | 10 Feb 02:29

1.7.9, libcharset missing from EXTLIBS

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

Със здраве
   Дилян
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hilco Wijbenga | 10 Feb 02:11
Picon

Re: Git, Builds, and Filesystem Type

On 9 February 2012 15:24, Luke Diamand <luke <at> diamand.org> wrote:
> On Thu, Feb 9, 2012 at 9:23 PM, Hilco Wijbenga <hilco.wijbenga <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zbigniew Jędrzejewski-Szmek | 10 Feb 00:58
Picon
Favicon
Gravatar

(unknown)

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 | Reply | 11 comments |
headers
Junio C Hamano | 10 Feb 01:15
Picon
Picon
Favicon
Gravatar

What's cooking in git.git (Feb 2012, #03; Thu, 9)

What's cooking in git.git (Feb 2012, #03; Thu, 9)
--------------------------------------------------

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.

Compared to the recent activity level on discussions of new features on
the list, some people may be wondering if the rate of advancement of the
'master' and 'next' branches is getting throttled.

That is because it is.

Now the obviously good bits that have been cooking during the feature
freeze are pushed out to 'master', I'd want to make sure we can have a
timely release of v1.7.9.1 so that people can start benefiting from the
features and fixes introduced in v1.7.9 more smoothly and sooner, and that
is where my focus lies at this moment. I've been picking up new topics and
adding them to 'pu' only "as time and attention permit" basis, and this
mode of operation probably will continue throughout the second week of the
post v1.7.9 cycle (cf. http://tinyurl.com/gitcal).

I would like to see more people test the tip of 'pu' as soon as possible
to make sure the fixes to 'git merge' give more pleasant user experience
than stock 1.7.9 release. Things to expect are:

 * "git merge --ff-only v3.2" that should fast-forward to the commit that
   is tagged should fast-forward, without creating the merge commit that
   records the contents taken from v3.2 tag (the topic
   jc/merge-ff-only-stronger-than-signed-merge in 'next' should take care
   of this issue);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke Diamand | 10 Feb 00:17

[RFC/PATCHv2 0/2] git-p4: possible RCS keyword fixes

Re-rolled with elementary shell coding errors fixed as per comments
from Junio - thanks!

I said before I wouldn't try to fix this, but maybe it could be
made to work after all. If nothing else, the failing test
case would be useful.

Luke Diamand (2):
  git-p4: add test case for RCS keywords
  git-p4: initial demonstration of possible RCS keyword fixup

 contrib/fast-import/git-p4 |   43 ++++++++++++++++++++++-
 t/t9810-git-p4-rcs.sh      |   81 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 122 insertions(+), 2 deletions(-)
 create mode 100755 t/t9810-git-p4-rcs.sh

--

-- 
1.7.9.rc2.128.gfce41.dirty
Permalink | Reply | 3 comments |
headers
Nickolai Leschov | 9 Feb 22:51
Picon
Gravatar

fatal: Unable to find remote helper for 'https'

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
Permalink | Reply | 2 comments |
headers
Hilco Wijbenga | 9 Feb 22:23
Picon

Git, Builds, and Filesystem Type

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?

Cheers,
Hilco
Permalink | Reply | 6 comments |

Gmane