Re: ephemeral-branches instead of detached-head?

[Sitaram Chamarty]

On 08/14/2013 07:14 AM, Junio C Hamano wrote:
 Sitaram Chamarty sitar...@gmail.com writes:
 
 # all reflog entries that are not on a branch, tag, or remote
 d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches 
 --tags --remotes
 # all dangling commits not on a branch, tag, or remote
 d2 = !gitk --date-order $(git fsck | grep dangling.commit | cut -f3 
 -d' ') --not --branches --tags --remotes

 (Apologies if something like this was already said; I was not following
 the discussion closely enough to notice)
 
 Yup.
 
 A potential problem is that the output from log -g --pretty=%H or
 fsck | grep dangling may turn out to be humongous.  Other than
 that, they correctly compute what you want.

I thought I mentioned that but I can't find my email now so maybe I
didn't.

In practice though, I find that, bash at least seems happy to take
command lines as long as 7+ million characters long, so with the default
reflog expire times, that should work out to 10,000 commits *per day*.
[Tested with: echo {100..190}   junk; echo `cat junk` | wc]

Incidentally, am I the only one who thinks the default values for
gc.reflogexpire (90 days) and gc.reflogexpireunreachable (30) should be
reversed?

In terms of recovering potentially lost commits at least, it seems it
would make more sense that something that is UNreachable have a longer
expiry, whereas stuff that's reachable... that's only a quick gitk
browse away.

Design question: is the primary purpose of the reflog what was I doing
X days ago or is it I need some code from a commit that got rebased
out [or whatever] X days ago?

I have always only used the reflog for the latter.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Aug 2013, #03; Tue, 13)

[Stefan Beller]

On 08/14/2013 12:06 AM, Junio C Hamano wrote:
 * sb/parseopt-boolean-removal (2013-08-07) 9 commits
   (merged to 'next' on 2013-08-08 at b138a2d)
  + revert: use the OPT_CMDMODE for parsing, reducing code
  + checkout-index: fix negations of even numbers of -n
  + config parsing options: allow one flag multiple times
  + hash-object: replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP
  + branch, commit, name-rev: ease up boolean conditions
  + checkout: remove superfluous local variable
  + log, format-patch: parsing uses OPT__QUIET
  + Replace deprecated OPT_BOOLEAN by OPT_BOOL
  + Remove deprecated OPTION_BOOLEAN for parsing arguments
  (this branch uses jc/parseopt-command-modes.)
 
  Convert most uses of OPT_BOOLEAN/OPTION_BOOLEAN that can use
  OPT_BOOL/OPTION_BOOLEAN which have much saner semantics, and turn
  remaining ones into OPT_SET_INT, OPT_COUNTUP, etc. as necessary;
  there seems to be some misconversion that makes many tests fail,
  though.
 
  Will cook in 'next'.

Locally here all tests succeed, when testing that branch alone.
Which tests fail for you, so I can look into it?

 * sb/fsck-opt-bool (2013-07-29) 1 commit
  (merged to 'next' on 2013-07-30 at 8a9964c)
 + fsck: Replace deprecated OPT_BOOLEAN by OPT_BOOL

 Will cook in 'next'.

This one is completely included in sb/parseopt-boolean-removal,
but doesn't need jc/parseopt-command-modes. So once we're
confident with jc/parseopt-command-modes, we could drop this
branch as well.

Thanks,
Stefan



signature.asc
Description: OpenPGP digital signature

Re: Possible git bug

[Jeff King]

On Wed, Aug 14, 2013 at 07:42:11AM +0200, Daniel Knittl-Frank wrote:

  So would that be a bug? Or maybe a feature? I would like it that
  when you do a rebase and select no commits, it will rebase ontop of
  the commit you chose, and remove all the commits not shown in the
  interactive listing (so all).
 
 You can just use `git reset --hard commit to rollback to`  to
 discard all commits after the given commit (Unless they're part of
 another branch, of course). `git reset --soft` if you want to keep the
 state of your current working directory.

You can also use a noop line in the rebase instruction list rather
than a completely blank list to mean yes, really, do not apply any
commits.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ephemeral-branches instead of detached-head?

[Jeff King]

On Wed, Aug 14, 2013 at 12:02:24PM +0530, Sitaram Chamarty wrote:

  # all reflog entries that are not on a branch, tag, or remote
  d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches 
  --tags --remotes
 [...]

  A potential problem is that the output from log -g --pretty=%H or
  fsck | grep dangling may turn out to be humongous.  Other than
  that, they correctly compute what you want.
 
 I thought I mentioned that but I can't find my email now so maybe I
 didn't.
 
 In practice though, I find that, bash at least seems happy to take
 command lines as long as 7+ million characters long, so with the default
 reflog expire times, that should work out to 10,000 commits *per day*.
 [Tested with: echo {100..190}   junk; echo `cat junk` | wc]

You can also do:

  git log -g --pretty=%H |
  git log --stdin --not --branches --tags --remotes

to avoid any argv limitations.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git should not use a default user.email config value

[Michael Haggerty]

On 08/13/2013 01:46 PM, Jeff King wrote:
 On Tue, Aug 13, 2013 at 09:05:40PM +1000, Andrew Ardill wrote:
 
 I applied this on top of latest next (1da3ebde8999d07), and it worked
 perfectly for my use case.

 For what it's worth, it also passed the test suite!

 Would be great to see this, or something on the same theme, get into
 master. I'd be happy to review patches/write tests/write documentation
 if needed.
 
 Like I said, I do not have a particular use for it, but I don't think it
 would hurt anybody who does not use it. If you want to polish it up into
 a real patch with docs and tests, I don't mind.
 
 The only downside I can think of is that we might want to use the
 subsection in include.SUBSECTION.* for some other limiting conditions
 (e.g., only include this config when running version = X.Y, or even
 include only when environment variable FOO is true).
 
 I guess we could do something like:
 
   [include repo:...your regex here...]
 path = .gitconfig-only-for-some-repos
   [include env:USE_MY_MAGIC_CONFIG]
 path = .gitconfig-only-when-magic-env-set
 
 Adding the repo: prefix for this repo-dir matching is pretty trivial.
 Adding a similar env-matching is only slightly less trivial; but does
 anybody actually want it?

Gaaak!  Let me again plead for supporting a post-clone hook rather than
inventing some crazy config-file syntax that is becoming ever more
complicated.  A post-clone hook would make all of these things that have
been suggested pretty easy, and would also open lots of other
possibilities, all without further changes in git.core, like (I'm just
brainstorming here):

#! /bin/sh

remote=$1

ln -s $(HOME)/.githooks/* .git/hooks

case $(git --version) in
*.1.[78].*)
git config include.path $(HOME)/.gitinclude
;;
esac

echo (cd $(pwd)  git gc) $(HOME)/cron.weekly/git-gc

case $remote in
*.work.com/*)
git config user.email m...@work.com
;;
*.github.com/*)
git config user.email m...@debian.org
;;
*)
echo '### Remember to set user.email ###'
;;
esac

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ephemeral-branches instead of detached-head?

[Andres Perera]

On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
 On 08/14/2013 07:14 AM, Junio C Hamano wrote:
 Sitaram Chamarty sitar...@gmail.com writes:

 # all reflog entries that are not on a branch, tag, or remote
 d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches 
 --tags --remotes
 # all dangling commits not on a branch, tag, or remote
 d2 = !gitk --date-order $(git fsck | grep dangling.commit | cut -f3 
 -d' ') --not --branches --tags --remotes

 (Apologies if something like this was already said; I was not following
 the discussion closely enough to notice)

 Yup.

 A potential problem is that the output from log -g --pretty=%H or
 fsck | grep dangling may turn out to be humongous.  Other than
 that, they correctly compute what you want.

 I thought I mentioned that but I can't find my email now so maybe I
 didn't.

 In practice though, I find that, bash at least seems happy to take
 command lines as long as 7+ million characters long, so with the default
 reflog expire times, that should work out to 10,000 commits *per day*.
 [Tested with: echo {100..190}   junk; echo `cat junk` | wc]

echo is a builtin in bash, as is the case with other shell implementations

builtins may have different limit's than exec()'s ARG_MAX

$ getconf ARG_MAX
262144
$ perl -e 'print A x (262144 * 2)' | wc -c
  524288
$ perl -e 'print A x (262144 * 2)' | sh -c 'read v; echo $v' | wc -c
  524289
$ perl -e 'print A x (262144 * 2)' | sh -c 'read v; /bin/echo $v' | wc -c
sh: /bin/echo: Argument list too long
   0

builtin's argument buffer limit tends to be aligned with the
implementation's lexer buffer limit
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Rewriting git-repack in C

[Matthieu Moy]

Stefan Beller stefanbel...@googlemail.com writes:

 Also I'd like to propose a small technical change:
 I found no easy way to get a subset of files in a specific directory,
 which is very easy in the shell version via * (rm 
 file/in/dir/startswithprefix-*),
 So maybe instead of just prefixing the temporary files such as:
 $PACKDIR/.tmp-$PID-pack-*

If it's just a prefix, you can iterate over the full list of files, and
then use prefixcmp(...) to find the right files. May seem inefficient,
but AFAIK it's how the shell does wildcard expansion.

You should be carefull that if the operation is interrupted, the next
git gc must remove all the garbage, so if you change the naming
convention, you must also change the place where the cleanup is done.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] repack: rewrite the shell script in C.

[Matthieu Moy]

Stefan Beller stefanbel...@googlemail.com writes:

 This is the beginning of the rewrite of the repacking.

(please, mark your patch as RFC/PATCH in the subject in this case)

A few quick comments on style below.

  Makefile   |   2 +-
  builtin.h  |   1 +
  builtin/repack.c   | 313 
 +
  contrib/examples/git-repack.sh | 194 +
  git-repack.sh  | 194 -
  git.c  |   1 +

I suggested that you first enrich the test suite if needed. Did you
check that the testsuite had good enough coverage for git-repack?

 +static const char * const git_repack_usage[] = {

Style: no space after *.

 +static int delta_base_offset = 1; // enabled by default since 22c79eab 
 (2008-06-25)

No // comments please (they're C99, not portable C90).

 +int cmd_repack(int argc, const char **argv, const char *prefix) {

Brace on the next line.

 + fname = xmalloc(strlen(packdir) + 47); // 40 chars for the sha1

 + fname_old = xmalloc(strlen(packdir) + 52); // 40 chars for the sha1

I'd rather have 40 + strlen(whatever) explicitly.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git should not use a default user.email config value

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 Jeff King p...@peff.net writes:

 I guess we could do something like:

   [include repo:...your regex here...]
 path = .gitconfig-only-for-some-repos
   [include env:USE_MY_MAGIC_CONFIG]
 path = .gitconfig-only-when-magic-env-set

 I am not sure if env is very useful, but there certainly are other
 possibilities (e.g. apply this only on this host, only for members
 of this UNIX group, etc.)

I have already wished I had git version = XXX here (but that's tricky
to implement).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git should not use a default user.email config value

[Jeff King]

On Wed, Aug 14, 2013 at 09:09:05AM +0200, Michael Haggerty wrote:

 Gaaak!  Let me again plead for supporting a post-clone hook rather than
 inventing some crazy config-file syntax that is becoming ever more
 complicated.  A post-clone hook would make all of these things that have
 been suggested pretty easy, and would also open lots of other
 possibilities, all without further changes in git.core, like (I'm just
 brainstorming here):

My problem with a post-clone hook is that it only runs once, and then
potentially goes stale.  For example:

 ln -s $(HOME)/.githooks/* .git/hooks

Because of the symlink, this tracks hooks as they are updated, but what
happens when you add a new hook (or delete one)? You have to manually
hunt down each repository using it and update the links. You can get it
around it by replacing and symlinking the whole hook directory, though.

 case $(git --version) in
 *.1.[78].*)
 git config include.path $(HOME)/.gitinclude
 ;;
 esac

What happens when you upgrade (or downgrade) your git, or even use
multiple versions interleaved? You need to revisit this version check.

 echo (cd $(pwd)  git gc) $(HOME)/cron.weekly/git-gc

What happens when you move your repository to a different directory? You
have to manually fix up the generated cron script.

 case $remote in
 *.work.com/*)
 git config user.email m...@work.com
 ;;
 *.github.com/*)
 git config user.email m...@debian.org
 ;;
 *)
 echo '### Remember to set user.email ###'
 ;;
 esac

What happens when you update your address? You have to manually fix up
each repository.

I agree that running arbitrarily shell code is the most flexible thing,
but I think in many cases users would prefer to have something that
makes decisions at runtime, rather than having to remember to update
existing repositories with changes. That can be shell code, too, though
there are complications (performance and security come to mind).

I do not see the two features as necessarily an either-or; they can
accomplish the same thing, but with different tradeoffs in complexity
for the user.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git should not use a default user.email config value

[Jeff King]

On Wed, Aug 14, 2013 at 09:28:24AM +0200, Matthieu Moy wrote:

 Junio C Hamano gits...@pobox.com writes:
 
  Jeff King p...@peff.net writes:
 
  I guess we could do something like:
 
[include repo:...your regex here...]
  path = .gitconfig-only-for-some-repos
[include env:USE_MY_MAGIC_CONFIG]
  path = .gitconfig-only-when-magic-env-set
 
  I am not sure if env is very useful, but there certainly are other
  possibilities (e.g. apply this only on this host, only for members
  of this UNIX group, etc.)
 
 I have already wished I had git version = XXX here (but that's tricky
 to implement).

I assume it is because version XXX understands config option Y, but
older versions do not[1]. Rather than ask for version XXX, then, you
could ask for

  [include option:Y]
path = ...

and versions which understand Y (which happens to be XXX or greater)
would internally know that and consider the conditional true.

This whole discussion is basically implementing conditional config. In
my patch, the conditional is limited only to including other config. But
if you have many such conditions (and especially if each one only has
one varying config key), the result can be unwieldy. Another way of
doing this would be to introduce a conditional syntax to ignore or
respect some part of the file. The problem is that it would be tricky to
do in a backwards-compatible way.

-Peff

[1] I used to run into this with pager.*, which originally could only be
a bool, but later learned to take custom pagers. I solved it with:

  git config --file .gitconfig-pager pager.diff ...
  git config --global include.path .gitconfig-pager

which does not need a version or option conditional, because the
option was added _before_ the include feature. IOW, older versions
of git ignore it, and any which actually respect the include will
know how to handle custom pagers. But that does not work with
changes that came after the include feature was added. :)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

About *git clone --depth=n* puzzle

[XinLingchao]

Hi Guys,

I think I have got some trouble when I use `git clone --depth=n` command. Take 
a real repo for example:


`git clone https://github.com/douglarek/vimrc.git --depth=1`


then I use `git log`:
  
```  
    commit d04ca09ecc723739123fae11ad56784eb0c9b36a
    Author: Lingchao Xin dougla...@outlook.com
    Date:   Fri Jun 7 09:39:22 2013 +0800

    Update vnudle to master branch, add wm shortcut, pylint optimization

    commit c66d827dc212f6ae8aab6b5c44631564bcbe2acd
    Author: icocoa lingc...@outlook.com
    Date:   Tue Mar 12 01:36:34 2013 -0700

    Merge pull request #1 from douglarek/master

    Add markdown, flake8, pylint plugin

```
    but when I clone it with `file://`:

    git clone https://github.com/douglarek/vimrc.git
    git clone file://vimrc.git --depth=1 vimrc1

    I got this log:
```
    commit d04ca09ecc723739123fae11ad56784eb0c9b36a
Author: Lingchao Xin dougla...@outlook.com
Date:   Fri Jun 7 09:39:22 2013 +0800

    Update vnudle to master branch, add wm shortcut, pylint optimization
```

so the two results are not same, is it a bug? or it should be so?

My os is openSUSE 12.3 and git version 1.8.3.4; and myabe it occured in git 
1.8.1.4 +.


Thanks and Best regards

Lingchao Xin  --
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git should not use a default user.email config value

[Matthieu Moy]

Jeff King p...@peff.net writes:

 This whole discussion is basically implementing conditional config.
 [...] The problem is that it would be tricky to do in a
 backwards-compatible way.

That could be done with conditional comments like

# if some-condition then
[core]
pager = less
# endif

That's rather ugly, and the implementation would be even more ugly, but
backward-compatible.

 [1] I used to run into this with pager.*, which originally could only be
 a bool, but later learned to take custom pagers. I solved it with:

   git config --file .gitconfig-pager pager.diff ...
   git config --global include.path .gitconfig-pager

Same here, with push.default = upstream, which breaks old versions of
Git ;-).

(I have a recent Git on my desktop, and my $HOME is shared with a server
running Debian oldstable)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About *git clone --depth=n* puzzle

[Stefan Beller]

On 08/14/2013 10:20 AM, XinLingchao wrote:
 Hi Guys,
 
 I think I have got some trouble when I use `git clone --depth=n` command. 
 Take a real repo for example:
 
 
 `git clone https://github.com/douglarek/vimrc.git --depth=1`
 
 
 then I use `git log`:
   
 ```  
 commit d04ca09ecc723739123fae11ad56784eb0c9b36a
 Author: Lingchao Xin dougla...@outlook.com
 Date:   Fri Jun 7 09:39:22 2013 +0800
 
 Update vnudle to master branch, add wm shortcut, pylint optimization
 
 commit c66d827dc212f6ae8aab6b5c44631564bcbe2acd
 Author: icocoa lingc...@outlook.com
 Date:   Tue Mar 12 01:36:34 2013 -0700
 
 Merge pull request #1 from douglarek/master
 
 Add markdown, flake8, pylint plugin
 
 ```
 but when I clone it with `file://`:
 
 git clone https://github.com/douglarek/vimrc.git
 git clone file://vimrc.git --depth=1 vimrc1
 
 I got this log:
 ```
 commit d04ca09ecc723739123fae11ad56784eb0c9b36a
 Author: Lingchao Xin dougla...@outlook.com
 Date:   Fri Jun 7 09:39:22 2013 +0800
 
 Update vnudle to master branch, add wm shortcut, pylint optimization
 ```
 
 so the two results are not same, is it a bug? or it should be so?
 
 My os is openSUSE 12.3 and git version 1.8.3.4; and myabe it occured in git 
 1.8.1.4 +.
 
 
 Thanks and Best regards
 
 Lingchao Xin--

There was a similar discussion going on in July this year,
maybe this is an interesting read with respect to this topic
http://www.spinics.net/lists/git/msg196138.html

Stefan




signature.asc
Description: OpenPGP digital signature

Re: ephemeral-branches instead of detached-head?

[Sitaram Chamarty]

On 08/14/2013 12:40 PM, Andres Perera wrote:
 On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
 On 08/14/2013 07:14 AM, Junio C Hamano wrote:
 Sitaram Chamarty sitar...@gmail.com writes:

 # all reflog entries that are not on a branch, tag, or remote
 d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches 
 --tags --remotes
 # all dangling commits not on a branch, tag, or remote
 d2 = !gitk --date-order $(git fsck | grep dangling.commit | cut -f3 
 -d' ') --not --branches --tags --remotes

 (Apologies if something like this was already said; I was not following
 the discussion closely enough to notice)

 Yup.

 A potential problem is that the output from log -g --pretty=%H or
 fsck | grep dangling may turn out to be humongous.  Other than
 that, they correctly compute what you want.

 I thought I mentioned that but I can't find my email now so maybe I
 didn't.

 In practice though, I find that, bash at least seems happy to take
 command lines as long as 7+ million characters long, so with the default
 reflog expire times, that should work out to 10,000 commits *per day*.
 [Tested with: echo {100..190}   junk; echo `cat junk` | wc]
 
 echo is a builtin in bash, as is the case with other shell implementations
 
 builtins may have different limit's than exec()'s ARG_MAX
 
 $ getconf ARG_MAX
 262144
 $ perl -e 'print A x (262144 * 2)' | wc -c
   524288
 $ perl -e 'print A x (262144 * 2)' | sh -c 'read v; echo $v' | wc -c
   524289
 $ perl -e 'print A x (262144 * 2)' | sh -c 'read v; /bin/echo $v' | wc -c
 sh: /bin/echo: Argument list too long
0
 
 builtin's argument buffer limit tends to be aligned with the
 implementation's lexer buffer limit

Aah; good catch -- I did not know this.  Thanks!

My systems show 2621440 on CentOS 6 and 2097152 on Fedora 19, so --
dividing by 8 (abbrev SHA + space) then by 90, that's still 2900 commits
*per day* to run past this limit though!

(side note: making a single argument that long seems to have a much
lower limit than having multiple arguments:

$ /bin/echo `perl -e 'print A x (100)'` | wc
-bash: /bin/echo: Argument list too long
  0   0   0
$ /bin/echo `perl -e 'print A  x (100)'` | wc
  1 100 200

notice that the second one is twice as long in terms of bytes, but it's
not a single argument).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reproducible, corrupt packfile after fresh git-svn checkout message

[Thomas Rast]

Ben Tebulin tebu...@googlemail.com writes:

 Hello everybody!

 I have some _very interesting_ news regarding this issue!
 Here is the deal:

   1. I was able to *reproduce the error on a machine of a coworker!*

   2. I was able to rule out
   - HDD: It's reproducible from /dev/shm
   - Memory: Memory tests works fine

 now the interesting part:

   3. Occurs on Linux kernels 3.7.10, 3.8.x, 3.9.11, 3.10.5
  _but not on:_ 3.6.11, 3.5.7 and 2.6.32

 Both machines showing this problem are »Dell Latitude E6330« with an
 »i5-3340M @ 2.70GHz« CPU. Mine running stock kernels, coworker using
 plain Ubuntu 13.04.

 Furthermore I need to stress, that we never had any issues with our
 devices during daily _at all_.

 So what to do best now?

If you're still interested...

What did memcheck86 say about these machines?


My best theory so far:

malloc()/free() actually use mmap()/munmap() for large allocations.
mallopt(3) tells me that large here means a dynamic limit on modern
glibc, but with an upper limit of 32MB on 64-bit.  So your 39MB blob
would always result in an mmap() type allocation.

And it should be easy for glibc to check mmap() type allocations against
double free(), at least if the address has not been mapped again in the
same process.  So it probably does that, which aborts the program.

You could try to gather some data on this by looking at

  strace -o fsck.trace -f git fsck

for a crash case.  If the theory is correct, you should see an munmap()
for an address similar to the one pointed out by the glibc error
message, as follows: if you get

  *** glibc detected *** unknown: free(): invalid pointer: 0x7fe129669010 
***

check for the address 0x7fe129669000 (the start of the page that the
address is in).

Note that this is a pretty weak theory, because double free() detection
is squarely up valgrind's alley.  So valgrind's lack of complaints is a
strong argument against it.  But it's the best I've got so far.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: About *git clone --depth=n* puzzle

[XinLingchao]

---
 Date: Wed, 14 Aug 2013 10:51:53 +0200
 From: stefanbel...@googlemail.com
 To: dougla...@outlook.com
 CC: git@vger.kernel.org; junchunx.g...@gmail.com
 Subject: Re: About *git clone --depth=n* puzzle

 On 08/14/2013 10:20 AM, XinLingchao wrote:
 Hi Guys,

 I think I have got some trouble when I use `git clone --depth=n` command. 
 Take a real repo for example:


 `git clone https://github.com/douglarek/vimrc.git --depth=1`


 then I use `git log`:

 ```
 commit d04ca09ecc723739123fae11ad56784eb0c9b36a
 Author: Lingchao Xin dougla...@outlook.com
 Date: Fri Jun 7 09:39:22 2013 +0800

 Update vnudle to master branch, add wm shortcut, pylint optimization

 commit c66d827dc212f6ae8aab6b5c44631564bcbe2acd
 Author: icocoa lingc...@outlook.com
 Date: Tue Mar 12 01:36:34 2013 -0700

 Merge pull request #1 from douglarek/master

 Add markdown, flake8, pylint plugin

 ```
 but when I clone it with `file://`:

 git clone https://github.com/douglarek/vimrc.git
 git clone file://vimrc.git --depth=1 vimrc1

 I got this log:
 ```
 commit d04ca09ecc723739123fae11ad56784eb0c9b36a
 Author: Lingchao Xin dougla...@outlook.com
 Date: Fri Jun 7 09:39:22 2013 +0800

 Update vnudle to master branch, add wm shortcut, pylint optimization
 ```

 so the two results are not same, is it a bug? or it should be so?

 My os is openSUSE 12.3 and git version 1.8.3.4; and myabe it occured in git 
 1.8.1.4 +.


 Thanks and Best regards

 Lingchao Xin --

 There was a similar discussion going on in July this year,
 maybe this is an interesting read with respect to this topic
 http://www.spinics.net/lists/git/msg196138.html

 Stefan



Stefan, I do NOT think so, the key point is not about the depth limit, it is 
about whether remote clone depth equals local clone depth.

cheers

Lingchao Xin  

Re: re-ignoring a force added file

[Thomas Rast]

Raza Ali r...@ebi.ac.uk writes:

 I have force added a file we usually like to ignore (but keep in the
 repository). That was a change a while ago, and cannot be undone
 without serious pain. I would like to re-ignore the file though, as we
 dont want to track changes to it. Some of the options I came across
 are not useful for me. For example

 git rm --cached FILE // removes the file from the remote repository if
 I push, not desirable
 git update-index --assume-unchanged //Will ignore changes to the file
 locally, but someone else clones and the file is tracked for them.

 What we would like is to go back to the old state of affairs: the file
 was in the working directory when someone cloned from the remote
 repository, but changes to the file werent tracked or committed.

I highly doubt that this description is accurate:

Either the file was actually in the repository (more specifically, in
the commit that git-clone chose to be checked out).  In this case, it
appears in the worktree after cloning.  But its presence in the HEAD
commit of the resulting repo also means that it is tracked.

Or it was not in the repository.  In which case it will not appear in a
new clone.  And there is no third option here.

So your old state in fact did not exist.  And it unfortunately is also
not attainable in more roundabout ways: any given file can only be
either tracked or ignored (or untracked-but-not-ignored, but that's
beside the point).  You cannot use ignore rules to ignore files that are
tracked.

Please check https://gist.github.com/canton7/1423106 for a list of other
ways to achieve what you are trying to do (link from the corresponding
bot quote on #git).  But do note that --assume-unchanged is a rather
more dangerous beast than you may think, and I cannot recommend actually
using it.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reproducible, corrupt packfile after fresh git-svn checkouts - IDENTIFIED

[Ben Tebulin]

Hello everybody!

I'm the guy having the issue, that in a particular Git repository the
reads of an object fail the SHA1 reproducible on *two independent
machines* .

The issue occurs on a very specific repository starting with Linux
Kernel 3.7.2. Unfortunately my E-Mail to the kernel list dit get no
response.

After a long session of rebooting and bisecting the Linux kernel
(fortunately I had a SSD and ccache!) I was able to pinpoint this to the
following patch related to _memory management_ causing my data
corruption with git:

*mm: limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT*
  787f7301074ccd07a3e82236ca41eefd245f4e07 linux stable [1]
  53a59fc67f97374758e63a9c785891ec62324c81 upstream commit [2]

The patch speaks about batching [memory] pages to be freed so I'm a
bit unsure: Is this a Git or a Linux kernel issue?


Thanks
- Ben


[1] 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=787f7301074ccd07a3e82236ca41eefd245f4e07
[2] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=53a59fc67f97374758e63a9c785891ec62324c81
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] extend imap-send to accept pull-requests

[Thilo Borgmann]

Hi,

I want to get rid of my script attaching fake Header lines to a pull-request to
be send to my imap by imap-send.

Or in other words, I want git request-pull ... | git imap-send to work as
expected. Bevore I'm going to work on the code and send patches I want to hear
from you if such a patch would be welcome or be declined for any reasons.

Thanks,
Thilo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reproducible, corrupt packfile after fresh git-svn checkout message

[Ben Tebulin]

 My best theory so far:
 malloc()/free() actually use mmap()/munmap() for large allocations.
 mallopt(3) tells me that [...]

Many things I don't grab at first go :-)

Last night I did a long git-bisect of the kernel and was able to
pinpoint a change in the Linux memory management as cause (see my
pre-prepared email I just sent).

Would that fit into your theory?

 You could try to gather some data on this by  [...]
Before I dive into that maybe you could throw a quick look at the
causing Kernel change (which reading from the words _could_ be related)
if this fits into the picture?

If yes, I'm happy to try to assist you in further pinning this issue down!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About *git clone --depth=n* puzzle

[Jeff King]

On Wed, Aug 14, 2013 at 05:19:36PM +0800, XinLingchao wrote:

  There was a similar discussion going on in July this year,
  maybe this is an interesting read with respect to this topic
  http://www.spinics.net/lists/git/msg196138.html
 
 Stefan, I do NOT think so, the key point is not about the depth limit,
 it is about whether remote clone depth equals local clone depth.

I do not think it is about local vs remote, but rather about which
version of git the remote side is running. Prior to 682c7d2
(upload-pack: fix off-by-one depth calculation in shallow clone,
2013-01-11), a shallow clone always returned one extra commit. That fix
went into v1.8.2.

So if you have a post-v1.8.2 git client, a local clone will use the same
git version as the remote side of the connection. But if you are
contacting a remote server, the results you get will depend on what
version of git is running on the remote server.

And as the example you showed uses github.com as the remote, and as I
happen to know that GitHub's servers do not currently have 682c7d2, you
would see the old behavior.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: About *git clone --depth=n* puzzle

[XinLingchao]

Peff, thanks for your detial explain,  and I think I have got the point :P

-Lingchao Xin


 Date: Wed, 14 Aug 2013 07:59:56 -0400
 From: p...@peff.net
 To: dougla...@outlook.com
 CC: stefanbel...@googlemail.com; git@vger.kernel.org; junchunx.g...@gmail.com
 Subject: Re: About *git clone --depth=n* puzzle

 On Wed, Aug 14, 2013 at 05:19:36PM +0800, XinLingchao wrote:

 There was a similar discussion going on in July this year,
 maybe this is an interesting read with respect to this topic
 http://www.spinics.net/lists/git/msg196138.html

 Stefan, I do NOT think so, the key point is not about the depth limit,
 it is about whether remote clone depth equals local clone depth.

 I do not think it is about local vs remote, but rather about which
 version of git the remote side is running. Prior to 682c7d2
 (upload-pack: fix off-by-one depth calculation in shallow clone,
 2013-01-11), a shallow clone always returned one extra commit. That fix
 went into v1.8.2.

 So if you have a post-v1.8.2 git client, a local clone will use the same
 git version as the remote side of the connection. But if you are
 contacting a remote server, the results you get will depend on what
 version of git is running on the remote server.

 And as the example you showed uses github.com as the remote, and as I
 happen to know that GitHub's servers do not currently have 682c7d2, you
 would see the old behavior.

 -Peff   --
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Git bug. make [all] does not use USE_LIBPCRE when configure --with-libpcre was previously run

[Alexey Shumkin]

Hello, Stefan!

I'll begin from afar.

From time to time, I use `git grep -P` to search text in sources using PCRE.
Today I was suprised when that command gave me the error
fatal: cannot use Perl-compatible regexes when not compiled with
USE_LIBPCRE

As far as I always use
./configure --with-libpcre 
make all
to build my Cygwin version of Git that was a VERY sudden error for me.
(but this is not a Cygwin-specific error, I've reproduced it on my Linux
box).

I've found out that `make` does not know anymore about USE_LIBPCRE=YesPlease
even `./configure --with-libpcre` was run before it. But I do remember
that it worked in some versions before (currently I use latest - v1.8.3.4).

So, I've got armed with the following test script:

---8---
#!/bin/sh

set -e
./configure --with-libpcre
make
set +e
./bin-wrappers/git grep -qIP das+
# if cannot use Perl-compatible regexes error occurs
# then Git exits with an error code 128 (but `git bisect run` fails to
# expect this exit code).
if test $? -eq 128
then
exit 1
fi
---8---

and `git bisect run` to find out where Git was broken.
That gave me:

---8---
40bfbde9da5c6cbc85f49a755f27162dc966fd89 is the first bad commit
commit 40bfbde9da5c6cbc85f49a755f27162dc966fd89
Author: Stefano Lattarini stefano.lattar...@gmail.com
Date:   Tue Sep 11 17:45:30 2012 +0200

build: don't duplicate substitution of make variables

Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR'
can be defined to a value 'VAL' at ./configure runtime in our build system
simply by using GIT_CONF_SUBST([VAR], [VAL]) in configure.ac, rather than
having both to call AC_SUBST([VAR], [VAL]) in configure.ac and adding the
'VAR = @VAR@' definition in config.mak.in.  Less duplication, less margin
for error, less possibility of confusion.

While at it, fix some formatting issues in configure.ac that unnecessarily
obscured the code flow.

Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com

:100644 100644 802d34223a2859ee1341d94ee722d7939b7276aa 
69d48382fe69b8699eb350949fff04975db923f8 M  config.mak.in
:100644 100644 450bbe7f1020711b4af2ad6ea52d717651c30b0b 
da1f41f58871b2102a9ed5eaeff7df3c9623f4bd M  configure.ac
bisect run success

---8---

I'm not a C programmer to fix that, so I ask you to.

-- 
Alexey Shumkin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git should not use a default user.email config value

[Junio C Hamano]

On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:

 Jeff King p...@peff.net writes:

  This whole discussion is basically implementing conditional config.
  [...] The problem is that it would be tricky to do in a
  backwards-compatible way.

 That could be done with conditional comments like

 # if some-condition then
 [core]
 pager = less
 # endif

 That's rather ugly, and the implementation would be even more ugly, but
 backward-compatible.


I highly doubt that you would want to be backward compatible in this
case, though.
The section of the configuration you are enclosing the new if/endif
syntax may be
understood only by newer Git (e.g. imagine core.pager is still
bool-only today), and
older Git that do not understand if/endif syntax will happily read
that section and
choke on it, no?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git should not use a default user.email config value

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 On Wed, Aug 14, 2013 at 1:37 AM, Matthieu Moy
 matthieu@grenoble-inp.fr wrote:

 Jeff King p...@peff.net writes:

  This whole discussion is basically implementing conditional config.
  [...] The problem is that it would be tricky to do in a
  backwards-compatible way.

 That could be done with conditional comments like

 # if some-condition then
 [core]
 pager = less
 # endif

 That's rather ugly, and the implementation would be even more ugly, but
 backward-compatible.


 I highly doubt that you would want to be backward compatible in this
 case, though.
 The section of the configuration you are enclosing the new if/endif
 syntax may be
 understood only by newer Git (e.g. imagine core.pager is still
 bool-only today), and
 older Git that do not understand if/endif syntax will happily read
 that section and
 choke on it, no?

Indeed. That would be more

# if some-condition then
# [core]
#   pager = less
# endif

which is even more ugly ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

conditional config syntax

[Jeff King]

[updated subject, as we are very far off the original topic]

On Wed, Aug 14, 2013 at 07:00:58AM -0700, Junio C Hamano wrote:

   This whole discussion is basically implementing conditional config.
   [...] The problem is that it would be tricky to do in a
   backwards-compatible way.
 
  That could be done with conditional comments like
 
  # if some-condition then
  [core]
  pager = less
  # endif
 
  That's rather ugly, and the implementation would be even more ugly, but
  backward-compatible.
 
 I highly doubt that you would want to be backward compatible in this
 case, though.  The section of the configuration you are enclosing the
 new if/endif syntax may be understood only by newer Git (e.g. imagine
 core.pager is still bool-only today), and older Git that do not
 understand if/endif syntax will happily read that section and choke on
 it, no?

I would think the ideal behavior would be for existing implementations
to just not include the conditional section.

If we take the conditional by default in existing versions of git (i.e.,
the behavior of Matthieu's proposal), then any do this only if version
X or greater conditional is going to be inconsistent (it will be true
for old versions, not true for versions which understand conditionals
but pre-date X, and then true again for the actual versions you want).

Likewise, if we introduce some new non-backwards-compatible syntax that
existing Git chokes on, then you have created a new compatibility
problem. You cannot use older versions of git, which is the exact
problem a version conditional is trying to solve.

That is one of the reasons that include.path is designed as it is; old
versions accept it and do nothing (unless you specifically ask for it as
a value). And likewise, include.*.path will do nothing for existing
versions of git.

Or hmm. Maybe that is what you mean by choke on it. Choke on the
invalid config, not on the new syntax.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] branch: not report invalid tracking branch

[Junio C Hamano]

Jiang Xin worldhello@gmail.com writes:

 Command git branch -vv will report tracking branches, but invalid
 tracking branches are also reported. This is because the function
 stat_tracking_info() can not distinguish whether the upstream branch
 does not exist, or nothing is changed between one branch and its
 upstream.

 This patch changes the return value of function stat_tracking_info().
 Only returns false when there is no tracking branch or the tracking
 branch is invalid, otherwise true. If the caller does not like to
 report tracking info when nothing changed between the branch and its
 upstream, simply checks if num_theirs and num_ours are both 0.

 Signed-off-by: Jiang Xin worldhello@gmail.com
 ---
  builtin/branch.c | 18 +-
  remote.c | 24 
  wt-status.c  | 13 +++--
  3 files changed, 28 insertions(+), 27 deletions(-)

 diff --git a/builtin/branch.c b/builtin/branch.c
 index 0836890..359e75d 100644
 --- a/builtin/branch.c
 +++ b/builtin/branch.c
 @@ -424,19 +424,8 @@ static void fill_tracking_info(struct strbuf *stat, 
 const char *branch_name,
   struct branch *branch = branch_get(branch_name);
   struct strbuf fancy = STRBUF_INIT;
  
 - if (!stat_tracking_info(branch, ours, theirs)) {
 - if (branch  branch-merge  branch-merge[0]-dst 
 - show_upstream_ref) {
 - ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
 - if (want_color(branch_use_color))
 - strbuf_addf(stat, [%s%s%s] ,
 - 
 branch_get_color(BRANCH_COLOR_UPSTREAM),
 - ref, 
 branch_get_color(BRANCH_COLOR_RESET));
 - else
 - strbuf_addf(stat, [%s] , ref);
 - }
 + if (!stat_tracking_info(branch, ours, theirs))
   return;
 - }
  
   if (show_upstream_ref) {
   ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
 @@ -448,7 +437,10 @@ static void fill_tracking_info(struct strbuf *stat, 
 const char *branch_name,
   strbuf_addstr(fancy, ref);
   }
  
 - if (!ours) {
 + if (!ours  !theirs) {
 + if (ref)
 + strbuf_addf(stat, _([%s]), fancy.buf);

Mental note: the updated stat_tracking_info() says something to
report exists when the current branch and its @{u} are the same,
and we report the branch here.

 + } else if (!ours) {
   if (ref)
   strbuf_addf(stat, _([%s: behind %d]), fancy.buf, 
 theirs);

This is not a fault of your change, but the logic to show the
upstream ref is unnecessarily unclear due to variable cascading.
The master switch show_upstream_ref is what is used to ask this to
fill the name of the upstream ref, and ref is made non-NULL only
when show_upstream_ref is true.  Also fancy would be non-empty
only in that case, so this if (ref) could be any one of these:

if (show_upstream_ref)
if (ref)
if (fancy.len)

It is disturbing that the middle one is used.  If you take the
stance that the code should reflect the logic, the first one
(i.e. we were asked to show upstream ref, so we show it here)
makes the most sense.  If you take the stance that the code should
be safe with the low-level implementation, the last one (i.e. we
are showing what is in fancy, if we have prepared something to show
in that buffer) makes sense.  The middle one is the least logical
thing to base the decision on.

 diff --git a/remote.c b/remote.c
 index 2433467..c747936 100644
 --- a/remote.c
 +++ b/remote.c
 @@ -1729,7 +1729,8 @@ int ref_newer(const unsigned char *new_sha1, const 
 unsigned char *old_sha1)
  }
  
  /*
 - * Return true if there is anything to report, otherwise false.
 + * Return false if cannot stat a tracking branch (not exist or invalid),
 + * otherwise true.
   */
  int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
  {
 @@ -1740,18 +1741,12 @@ int stat_tracking_info(struct branch *branch, int 
 *num_ours, int *num_theirs)
   const char *rev_argv[10], *base;
   int rev_argc;
  
 - /*
 -  * Nothing to report unless we are marked to build on top of
 -  * somebody else.
 -  */
 + /* False unless we are marked to build on top of somebody else. */

Aren't these saying the same thing?  I'd rather see the comment say
nothing/something to report, instead of false/true.  The latter
can be read from the value returned in the code, and writing that in
the comment is redundant.  The former tells the reader what that
false _means_, which is the whole point of adding a comment.

   if (!branch ||
   !branch-merge || !branch-merge[0] || !branch-merge[0]-dst)
   return 0;
  
 - /*
 -  * If what we used to build on no longer exists, there is
 -  * nothing to report.
 -  */
 +

Re: [PATCH v5 1/2] branch: not report invalid tracking branch

[Junio C Hamano]

Jiang Xin worldhello@gmail.com writes:

 Command git branch -vv will report tracking branches, but invalid
 tracking branches are also reported. This is because the function
 stat_tracking_info() can not distinguish whether the upstream branch
 does not exist, or nothing is changed between one branch and its
 upstream.

I am guessing that by invalid, you used to have another branch
(possibly a remote one) you built a branch on (hence the upstream of
the latter is set to the former) and the former branch no longer
exists.

Shouldn't that case reported a bit more specially?  After doing this:

git init
git commit --allow-empty -m initial ;# on master
git branch topicbase
git checkout -t -b topic topicbase
git commit --allow-empty -m topic ;# on topic
git branch -d topicbase

the branch topic _thinks_ it is still based on topicbase, but of
course git log @{u}.. will fail.

A few thought-alouds:

 - Perhaps git branch -d topicbase should have warned that there
   are some branches that are based on it?  Should it have failed?
   Or should it automatically removed branch.*.merge entries that
   point at it (while warning)?

 - The operation that removes the @{u} of some branch does not have
   to be git branch -d.  It could be remote --prune, and it does
   not make much sense to fail that operation, as what is gone from
   the other side is gone, and the point of having remote tracking
   branches is to keep a faithful copy of the observed status of the
   remote.  It implies that failing git branch -d topicbase is not
   a good idea.  Also removing the branch.*.merge automatically is
   probably not what the user wants (at least, the name would hint
   something, even after the topicbase branch is gone).

So git branch -v -v [topic] would want to still say that topic is
based on topicbranch, even though the latter is gone and there is no
longer a real building on relationship.

E.g. before git branch -d topicbase we would see something like:

$ git branch -v -v
  mastere67ac84 initial
* topic 3fc0f2a [topicbase: ahead 1] topic
  topicbase e67ac84 [master] initial

and after it, we currently see:

$ git branch -v -v
  mastere67ac84 initial
* topic 3fc0f2a [topicbase] topic
  topicbase e67ac84 [master] initial

but we may want to say:

$ git branch -v -v
  mastere67ac84 initial
* topic 3fc0f2a [topicbase (gone)] topic
  topicbase e67ac84 [master] initial

or something.

In order to distinguish these three cases (i.e. no tracking, with
configured but no longer valid tracking, and with tracking), you
would need more than true/false.

 This patch changes the return value of function stat_tracking_info().
 Only returns false when there is no tracking branch or the tracking
 branch is invalid, otherwise true.

Instead, you would need -1 (with gone base), 0 (no base), 1 (with
base).

This is a tangent, but we might want to rename stat_tracking_info().
A branch A building on top of another branch B does not mean A
tracks B.  The wording is a source of confusion.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: conditional config syntax

[Junio C Hamano]

Jeff King p...@peff.net writes:

 Or hmm. Maybe that is what you mean by choke on it. Choke on the
 invalid config, not on the new syntax.

Yes ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git bug. make [all] does not use USE_LIBPCRE when configure --with-libpcre was previously run

[Junio C Hamano]

Alexey Shumkin alex.crez...@gmail.com writes:

From time to time, I use `git grep -P` to search text in sources using PCRE.
 Today I was suprised when that command gave me the error
 fatal: cannot use Perl-compatible regexes when not compiled with
 USE_LIBPCRE

 As far as I always use
 ./configure --with-libpcre 
 make all
 to build my Cygwin version of Git that was a VERY sudden error for me.
 (but this is not a Cygwin-specific error, I've reproduced it on my Linux
 box).

 I've found out that `make` does not know anymore about USE_LIBPCRE=YesPlease
 even `./configure --with-libpcre` was run before it.
 ...
 and `git bisect run` to find out where Git was broken.
 That gave me:

 ---8---
 40bfbde9da5c6cbc85f49a755f27162dc966fd89 is the first bad commit
 commit 40bfbde9da5c6cbc85f49a755f27162dc966fd89
 Author: Stefano Lattarini stefano.lattar...@gmail.com
 Date:   Tue Sep 11 17:45:30 2012 +0200

 build: don't duplicate substitution of make variables
 
 Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 
 'VAR'
 can be defined to a value 'VAL' at ./configure runtime in our build system
 simply by using GIT_CONF_SUBST([VAR], [VAL]) in configure.ac, rather 
 than
 having both to call AC_SUBST([VAR], [VAL]) in configure.ac and adding 
 the
 'VAR = @VAR@' definition in config.mak.in.  Less duplication, less margin
 for error, less possibility of confusion.
 
 While at it, fix some formatting issues in configure.ac that unnecessarily
 obscured the code flow.
 
 Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
 Signed-off-by: Junio C Hamano gits...@pobox.com

 :100644 100644 802d34223a2859ee1341d94ee722d7939b7276aa 
 69d48382fe69b8699eb350949fff04975db923f8 M  config.mak.in
 :100644 100644 450bbe7f1020711b4af2ad6ea52d717651c30b0b 
 da1f41f58871b2102a9ed5eaeff7df3c9623f4bd M  configure.ac
 bisect run success

 ---8---

 I'm not a C programmer to fix that, so I ask you to.

Yikes and thanks for reporting.

This does not have anything to do with C, but is a breakage in our
autoconf script.  It appears that anything that is meant to be
appended at end via $config_appended_defs mechanism is missing from
the end result.

In fact, symbols whose explicit substitution the above patch
removes, e.g. CC_LD_DYNPATH, TCLTK_PATH, NEEDS_SSL_WITH_CRYPTO,
etc. are all missing.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] repack: rewrite the shell script in C.

[Stefan Beller]

On 08/14/2013 09:26 AM, Matthieu Moy wrote:
 I suggested that you first enrich the test suite if needed. Did you
 check that the testsuite had good enough coverage for git-repack?

There are already quite some tests using git-repack for testing other
purposes. Also git repack seems to be called from other commands
internally such as git notes prune or git gc.

I'll look into enhancing the test suite once I got the rewritten
code working on the current test suite.

Stefan





signature.asc
Description: OpenPGP digital signature

[RFC PATCH] repack: rewrite the shell script in C.

[Stefan Beller]

* Suggestions by Matthieu Moy have been included.
* I think it is completed apart from small todos and bugfixes.
* breaks the test suite, first breakage is t5301 (gc, sliding window)

Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
 Makefile   |   2 +-
 builtin.h  |   1 +
 builtin/repack.c   | 410 +
 contrib/examples/git-repack.sh | 194 +++
 git-repack.sh  | 194 ---
 git.c  |   1 +
 6 files changed, 607 insertions(+), 195 deletions(-)
 create mode 100644 builtin/repack.c
 create mode 100755 contrib/examples/git-repack.sh
 delete mode 100755 git-repack.sh

diff --git a/Makefile b/Makefile
index ef442eb..4ec5bbe 100644
--- a/Makefile
+++ b/Makefile
@@ -464,7 +464,6 @@ SCRIPT_SH += git-pull.sh
 SCRIPT_SH += git-quiltimport.sh
 SCRIPT_SH += git-rebase.sh
 SCRIPT_SH += git-remote-testgit.sh
-SCRIPT_SH += git-repack.sh
 SCRIPT_SH += git-request-pull.sh
 SCRIPT_SH += git-stash.sh
 SCRIPT_SH += git-submodule.sh
@@ -972,6 +971,7 @@ BUILTIN_OBJS += builtin/reflog.o
 BUILTIN_OBJS += builtin/remote.o
 BUILTIN_OBJS += builtin/remote-ext.o
 BUILTIN_OBJS += builtin/remote-fd.o
+BUILTIN_OBJS += builtin/repack.o
 BUILTIN_OBJS += builtin/replace.o
 BUILTIN_OBJS += builtin/rerere.o
 BUILTIN_OBJS += builtin/reset.o
diff --git a/builtin.h b/builtin.h
index 8afa2de..b56cf07 100644
--- a/builtin.h
+++ b/builtin.h
@@ -102,6 +102,7 @@ extern int cmd_reflog(int argc, const char **argv, const 
char *prefix);
 extern int cmd_remote(int argc, const char **argv, const char *prefix);
 extern int cmd_remote_ext(int argc, const char **argv, const char *prefix);
 extern int cmd_remote_fd(int argc, const char **argv, const char *prefix);
+extern int cmd_repack(int argc, const char **argv, const char *prefix);
 extern int cmd_repo_config(int argc, const char **argv, const char *prefix);
 extern int cmd_rerere(int argc, const char **argv, const char *prefix);
 extern int cmd_reset(int argc, const char **argv, const char *prefix);
diff --git a/builtin/repack.c b/builtin/repack.c
new file mode 100644
index 000..d39c34e
--- /dev/null
+++ b/builtin/repack.c
@@ -0,0 +1,410 @@
+/*
+ * The shell version was written by Linus Torvalds (2005) and many others.
+ * This is a translation into C by Stefan Beller (2013)
+ */
+
+#include builtin.h
+#include cache.h
+#include dir.h
+#include parse-options.h
+#include run-command.h
+#include sigchain.h
+#include strbuf.h
+#include string-list.h
+
+#include sys/types.h
+#include unistd.h
+#include stdio.h
+#include dirent.h
+
+static const char *const git_repack_usage[] = {
+   N_(git repack [options]),
+   NULL
+};
+
+/* enabled by default since 22c79eab (2008-06-25) */
+static int delta_base_offset = 1;
+
+static int repack_config(const char *var, const char *value, void *cb)
+{
+   if (!strcmp(var, repack.usedeltabaseoffset)) {
+   delta_base_offset = git_config_bool(var, value);
+   return 0;
+   }
+   return git_default_config(var, value, cb);
+}
+
+static void remove_temporary_files() {
+   DIR *dir;
+   struct dirent *e;
+   char *prefix, *path, *fname;
+
+   prefix = xmalloc(strlen(.tmp-1-pack) + 1);
+   sprintf(prefix, .tmp-%d-pack, getpid());
+
+   path = xmalloc(strlen(get_object_directory()) + strlen(/pack) + 1);
+   sprintf(path, %s/pack, get_object_directory());
+
+   fname = xmalloc(strlen(path) + strlen(/)
+   + strlen(prefix) + strlen(/)
+   + 40 + strlen(.pack) + 1);
+
+   dir = opendir(path);
+   while ((e = readdir(dir)) != NULL) {
+   if (!prefixcmp(e-d_name, prefix)) {
+   sprintf(fname, %s/%s, path, e-d_name);
+   unlink(fname);
+   }
+   }
+   free(fname);
+   free(prefix);
+   free(path);
+   closedir(dir);
+}
+
+static void remove_pack_on_signal(int signo)
+{
+   remove_temporary_files();
+   sigchain_pop(signo);
+   raise(signo);
+}
+
+void get_pack_sha1_list(char *packdir, struct string_list *sha1_list)
+{
+   DIR *dir;
+   struct dirent *e;
+   char *path, *suffix;
+
+   path = xmalloc(strlen(get_object_directory()) + strlen(/pack) + 1);
+   sprintf(path, %s/pack, get_object_directory());
+
+   suffix = .pack;
+
+   dir = opendir(path);
+   while ((e = readdir(dir)) != NULL) {
+   if (!suffixcmp(e-d_name, suffix)) {
+   char buf[255], *sha1;
+   strcpy(buf, e-d_name);
+   buf[strlen(e-d_name) - strlen(suffix)] = '\0';
+   sha1 = buf[strlen(e-d_name) - strlen(suffix) - 40];
+   string_list_append(sha1_list, sha1);
+   }
+   }
+   free(path);
+   closedir(dir);
+}
+
+void remove_pack(char *path, char* sha1)
+{
+   DIR *dir;
+   

Re: Git bug. make [all] does not use USE_LIBPCRE when configure --with-libpcre was previously run

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 This does not have anything to do with C, but is a breakage in our
 autoconf script.  It appears that anything that is meant to be
 appended at end via $config_appended_defs mechanism is missing from
 the end result.

 In fact, symbols whose explicit substitution the above patch
 removes, e.g. CC_LD_DYNPATH, TCLTK_PATH, NEEDS_SSL_WITH_CRYPTO,
 etc. are all missing.

Wait, I spoke too soon.

$ rm -f configure config.status 
  make configure 
  ./configure --with-libpcre 
  grep USE_LIBPCRE config.mak.autogen
USE_LIBPCRE=YesPlease

no longer reproduces for me (even though I _thought_ I tried and saw
the breakage).  Hmm.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ephemeral-branches instead of detached-head?

[Andres Perera]

On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty sitar...@gmail.com wrote:
 On 08/14/2013 12:40 PM, Andres Perera wrote:
 On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
 On 08/14/2013 07:14 AM, Junio C Hamano wrote:
 Sitaram Chamarty sitar...@gmail.com writes:

 # all reflog entries that are not on a branch, tag, or remote
 d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches 
 --tags --remotes
 # all dangling commits not on a branch, tag, or remote
 d2 = !gitk --date-order $(git fsck | grep dangling.commit | cut -f3 
 -d' ') --not --branches --tags --remotes

 (Apologies if something like this was already said; I was not following
 the discussion closely enough to notice)

 Yup.

 A potential problem is that the output from log -g --pretty=%H or
 fsck | grep dangling may turn out to be humongous.  Other than
 that, they correctly compute what you want.

 I thought I mentioned that but I can't find my email now so maybe I
 didn't.

 In practice though, I find that, bash at least seems happy to take
 command lines as long as 7+ million characters long, so with the default
 reflog expire times, that should work out to 10,000 commits *per day*.
 [Tested with: echo {100..190}   junk; echo `cat junk` | wc]

 echo is a builtin in bash, as is the case with other shell implementations

 builtins may have different limit's than exec()'s ARG_MAX

 $ getconf ARG_MAX
 262144
 $ perl -e 'print A x (262144 * 2)' | wc -c
   524288
 $ perl -e 'print A x (262144 * 2)' | sh -c 'read v; echo $v' | wc -c
   524289
 $ perl -e 'print A x (262144 * 2)' | sh -c 'read v; /bin/echo $v' | wc -c
 sh: /bin/echo: Argument list too long
0

 builtin's argument buffer limit tends to be aligned with the
 implementation's lexer buffer limit

 Aah; good catch -- I did not know this.  Thanks!

 My systems show 2621440 on CentOS 6 and 2097152 on Fedora 19, so --
 dividing by 8 (abbrev SHA + space) then by 90, that's still 2900 commits
 *per day* to run past this limit though!

ARG_MAX may also include the process environment, which needs to be
copied over to the new vm

the limit may also include the argv pointer sizes

those calculations based on SHA string length are just approximates


 (side note: making a single argument that long seems to have a much
 lower limit than having multiple arguments:

 $ /bin/echo `perl -e 'print A x (100)'` | wc
 -bash: /bin/echo: Argument list too long
   0   0   0
 $ /bin/echo `perl -e 'print A  x (100)'` | wc
   1 100 200

 notice that the second one is twice as long in terms of bytes, but it's
 not a single argument).

the behaviour is different in OpenBSD-amd64:

perl -e 'print A  x ((262144/2)-5)' | env -i sh -c 'unset PATH; read
v; /bin/echo $v' | wc -c

a bigger size and i get E2BIG. if i pass the env or let PATH get
exported, again, i need to reduce the multiplier

apparently Linux is doing copyin() for each argument. that seems
excessive to me :)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Antoine Pelisse]

On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
  builtin/repack.c   | 410 
 +
  contrib/examples/git-repack.sh | 194 +++
  git-repack.sh  | 194 ---

I'm still not sure I understand the trade-off here.

Most of what git-repack does is compute some file paths, (re)move
those files and call git-pack-objects, and potentially
git-prune-packed and git-update-server-info.
Maybe I'm wrong, but I have the feeling that the correct tool for that
is Shell, rather than C (and I think the code looks less intuitive in
C for that matter).
I'm not sure anyone would run that command a thousand times a second,
so I'm not sure it would make a real-life performance difference.

Last and very less important: I think it's OK to format-patch with -M,
especially when you move a file.

Cheers,
Antoine
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Junio C Hamano]

Stefan Beller stefanbel...@googlemail.com writes:

 diff --git a/builtin/repack.c b/builtin/repack.c
 new file mode 100644
 index 000..d39c34e
 --- /dev/null
 +++ b/builtin/repack.c
 @@ -0,0 +1,410 @@
 +/*
 + * The shell version was written by Linus Torvalds (2005) and many others.
 + * This is a translation into C by Stefan Beller (2013)
 + */
 +
 +#include builtin.h
 +#include cache.h
 +#include dir.h
 +#include parse-options.h
 +#include run-command.h
 +#include sigchain.h
 +#include strbuf.h
 +#include string-list.h
 +
 +#include sys/types.h
 +#include unistd.h
 +#include stdio.h
 +#include dirent.h

If you need these system-includes here, it means that our own
platform-portability layer git-compat-util.h is broken.  On
various systems, often some system header files are missing, need a
few feature macros to be defined before including, and/or need to be
included in certain order, etc., and git-compat-util.h is meant to
hide all such details from the programmers.

I do not think the above four needs to be included in *.c, as long
as you include either builtin.h or cache.h, both of which includes
the compat-util header.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Stefan Beller]

On 08/14/2013 06:49 PM, Antoine Pelisse wrote:
 On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
 stefanbel...@googlemail.com wrote:
  builtin/repack.c   | 410 
 +
  contrib/examples/git-repack.sh | 194 +++
  git-repack.sh  | 194 ---
 
 I'm still not sure I understand the trade-off here.
 
 Most of what git-repack does is compute some file paths, (re)move
 those files and call git-pack-objects, and potentially
 git-prune-packed and git-update-server-info.
 Maybe I'm wrong, but I have the feeling that the correct tool for that
 is Shell, rather than C (and I think the code looks less intuitive in
 C for that matter).
 I'm not sure anyone would run that command a thousand times a second,
 so I'm not sure it would make a real-life performance difference.

From IRC:
iveqy IIRC repack is one of the most important scripts to port
iveqy it's one of the rare times a script is used serverside
PjotrOrial heh, I picked it because of its size
iveqy (and people want to be able to use git in chrooted enviroments
with few dependencies)

My contributions as of now are very small nit picking things just to
familiarize with the code base, most of the time supported by tools
such as static code checkers.

However I'd like to contribute to the project in a more meaningful way,
but I still have the feeling to not be completely familar with the
projects code base (heh, it sure takes time for such large projects)

So I think the best way to get a feeling for the code base is to
rewrite a shell script in C. I picked the smallest script, to have
only a little task. So I thought at least. The rewriting is larger than
originally assumed.


But apart from my blabbering, I think ivegy made a good point:
The C parts just don't rely on external things, but only libc and
kernel, so it may be nicer than a shell script. Also as it is used
serversided, the performance aspect is not negligible.

I included Jeff King, who maybe could elaborate on git-repack on the
serverside?


 
 Last and very less important: I think it's OK to format-patch with -M,
 especially when you move a file.
 

Noted, thanks.

 Cheers,
 Antoine
 

Stefan




signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Jeff King]

On Wed, Aug 14, 2013 at 07:04:37PM +0200, Stefan Beller wrote:

 But apart from my blabbering, I think ivegy made a good point:
 The C parts just don't rely on external things, but only libc and
 kernel, so it may be nicer than a shell script. Also as it is used
 serversided, the performance aspect is not negligible.
 
 I included Jeff King, who maybe could elaborate on git-repack on the
 serverside?

I don't think the performance of repack as a C program versus a shell
script is really relevant to us at GitHub. Sure, we run a fair number of
repacks, but the cost is totally dominated by the pack-objects process
itself.

You might be able to achieve some speedups if it was not simply a
shell-C conversion, but an overall gc rewrite that did more in a single
process, and reused results (for example, you can reuse all or part of
the history traversal from pack-object's counting objects phase to do
the reachability analysis during prune)[1].

But I'd be very wary of stuffing too many things in a single process.
There are parts of the code that make assumptions about which objects
have been seen in the global object hash table (I believe index-pack is
one of these; see check_objects). And there are parts of the code which
must run separately (e.g., the connectivity check after transfer runs in
a separate process, both because it may die(), but also because we want
a clean slate of which packs are available, with no caching of results
we may have seen).

None of those problems is unsolvable, but it's very hard to know when
one is going to pop up and bite you. And because the repacking and
pruning code is the most likely place for a bug to cause data loss, it
makes me a bit nervous.

-Peff

[1] Another way to reuse the history traversal is to generate the
much-discussed pack reachability bitmaps, and then use them in
git-prune.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mail Back If Interested!

[YONG WONG]

Good Day,

I appologize for using this medium of internet to reach you, though it has
been greatly abused, but I chose to reach you because it is still the
fastest meansof communication in the world,however this correspondent is
unofficial and private.

My name is Yong Wong, I work with the hang seng Bank Hong Kong, I have a
business proposition for you involving the sum of $24.500.000.00 Million
Dollars in my bank which I know we will be of mutual benefit to both of
us,There is no risk involved. If interested please reply back to my
private email: wongyong...@yahoo.com.hk

Regards,
Yong Wong.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Martin Fick]

On Wednesday, August 14, 2013 10:49:58 am Antoine Pelisse 
wrote:
 On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
 
 stefanbel...@googlemail.com wrote:
   builtin/repack.c   | 410
   +
   contrib/examples/git-repack.sh | 194
   +++ git-repack.sh  |
   194 ---
 
 I'm still not sure I understand the trade-off here.
 
 Most of what git-repack does is compute some file paths,
 (re)move those files and call git-pack-objects, and
 potentially git-prune-packed and git-update-server-info.
 Maybe I'm wrong, but I have the feeling that the correct
 tool for that is Shell, rather than C (and I think the
 code looks less intuitive in C for that matter).
 I'm not sure anyone would run that command a thousand
 times a second, so I'm not sure it would make a
 real-life performance difference.

I have been holding off a bit on expressing this opinion too 
because I don't want to squash someone's energy to improve 
things, and because I am not yet a git dev, but since it was 
brought up anyway...
 
I can say that as a user, having git-repack as a shell 
script has been very valuable.  For example:  we have 
modified it for our internal use to no longer ever overwrite
new packfiles with the same name as the current packfile.  
This modification was relatively easy to do and see in shell 
script.  If this were C code I can't imagine having 
personally: 1) identified that there was an issue with the 
original git-repack (it temporarily makes objects 
unavailable) 2) made a simple custom fix to that policy.

The script really is mostly a policy script, and with the 
discussions happening in other threads about how to improve 
git gc, I think it is helpful to potentially be able to 
quickly modify the policies in this script, it makes it 
easier to prototype things.  Shell portability issues aside, 
this script is not a low level type of tool that I feel will 
benefit from being in C, I feel it will in fact be worse off 
in C,

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation
 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Junio C Hamano]

Antoine Pelisse apeli...@gmail.com writes:

 On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
 stefanbel...@googlemail.com wrote:
  builtin/repack.c   | 410 
 +
  contrib/examples/git-repack.sh | 194 +++
  git-repack.sh  | 194 ---

 I'm still not sure I understand the trade-off here.

 Most of what git-repack does is compute some file paths, (re)move
 those files and call git-pack-objects, and potentially
 git-prune-packed and git-update-server-info.
 Maybe I'm wrong, but I have the feeling that the correct tool for that
 is Shell, rather than C (and I think the code looks less intuitive in
 C for that matter).
 I'm not sure anyone would run that command a thousand times a second,
 so I'm not sure it would make a real-life performance difference.

I do not think the motivation of this patch is about performance in
the first place, though.

 Last and very less important: I think it's OK to format-patch with -M,
 especially when you move a file.

 Cheers,
 Antoine
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

New special handing of '@' character broke my use case

[Stefano Lattarini]

Hello list.

In the last year or so, I developed a personal idiom of using a
naming scheme of @/BRANCH-NAME/NUMto save the older versions
of branches I'm going to rebase (interactively or not).  Here is an
idealized example of my use case:

  $ git co --help
  `git co' is aliased to `checkout'
  $ git co -b topic
  $ ... hack hack hack ...
  $ git co master  git pull # Let's say this brings in 100 commits
  $ git co topic # I want to rebase this to avoid merge conflicts later
  $ git branch @/topic/1 # So I save original version of the branch
  $ git rebase master # Do the rebase, solve conflicts etc.
  $ ... hack hack hack (20 commits) ...
  # Here I notice botched commits messages and badly-ordered
  # commits in the last 10 commits or so.  I want to fix that.
  $ git branch @/topic/2 # Save latest version of the branch
  $ git rebase -i HEAD~12 # Fix issues

My problems is that some new automagical interpretation of the bare '@' 
character (introduced after 1.8.3) has destroyed my use case:


  $ /usr/bin/git --version
  git version 1.8.3
  $ git --version
  git version 1.8.4.rc2
  $ git co master
  $ /usr/bin/git branch @/foo# Old git
  $ git branch
@/foo   # -- good
  * master
  $ git branch   # New git.
@/foo# -- good
HEAD/bar # -- BAD!
  * master

I don't want to ask you to revert this new behaviour, but I'd like to
at least have an option to disable it.  Even better if such an option is 
already present -- in which case, could you just point me at it?


Failing that, I can re-train myself to use another character (like '='
or '+') to take the same role '@' has hold for me until today, no big
deal.  But in that case, I'd like some assurance that such a character 
is not going to be turned into a magical character some time in the 
future ;-)


Thanks,
  Stefano

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New special handing of '@' character broke my use case

[Junio C Hamano]

Stefano Lattarini stefano.lattar...@gmail.com writes:

 My problems is that some new automagical interpretation of the bare
 @' character (introduced after 1.8.3) has destroyed my use case:
 ...
 I don't want to ask you to revert this new behaviour, but I'd like to
 at least have an option to disable it.

I do not think it is simply not worth the complexity to selectively
disable it.  If it is a regression, it is much better to simply
revert, if we can (it appears that cdfd9483 (Add new @ shortcut for
HEAD, 2013-05-07) can be reverted without any textual context, but
there may already be new stuff that depends on the @).

For the upcoming release, I am very much tempted to revert it and
let the topic retried, by people who really want the let's save
four keystrokes and replace it with @ aka Shift-something,
without hurting your use case (and others), after the upcoming
release.

What do others think?

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

duplicate objects in packfile

[Jeff King]

I'm tracking down a rather odd problem in a packfile I found on GitHub.
This particular packfile contains the same object at various offsets
within the file. In fact there are several packfiles that exhibit this
behavior, all in the same repository, and in each one there are several
duplicated objects (some of which are present 3 or even 4 times).

index-pack is happy to index these packfiles, and just creates multiple
entries for the object. The usual binary search in find_pack_entry_one
will find one of them (though of course which depends on the exact
layout of the index). But curiously, the experimental sha1_entry_pos
lookup does not.  It hits an assert() that can only be triggered in the
face of duplicate objects. For example:

  $ git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
  commit

  $ GIT_USE_LOOKUP=1 git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
  git: sha1-lookup.c:222: sha1_entry_pos: Assertion `lov  hiv' failed.
  Aborted

It's easy enough to fix with a repack, but I am curious:

  1. Is sha1_entry_pos wrong to barf on duplicate items in the index? If
 so, do we want to fix it, or simply retire GIT_USE_LOOKUP?

 Related, should we consider duplicate items in a packfile to be a
 bogus packfile (and consequently notice and complain during
 indexing)? I don't think it _hurts_ anything (aside from the assert
 above), though it is of course wasteful.

 I didn't go into detail on how the assertion above is triggered,
 but I can break it down line by line if anybody cares; the short of
 it is that it can only be caused by an unsorted index or a
 duplicate entry.

  2. How can duplicate entries get into a packfile?

 Git itself should not generate duplicate entries (pack-objects is
 careful to remove duplicates). Since these packs almost certainly
 were pushed by a client, I wondered if index-pack --fix-thin
 might accidentally add multiple copies of an object when it is the
 preferred base for multiple objects, but it specifically avoids
 doing so.

 The packs in question were received by us in 2010. Did we ever have
 bugs in this area? I don't recall any, nor could I find any in the
 history.

 That makes me suspect the user may have been using an alternate git
 implementation. libgit2 did not know how to pack in 2010, and Grit
 still doesn't.  JGit did, and I don't know offhand about Dulwich.
 Does anyone know of bugs in those implementations that might have
 caused this?

The packs in question are public, so I can share them if anybody is
curious to look (but the whole repository is on the order of 700M).

Given the dates on the packs and how rare this is, I'm pretty much
willing to chalk it up to a random bug (in git or otherwise) that does
not any longer exist. But I was curious if anybody else knew anything,
and we may want to fix sha1_entry_pos to behave more like the regular
binary search.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New special handing of '@' character broke my use case

[Junio C Hamano]

Stefano Lattarini stefano.lattar...@gmail.com writes:

 ...  But in that case, I'd like some assurance that such a character
 is not going to be turned into a magical character some time in the
 future ;-)

I'd say that any special letter could be considered a fair game by
the next person who would want a funky short-cut.  If you used S
or something, e.g. git branch S/ropic/1 etc., it would be very
unlikely to conflict with any such future changes.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: duplicate objects in packfile

[Junio C Hamano]

Jeff King p...@peff.net writes:

 lookup does not.  It hits an assert() that can only be triggered in the
 face of duplicate objects. For example:

   $ git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
   commit

   $ GIT_USE_LOOKUP=1 git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
   git: sha1-lookup.c:222: sha1_entry_pos: Assertion `lov  hiv' failed.
   Aborted

Older versions of JGit used to put duplicate objects in a pack, and
IIRC Shawn declared that a bug in the packer and fixed it, so from
that point of view, I think rejecting is probably the right thing,
even though I think warning and continuing is also acceptable and
indeed may be better.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: duplicate objects in packfile

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 Jeff King p...@peff.net writes:

 lookup does not.  It hits an assert() that can only be triggered in the
 face of duplicate objects. For example:

   $ git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
   commit

   $ GIT_USE_LOOKUP=1 git cat-file -t 4ea4acbcb0930ac42acc87a0d203864dec1a9697
   git: sha1-lookup.c:222: sha1_entry_pos: Assertion `lov  hiv' failed.
   Aborted

 Older versions of JGit used to put duplicate objects in a pack, and
 IIRC Shawn declared that a bug in the packer and fixed it, so from
 that point of view, I think rejecting is probably the right thing,
 even though I think warning and continuing is also acceptable and
 indeed may be better.

Also repacking may have a funny corner case. I do not recall the
details as the above was a long time ago, but when I was tracking it
down, a delta was made against one copy of the base object, and
referred to it using delta-offset, while there was another copy of
the base object which was found by the bisection search, and from
there on, the inconsistencies between these two (they represent the
same payload, but they are at different offsets in the same pack and
with different in-pack sizes) led to some funky behaviour.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: duplicate objects in packfile

[Nicolas Pitre]

On Wed, 14 Aug 2013, Jeff King wrote:

   1. Is sha1_entry_pos wrong to barf on duplicate items in the index? If
  so, do we want to fix it, or simply retire GIT_USE_LOOKUP?

I'd think that sha1_entry_pos should be more lenient here, especially if 
this doesn't compromize the overall git behavior.

  Related, should we consider duplicate items in a packfile to be a
  bogus packfile (and consequently notice and complain during
  indexing)? I don't think it _hurts_ anything (aside from the assert
  above), though it is of course wasteful.

This should indeed be considered a bogus pack file.  But we have a lot 
of code to be able to cope with bogus/corrupted pack files already.  
Handling this case as well would not hurt.

More importantly we should make sure the code we have doesn't generate 
such packs.

   2. How can duplicate entries get into a packfile?
 
  Git itself should not generate duplicate entries (pack-objects is
  careful to remove duplicates). Since these packs almost certainly
  were pushed by a client, I wondered if index-pack --fix-thin
  might accidentally add multiple copies of an object when it is the
  preferred base for multiple objects, but it specifically avoids
  doing so.

It is probably simpler than that.  An alternative pack-objects 
implementation could stream multiple copies of an object upon a push, 
and index-pack on the receiving end would simply store what's been 
received to disk as is without a fuss.

 Given the dates on the packs and how rare this is, I'm pretty much
 willing to chalk it up to a random bug (in git or otherwise) that does
 not any longer exist.

Possibly.  Given this is not compromizing the validity of the pack, and 
a simple repack fixes it, I would not worry too much about it.


Nicolas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: duplicate objects in packfile

[Nicolas Pitre]

On Wed, 14 Aug 2013, Junio C Hamano wrote:

 Also repacking may have a funny corner case. I do not recall the
 details as the above was a long time ago, but when I was tracking it
 down, a delta was made against one copy of the base object, and
 referred to it using delta-offset, while there was another copy of
 the base object which was found by the bisection search, and from
 there on, the inconsistencies between these two (they represent the
 same payload, but they are at different offsets in the same pack and
 with different in-pack sizes) led to some funky behaviour.

Crap.

Better try to cope with this (with a test case, etc.) rather than 
rejecting them now I'd say.  Strictly speaking, they're still valid pack 
files.


Nicolas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Proper URI for svn clone on a network share (Win32)

[Tim Chase]

I've been sparring with the proper syntax and hope someone can give
me the magic I'm missing.  I want to do something of the form

  c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1

but get various failures.  My best-effort (above) gets me as far as
actually starting some sort of clone but it dies with


Permission denied: Can't open '/tmp/report.tmp': Permission denied 
at /usr/lib/perl5/site_perl/Git/SVN.pm line 1210


If it makes any difference, this is within a cmd.exe shell (with $PATH
set appropriately so git is being found).

Am I missing something in the URL syntax to get it to clone my svn
repo with less drama?

-tkc

PS: I don't really care much about pushing back to svn, existing
svn branches or tags, or username mapping.  If needed, I can apply
patches out of git which is far less painful than switching/merging
branches in svn.  So I can be a little rough-shod with cloning the
svn repo.

PPS: in case it matters:
C:\work\utils\temp\iosgit version
git version 1.8.3.msysgit.0



.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New special handing of '@' character broke my use case

[Stefano Lattarini]

[re-sending to the list, sorry Junio for the duplicate mail]

On 08/14/2013 07:05 PM, Junio C Hamano wrote:
 Stefano Lattarini stefano.lattar...@gmail.com writes:

 My problems is that some new automagical interpretation of the bare
 @' character (introduced after 1.8.3) has destroyed my use case:
 ...
 I don't want to ask you to revert this new behaviour, but I'd like to
 at least have an option to disable it.

 I do not think it is simply not worth the complexity to selectively
 disable it.  If it is a regression, it is much better to simply
 revert, if we can (it appears that cdfd9483 (Add new @ shortcut for
 HEAD, 2013-05-07) can be reverted without any textual context, but
 there may already be new stuff that depends on the @).

I'm not sure I want to force a revert simply to cater to a personal 
idiom of mine (and not that important).  I'd first like to hear what the 
community thinks about the issue (with silence meaning don't revert).


 For the upcoming release, I am very much tempted to revert it and
 let the topic retried, by people who really want the let's save
 four keystrokes and replace it with @ aka Shift-something,
 without hurting your use case (and others), after the upcoming
 release.

 What do others think?

I second this question :-)

Thanks,
  Stefano

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New special handing of '@' character broke my use case

[Johannes Sixt]

Am 14.08.2013 20:05, schrieb Junio C Hamano:

Stefano Lattarini stefano.lattar...@gmail.com writes:


My problems is that some new automagical interpretation of the bare
@' character (introduced after 1.8.3) has destroyed my use case:
...
I don't want to ask you to revert this new behaviour, but I'd like to
at least have an option to disable it.


I do not think it is simply not worth the complexity to selectively
disable it.  If it is a regression, it is much better to simply
revert, if we can (it appears that cdfd9483 (Add new @ shortcut for
HEAD, 2013-05-07) can be reverted without any textual context, but
there may already be new stuff that depends on the @).

For the upcoming release, I am very much tempted to revert it and
let the topic retried, by people who really want the let's save
four keystrokes and replace it with @ aka Shift-something,
without hurting your use case (and others), after the upcoming
release.

What do others think?


Stefano's use-case, where @/foo is turned into HEAD/foo, indicates a bug.

In my opinion, the topic, which touches a central part of ref handling, 
was a bit hurried (and this report is a symptom of it), and I wouldn't 
mind seeing it reverted.


-- Hannes

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New special handing of '@' character broke my use case

[Junio C Hamano]

Johannes Sixt j...@kdbg.org writes:

 Am 14.08.2013 20:05, schrieb Junio C Hamano:
 Stefano Lattarini stefano.lattar...@gmail.com writes:

 My problems is that some new automagical interpretation of the bare
 @' character (introduced after 1.8.3) has destroyed my use case:
 ...
 I don't want to ask you to revert this new behaviour, but I'd like to
 at least have an option to disable it.

 I do not think it is simply not worth the complexity to selectively
 disable it.  If it is a regression, it is much better to simply
 revert, if we can (it appears that cdfd9483 (Add new @ shortcut for
 HEAD, 2013-05-07) can be reverted without any textual context, but
 there may already be new stuff that depends on the @).

 For the upcoming release, I am very much tempted to revert it and
 let the topic retried, by people who really want the let's save
 four keystrokes and replace it with @ aka Shift-something,
 without hurting your use case (and others), after the upcoming
 release.

 What do others think?

 Stefano's use-case, where @/foo is turned into HEAD/foo, indicates a bug.

 In my opinion, the topic, which touches a central part of ref
 handling, was a bit hurried (and this report is a symptom of it), and
 I wouldn't mind seeing it reverted.

Thanks; you said it much better than I did.  I think the short-hand
is not a bad idea by itself, but the execution may need to be redone
a bit more carefully, and it is prudent to revert it from the
upcoming release.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Stefan Beller]

On 08/14/2013 07:25 PM, Martin Fick wrote:
 I have been holding off a bit on expressing this opinion too 
 because I don't want to squash someone's energy to improve 
 things, and because I am not yet a git dev, but since it was 
 brought up anyway...

It's ok, if you knew a better topic to work on, I'd gladly switch over.
(Given it would be a good beginners topic.)

  
 I can say that as a user, having git-repack as a shell 
 script has been very valuable.  For example:  we have 
 modified it for our internal use to no longer ever overwrite
 new packfiles with the same name as the current packfile.  
 This modification was relatively easy to do and see in shell 
 script.  If this were C code I can't imagine having 
 personally: 1) identified that there was an issue with the 
 original git-repack (it temporarily makes objects 
 unavailable) 2) made a simple custom fix to that policy.

Looking at the `git log -- git-repack.sh` the last commit is
from April 2012 and the commit before is 2011, so I assumed it
stable enough for porting over to C, as there is not much
modification going on. I'd be glad to include these changes
you're using into the rewrite or the shell script as of now.

 
 The script really is mostly a policy script, and with the 
 discussions happening in other threads about how to improve 
 git gc, I think it is helpful to potentially be able to 
 quickly modify the policies in this script, it makes it 
 easier to prototype things.  Shell portability issues aside, 
 this script is not a low level type of tool that I feel will 
 benefit from being in C, I feel it will in fact be worse off 
 in C,

So far I have been following the git mailing list, there are
people dreaming of 'everything in C' and apparently those, who
are ok with lots of shell code as well, 'because it's high level'.
I tend to follow the first group, dreaming of everything in C.
Thanks for pointing that out, if it really hurts people from using
git effectively, I'd rather not contribute this patch. But I'd like
to stress again, that the prototying should be done by now.

I asked for a todo wish list a few weeks ago, but got no real answer,
but rather: Pick your choice and try to come up with good patches.
This is a good policy from the projects point of view (your choice
helps in doing good patches, and good patches do not need as much
review, hence the reviewing costs are low), so I also choose this topic.

 
 -Martin
 

Stefan



signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Martin Fick]

On Wednesday, August 14, 2013 04:16:35 pm Stefan Beller 
wrote:
 On 08/14/2013 07:25 PM, Martin Fick wrote:
  I have been holding off a bit on expressing this
  opinion too because I don't want to squash someone's
  energy to improve things, and because I am not yet a
  git dev, but since it was brought up anyway...
 
 It's ok, if you knew a better topic to work on, I'd
 gladly switch over. (Given it would be a good beginners
 topic.)

See below...

  I can say that as a user, having git-repack as a shell
  script has been very valuable.  For example:  we have
  modified it for our internal use to no longer ever
  overwrite new packfiles with the same name as the
  current packfile. This modification was relatively
  easy to do and see in shell script.  If this were C
  code I can't imagine having personally: 1) identified
  that there was an issue with the original git-repack
  (it temporarily makes objects unavailable) 2) made a
  simple custom fix to that policy.
 
 Looking at the `git log -- git-repack.sh` the last commit
 is from April 2012 and the commit before is 2011, so I
 assumed it stable enough for porting over to C, as there
 is not much modification going on. I'd be glad to
 include these changes you're using into the rewrite or
 the shell script as of now.

One suggestion would be to change the repack code to create 
pack filenames based on the sha1 of the contents of the pack 
file instead of on the sha1 of the objects in the packfile.  

Since the same objects can be stored in a packfile in many 
ways (different deltification/compression options), it is 
currently possible to have 2 different pack files with the 
same names.  The contents are different, but the contained 
objects are the same.  This causes the object availability 
bug that I describe above in git repack when a new packfile 
is generated with the same name as a current one.

I am not 100% sure if the change in naming convention I 
propose wouldn't cause any problems?  But if others agree it 
is a good idea, perhaps it is something a beginner could do?

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation
 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Matthieu Moy]

Antoine Pelisse apeli...@gmail.com writes:

 On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
 stefanbel...@googlemail.com wrote:
  builtin/repack.c   | 410 
 +
  contrib/examples/git-repack.sh | 194 +++
  git-repack.sh  | 194 ---

 I'm still not sure I understand the trade-off here.

 Most of what git-repack does is compute some file paths, (re)move
 those files and call git-pack-objects, and potentially
 git-prune-packed and git-update-server-info.
 Maybe I'm wrong, but I have the feeling that the correct tool for that
 is Shell, rather than C (and I think the code looks less intuitive in
 C for that matter).

There's a real problem with git-repack being shell (I already mentionned
it in the previous thread about the rewrite): it creates dependencies on
a few external binaries, and a restricted server may not have them. I
have this issue on a fusionforge server where Git repos are accessed in
a chroot with very few commands available: everything went OK until the
first project grew enough to require a git gc --auto, and then it
stopped accepting pushes for that project.

I tracked down the origin of the problem and the sysadmins disabled
auto-gc, but that's not a very satisfactory solution.

C is rather painfull to write, but as a sysadmin, drop the binary on
your server and it just works. That's really important. AFAIK,
git-repack is the only remaining shell part on the server, and it's
rather small. I'd really love to see it disapear.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Junio C Hamano]

Stefan Beller stefanbel...@googlemail.com writes:

 I asked for a todo wish list a few weeks ago, but got no real answer,
 but rather: Pick your choice and try to come up with good patches.

Hmph, I hope that wasn't me.

There are some good ones here;

  http://git-blame.blogspot.com/search?q=leftover

Some are trivial, some are moderate complexity, and some are
pie-in-the-sky.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Junio C Hamano]

Martin Fick mf...@codeaurora.org writes:

 One suggestion would be to change the repack code to create 
 pack filenames based on the sha1 of the contents of the pack 
 file instead of on the sha1 of the objects in the packfile.  
 ...
 I am not 100% sure if the change in naming convention I 
 propose wouldn't cause any problems?  But if others agree it 
 is a good idea, perhaps it is something a beginner could do?

I would not be surprised if that change breaks some other people's
reimplementation.  I know we do not validate the pack name with the
hash of the contents in the current code, but at the same time I do
remember that was one of the planned things to be done while I and
Linus were working on the original pack design, which was the last
task we did together before he retired from the maintainership of
this project.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 Stefan Beller stefanbel...@googlemail.com writes:

 I asked for a todo wish list a few weeks ago, but got no real answer,
 but rather: Pick your choice and try to come up with good patches.

 Hmph, I hope that wasn't me.

 There are some good ones here;

   http://git-blame.blogspot.com/search?q=leftover

See also:

  https://git.wiki.kernel.org/index.php/SmallProjectsIdeas

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Martin Fick]

On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy 
wrote:
 Antoine Pelisse apeli...@gmail.com writes:
  On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
  
  stefanbel...@googlemail.com wrote:
   builtin/repack.c   | 410
   +
   contrib/examples/git-repack.sh | 194
   +++ git-repack.sh  |
   194 ---
  
  I'm still not sure I understand the trade-off here.
  
  Most of what git-repack does is compute some file
  paths, (re)move those files and call git-pack-objects,
  and potentially git-prune-packed and
  git-update-server-info.
  Maybe I'm wrong, but I have the feeling that the
  correct tool for that is Shell, rather than C (and I
  think the code looks less intuitive in C for that
  matter).
 
 There's a real problem with git-repack being shell (I
 already mentionned it in the previous thread about the
 rewrite): it creates dependencies on a few external
 binaries, and a restricted server may not have them. I
 have this issue on a fusionforge server where Git repos
 are accessed in a chroot with very few commands
 available: everything went OK until the first project
 grew enough to require a git gc --auto, and then it
 stopped accepting pushes for that project.
 
 I tracked down the origin of the problem and the
 sysadmins disabled auto-gc, but that's not a very
 satisfactory solution.
 
 C is rather painfull to write, but as a sysadmin, drop
 the binary on your server and it just works. That's
 really important. AFAIK, git-repack is the only
 remaining shell part on the server, and it's rather
 small. I'd really love to see it disapear.

I didn't review the proposed C version, but how was it 
planning on removing the dependencies on these binaries?  
Was it planning to reimplement mv, cp, find?  Were there 
other binaries that were problematic that you were thinking 
of?  From what I can tell it also uses test, mkdir, sed, 
chmod and naturally sh, that is 8 dependencies.  If those 
can't be depended upon for existing, perhaps git should just 
consider bundling busy-box or some other limited shell 
utils, or yikes!, even its own reimplementation of these 
instead of implementing these independently inside other git 
programs?

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation
 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Proper URI for svn clone on a network share (Win32)

[Tim Chase]

On 2013-08-14 12:49, Tim Chase wrote:
 If it makes any difference, this is within a cmd.exe shell (with
 $PATH set appropriately so git is being found).

Just a follow-up, I tried it within the bashish shell included in
the git install and got the same error regarding /tmp/report.tmp.

-tkc




--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Martin Fick]

On Wednesday, August 14, 2013 04:53:36 pm Junio C Hamano 
wrote:
 Martin Fick mf...@codeaurora.org writes:
  One suggestion would be to change the repack code to
  create pack filenames based on the sha1 of the
  contents of the pack file instead of on the sha1 of
  the objects in the packfile. ...
  I am not 100% sure if the change in naming convention I
  propose wouldn't cause any problems?  But if others
  agree it is a good idea, perhaps it is something a
  beginner could do?
 
 I would not be surprised if that change breaks some other
 people's reimplementation.  I know we do not validate
 the pack name with the hash of the contents in the
 current code, but at the same time I do remember that
 was one of the planned things to be done while I and
 Linus were working on the original pack design, which
 was the last task we did together before he retired from
 the maintainership of this project.

Perhaps a config option?  One that becomes standard for git 
2.0?

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation
 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Martin Fick]

On Wednesday, August 14, 2013 05:25:42 pm Martin Fick wrote:
 On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
 
 wrote:
  Antoine Pelisse apeli...@gmail.com writes:
   On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
   
   stefanbel...@googlemail.com wrote:
builtin/repack.c   | 410
+
contrib/examples/git-repack.sh | 194
+++ git-repack.sh 
| 194 ---
   
   I'm still not sure I understand the trade-off here.
   
   Most of what git-repack does is compute some file
   paths, (re)move those files and call
   git-pack-objects, and potentially git-prune-packed
   and
   git-update-server-info.
   Maybe I'm wrong, but I have the feeling that the
   correct tool for that is Shell, rather than C (and I
   think the code looks less intuitive in C for that
   matter).
  
  There's a real problem with git-repack being shell (I
  already mentionned it in the previous thread about the
  rewrite): it creates dependencies on a few external
  binaries, and a restricted server may not have them. I
  have this issue on a fusionforge server where Git repos
  are accessed in a chroot with very few commands
  available: everything went OK until the first project
  grew enough to require a git gc --auto, and then it
  stopped accepting pushes for that project.
  
  I tracked down the origin of the problem and the
  sysadmins disabled auto-gc, but that's not a very
  satisfactory solution.
  
  C is rather painfull to write, but as a sysadmin, drop
  the binary on your server and it just works. That's
  really important. AFAIK, git-repack is the only
  remaining shell part on the server, and it's rather
  small. I'd really love to see it disapear.
 
 I didn't review the proposed C version, but how was it
 planning on removing the dependencies on these binaries?
 Was it planning to reimplement mv, cp, find?  Were there
 other binaries that were problematic that you were
 thinking of?  From what I can tell it also uses test,
 mkdir, sed, chmod and naturally sh, that is 8
 dependencies.  If those can't be depended upon for
 existing, perhaps git should just consider bundling
 busy-box or some other limited shell utils, or yikes!,
 even its own reimplementation of these instead of
 implementing these independently inside other git
 programs?

Sorry I didn't comprehend your email fully when I first read 
it.  I guess that wouldn't really solve your problem unless 
someone had a way of bundling an sh program and whatever it 
calls inside a single executable? :(

I can see why you would want what you want,

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation
 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About *git clone --depth=n* puzzle

[Duy Nguyen]

On Wed, Aug 14, 2013 at 3:20 PM, XinLingchao dougla...@outlook.com wrote:
 Hi Guys,

 I think I have got some trouble when I use `git clone --depth=n` command. 
 Take a real repo for example:


 `git clone https://github.com/douglarek/vimrc.git --depth=1`


 then I use `git log`:

 ```
 commit d04ca09ecc723739123fae11ad56784eb0c9b36a
 Author: Lingchao Xin dougla...@outlook.com
 Date:   Fri Jun 7 09:39:22 2013 +0800

 Update vnudle to master branch, add wm shortcut, pylint optimization

 commit c66d827dc212f6ae8aab6b5c44631564bcbe2acd
 Author: icocoa lingc...@outlook.com
 Date:   Tue Mar 12 01:36:34 2013 -0700

 Merge pull request #1 from douglarek/master

 Add markdown, flake8, pylint plugin

 ```
 but when I clone it with `file://`:

 git clone https://github.com/douglarek/vimrc.git
 git clone file://vimrc.git --depth=1 vimrc1

 I got this log:
 ```
 commit d04ca09ecc723739123fae11ad56784eb0c9b36a
 Author: Lingchao Xin dougla...@outlook.com
 Date:   Fri Jun 7 09:39:22 2013 +0800

 Update vnudle to master branch, add wm shortcut, pylint optimization
 ```

 so the two results are not same, is it a bug? or it should be so?

 My os is openSUSE 12.3 and git version 1.8.3.4; and myabe it occured in git 
 1.8.1.4 +.

The fix is at the server side. =1.8.2 corrects --depth, which is what
you use for file://. github is still on 1.8.1.6, which does not have
that fix. Oh and the commit is 682c7d2 (upload-pack: fix off-by-one
depth calculation in shallow clone - 2013-01-11)
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] branch: not report invalid tracking branch

[Jiang Xin]

2013/8/14 Junio C Hamano gits...@pobox.com
   /*
  - * Return true if there is anything to report, otherwise false.
  + * Return false if cannot stat a tracking branch (not exist or invalid),
  + * otherwise true.
*/
   int stat_tracking_info(struct branch *branch, int *num_ours, int 
  *num_theirs)
   {
  @@ -1740,18 +1741,12 @@ int stat_tracking_info(struct branch *branch, int 
  *num_ours, int *num_theirs)
const char *rev_argv[10], *base;
int rev_argc;
 
  - /*
  -  * Nothing to report unless we are marked to build on top of
  -  * somebody else.
  -  */
  + /* False unless we are marked to build on top of somebody else. */

 Aren't these saying the same thing?  I'd rather see the comment say
 nothing/something to report, instead of false/true.  The latter
 can be read from the value returned in the code, and writing that in
 the comment is redundant.  The former tells the reader what that
 false _means_, which is the whole point of adding a comment.

Maybe Cannot stat unless ... is better than Nothing to report unless ...,
because this patch change the meaning of returns of stat_tracking_info().
And I have already updated the comments for this function.


  + *num_theirs = 0;
  + *num_ours = 0;
  +
/* are we the same? */
if (theirs == ours)
  - return 0;
  + return 1;

 Shouldn't these zero assignments belong to this condition?  I.e.

 if (theirs == ours) {
 *num_theirs = *num_ours = 0;
 return 1;
 }

I will refactor like this,

  @@ -1786,8 +1784,6 @@ int stat_tracking_info(struct branch *branch, int 
  *num_ours, int *num_theirs)
prepare_revision_walk(revs);
 
/* ... and count the commits on each side. */
  - *num_ours = 0;
  - *num_theirs = 0;
while (1) {
struct commit *c = get_revision(revs);
if (!c)

and these two variables(*num_ours and *num_theirs) have to be
initialized here again.

  @@ -1815,6 +1811,10 @@ int format_tracking_info(struct branch *branch, 
  struct strbuf *sb)
if (!stat_tracking_info(branch, num_ours, num_theirs))
return 0;
 
  + /* Nothing to report if neither side has changes. */
  + if (!num_ours  !num_theirs)
  + return 0;

 As far as I can tell, all callers of stat_tracking_info() pass
 non-NULL pointers to these two parameters, with or without your
 patch.  Can this ever trigger?

 The changes you made to builtin/branch.c seems to expect that
 returned *num_ours and *num_theirs could both be 0, so it does not
 look like the above is a typo of

 if (!*num_ours  !*num_theirs)
 return 0;


It's really easy to make people puzzled, since these two hunks in this patch
both have two similar variables: num_ours and num_theirs. But they are
different.

In previous hunk, num_ours and num_theres are from stat_tracking_info(),
and they are pointers.

int stat_tracking_info(struct branch *branch,
   int *num_ours,
   int *num_theirs)

But in this hunk, num_ours and num_theres are defined as integers in
funciton  format_tracking_info().

int format_tracking_info(struct branch *branch, struct strbuf *sb)
{
int num_ours, num_theirs;

To make it clear, I should change the variables name to ours and theirs
just like function fill_tracking_info() in builtin/branch.c.

-- 
Jiang Xin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] gitweb: add plumbing for filename search

[Christopher Durkin]

Add filename search config option and add it to the drop-down.
---
 gitweb/gitweb.perl | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4a7b0a5..087b4cb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -374,6 +374,20 @@ our %feature = (
  'override' = 0,
  'default' = [1]},

+ # Enable the filename search, which will list the files whose
+ # names contain the given string. Enabled by default. Note
+ # that you need to have 'search' feature enabled too.
+
+ # To enable system wide have in $GITWEB_CONFIG
+ # $feature{'filename'}{'default'} = [1];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'filename'}{'override'} = 1;
+ # and in project config gitweb.pickaxe = 0|1;
+ 'filename' = {
+ 'sub' = sub { feature_bool('filename', @_) },
+ 'override' = 0,
+ 'default' = [1]},
+
  # Enable showing size of blobs in a 'tree' view, in a separate
  # column, similar to what 'ls -l' does.  This cost a bit of IO.

@@ -4034,7 +4048,7 @@ sub print_search_form {
   $cgi-input({-name=a, -value=search, -type=hidden}) . \n .
   $cgi-input({-name=h, -value=$search_hash, -type=hidden}) . \n .
   $cgi-popup_menu(-name = 'st', -default = 'commit',
-   -values = ['commit', 'grep', 'author',
'committer', 'pickaxe']) .
+   -values = ['commit', 'grep', 'author',
'committer', 'pickaxe', 'filename']) .
   $cgi-sup($cgi-a({-href = href(action=search_help)}, ?)) .
search:\n,
   $cgi-textfield(-name = s, -value = $searchtext, -override
= 1) . \n .
@@ -7996,6 +8010,12 @@ sub git_search {
  or die_error(403, Grep search is disabled);
  }

+ if ($searchtype eq 'filename') {
+# uses grep on output of git ls-tree, maybe CPU-intensive
+ gitweb_check_feature('filename')
+ or die_error(403, Filename search is disabled);
+ }
+
  if (!defined $searchtext) {
  die_error(400, Text field is empty);
  }
@@ -8018,6 +8038,8 @@ sub git_search {
  git_search_changes(%co);
  } elsif ($searchtype eq 'grep') {
  git_search_files(%co);
+ } elsif ($searchtype eq 'filename') {
+git_search_filenames(%co);
  } else {
  die_error(400, Unknown search type);
  }
-- 
1.8.3.msysgit.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] gitweb: add filename search function

[Christopher Durkin]

Add another item to the search drop-down (author/committer/etc)
to search for file names instead of file content. Output is similar
to the grep contents output, with each entry linking to the file.
---
 gitweb/gitweb.perl | 59 ++
 1 file changed, 59 insertions(+)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f429f75..4a7b0a5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6360,6 +6360,65 @@ sub git_search_grep_body {
  print /table\n;
 }

+sub git_search_filenames {
+my %co = @_;
+local $/ = \n;
+my $match_limit = 1000;
+
+open my $fd, -|, git_cmd(), 'ls-tree', '--name-only',
'--full-name', '-r',
+  $co{'tree'} or die_error(500, Open git-ls-tree failed);
+
+git_header_html();
+
+git_print_page_nav('','', $hash,$co{'tree'},$hash);
+git_print_header_div('commit', esc_html($co{'title'}), $hash);
+
+print table class=\filename_search\\n;
+my $matches = 0;
+my $alternate = 1;
+my $file_href;
+
+while (my $filename = $fd) {
+chomp $filename;
+
+if ($matches  $match_limit) {
+print div class=\diff nodifferences\Too many
matches, listing trimmed/div\n;
+last;
+}
+
+if ($search_use_regexp) {
+next unless ($filename =~ /$searchtext/);
+} else {
+next unless index($filename,$searchtext) = 0;
+}
+
+$matches++;
+$file_href = href(action=blob, hash_base=$co{'id'},
+  file_name=$filename);
+
+ if ($alternate) {
+print tr class=\dark\\n;
+ } else {
+print tr class=\light\\n;
+ }
+ $alternate ^= 1;
+
+print td class=\list\.
+$cgi-a({-href = $file_href, -class = list},
esc_path($filename));
+ print /td\n;
+ print /tr\n;
+}
+
+if ($matches == 0) {
+print div class=\diff nodifferences\No matches found/div\n;
+}
+close $fd;
+
+print /table\n;
+
+git_footer_html();
+}
+
 ## ==
 ## ==
 ## actions
-- 
1.8.3.msysgit.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Duy Nguyen]

On Thu, Aug 15, 2013 at 12:25 AM, Martin Fick mf...@codeaurora.org wrote:
 The script really is mostly a policy script, and with the
 discussions happening in other threads about how to improve
 git gc, I think it is helpful to potentially be able to
 quickly modify the policies in this script, it makes it
 easier to prototype things.  Shell portability issues aside,
 this script is not a low level type of tool that I feel will
 benefit from being in C, I feel it will in fact be worse off
 in C,

I think C is better for the modification you made in git-exproll.sh,
if it gets merged to git-repack.sh. Such calculations are not a strong
point of shell scripting. git-repack.sh is still around for
experimenting, although I think perl, ruby or python is better than
shell for prototyping.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] repack: rewrite the shell script in C.

[Duy Nguyen]

On Thu, Aug 15, 2013 at 5:51 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
 There's a real problem with git-repack being shell (I already mentionned
 it in the previous thread about the rewrite): it creates dependencies on
 a few external binaries, and a restricted server may not have them.

There's also the Windows port. A POSIX shell environment is required
for using git on Windows, but I feel one should be able to use core
functionlity even without POSIX utilities. git-repack is part of this
core in my opinion.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug: commit -p breaks with -m

[Matan Nassau]

With git 1.8.3.3,

 $ seq 5 data
 $ git add data
 $ git commit -mdata
 $ sed -i '2 d' data
 $ git commit -pmchange

At the prompt, type e to edit the hunk. The editor doesn't start, but git 
records a commit.

I found that builtin/commit.c sets the GIT_EDITOR env var to : when the user 
specifies the -m option. This was done in 406400ce4f69. Removing these two 
lines,

 if (!use_editor)
 setenv(GIT_EDITOR, :, 1);

seems to fix the issue, but I'm not sure this won't break the 
prepare-commit-msg hook. I'd like to submit a patch: can I get a hint if this 
change would break commit hooks or anything else I'm not seeing?--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html