date:20130327

Jeff King wrote:
> but also possibly just move it with the other remote parsing, like:
> [...]

Done.  Thanks for the dose of sanity.
--
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] Fixed typo in git-pull manual

2013-03-27 Thread Mihai Capotă

Signed-off-by: Mihai Capotă 
---
 Documentation/git-pull.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index c975743..eec4c1d 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -218,7 +218,7 @@ $ git merge origin/next
 
 
 
-If you tried a pull which resulted in a complex conflicts and
+If you tried a pull which resulted in a complex conflict and
 would want to start over, you can recover with 'git reset'.
 
 
-- 
1.7.9.5

--
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: Composing git repositories

Junio C Hamano wrote:
> So you have to stash it somewhere.  We could have made it to move
> them to $HOME/.safeplace or somewhere totally unrelated to the
> superproject.  So in that sense, the repositories are *not* owned by
> the superproject in any way.  However, you are working within the
> context of the superproject on the submodule after all, and
> somewhere under $GIT_DIR/ of the superorject is not too wrong a
> place to use as such a safe place.

Thanks for the explanation.  The paths in .git/modules are unnecessary
ugly and unwieldy, especially in the case of multiple levels of
nesting: I'll look into converting it to a flat structure using
.git, while handling name conflicts.  I'll also look
into adding a feature to relocate this/ using an object store from an
existing clone.

> Look for floating submodules in the list archive.

The most relevant message thread I could find was [1], back from 2011.
 You argue that floating submodules are Wrong, and that there is no
real usecase for it.

Like I explained earlier, I'm looking at one tool that solves a
superset of the problems mr, repo, submodules, subtrees, and other
tools solve.  I really like the way repo allows me to work on a meta
project like Android or ChromiumOS, but hate that it allows for zero
composition.

To move forward, I have the following design thoughts (elaborating on
my previous email):

1. If .gitmodules is tracked like a normal file, it is absolutely
impossible to tell the possible dependencies of the superproject
without cloning it entirely, and looking at the .gitmodules file in
each of the branches.  Can't we have it as a special ref instead, so I
can `git fetch` just that ref to figure out the dependencies?

2. True composition requires that I be able to specify the entire
manifest (for nested submodules) in the toplevel .gitmodules, or break
it up as I see fit.  This is currently impossible, and brings us back
to #1: the manifest for b/, b/c are in the toplevel repo's special
ref, and I need to fetch c's special ref to figure out what d is (or
error out if no such thing exists).

3. True floating submodules are impossible, because a change in the
submodule means a change in the commit object referenced by the
superproject's tree object; diff-tree will see that some content has
changed in the repository.  We can represent that diff however we want
(using diff.submodule), but we can't change the fact that the change
has to be committed.  Fixing this will require nothing short of
introducing a new kind of object (say "submodule" object which can be
a concrete SHA-1 or point to a ref).

Do you think thinking about these things is worthwhile?  I see more
complaints like [2] as git adoption in the industry increases, but we
have no solution: we can't make git scale to super-large repositories,
and we have no real way to compose smaller repositories.  Hacks like
repo sadden me.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/185164
[2]: http://thread.gmane.org/gmane.comp.version-control.git/189776
--
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 ate my home directory :-(

2013-03-27 Thread Duy Nguyen

On Tue, Mar 26, 2013 at 10:04 PM, Jeff King  wrote:
>>   specifies a path to use instead of the default `.git`
>>   for the base of the repository.
>>   The '--git-dir' command-line option also sets this value.
>> + If neither GIT_WORK_TREE nor '--work-tree' is set, the
>> + current directory will become the working tree.
>
> I think this is a good thing to mention, but a few nits:
>
>   1. core.worktree is another way of setting it
>
>   2. This can also be overridden by --bare (at least in "next").
>
>   3. I think having core.bare set will also override this

Yeah, I looked back at t1510 and gave up. I think it's still true:

-- 8< --
A few rules for repo setup:

1. GIT_DIR is relative to user's cwd. --git-dir is equivalent to
   GIT_DIR.

2. .git file is relative to parent directory. .git file is basically
   symlink in disguise. The directory where .git file points to will
   become new git_dir.

3. core.worktree is relative to git_dir.

4. GIT_WORK_TREE is relative to user's cwd. --work-tree is
   equivalent to GIT_WORK_TREE.

5. GIT_WORK_TREE/core.worktree was originally meant to work only if
   GIT_DIR is set, but earlier git didn't enforce it, and some scripts
   depend on the implementation that happened to first discover .git by
   going up from the users $cwd and then using the specified working tree
   that may or may not have any relation to where .git was found in.  This
   historical behaviour must be kept.

6. Effective GIT_WORK_TREE overrides core.worktree and core.bare

7. Effective core.worktree conflicts with core.bare

8. If GIT_DIR is set but neither worktree nor bare setting is given,
   original cwd becomes worktree.
-- 8< --
-- 
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 gitk] notes not reloaded on Update/Reload

2013-03-27 Thread Uwe Kleine-König

Hello,

running gitk from Debian (1:1.8.2~rc3-1) I noticed that

$ gitk ... &
$ git notes edit $some_ref_shown_by_gitk

and then pressing F5 or Shift-F5 doesn't update the notes shown.

Best regards
Uwe

PS: Please Cc: on replies as I'm not subscribed

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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 gitk] strange scrolling behaviour if history canvas not completely filled

2013-03-27 Thread Uwe Kleine-König

Hello,

(running gitk from Debian's gitk 1:1.8.2~rc3-1 package)

if only a few commits are shown in gitk such that the history canvas is
too big, i.e. there is place for more commits to be shown, the scroll
bar on the right hand side correctly is greyed out. Still I can scroll
using the mouse moving the oldest shown to the bottom of the canvas
(sometimes even half a line further). Not sure this qualifies as bug
already.

But when having scrolled down selecting commits with the mouse doesn't
work as expected anymore: If I click on the topmost commit, not that one
is selected but the one that would appear at the mouse tip if the
history were not scrolled down.

Best regards
Uwe

PS: I'm not subscribed, so please Cc: me on replies.

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] gitk: Move hard-coded colors to .gitk

2013-03-27 Thread Gauthier Östervall

Colors that are changeable in Preferences gave no sufficient control,
putting colors in the config file allows for easier configuration and
sharing of color schemes.

win32: Make the default foreground color that of window text rather
than button text.

Signed-off-by: Gauthier Östervall 
---
Screenshot of my current coloring setup using this patch, based on
zenburn:
http://s11.postimg.org/hozbtsfj7/gitk_zenburn.png
And the .gitk used to that end:
https://gist.github.com/fleutot/5253281

 gitk | 149 +--
 1 file changed, 110 insertions(+), 39 deletions(-)

diff --git a/gitk b/gitk
index b3706fc..2edaaa8 100755
--- a/gitk
+++ b/gitk
@@ -2026,6 +2026,9 @@ proc makewindow {} {
 global highlight_files gdttype
 global searchstring sstring
 global bgcolor fgcolor bglist fglist diffcolors selectbgcolor
+global uifgcolor uifgdisabledcolor
+global filesepbgcolor filesepfgcolor
+global mergecolors foundbgcolor currentsearchhitbgcolor
 global headctxmenu progresscanv progressitem progresscoords statusw
 global fprogitem fprogcoord lastprogupdate progupdatepending
 global rprogitem rprogcoord rownumsel numcommits
@@ -2177,10 +2180,10 @@ proc makewindow {} {
0x00, 0x38, 0xff, 0x7f, 0xff, 0x7f, 0xff, 0x7f, 0x00, 0x38, 0x00, 0x1c,
0x00, 0x0e, 0x00, 0x07, 0x80, 0x03, 0xc0, 0x01};
 }
-image create bitmap bm-left -data $bm_left_data
-image create bitmap bm-left-gray -data $bm_left_data -foreground "#999"
-image create bitmap bm-right -data $bm_right_data
-image create bitmap bm-right-gray -data $bm_right_data -foreground "#999"
+image create bitmap bm-left -data $bm_left_data -foreground $uifgcolor
+image create bitmap bm-left-gray -data $bm_left_data -foreground 
$uifgdisabledcolor
+image create bitmap bm-right -data $bm_right_data -foreground $uifgcolor
+image create bitmap bm-right-gray -data $bm_right_data -foreground 
$uifgdisabledcolor
 
 ${NS}::button .tf.bar.leftbut -command goback -state disabled -width 26
 if {$use_ttk} {
@@ -2349,32 +2352,32 @@ proc makewindow {} {
 lappend fglist $ctext
 
 $ctext tag conf comment -wrap $wrapcomment
-$ctext tag conf filesep -font textfontbold -back "#aa"
+$ctext tag conf filesep -font textfontbold -fore $filesepfgcolor -back 
$filesepbgcolor
 $ctext tag conf hunksep -fore [lindex $diffcolors 2]
 $ctext tag conf d0 -fore [lindex $diffcolors 0]
 $ctext tag conf dresult -fore [lindex $diffcolors 1]
-$ctext tag conf m0 -fore red
-$ctext tag conf m1 -fore blue
-$ctext tag conf m2 -fore green
-$ctext tag conf m3 -fore purple
-$ctext tag conf m4 -fore brown
-$ctext tag conf m5 -fore "#009090"
-$ctext tag conf m6 -fore magenta
-$ctext tag conf m7 -fore "#808000"
-$ctext tag conf m8 -fore "#009000"
-$ctext tag conf m9 -fore "#ff0080"
-$ctext tag conf m10 -fore cyan
-$ctext tag conf m11 -fore "#b07070"
-$ctext tag conf m12 -fore "#70b0f0"
-$ctext tag conf m13 -fore "#70f0b0"
-$ctext tag conf m14 -fore "#f0b070"
-$ctext tag conf m15 -fore "#ff70b0"
+$ctext tag conf m0 -fore [lindex $mergecolors 0]
+$ctext tag conf m1 -fore [lindex $mergecolors 1]
+$ctext tag conf m2 -fore [lindex $mergecolors 2]
+$ctext tag conf m3 -fore [lindex $mergecolors 3]
+$ctext tag conf m4 -fore [lindex $mergecolors 4]
+$ctext tag conf m5 -fore [lindex $mergecolors 5]
+$ctext tag conf m6 -fore [lindex $mergecolors 6]
+$ctext tag conf m7 -fore [lindex $mergecolors 7]
+$ctext tag conf m8 -fore [lindex $mergecolors 8]
+$ctext tag conf m9 -fore [lindex $mergecolors 9]
+$ctext tag conf m10 -fore [lindex $mergecolors 10]
+$ctext tag conf m11 -fore [lindex $mergecolors 11]
+$ctext tag conf m12 -fore [lindex $mergecolors 12]
+$ctext tag conf m13 -fore [lindex $mergecolors 13]
+$ctext tag conf m14 -fore [lindex $mergecolors 14]
+$ctext tag conf m15 -fore [lindex $mergecolors 15]
 $ctext tag conf mmax -fore darkgrey
 set mergemax 16
 $ctext tag conf mresult -font textfontbold
 $ctext tag conf msep -font textfontbold
-$ctext tag conf found -back yellow
-$ctext tag conf currentsearchhit -back orange
+$ctext tag conf found -back $foundbgcolor
+$ctext tag conf currentsearchhit -back $currentsearchhitbgcolor
 $ctext tag conf wwrap -wrap word
 
 .pwbottom add .bleft
@@ -2721,6 +2724,14 @@ proc savestuff {w} {
 global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
 global cmitmode wrapcomment datetimeformat limitdiffs
 global colors uicolor bgcolor fgcolor diffcolors diffcontext selectbgcolor
+global uifgcolor uifgdisabledcolor
+global headbgcolor headfgcolor headoutlinecolor remotebgcolor
+global tagbgcolor tagfgcolor tagoutlinecolor
+global reflinecolor filesepbgcolor filesepfgcolor
+global mergecolors foundbgcolor currentsearchhitbgc

Re: merge help

2013-03-27 Thread Magnus Bäck

On Tuesday, March 26, 2013 at 18:07 EDT,
 "J.V."  wrote:

> I have a branch for which I have made 0 (nada) changes.  I did the
> following:
> 
> $git pull --rebase --no-stat -v --progress origin mybranch
> 
> I get the following
> 
> U   java/Profile.java
> Pull is not possible because you have unmerged files.
> Please, fix them up in the work tree, and then use 'git add/rm '
> as appropriate to mark resolution, or use 'git commit -a'.
> --   (there is no local master branch), because of the
> conflict I was put on (no branch)
> * (no branch)
>   branch1
>   dev
>   tmpWork
> 
> Question 1)
> Why did I get a merge conflict if I have not changed any files?

The error message indicates that you already had a pending merge
conflict when you initiated the pull. Why you had that is impossible
to tell.

> Question 2)
> What is the command to show the difference between the files? (is
> there a visual tool that would let me merge)?

You're looking for this form of "git diff":

   git diff [options]   [--] [...]

Example:

   git diff origin/master HEAD -- file.c file.h

There are many graphical diff and merge tools that you can configure
for use with Git, e.g. kdiff3 and meld. See git-difftool(1) and
git-mergetool(1).

[...]

-- 
Magnus Bäck
ba...@google.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

[PATCH] Enhance git-commit doc for multiple `-m` options

2013-03-27 Thread Christian Helmuth

The text is copied from Documentation/git-tag.txt.

Signed-off-by: Christian Helmuth 
---
 Documentation/git-commit.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 24a99cc..05f8297 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -137,6 +137,8 @@ OPTIONS
 -m ::
 --message=::
Use the given  as the commit message.
+   If multiple `-m` options are given, their values are
+   concatenated as separate paragraphs.
 
 -t ::
 --template=::
-- 
1.8.1.5


-- 
Christian Helmuth
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
--
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] git-web--browse: recognize iTerm as a GUI terminal on OS X

John Szakmeister  writes:

> Sorry about the repeat Junio, I meant to hit "Reply to All".
>
> On Mon, Mar 25, 2013 at 5:44 PM, Junio C Hamano  wrote:
> [snip]
>> Your patch makes me wonder if
>>
>> test -n "$TERM_PROGRAM"
>>
>> without any SECURITYSESSIONID or explicit program name checks should
>> suffice, though.
>
> So, after downloading a couple of other terminals and trying things
> out, I think you're suggestion does suffice.  Should I send an updated
> patch?

If that approach is better than what you originally sent, then yes.

But I do not use OS X, so you may need to pay attention to possible
complaints and comments from other Mac users on this list for a
while---there may be people who run the program in question without
that environment variable.
--
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: propagating repo corruption across clone

Sitaram Chamarty  writes:

> On Wed, Mar 27, 2013 at 9:17 AM, Junio C Hamano  wrote:
>
>> To be paranoid, you may want to set transfer.fsckObjects to true,
>> perhaps in your ~/.gitconfig.
>
> do we have any numbers on the overhead of this?
>
> Even a "guesstimate" will do...

On a reasonably slow machine:

$ cd /project/git/git.git && git repack -a -d
$ ls -hl .git/objects/pack/*.pack
-r--r--r-- 1 junio src 44M Mar 26 13:18 
.git/objects/pack/pack-c40635e5ee2b7094eb0e2c416e921a2b129bd8d2.pack

$ cd .. && git --bare init junk && cd junk
$ time git index-pack --strict --stdin <../git.git/.git/objects/pack/*.pack
real0m13.873s
user0m21.345s
sys 0m2.248s

That's about 3.2 Mbps?

Compare that with the speed your other side feeds you (or your line
speed could be the limiting factor) and decide how much you value
your data.
--
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 15/15] t7502: remove clear_config

Yann Droneaud  writes:

> Using test_config ensure the configuration variable are removed
> at the end of the test, there's no need to remove variable
> at the beginning of the test.
>
> Signed-off-by: Yann Droneaud 

This is a good change in the longer term, but there must not be any
other topic in-flight that adds new tests that modify configuration
in a persistent way, which your previous patch based on 'master'
wouldn't have addressed, for this to be a safe change (I assume that
you already have checked that).

Otherwise these apparently redundant unsets need to be left as "belt
and suspenders" safety.  The same for the change to 4202 in [PATCH
07/15].

Thanks.
--
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 00/15] Use test_config

Yann Droneaud  writes:

> Tested against master, 7b592fadf1e23b10b913e0771b9f711770597266

Is this because I suggested you to clean things up while you were
touching in a vicinity of something that could use this clean-up?

If so, please first clean _that_ script in a patch, and then add the
change you wanted to do in another patch, as a single two-patch
series, without touching anything else that is not related to that
change.  The patch to t7600 is the one that needs to become two
patches, one to clean up and the other to add tests for --no-ff.

The rest, as a separate "only cleaning up, doing nothing else"
series, are fine as a follow-up, but please make sure that they do
not touch anything in-flight (one easy way to check is to see "git
diff --name-only maint pu -- t/").  I would prefer to see "clean-up
only" changes that introduce unnecessary conflicts with other real
features and fixes held off until the dust settles.

> Yann Droneaud (15):
>   t4018: remove test_config implementation
>   t7810: remove test_config implementation
>   t7811: remove test_config implementation

We already have equivalents of these in-flight.

>   t7600: use test_config to set/unset git config variables

Needs to be split into two.

--
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 v2] log: Read gpg settings for signed commit verification

2013-03-27 Thread Hans Brigman

From: Jacob Sarvis

log: Read gpg settings for signed commit verification

Commit signature verification fails when alternative gpg.program
signs the commit, but gpg attempts to verify the signature.
"show --show-signature" and "log --show-signature" do not read
the gpg.program setting from git config.
Commit signing, tag signing, and tag verification use this setting
properly.

Make log and show commands pass through settings to gpg interface.

Signed-off-by: Hans Brigman 
---
 builtin/log.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/builtin/log.c b/builtin/log.c
index 8f0b2e8..31f5a9e 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -23,6 +23,7 @@
 #include "streaming.h"
 #include "version.h"
 #include "mailmap.h"
+#include "gpg-interface.h"

 /* Set a default date-time format for git log ("log.date" config variable) */
 static const char *default_date_mode = NULL;
@@ -364,7 +365,8 @@ static int git_log_config(const char *var, const char 
*value, void *cb)
use_mailmap_config = git_config_bool(var, value);
return 0;
}
-
+   if (git_gpg_config(var, value, cb) < 0)
+   return -1;
if (grep_config(var, value, cb) < 0)
return -1;
return git_diff_ui_config(var, value, cb);
-- 
1.7.11.msysgit.0

On Mon, Mar 25, 2013 at 01:03:52PM -0500, Hans Brigman wrote:

> "show --show-signature" doesn't currently use the gpg.program setting.  
> Commit signing, tag signing, and tag verification currently use this setting 
> properly, so the logic has been added to handle it here as well.

Please wrap your commit messages at something reasonable (70 is probably as 
high as you want to go, given that log output is often shown indented).

> @@ -364,7 +365,8 @@ static int git_log_config(const char *var, const char 
> *value, void *cb)
>   use_mailmap_config = git_config_bool(var, value);
>   return 0;
>   }
> -
> + if (!prefixcmp(var, "gpg."))
> + return git_gpg_config(var, value, NULL);
>   if (grep_config(var, value, cb) < 0)
>   return -1;

The gpg config can also be other places than "gpg.*". Right now it is just 
user.signingkey, which log would not care about, but it feels like we are 
depending an unnecessary detail here. We also don't know whether it would care 
about the callback data. Is there a reason not to do:

  if (git_gpg_config(var, value, cb) < 0)
  return -1;

just like the grep_config call below?

-Peff

0001-log-Read-gpg-settings-for-signed-commit-verification.patch
Description: 0001-log-Read-gpg-settings-for-signed-commit-verification.patch

Segfault with merge-tree on multiple Git versions


I am experiencing a segmentation fault in various versions of Git using
different repositories. Specifically, I have reproduced it using a
public repo and the latest stable Git version. Other repos trigger the
error on different versions.

Full info can be found below. Thanks,

Charlie


Test repository:
https://github.com/atech/mail

Test Command
git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945f231cd7c8fb1cfe48b3a12083

Environment:
Linux codebase-staging 2.6.32-41-server #91-Ubuntu SMP Wed Jun 13
11:58:56 UTC 2012 x86_64 GNU/Linux

Git:
git version 1.8.2

Output:
charlie@codebase-staging:~/mail$ git merge-tree
26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945f231cd7c8fb1cfe48b3a12083
Segmentation fault



Charlie Smurthwaite aTech Media

tel. 01202 901 222 (ext. 603) email. 
char...@atechmedia.com web. 
atechmedia.com

aTech Media Limited is a registered company in England and Wales. Registration 
Number 5523199. Registered Office: Unit 9 Winchester Place, North Street, 
Poole, Dorset, BH15 1NX. VAT Registration Number: GB 868 861 560. This e-mail 
is confidential and for the intended recipient only. If you are not the 
intended recipient, be advised that you have received this e-mail in error and 
that any use, dissemination, forwarding, printing, or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the sender.
--
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 v2 00/45] parse_pathspec and :(glob) magic

Duy Nguyen  writes:

> On Sat, Mar 23, 2013 at 10:13 AM, Duy Nguyen  wrote:
>> which also includes all document bugs reported so far.
>
> s/all/fixes for all/

Slurped from your github repository and didn't find anything
questionable relative to the original series that was posted here.

Thanks.  Will requeue.
--
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: propagating repo corruption across clone

2013-03-27 Thread Sitaram Chamarty

On Wed, Mar 27, 2013 at 8:33 PM, Junio C Hamano  wrote:
> Sitaram Chamarty  writes:
>
>> On Wed, Mar 27, 2013 at 9:17 AM, Junio C Hamano  wrote:
>>
>>> To be paranoid, you may want to set transfer.fsckObjects to true,
>>> perhaps in your ~/.gitconfig.
>>
>> do we have any numbers on the overhead of this?
>>
>> Even a "guesstimate" will do...
>
> On a reasonably slow machine:
>
> $ cd /project/git/git.git && git repack -a -d
> $ ls -hl .git/objects/pack/*.pack
> -r--r--r-- 1 junio src 44M Mar 26 13:18 
> .git/objects/pack/pack-c40635e5ee2b7094eb0e2c416e921a2b129bd8d2.pack
>
> $ cd .. && git --bare init junk && cd junk
> $ time git index-pack --strict --stdin <../git.git/.git/objects/pack/*.pack
> real0m13.873s
> user0m21.345s
> sys 0m2.248s
>
> That's about 3.2 Mbps?
>
> Compare that with the speed your other side feeds you (or your line
> speed could be the limiting factor) and decide how much you value
> your data.

Thanks.  I was also interested in overhead on the server just as a %-age.

I have no idea why but when I did some tests a long time ago I got
upwards of 40% or so, but now when I try these tests for git.git

cd 
git init --bare
# git config transfer.fsckobjects true
git fetch file:///full/path/to/git.git refs/*:refs/*

then, the difference in elapsed time 18s -> 22s, so about 22%, and CPU
time is 31 -> 37, so about 20%.  I didn't measure disk access
increases, but I guess 20% is not too bad.

Is it likely to be linear in the size of the repo, by and large?
--
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: Segfault with merge-tree on multiple Git versions

2013-03-27 Thread thomas

Charlie Smurthwaite  writes:

> I am experiencing a segmentation fault in various versions of Git using
> different repositories. Specifically, I have reproduced it using a
> public repo and the latest stable Git version. Other repos trigger the
> error on different versions.
>
> Full info can be found below. Thanks,
>
> Charlie
>
>
> Test repository:
> https://github.com/atech/mail
>
> Test Command
> git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
> 8d6bdf012941d876b2279994e02f1bb0d5c26e7d
> d5ef97ac407d945f231cd7c8fb1cfe48b3a12083

I happened to walk past on IRC and found I could easily reproduce it, so
I bisected:

  35ffe7583108ab236dcf81226690388491d9962f is the first bad commit
  commit 35ffe7583108ab236dcf81226690388491d9962f
  Author: Junio C Hamano 
  Date:   Thu Dec 13 15:51:29 2012 -0800

  merge-tree: fix d/f conflicts
  
  The previous commit documented two known breakages revolving around
  a case where one side flips a tree into a blob (or vice versa),
  where the original code simply gets confused and feeds a mixture of
  trees and blobs into either the recursive merge-tree (and recursing
  into the blob will fail) or three-way merge (and merging tree contents
  together with blobs will fail).
  
  Fix it by feeding trees (and only trees) into the recursive
  merge-tree machinery and blobs (and only blobs) into the three-way
  content level merge machinery separately; when this happens, the
  entire merge has to be marked as conflicting at the structure level.
  
  Signed-off-by: Junio C Hamano 

It seems to be a vanilla null dereference:

  Program received signal SIGSEGV, Segmentation fault.
  0x00453bf9 in add_merge_entry (entry=0x0) at builtin/merge-tree.c:24
  24  *merge_result_end = entry;
  (gdb) bt
  #0  0x00453bf9 in add_merge_entry (entry=0x0) at 
builtin/merge-tree.c:24
  #1  0x004545f4 in unresolved (info=0x7fffce90, n=0x7ff7f0) at 
builtin/merge-tree.c:265
  #2  0x00454741 in threeway_callback (n=3, mask=7, dirmask=7, 
entry=0x7ff7f0, 
  info=0x7fffce90) at builtin/merge-tree.c:330
  #3  0x005233f3 in traverse_trees (n=3, t=0x7fffcf10, 
info=0x7fffce90)
  at tree-walk.c:407
  #4  0x00454792 in merge_trees_recursive (t=0x7fffcf10, 
base=0x800530 "lib/mail", 
  df_conflict=1) at builtin/merge-tree.c:341
  #5  0x00454382 in unresolved_directory (info=0x7fffd120, 
n=0x800420, df_conflict=1)
  at builtin/merge-tree.c:216
  #6  0x00454507 in unresolved (info=0x7fffd120, n=0x800420) at 
builtin/merge-tree.c:253
  #7  0x00454741 in threeway_callback (n=3, mask=7, dirmask=7, 
entry=0x800420, 
  info=0x7fffd120) at builtin/merge-tree.c:330
  #8  0x005233f3 in traverse_trees (n=3, t=0x7fffd1a0, 
info=0x7fffd120)
  at tree-walk.c:407
  #9  0x00454792 in merge_trees_recursive (t=0x7fffd1a0, 
base=0x7fd170 "lib", df_conflict=1)
  at builtin/merge-tree.c:341
  #10 0x00454382 in unresolved_directory (info=0x7fffd3b0, 
n=0x8069f0, df_conflict=1)
  at builtin/merge-tree.c:216
  #11 0x00454507 in unresolved (info=0x7fffd3b0, n=0x8069f0) at 
builtin/merge-tree.c:253
  #12 0x00454741 in threeway_callback (n=3, mask=7, dirmask=7, 
entry=0x8069f0, 
  info=0x7fffd3b0) at builtin/merge-tree.c:330
  #13 0x005233f3 in traverse_trees (n=3, t=0x7fffd450, 
info=0x7fffd3b0)
  at tree-walk.c:407
  #14 0x00454792 in merge_trees_recursive (t=0x7fffd450, 
base=0x5510fc "", df_conflict=0)
  at builtin/merge-tree.c:341
  #15 0x004547bc in merge_trees (t=0x7fffd450, base=0x5510fc "") at 
builtin/merge-tree.c:346
  #16 0x004548ef in cmd_merge_tree (argc=4, argv=0x7fffd728, 
prefix=0x0)
  at builtin/merge-tree.c:373
  #17 0x004056ec in run_builtin (p=0x7a1c88 , 
argc=4, argv=0x7fffd728)
  at git.c:273
  #18 0x0040587f in handle_internal_command (argc=4, 
argv=0x7fffd728) at git.c:434
  #19 0x00405a4b in main (argc=4, argv=0x7fffd728) at git.c:523

Unfortunately I'm not familiar with the merge code, but if you can't
reproduce at your end let me know.

-- 
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: Segfault with merge-tree on multiple Git versions

On Wed, Mar 27, 2013 at 04:53:27PM +0100, thomas wrote:
> Charlie Smurthwaite  writes:
> 
> > I am experiencing a segmentation fault in various versions of Git using
> > different repositories. Specifically, I have reproduced it using a
> > public repo and the latest stable Git version. Other repos trigger the
> > error on different versions.
> >
> > Full info can be found below. Thanks,
> >
> > Charlie
> >
> >
> > Test repository:
> > https://github.com/atech/mail
> >
> > Test Command
> > git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
> > 8d6bdf012941d876b2279994e02f1bb0d5c26e7d
> > d5ef97ac407d945f231cd7c8fb1cfe48b3a12083
> 
> I happened to walk past on IRC and found I could easily reproduce it, so
> I bisected:
> 
>   35ffe7583108ab236dcf81226690388491d9962f is the first bad commit
>   commit 35ffe7583108ab236dcf81226690388491d9962f
>   Author: Junio C Hamano 
>   Date:   Thu Dec 13 15:51:29 2012 -0800
> 
>   merge-tree: fix d/f conflicts
>   
>   The previous commit documented two known breakages revolving around
>   a case where one side flips a tree into a blob (or vice versa),
>   where the original code simply gets confused and feeds a mixture of
>   trees and blobs into either the recursive merge-tree (and recursing
>   into the blob will fail) or three-way merge (and merging tree contents
>   together with blobs will fail).
>   
>   Fix it by feeding trees (and only trees) into the recursive
>   merge-tree machinery and blobs (and only blobs) into the three-way
>   content level merge machinery separately; when this happens, the
>   entire merge has to be marked as conflicting at the structure level.
>   
>   Signed-off-by: Junio C Hamano 

Looks like a simple typo in merge-tree.c::unresolved:

-- >8 --
merge-tree: fix typo in merge-tree.c::unresolved

When calculating whether there is a d/f conflict, the calculation of
whether both sides are directories generates an incorrect references
mask because it does not use the loop index to set the correct bit.
Fix this typo.

Signed-off-by: John Keeping 

diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index e0d0b7d..bc912e3 100644
--- a/builtin/merge-tree.c
+++ b/builtin/merge-tree.c
@@ -245,7 +245,7 @@ static void unresolved(const struct traverse_info *info, 
struct name_entry n[3])
unsigned dirmask = 0, mask = 0;
 
for (i = 0; i < 3; i++) {
-   mask |= (1 << 1);
+   mask |= (1 << i);
if (n[i].mode && S_ISDIR(n[i].mode))
dirmask |= (1 << i);
}
--
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] log: make "show --show-signature" use gpg.program setting

Jeff King  writes:

> On Mon, Mar 25, 2013 at 01:03:52PM -0500, Hans Brigman wrote:
>
>> "show --show-signature" doesn't currently use the gpg.program setting.  
>> Commit signing, tag signing, and tag verification currently use this setting 
>> properly, so the logic has been added to handle it here as well.
>
> Please wrap your commit messages at something reasonable (70 is probably
> as high as you want to go, given that log output is often shown
> indented).

Thanks for pointing out Documentation/SubmittingPatches.

Also please do not send multipart/mixed (or alternative).  Send
patches in text/plain.

>> @@ -364,7 +365,8 @@ static int git_log_config(const char *var, const char 
>> *value, void *cb)
>>  use_mailmap_config = git_config_bool(var, value);
>>  return 0;
>>  }
>> -
>> +if (!prefixcmp(var, "gpg."))
>> +return git_gpg_config(var, value, NULL); 
>>  if (grep_config(var, value, cb) < 0)
>>  return -1;
>
> The gpg config can also be other places than "gpg.*". Right now it is
> just user.signingkey, which log would not care about, but it feels like
> we are depending an unnecessary detail here. We also don't know whether
> it would care about the callback data. Is there a reason not to do:
>
>   if (git_gpg_config(var, value, cb) < 0)
>   return -1;
>
> just like the grep_config call below?
>
> -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: Segfault with merge-tree on multiple Git versions

John Keeping  writes:

> merge-tree: fix typo in merge-tree.c::unresolved
>
> When calculating whether there is a d/f conflict, the calculation of
> whether both sides are directories generates an incorrect references
> mask because it does not use the loop index to set the correct bit.
> Fix this typo.
>
> Signed-off-by: John Keeping 
>
> diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
> index e0d0b7d..bc912e3 100644
> --- a/builtin/merge-tree.c
> +++ b/builtin/merge-tree.c
> @@ -245,7 +245,7 @@ static void unresolved(const struct traverse_info *info, 
> struct name_entry n[3])
>   unsigned dirmask = 0, mask = 0;
>  
>   for (i = 0; i < 3; i++) {
> - mask |= (1 << 1);
> + mask |= (1 << i);
>   if (n[i].mode && S_ISDIR(n[i].mode))
>   dirmask |= (1 << i);
>   }

Indeed, that fixes 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

Re: Composing git repositories

Ramkumar Ramachandra  writes:

> Junio C Hamano wrote:
>> So you have to stash it somewhere.  We could have made it to move
>> them to $HOME/.safeplace or somewhere totally unrelated to the
>> superproject.  So in that sense, the repositories are *not* owned by
>> the superproject in any way.  However, you are working within the
>> context of the superproject on the submodule after all, and
>> somewhere under $GIT_DIR/ of the superorject is not too wrong a
>> place to use as such a safe place.
>
> Thanks for the explanation.

What do you _exactly_ mean by that?  You understood why things are
arranged in that way, and no longer think that it is unnecessary,
ugly and unwieldy to stash the real copy of $GIT_DIR of submodules
away from their working trees and store them inside $GIT_DIR/modules
of the superproject?

> The paths in .git/modules are unnecessary ugly and unwieldy,
> especially in the case of multiple levels of nesting...
--
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] Fixed typo in git-pull manual

Mihai Capotă  writes:

> Signed-off-by: Mihai Capotă 
> ---

Thanks.

It might be better to make it "which resulted in complex conflicts",
though.

>  Documentation/git-pull.txt |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index c975743..eec4c1d 100644
> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@ -218,7 +218,7 @@ $ git merge origin/next
>  
>  
>  
> -If you tried a pull which resulted in a complex conflicts and
> +If you tried a pull which resulted in a complex conflict and
>  would want to start over, you can recover with 'git reset'.
--
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 v2] log: Read gpg settings for signed commit verification

Hans Brigman  writes:

> Content-Type: multipart/mixed; 
> boundary="_002_8C726954D36902459248B0627BF2E66F45D70C3E4EAUSP01VMBX10c_"

No multipart/anything please.  We prefer to see text/plain.

In general, please follow Documentation/SubmittingPatches.

> From: Jacob Sarvis

Missing SP between name and e-mail.

>
> log: Read gpg settings for signed commit verification

That's the same as the e-mail subject; drop it.

>
> Commit signature verification fails when alternative gpg.program
> signs the commit, but gpg attempts to verify the signature.
> "show --show-signature" and "log --show-signature" do not read
> the gpg.program setting from git config.
> Commit signing, tag signing, and tag verification use this setting
> properly.
>
> Make log and show commands pass through settings to gpg interface.
>
> Signed-off-by: Hans Brigman 

Needs the author's Sign-off before yours.

> ---
>  builtin/log.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index 8f0b2e8..31f5a9e 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -23,6 +23,7 @@
>  #include "streaming.h"
>  #include "version.h"
>  #include "mailmap.h"
> +#include "gpg-interface.h"
>  
>  /* Set a default date-time format for git log ("log.date" config variable) */
>  static const char *default_date_mode = NULL;
> @@ -364,7 +365,8 @@ static int git_log_config(const char *var, const char 
> *value, void *cb)
>   use_mailmap_config = git_config_bool(var, value);
>   return 0;
>   }
> -
> + if (git_gpg_config(var, value, cb) < 0)
> + return -1;
>   if (grep_config(var, value, cb) < 0)
>   return -1;

Hmph.  I do not particularly like the way the call to grep_config()
loses information by not ignoring its return value and always
returning -1, but I'll let it pass for this patch.

>   return git_diff_ui_config(var, value, cb);
--
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] config: Consistent call style to gpg settings

Hans Brigman  writes:

> From: Jacob Sarvis 
>
> config: Consistent call style to gpg settings
>
> Calling style for passing settings to git_gpg_config is inconsistent
> between commit-tree, commit, merge, tag, and verify-tag.
>
> Consolidate style of calling git_gpg_config.
>
> Signed-off-by: Hans Brigman 

Exactly the same comments as the review for the other patch apply here.

> ---
> builtin/commit-tree.c |  5 ++---
> builtin/commit.c  |  6 ++
> builtin/merge.c   | 12 
> builtin/tag.c |  5 ++---
> builtin/verify-tag.c  |  5 ++---
> 5 files changed, 12 insertions(+), 21 deletions(-)
>
> diff --git a/builtin/commit-tree.c b/builtin/commit-tree.c
> index eac901a..45e0152 100644
> --- a/builtin/commit-tree.c
> +++ b/builtin/commit-tree.c
> @@ -28,9 +28,8 @@ static void new_parent(struct commit *parent, struct 
> commit_list **parents_p)
>  static int commit_tree_config(const char *var, const char *value, void *cb)
> {
> -  int status = git_gpg_config(var, value, NULL);
> -  if (status)
> -  return status;
> + if (git_gpg_config(var, value, cb) < 0)
> + return -1;
>return git_default_config(var, value, cb);
> }

Earlier, we always returned what the underlying helper returned, but
in this version, we ignore error return values from git_gpg_config()
but honor error return values from git_default_config().

This is making things worse, 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: [PATCH 00/15] Use test_config

2013-03-27 Thread Yann Droneaud


Hi,

Le 27.03.2013 16:05, Junio C Hamano a écrit :

Yann Droneaud  writes:


Tested against master, 7b592fadf1e23b10b913e0771b9f711770597266


Is this because I suggested you to clean things up while you were
touching in a vicinity of something that could use this clean-up?



Yes, grep'ing shows others usage of the test_config pattern. I patched 
them all.



If so, please first clean _that_ script in a patch, and then add the
change you wanted to do in another patch, as a single two-patch
series, without touching anything else that is not related to that
change.  The patch to t7600 is the one that needs to become two
patches, one to clean up and the other to add tests for --no-ff.



Actually the initial patch adding test for --no-ff-only is not part of 
this series.



Patch against t7600 has a special note about a strange behavor found 
while testing
test_config "anyware", that's why there's somes line added to the test 
and a note

in the commit message.

I was waiting for your opinion on this change in the test, but more, on 
the difference

of behavior exhibited in the patched test "merge log message":

  git merge --no-log
  git show -s --pretty=format:%b HEAD

vs

  git merge --no-ff --no-log
  git show -s --pretty=format:%b HEAD


First produce an empty file, while the second produce an empty line.

This was revealed by changing test "merge c0 with c1 (ff overrides 
no-ff)

-git config branch.master.mergeoptions "--no-ff" &&
-test_config branch.master.mergeoptions "--no-ff" &&


I could split this patch in a first patch that add the behavor test to 
"merge log message" test,

than I could rebase the patch series against.
And later, submit my proposition for new tests in t7600 regarding 
--no-ff-only and tags.



The rest, as a separate "only cleaning up, doing nothing else"
series, are fine as a follow-up, but please make sure that they do
not touch anything in-flight (one easy way to check is to see "git
diff --name-only maint pu -- t/").  I would prefer to see "clean-up
only" changes that introduce unnecessary conflicts with other real
features and fixes held off until the dust settles.



It's a good advice that fit perfectly in 
Documentation/SubmittingPatches.


Regards.

--
Yann Droneaud
OPTEYA

--
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 v2] log: Read gpg settings for signed commit verification

On Wed, Mar 27, 2013 at 09:15:58AM -0700, Junio C Hamano wrote:

> > }
> > -
> > +   if (git_gpg_config(var, value, cb) < 0)
> > +   return -1;
> > if (grep_config(var, value, cb) < 0)
> > return -1;
> 
> Hmph.  I do not particularly like the way the call to grep_config()
> loses information by not ignoring its return value and always
> returning -1, but I'll let it pass for this patch.

That's my fault for suggesting he follow the same style as grep here.
But I wonder if it is worth the effort. We have never cared about
anything beyond "was there an error" in our config callbacks, and the
value returned from the callbacks is lost in git_parse_file (i.e., we do
not propagate the actual return value, but only check that
"callback(var, value, data) < 0", and die if so).

Existing callbacks pass data out by writing into a struct pointed to by
the data pointer, which is more flexible, anyway.

So unless you want to overhaul the whole config system to propagate
return codes back to the caller, I do not think there is any point in
worrying about it.

-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] git-svn: Support custom tunnel schemes instead of SSH only

Eric Wong  writes:

> Sebastian Schuberth  wrote:
>> This originates from an msysgit pull request, see:
>> 
>> https://github.com/msysgit/git/pull/58
>> 
>> Signed-off-by: Eric Wieser 
>> Signed-off-by: Sebastian Schuberth 
>
> Thanks, looks obviously correct.
>
> Signed-off-by: Eric Wong 
> ...
>
> Junio:
>
> The following changes since commit 2bba2f0e6542d541e9f27653d8c9d5fc8d0e679c:
>
>   More topics from the second batch for 1.8.3 (2013-03-26 13:16:11 -0700)
>
> are available in the git repository at:
>
>   git://git.bogomips.org/git-svn.git master
>
> for you to fetch changes up to 3747c015704399dea1aa7ae6569a507e5727e20b:
>
>   git-svn: Support custom tunnel schemes instead of SSH only (2013-03-27 
> 04:28:04 +)

Thanks.  Will pull.

By the way, did nobody in the patch chain find the log message
problematic?  It does not give any information other than a URL to
an external site, and if you look at the URL it refers to, it only
says

  "git svn fetch" failed while talking to svn+xyz:// at Git/SVN/Ra.pm line 307

which could easily have been written in the log message itself with
fewer words.
--
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] Enhance git-commit doc for multiple `-m` options

Thanks.
--
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: Segfault with merge-tree on multiple Git versions

John Keeping  writes:

> Looks like a simple typo in merge-tree.c::unresolved:

Thanks.

>
> -- >8 --
> merge-tree: fix typo in merge-tree.c::unresolved
>
> When calculating whether there is a d/f conflict, the calculation of
> whether both sides are directories generates an incorrect references
> mask because it does not use the loop index to set the correct bit.
> Fix this typo.
>
> Signed-off-by: John Keeping 
>
> diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
> index e0d0b7d..bc912e3 100644
> --- a/builtin/merge-tree.c
> +++ b/builtin/merge-tree.c
> @@ -245,7 +245,7 @@ static void unresolved(const struct traverse_info *info, 
> struct name_entry n[3])
>   unsigned dirmask = 0, mask = 0;
>  
>   for (i = 0; i < 3; i++) {
> - mask |= (1 << 1);
> + mask |= (1 << i);
>   if (n[i].mode && S_ISDIR(n[i].mode))
>   dirmask |= (1 << i);
>   }
--
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 status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Jim Kinsman

git status takes 30 seconds on Windows 7. Here are some stats:
git ls-files | wc -l
27330

git ls-files -o | wc -l
4

$ git diff --name-only | xargs du -chs
68K update_import_contacts.php
68K total

What can I do??? This is so slow it is unbearable.
By the way i've done git gc several times and nothing changed.
--
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 status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Andreas Ericsson

On 03/27/2013 05:39 PM, Jim Kinsman wrote:
> git status takes 30 seconds on Windows 7. Here are some stats:
> git ls-files | wc -l
> 27330
> 
> git ls-files -o | wc -l
> 4
> 
> $ git diff --name-only | xargs du -chs
> 68K update_import_contacts.php
> 68K total
> 
> What can I do??? This is so slow it is unbearable.
> By the way i've done git gc several times and nothing changed.

I'm guessing it's the disk that's so slow. I accidentally put a git
repo on a network-mounted drive once. With 20ms round-trip time to
the server, git operations took forever.

Could you try it on a disk you know is local? Preferrably a solid
state drive. If it's still slow there, we know for sure something's
broken inside git. If switching media causes git to become fast,
you'll know it's a hardware problem.

-- 
Andreas Ericsson   andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
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 status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Konstantin Khomoutov

On Wed, 27 Mar 2013 11:39:31 -0500
Jim Kinsman  wrote:

> git status takes 30 seconds on Windows 7. Here are some stats:
[...]
> What can I do??? This is so slow it is unbearable.
> By the way i've done git gc several times and nothing changed.

You could try some voodoo [1] or experimental caching features [2].

1. http://groups.google.com/group/msysgit/browse_thread/thread/02e3c0e046f07215
2. 
http://groups.google.com/group/msysgit/browse_thread/thread/7cbfe3ca452650d1/93ce48e3875f7416
--
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: Composing git repositories

Junio C Hamano wrote:
> Ramkumar Ramachandra  writes:
>> Junio C Hamano wrote:
>>> So you have to stash it somewhere.  We could have made it to move
>>> them to $HOME/.safeplace or somewhere totally unrelated to the
>>> superproject.  So in that sense, the repositories are *not* owned by
>>> the superproject in any way.  However, you are working within the
>>> context of the superproject on the submodule after all, and
>>> somewhere under $GIT_DIR/ of the superorject is not too wrong a
>>> place to use as such a safe place.
>>
>> Thanks for the explanation.
>
> What do you _exactly_ mean by that?  You understood why things are
> arranged in that way, and no longer think that it is unnecessary,
> ugly and unwieldy to stash the real copy of $GIT_DIR of submodules
> away from their working trees and store them inside $GIT_DIR/modules
> of the superproject?

In essence, git commands are built to act on pure worktrees.  It's
trivially Correct to pretend that an object store present in the
toplevel directory (as .git/) of the worktree doesn't exist, but it's
quite non-trivial to handle a .git directory anywhere else in the
worktree.  Since we built git ground-up to act on a single
repository's worktree, embedding one repository inside another is a
hack: as a "workaround", we simply relocate the object store of the
submodule repository.  Even then, working with one worktree embedded
inside another is something git never designed for: it explains why I
have to literally fight with git when using submodules (no offense
Jens; it's a very hard problem).

Representing submodules as commit objects in the tree is also a hack.
I'm sorry, but a submodule is not a commit object.  We need a fifth
object type if we want them to be first-class citizens.

Sorry, I'm deviating.  I learnt why you think the hack is necessary
and not "too wrong".  As I explained above, the entire design is
asymmetric and inelegant; I think we can do much better than this.
--
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 v2] log: Read gpg settings for signed commit verification

Jeff King  writes:

> On Wed, Mar 27, 2013 at 09:15:58AM -0700, Junio C Hamano wrote:
>
>> >}
>> > -
>> > +  if (git_gpg_config(var, value, cb) < 0)
>> > +  return -1;
>> >if (grep_config(var, value, cb) < 0)
>> >return -1;
>> 
>> Hmph.  I do not particularly like the way the call to grep_config()
>> loses information by not ignoring its return value and always
>> returning -1, but I'll let it pass for this patch.
>
> That's my fault for suggesting he follow the same style as grep here.
> But I wonder if it is worth the effort. We have never cared about
> anything beyond "was there an error" in our config callbacks, and the
> value returned from the callbacks is lost in git_parse_file (i.e., we do
> not propagate the actual return value, but only check that
> "callback(var, value, data) < 0", and die if so).
>
> Existing callbacks pass data out by writing into a struct pointed to by
> the data pointer, which is more flexible, anyway.
>
> So unless you want to overhaul the whole config system to propagate
> return codes back to the caller, I do not think there is any point in
> worrying about it.

Yeah, that is where my conclusion in the message you are responding
comes from ;-)
--
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: Rename conflicts in the index

2013-03-27 Thread Edward Thomson

Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson  writes:
> > I would propose that this not simply track rename conflicts, but all
> > conflicts.
> 
> That is a no starter.

So.  Can you explain to me why this would be a non starter?  Can you suggest
some alternate strategy here?

Maybe there's something I'm fundamentally misunderstanding.  It seems that
at present, git will:

1. Detect rename conflicts when performing a merge (at least,
   git-merge-recursive will, which is the default.)

2. If the rename itself caused a conflict (eg, renamed in one side, added in
   the other) then the merge cannot succeed.

3. The resultant index is written as if renames were not detected, which
   means - at best - records the files that went in to the name conflict
   and git status reports an "added in ours" conflict, which is a pretty
   disappointing conflict.  Often, though, many of the files will not
   exist at higher stage entries, since without rename detection, they
   would have not been conflicts.  At worst, one side is staged, there are
   no conflicts in the index and the user can commit (and thus lose the
   other side.)

Thus it's not like we could add some extension that merely records the names
that produced the rename conflicts and point them at the higher stage entries
in the index.  That would require that they actually be in the index.

Thanks-
-ed
--
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 v2] Fixed typo in git-pull manual

2013-03-27 Thread Mihai Capotă

Signed-off-by: Mihai Capotă 
---
 Documentation/git-pull.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index c975743..24ab07a 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -218,7 +218,7 @@ $ git merge origin/next
 
 
 
-If you tried a pull which resulted in a complex conflicts and
+If you tried a pull which resulted in complex conflicts and
 would want to start over, you can recover with 'git reset'.
 
 
-- 
1.7.9.5

--
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: Segfault with merge-tree on multiple Git versions

Charlie Smurthwaite  writes:

> I am experiencing a segmentation fault in various versions of Git using
> different repositories.
> ...
> Test Command
> git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
> 8d6bdf012941d876b2279994e02f1bb0d5c26e7d
> d5ef97ac407d945f231cd7c8fb1cfe48b3a12083

Thanks for a report (and thanks to John and Thomas for finding the
typo).

Nobody I know uses merge-tree; the last real change we did was back
from July 2010, and the only reason I was looking at it recently was
because I was planning to write a new merge strategy using it.

Mind if I ask what you are using it for?
--
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] git-send-email.perl: implement suggestions made by perlcritic

Junio,

I don't see this queued in 'pu'.  Do you have any objections to the
patch, or did you just forget?

Thanks.
--
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: Composing git repositories

Ramkumar Ramachandra  writes:

> Sorry, I'm deviating.  I learnt why you think the hack is necessary
> and not "too wrong".

OK.

> As I explained above, the entire design is
> asymmetric and inelegant; I think we can do much better than this.

I personally find the "explained above" part making not much sense.
Maybe others can comment on it.
--
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: Segfault with merge-tree on multiple Git versions


On 27/03/13 17:06, Junio C Hamano wrote:

Charlie Smurthwaite  writes:


I am experiencing a segmentation fault in various versions of Git using
different repositories.
...
Test Command
git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945f231cd7c8fb1cfe48b3a12083

Thanks for a report (and thanks to John and Thomas for finding the
typo).

Nobody I know uses merge-tree; the last real change we did was back
from July 2010, and the only reason I was looking at it recently was
because I was planning to write a new merge strategy using it.

Mind if I ask what you are using it for?
Thank you everybody for investigating this and creating a patch. Can I 
assume that this fix will reach somebody who can apply it to master?


With regard our use, we run an SCM hosting service http://codebasehq.com 
and are in the process of deploying a merge-request feature. We use 
git-merge-tree to determine whether a Git merge can be completed 
automatically (without manual conflict resolution), and if so offer the 
user a button to execute an actual merge. If there is a better way to do 
this, I'd be happy to consider it.


Charlie
--
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 status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Matthieu Moy

Jim Kinsman  writes:

> git status takes 30 seconds on Windows 7.

Any anti-virus installed? They can interfer badly with disk-intensive
tasks ...

-- 
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

[PATCH v2] config: Consistent call style to gpg settings

2013-03-27 Thread Hans Brigman

From: Jacob Sarvis 

Calling style for passing settings to git_gpg_config is inconsistent
between commit-tree, commit, log, merge, tag, and verify-tag.

Consolidate style of calling git_gpg_config.

Signed-off-by: Jacob Sarvis 
Signed-off-by: Hans Brigman 
---
 builtin/commit-tree.c | 2 +-
 builtin/log.c | 9 +++--
 builtin/merge.c   | 2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/builtin/commit-tree.c b/builtin/commit-tree.c
index eac901a..2e2b8d0 100644
--- a/builtin/commit-tree.c
+++ b/builtin/commit-tree.c
@@ -28,7 +28,7 @@ static void new_parent(struct commit *parent, struct 
commit_list **parents_p)
 
 static int commit_tree_config(const char *var, const char *value, void *cb)
 {
-   int status = git_gpg_config(var, value, NULL);
+   int status = git_gpg_config(var, value, cb);
if (status)
return status;
return git_default_config(var, value, cb);
diff --git a/builtin/log.c b/builtin/log.c
index 31f5a9e..7f02af7 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -339,6 +339,8 @@ static int cmd_log_walk(struct rev_info *rev)
 
 static int git_log_config(const char *var, const char *value, void *cb)
 {
+   int status;
+
if (!strcmp(var, "format.pretty"))
return git_config_string(&fmt_pretty, var, value);
if (!strcmp(var, "format.subjectprefix"))
@@ -365,8 +367,11 @@ static int git_log_config(const char *var, const char 
*value, void *cb)
use_mailmap_config = git_config_bool(var, value);
return 0;
}
-   if (git_gpg_config(var, value, cb) < 0)
-   return -1;
+   
+   status = git_gpg_config(var, value, cb);
+   if (status)
+   return status;
+   
if (grep_config(var, value, cb) < 0)
return -1;
return git_diff_ui_config(var, value, cb);
diff --git a/builtin/merge.c b/builtin/merge.c
index 7c8922c..6c03eb8 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -580,7 +580,7 @@ static int git_merge_config(const char *k, const char *v, 
void *cb)
status = fmt_merge_msg_config(k, v, cb);
if (status)
return status;
-   status = git_gpg_config(k, v, NULL);
+   status = git_gpg_config(k, v, cb);
if (status)
return status;
return git_diff_ui_config(k, v, cb);
-- 
1.7.11.msysgit.0


Hans Brigman  writes:

> From: Jacob Sarvis 
>
> config: Consistent call style to gpg settings
>
> Calling style for passing settings to git_gpg_config is inconsistent 
> between commit-tree, commit, merge, tag, and verify-tag.
>
> Consolidate style of calling git_gpg_config.
>
> Signed-off-by: Hans Brigman 

Exactly the same comments as the review for the other patch apply here.

> ---
> builtin/commit-tree.c |  5 ++---
> builtin/commit.c  |  6 ++
> builtin/merge.c   | 12 
> builtin/tag.c |  5 ++---
> builtin/verify-tag.c  |  5 ++---
> 5 files changed, 12 insertions(+), 21 deletions(-)
>
> diff --git a/builtin/commit-tree.c b/builtin/commit-tree.c index 
> eac901a..45e0152 100644
> --- a/builtin/commit-tree.c
> +++ b/builtin/commit-tree.c
> @@ -28,9 +28,8 @@ static void new_parent(struct commit *parent, struct 
> commit_list **parents_p)  static int commit_tree_config(const char 
> *var, const char *value, void *cb) {
> -  int status = git_gpg_config(var, value, NULL);
> -  if (status)
> -  return status;
> + if (git_gpg_config(var, value, cb) < 0)
> + return -1;
>return git_default_config(var, value, cb); }

Earlier, we always returned what the underlying helper returned, but in this 
version, we ignore error return values from git_gpg_config() but honor error 
return values from git_default_config().

This is making things worse, 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: [PATCH] push: Alias pushurl from push rewrites

2013-03-27 Thread Rob Hoelz

On Wed, 20 Mar 2013 07:35:58 -0700
Junio C Hamano  wrote:

> Rob Hoelz  writes:
> 
> > On 3/19/13 7:08 PM, Junio C Hamano wrote:
> >> Jonathan Nieder  writes:
> >>
> >>> Junio C Hamano wrote:
>  Jonathan Nieder  writes:
> > Test nits:
> > ...
> > Hope that helps,
> >
> > Jonathan Nieder (3):
> >   push test: use test_config where appropriate
> >   push test: simplify check of push result
> >   push test: rely on &&-chaining instead of 'if bad; then echo
> > Oops; fi'
>  Are these supposed to be follow-up patches?  Preparatory steps
>  that Rob can reroll on top?  Something else?
> >>> Preparatory steps.
> >> OK, thanks.  I'll queue these first then.
> >>
> > Should I apply these to my patch to move things along?  What's the
> > next step for me?
> 
> You would fetch from nearby git.git mirror, find the tip of
> Janathan's series and redo your patch on top.  Perhaps the session
> would go like this:
> 
> $ git fetch git://git.kernel.org/pub/scm/git/git.git/ pu
> $ git log --oneline --first-parent ..FETCH_HEAD | grep
> jn/push-tests 83a072a Merge branch 'jn/push-tests' into pu
> $ git checkout -b rh/push-pushurl-pushinsteadof 83a072a
> ... redo the work, perhaps with combinations of:
> $ git cherry-pick -n $your_original_branch
> $ edit t/t5516-fetch-push.sh
> ... and then
> $ make test
> $ git commit
> 

Ok, changes applied.  New patch coming.
--
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] push: Alias pushurl from push rewrites

2013-03-27 Thread Rob Hoelz

git push currently doesn't consider pushInsteadOf when
using pushurl; this test tests that.

If you use pushurl with an alias that has a pushInsteadOf configuration
value, Git does not take advantage of it.  For example:

[url "git://github.com/"]
insteadOf = github:
[url "git://github.com/myuser/"]
insteadOf = mygithub:
[url "g...@github.com:myuser/"]
pushInsteadOf = mygithub:
[remote "origin"]
url = github:organization/project
pushurl = mygithub:project

With the above configuration, the following occurs:

$ git push origin master
fatal: remote error:
  You can't push to git://github.com/myuser/project.git
  Use g...@github.com:myuser/project.git

So you can see that pushurl is being followed (it's not attempting to
push to git://github.com/organization/project), but insteadOf values are
being used as opposed to pushInsteadOf values for expanding the pushurl
alias.

This commit fixes that.

Signed-off-by: Rob Hoelz 
---
 remote.c  |  6 +++-
 t/t5516-fetch-push.sh | 77 +++
 2 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/remote.c b/remote.c
index e53a6eb..1ea240a 100644
--- a/remote.c
+++ b/remote.c
@@ -465,7 +465,11 @@ static void alias_all_urls(void)
if (!remotes[i])
continue;
for (j = 0; j < remotes[i]->pushurl_nr; j++) {
-   remotes[i]->pushurl[j] = 
alias_url(remotes[i]->pushurl[j], &rewrites);
+   char *copy = xstrdup(remotes[i]->pushurl[j]);
+   remotes[i]->pushurl[j] = 
alias_url(remotes[i]->pushurl[j], &rewrites_push);
+   if (!strcmp(copy, remotes[i]->pushurl[j]))
+   remotes[i]->pushurl[j] = 
alias_url(remotes[i]->pushurl[j], &rewrites);
+   free(copy);
}
add_pushurl_aliases = remotes[i]->pushurl_nr == 0;
for (j = 0; j < remotes[i]->url_nr; j++) {
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index c31e5c1..119f043 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -244,6 +244,83 @@ test_expect_success 'push with pushInsteadOf and explicit 
pushurl (pushInsteadOf
)
 '
 
+test_expect_success 'push with pushInsteadOf and explicit pushurl (pushurl + 
pushInsteadOf does rewrite in this case)' '
+   mk_empty &&
+   rm -rf ro rw &&
+   TRASH="$(pwd)/" &&
+   mkdir ro &&
+   mkdir rw &&
+   git init --bare rw/testrepo &&
+   test_config "url.file://$TRASH/ro/.insteadOf" ro: &&
+   test_config "url.file://$TRASH/rw/.pushInsteadOf" rw: &&
+   test_config remote.r.url ro:wrong &&
+   test_config remote.r.pushurl rw:testrepo &&
+   git push r refs/heads/master:refs/remotes/origin/master &&
+   (
+   cd rw/testrepo &&
+   echo "$the_commit commitrefs/remotes/origin/master" > 
expected &&
+   git for-each-ref refs/remotes/origin > actual &&
+   test_cmp expected actual
+   )
+'
+
+test_expect_success 'push without pushInsteadOf and explicit pushurl (pushurl 
+ insteadOf is used for rewrite)' '
+   mk_empty &&
+   rm -rf ro rw &&
+   TRASH="$(pwd)/" &&
+   mkdir ro &&
+   mkdir rw &&
+   git init --bare rw/testrepo &&
+   test_config "url.file://$TRASH/ro/.insteadOf" ro: &&
+   test_config "url.file://$TRASH/rw/.insteadOf" rw: &&
+   test_config remote.r.url ro:wrong &&
+   test_config remote.r.pushurl rw:testrepo &&
+   git push r refs/heads/master:refs/remotes/origin/master &&
+   (
+   cd rw/testrepo &&
+   echo "$the_commit commitrefs/remotes/origin/master" > 
expected &&
+   git for-each-ref refs/remotes/origin > actual &&
+   test_cmp expected actual
+   )
+'
+
+test_expect_success 'push with pushInsteadOf but without explicit pushurl (url 
+ pushInsteadOf is used for rewrite)' '
+   mk_empty &&
+   rm -rf ro rw &&
+   TRASH="$(pwd)/" &&
+   mkdir ro &&
+   mkdir rw &&
+   git init --bare rw/testrepo &&
+   test_config "url.file://$TRASH/ro/.insteadOf" rw: &&
+   test_config "url.file://$TRASH/rw/.pushInsteadOf" rw: &&
+   test_config remote.r.url rw:testrepo &&
+   git push r refs/heads/master:refs/remotes/origin/master &&
+   (
+   cd rw/testrepo &&
+   echo "$the_commit commitrefs/remotes/origin/master" > 
expected &&
+   git for-each-ref refs/remotes/origin > actual &&
+   test_cmp expected actual
+   )
+'
+
+test_expect_success 'push without pushInsteadOf and without explicit pushurl 
(url + insteadOf is used for rewrite)' '
+   mk_empty &&
+   rm -rf ro rw &&
+   TRASH="$(pwd)/" &&
+   mkdir ro &&
+   mkdir rw &&
+   git init --bare rw/testrepo &&
+   test_config "url.file://$TRASH/rw/.insteadOf

Re: git status takes 30 seconds on Windows 7. Why?

On Wed, Mar 27, 2013 at 11:39:31AM -0500, Jim Kinsman wrote:
> git status takes 30 seconds on Windows 7. Here are some stats:
> git ls-files | wc -l
> 27330
> 
> git ls-files -o | wc -l
> 4
> 
> $ git diff --name-only | xargs du -chs
> 68K update_import_contacts.php
> 68K total
> 
> What can I do??? This is so slow it is unbearable.
> By the way i've done git gc several times and nothing changed.

Can you run these commands under "time" so that we can see that it's
definitely the "git ls-files" taking 30 seconds and not something in
$PS1?
--
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: Rename conflicts in the index

Edward Thomson  writes:

> Junio C Hamano [mailto:gits...@pobox.com] wrote:
>> Edward Thomson  writes:
>> > I would propose that this not simply track rename conflicts, but all
>> > conflicts.
>> 
>> That is a no starter.
>
> So.  Can you explain to me why this would be a non starter?

At least two, IIRC.  One is the consequence of the other.

We do not gratuitously break existing implementations.  If no
conflict is stored as higher-stage index entries in an index that
has your index extension, no existing implementation can read a
conflicted index written by your implementation and have users
resolve conflicts.

When a path originally at A is moved to B on only one branch, and
there are content-level conflicts between the changes made by one
branch (while going from A to B) and by the other branch (while
keeping it at A), we would end up having three stages for path B
without any trace of path A.  I do not offhand know how much it
helps to learn A in such a situation in the real life, but we are
indeed losing information, and I do not have any problem with an
extension that records in the index the fact that in the two (of the
three) commits involved in the merge, the path was at A.

But people have been successfully using existing versions of Git
without that information to merge branches with renames, and
resolving the content-level conflicts.  Your tool that
_additionally_ records "This path that currently has three stages
for B was at A in the common ancestor (i.e. stage #1) and that
branch (either stage #2 or stage #3)" does not _have_ _to_ break
these users by removing the three stages for B from the main index.

Also we do not duplicate information unnecessarily.  Nowhere in the
above "we have been losing the fact that two of the three had the
contents we have at path B in the resulting unmerged index at path
A, and that information might be useful as well", there is a reason
to write another copy of mode or SHA-1 for any of the three variants.

As I said, you do not live in the world where you are writing
something like Git from scratch.  Perhaps you do, but then the
result will not be Git and we wouldn't be discussing that system on
this mailing list.

--
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] git-send-email.perl: implement suggestions made by perlcritic

Ramkumar Ramachandra  writes:

> I don't see this queued in 'pu'.  Do you have any objections to the
> patch, or did you just forget?

I do not recall the details but I think I was expecting a re-roll
updating the log message (if the original invited questions, there
must have been some room for improvement to avoid such confusions,
right?) for a few days since the exchange, and then forgot.

--
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: Segfault with merge-tree on multiple Git versions


On 27/03/13 17:06, Junio C Hamano wrote:

Charlie Smurthwaite  writes:


I am experiencing a segmentation fault in various versions of Git using
different repositories.
...
Test Command
git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945f231cd7c8fb1cfe48b3a12083

Thanks for a report (and thanks to John and Thomas for finding the
typo).

Nobody I know uses merge-tree; the last real change we did was back
from July 2010, and the only reason I was looking at it recently was
because I was planning to write a new merge strategy using it.

Mind if I ask what you are using it for?


I am also using this to obtain a diff that would be applied if a merge 
were to be run. Is there a better way to obtain this information that is 
more commonly used?


--
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 v2] Fixed typo in git-pull manual

Thanks.
--
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: Segfault with merge-tree on multiple Git versions

2013-03-27 Thread Jed Brown

Charlie Smurthwaite  writes:

> I am also using this to obtain a diff that would be applied if a merge 
> were to be run. Is there a better way to obtain this information that is 
> more commonly used?

You can do an actual merge using detached HEAD:

  $ git checkout --detach upstream-branch
  $ git merge topic-branch

This has the benefit that if there are conflicts, you can resolve them
here and commit the result so that rerere can auto-resolve them later.

Are you looking for something that can be run in a bare repo?
--
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] git-svn: Support custom tunnel schemes instead of SSH only

2013-03-27 Thread Eric Wong

Junio C Hamano  wrote:
> Eric Wong  writes:
> >
> >   git-svn: Support custom tunnel schemes instead of SSH only (2013-03-27 
> > 04:28:04 +)
> 
> Thanks.  Will pull.
> 
> By the way, did nobody in the patch chain find the log message
> problematic?  It does not give any information other than a URL to
> an external site, and if you look at the URL it refers to, it only
> says
> 
>   "git svn fetch" failed while talking to svn+xyz:// at Git/SVN/Ra.pm line 307
> 
> which could easily have been written in the log message itself with
> fewer words.

Oops, I wasn't happy with the log message, either, but remained silent
since I thought the subject/title for an obvious one-line change was
sufficient.  In other words, I think an empty log message (+S-o-b) would
suffice, too.
--
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 status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Jim Kinsman

The only anti-virus I have installed is Microsoft Security Essentials
I turned off and it was still the same:
$ cat /usr/bin/gitstatus
start_time=`date +%s`
git status && echo run time is $(expr `date +%s` - $start_time) s


$ gitstatus
# On branch test
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   orgoptions.php
#   modified:   update_import_contacts.php
#
no changes added to commit (use "git add" and/or "git commit -a")
run time is 10 s

On Wed, Mar 27, 2013 at 12:17 PM, Matthieu Moy
 wrote:
> Jim Kinsman  writes:
>
>> git status takes 30 seconds on Windows 7.
>
> Any anti-virus installed? They can interfer badly with disk-intensive
> tasks ...
>
> --
> 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: propagating repo corruption across clone

2013-03-27 Thread Rich Fromm

Jonathan Nieder-2 wrote
> Is the "[transfer] fsckObjects" configuration on the host executing the
> clone set to true?

I hadn't been setting it at all, and according to git-config(1) it defaults
to false, so the answer is no. It looks like setting it might be a good
idea.

But I'm still somewhat confused about what is and is not checked under what
conditions. Consider the three statements:

# 1
git clone --mirror myuser@myhost:my_repo

# 2
git clone --mirror --config transfer.fsckObjects=true myuser@myhost:my_repo

# 3
git clone --mirror myuser@myhost:my_repo && cd my_repo.git && git-fsck

Are 2 and 3 equivalent? Or is there an increasing level of checking that
occurs from 1 to 2, and from 2 to 3? My guess is the latter, but perhaps
this could be clearer in the man pages.

git-config(1) says that transfer.fsckObjects essentially (if fetch... and
receive... are not explicitly set) "git-fetch-pack will check all fetched
objects" and "git-receive-pack will check all received objects." While
git-fsck(1) says "git-fsck tests SHA1 and general object sanity, and it does
full tracking of the resulting reachability and everything else." The
latter sounds like a stronger statement to me. But if that's true, perhaps
should the relevant section(s) of git-config(1) explicitly note that this is
not equivalent to a full git-fsck ?

--
View this message in context:
http://git.661346.n2.nabble.com/propagating-repo-corruption-across-clone-tp7580504p7580839.html
Sent from the git mailing list archive at Nabble.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: [PATCH] push: Alias pushurl from push rewrites

Rob Hoelz wrote:

> --- a/remote.c
> +++ b/remote.c
> @@ -465,7 +465,11 @@ static void alias_all_urls(void)
>   if (!remotes[i])
>   continue;
>   for (j = 0; j < remotes[i]->pushurl_nr; j++) {
> - remotes[i]->pushurl[j] = 
> alias_url(remotes[i]->pushurl[j], &rewrites);
> + char *copy = xstrdup(remotes[i]->pushurl[j]);
> + remotes[i]->pushurl[j] = 
> alias_url(remotes[i]->pushurl[j], &rewrites_push);
> + if (!strcmp(copy, remotes[i]->pushurl[j]))
> + remotes[i]->pushurl[j] = 
> alias_url(remotes[i]->pushurl[j], &rewrites);
> + free(copy);

Interesting.

Suppose I configure

[url "git://anongit.myserver.example.com/"]
insteadOf = myserver.example.com:
[url "myserver:"]
pushInsteadOf = myserver.example.com:

The above code would make the insteadOf rule apply instead of
pushInsteadOf, even when pushing.  Perhaps something like the
following would work?

const char *url = remotes[i]->pushurl[j];
remotes[i]->pushurl[j] = alias_url(url, &rewrites_push);
if (remotes[i]->pushurl[j] == url)
/* No url.*.pushinsteadof configuration 
matched. */
remotes[i]->pushurl[j] = alias_url(url, 
&rewrites);

> --- a/t/t5516-fetch-push.sh
> +++ b/t/t5516-fetch-push.sh
> @@ -244,6 +244,83 @@ test_expect_success 'push with pushInsteadOf and 
> explicit pushurl (pushInsteadOf
>   )
>  '
>  
> +test_expect_success 'push with pushInsteadOf and explicit pushurl (pushurl + 
> pushInsteadOf does rewrite in this case)' '
> + mk_empty &&
> + rm -rf ro rw &&
> + TRASH="$(pwd)/" &&
> + mkdir ro &&
> + mkdir rw &&
> + git init --bare rw/testrepo &&
> + test_config "url.file://$TRASH/ro/.insteadOf" ro: &&
> + test_config "url.file://$TRASH/rw/.pushInsteadOf" rw: &&
> + test_config remote.r.url ro:wrong &&
> + test_config remote.r.pushurl rw:testrepo &&
> + git push r refs/heads/master:refs/remotes/origin/master &&
> + (
> + cd rw/testrepo &&
> + echo "$the_commit commitrefs/remotes/origin/master" > 
> expected &&
> + git for-each-ref refs/remotes/origin > actual &&
> + test_cmp expected actual
> + )

Looks good.  The usual style in git tests is to include no space
after >redirection operators:

git for-each-ref refs/remotes/origin >actual &&

Hope that helps,
Jonathan
--
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 and GSoC 2013

There was a big thread about a month ago on whether Git should do Google
Summer of Code this year[1].

Some people seemed in favor, and some not. The deadline for git to apply
to GSoC is March 29 (this Friday) at 19:00 UTC. I am willing to act as
the admin again if list consensus is that we should do it. But my point
in sending this email is not to say "yes, we should definitely apply";
it is to give people on both sides one more chance to make their points
and come to a conclusion before the deadline. I.e., I did not want the
decision to be made for us because people were not aware of the
deadline.

In my opinion, a lot of the issues come down to project selection; one
thing that seemed to come up in the thread was that projects are often
not scoped appropriately to get fully merged by the end of the summer. I
think the much smaller projects done by Matthieu Moy's summer students
in past years have been very successful _because_ they are of a size
much closer to patch series done by normal contributors. I realize that
the GSoC time-frame is longer, but I think it's again a matter of
scoping; one large project that tries to merge at the end of the summer
is never going to work. It must be broken down into a series of
reviewable steps, and those steps need to be reviewed and merged
throughout the summer, just like contributions from regular
contributors.

Hand in hand with that, I think we need to treat students more like
regular contributors: discussion on-list, patches reviewed and revised
on-list, etc. And all of that happening throughout the summer. Coding is
only part of being involved in open-source, and traditionally the
students have focused on the code and not on the process of interacting
with the community and shepherding their changes through to "master".

Looking over the proposed project page, I am not that excited about any
of them (including ones I have written for past years) as being both
scoped appropriately and interesting/useful for students and for the
project. I think if people want to do GSoC, we really need to make a
commitment to smaller-scoped projects, and to getting students more
involved in the "regular" process of patch submission. The obvious first
step to that is revising the Ideas list to either have smaller projects,
or to break larger ones into more manageable pieces. Unless that
happens, I don't think it's worth applying.

And if we do apply and get accepted, I think we should look carefully at
the proposals that we select, and be very picky about students and
projects that will fit in the summer scope.

I realize that there is only about 48 hours until the deadline, which is
not much. But I am willing to work on the application materials if
people can agree on a reasonable set of proposed projects[2].

-Peff

[1] http://thread.gmane.org/gmane.comp.version-control.git/216485

[2] I have always hoped for students who would submit their own project
proposals, independent of anything we suggest. After all, that is
how things happen naturally in open source; contributors scratch
their own itches. And that is part of why the ideas I post are often
vague and try to describe a problem rather than a solution. But in
all our years of GSoC, I recall very few cases of students proposing
their own projects, and even fewer of them being successful. So I
have kind of given up hope that we would get any proposal that is
not spelled out on our ideas page.
--
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: Segfault with merge-tree on multiple Git versions


On 27/03/13 18:06, Jed Brown wrote:

Charlie Smurthwaite  writes:


I am also using this to obtain a diff that would be applied if a merge
were to be run. Is there a better way to obtain this information that is
more commonly used?

You can do an actual merge using detached HEAD:

   $ git checkout --detach upstream-branch
   $ git merge topic-branch

This has the benefit that if there are conflicts, you can resolve them
here and commit the result so that rerere can auto-resolve them later.

Are you looking for something that can be run in a bare repo?


Yes, I would need to be able to do this on a bare repo for my use case. 
Thanks!


--
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 status takes 30 seconds on Windows 7. Why?

On Wed, Mar 27, 2013 at 01:15:43PM -0500, Jim Kinsman wrote:
> The only anti-virus I have installed is Microsoft Security Essentials
> I turned off and it was still the same:
> $ cat /usr/bin/gitstatus
> start_time=`date +%s`
> git status && echo run time is $(expr `date +%s` - $start_time) s
> 
> 
> $ gitstatus
> # On branch test
> # Changes not staged for commit:
> #   (use "git add ..." to update what will be committed)
> #   (use "git checkout -- ..." to discard changes in working directory)
> #
> #   modified:   orgoptions.php
> #   modified:   update_import_contacts.php
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> run time is 10 s

That doesn't seem hugely surprising to me.  I have a moderately sized
repository (3047 files, although it's Java so there are some deep trees)
and I get the following (Vista on a reasonably old laptop, best of 3,
Git version 1.8.1.msysgit.1):

$ time git ls-files >/dev/null

real0m0.047s
user0m0.015s
sys 0m0.015s

$ time git status >/dev/null

real0m2.715s
user0m0.000s
sys 0m0.031s

I'm not sure the "user" and "sys" times are correct, but the "real"
times feel right.  By comparison, on Linux on a much newer machine (so
not much of a comparison) on the same repository:

$ time git status >/dev/null

real0m0.347s
user0m0.171s
sys 0m0.167s

I think the simple reality is that Git was written with the assumption
that stat is cheap and that isn't really the case on Windows, where the
filesystem cache doesn't seem to do that well with this.  It may be that
Git's Windows compatibility code could do be made more efficient but I
know nothing about that, although a quick look in compat/mingw.c
indicates that Git does already use its own stat implementations in
place of the MSys ones in search of speed.

John
--
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: propagating repo corruption across clone

2013-03-27 Thread Rich Fromm

Junio C Hamano wrote
> If you use --local, that is equivalent to "cp -R".  Your corruption
> in the source will faithfully be byte-for-byte copied to the
> destination.  If you do not
> ...
> transport layer will notice
> object corruption.
> ...
> The difference between --mirror and no --mirror is a red herring.
> You may want to ask Jeff Mitchell to remove the mention of it; it
> only adds to the confusion without helping users.

Just to clarify, I don't know Jeff Mitchell personally, and I'm not
affiliated with the KDE project.  I happened to have recently implemented a
backup strategy for a different codebase, that relies on `git clone
--mirror` to take the actual snapshots of the live repos, and I read about
Jeff's experiences, and that's why I started following this discussion. 
Apologies if my questions are considered slightly off topic -- I'm not
positive if this is supposed to be a list for developers, and not users.

Nevertheless, I will try to contact Jeff and point him at this.  My initial
reading of his blog posts definitely gave me the impression that this was a
--mirror vs. not issue, but it really sounds like his main problem was using
--local.

However, I think there may be room for some additional clarity in the docs. 
The --local option in git-config(1) says "When the repository to clone from
is on a local machine, this flag bypasses the normal "git aware" transport
mechanism".  But there's no mention of the consequences of this transport
bypass.  There's also no mention of this in the "GIT URLS" section that
discusses transport protocols, and I also don't see anything noting it in
either of these sections of the git book:

http://git-scm.com/book/en/Git-on-the-Server-The-Protocols
http://git-scm.com/book/en/Git-Internals-Transfer-Protocols




--
View this message in context: 
http://git.661346.n2.nabble.com/propagating-repo-corruption-across-clone-tp7580504p7580845.html
Sent from the git mailing list archive at Nabble.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: Git and GSoC 2013

Jeff King wrote:

> There was a big thread about a month ago on whether Git should do Google
> Summer of Code this year[1].
[...]
> In my opinion, a lot of the issues come down to project selection;

Let me throw in some other issues. :)

 * I think the git project has been very disorganized in vetting
   candidate students.  Other organizations have formal requirements
   (for example, "must submit at least one properly formatted patch to
   qualify") but we seem to rely on a candidate's good sense,
   independence, and general sense of trustworthiness without
   providing guidance beyond that.

   At first glance that wouldn't seem to be a problem --- the accepted
   students have been very good anyway --- but I think that if we
   could communicate more clearly what we need, we might find there
   are more qualified students that we have been missing, and
   promising students might end up working a little in advance of
   GSoC to adapt themselves to the project.

 * Similarly, we are not very good at making clear the expectations
   for students during the program and making sure they are met.  At
   least I know I was lousy about this as a mentor.

   For example, students delay too long before posting patches
   on-list and do not ask for help quickly when they are stuck.  By
   the end of the summer they may start to get a sense of the usual
   contribution workflow when they could have been more effective
   by following it from the start.

   Some organizations require (as a non-negotiable rule) regular blog
   posts from their students, as a way of advertising to others what
   work they are doing and how to help them out.  That could help
   here. 

 * We didn't plan in advance for "What happens when summer ends and
   the students don't have free time any more?"

 * We don't advertise any good recourse available to students if a
   mentor is unexpectedly too busy or hard to contact.  I don't know
   if that's happened in practice.

Matthieu Moy's summer projects worked better in all these respects, I
think.

I don't think we should apply.  Better to take a break and prepare for
next time.

My two cents,
Jonathan
--
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: Rename conflicts in the index

2013-03-27 Thread Edward Thomson

Junio C Hamano [mailto:gits...@pobox.com] wrote:
> We do not gratuitously break existing implementations.  If no conflict is 
> stored
> as higher-stage index entries in an index that has your index extension, no
> existing implementation can read a conflicted index written by your
> implementation and have users resolve conflicts.

I'm not suggesting that anybody stop writing >0 stage entries.

> When a path originally at A is moved to B on only one branch, and there are
> content-level conflicts between the changes made by one branch (while going
> from A to B) and by the other branch (while keeping it at A), we would end up
> having three stages for path B without any trace of path A.  I do not offhand
> know how much it helps to learn A in such a situation in the real life, but 
> we are
> indeed losing information, and I do not have any problem with an extension 
> that
> records in the index the fact that in the two (of the
> three) commits involved in the merge, the path was at A.

What you've described is true only for a certain class of rename conflicts,
for example the rename/edit conflict you've described above.

It's also true if you were to rename some item 'a' to 'b' in both branches.
But when 'b' is sufficiently dissimilar to become a rewrite, then I end up
with a rename of a->b on one side and deleting a and adding b on the other.
The result is a mysterious "added by us" conflict:

100644 e2dd530c9f31550a2b0c90773ccde056929d6d66 2   b

Worse yet is if I don't do the rename in my side, but I just add a new b so
that in theirs I've renamed a to b and in mine I have both a and b.  When I
do the merge, I'm told I have conflicts, except that I don't:

100644 08d4f831774aed5d4c6cb496affefd4020dce40c 0   b

The other branch's b is long gone and exists only as a dirty file in the
workdir.

> But people have been successfully using existing versions of Git without that
> information to merge branches with renames, and resolving the content-level
> conflicts.

But you aren't afforded the option to resolve content-level conflicts if you
don't know where the conflict came from.  For example, in a rename 1->2
conflict, we dutifully detect that a was renamed to both b and c and fail,
but that fact is never given to the index.  This conflict could be fed into
a merge tool or, better, automerged, with the user only needing to pick a
path:

100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 1   a
100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 3   b
100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 2   c

I hate to sound like a broken record here, but without some more data in the
index - anywhere, really - any tool that doesn't have the luxury of emitting
data about what happened to stdout certainly can't infer anything about what
happened in the merge.

-ed
--
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

more git weirdness (git rebase, merge conflicts

2013-03-27 Thread J.V.

I have a local/development branch tracked to origin/development. I made
no changes to local/dev and did a git pull with rebase, I did not expect
any conflicts.

I got a conflict and was thrown onto another branch. I attempted a
merge (using IntelliJ) accepting everything from the server but a
variable definition was missing for some odd reason and the merge was
not successful (merge was resolved but the file would not compile) so I
decided to simply go back to my dev branch and figure out how to do a
git pull -f (force overwrite of all local files so that I could get my
local/dev back into sync with origin/dev.

On my screwed up branch that I was thrust onto:
I typed:
$git rebase --skip<= I was stuck in a rebase (rebase
failed, was thrown onto a tmp branch and thought this would get me out
of there)

Now I have been sitting here for an hour watching "Applying: scroll by and it looks like the messages are going backwards into the
past one by one. What the hell is happening?

Applying: add log information
Applying: All I want to do at this point is to get back to my dev branch and force
pull from origin/dev while keeping all local files that have not been
added to my local repo.

How do I stop this madness and get back to local dev and force pull from
origin/dev <= which is our master.

Any help would be greatly appreciated.

thanks

J.V.
--
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 status takes 30 seconds on Windows 7. Why?

On Wed, Mar 27, 2013 at 06:46:57PM +, John Keeping wrote:

> I think the simple reality is that Git was written with the assumption
> that stat is cheap and that isn't really the case on Windows, where the
> filesystem cache doesn't seem to do that well with this.

Yes, I think that's pretty much the case (though most of my
Git-on-Windows experience is from cygwin long ago, where the stat
performance was truly horrendous). Have you tried setting
core.preloadindex, which should run the stats in parallel?

-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: propagating repo corruption across clone

Rich Fromm  writes:

> Apologies if my questions are considered slightly off topic -- I'm not
> positive if this is supposed to be a list for developers, and not users.

The list is both for users and developers.

> However, I think there may be room for some additional clarity in the docs. 
> The --local option in git-config(1) says "When the repository to clone from
> is on a local machine, this flag bypasses the normal "git aware" transport
> mechanism".  But there's no mention of the consequences of this transport
> bypass.

Yeah, I would not mind a patch to update the documentation for
"clone --local" and rsync transport to say something about
byte-for-byte copying of broken repository.

Thanks.

--
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: Segfault with merge-tree on multiple Git versions

2013-03-27 Thread Jed Brown

Charlie Smurthwaite  writes:

> Yes, I would need to be able to do this on a bare repo for my use case. 

And if it's on the server, you don't want this to be observable, so
you don't want HEAD to move around. I don't know a better way than:

  $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo
  $ cd /tmp/merge-repo
  $ git pull URL incoming-branch

Cloning with --shared just writes a path into .git/objects/info/alternatives
and it doesn't need to be on the same file system (unlike --local).

Since 'git merge-tree' just works with trees, it has less information
than 'git merge'.
--
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: Composing git repositories

Ramkumar Ramachandra wrote:

>Even then, working with one worktree embedded
> inside another is something git never designed for: it explains why I
> have to literally fight with git when using submodules

Do you mean that you wish you could ignore subrepository boundaries
and use commands like

git clone --recurse-submodules http://git.zx2c4.com/cgit
cd cgit
vi git/cache.h
... edit edit edit ...
git add --recurse-submodules git/cache.h
git commit --recurse-submodules
git push --recurse-submodules

, possibly with configuration to allow the --recurse-submodules to be
implied, and have everything work out well?

I think something like that is a goal for submodules in the long term,
with a caveat that there are complications in that different projects
(the parent project and subproject) can have different contribution
guidelines, review and release schedules, and so on.

If submodules are not working for you today, you may find some of
Jens's submodule improvement patches interesting, or you may want to
look into alternatives that make different assumptions, such as
entirely independent repositories and tools like "mr" that iterate
over them.

Hope that helps,
Jonathan
--
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 status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Linus Torvalds

On Wed, Mar 27, 2013 at 12:04 PM, Jeff King  wrote:
>
> Yes, I think that's pretty much the case (though most of my
> Git-on-Windows experience is from cygwin long ago, where the stat
> performance was truly horrendous). Have you tried setting
> core.preloadindex, which should run the stats in parallel?

I wonder if preloadindex shouldn't be enabled by default.. It's a huge
deal on NFS, and the only real downside is that it expects threading
to work. It potentially slows things down a tiny bit for single-CPU
cases with everything cached, but that isn't likely to be a relevant
case.

Of course, it can trigger filesystem scalability issues, and as a
result it will often not help very much if you have the bulk of your
files in one (or a few) directories. But anybody who has so many files
that performance is an issue is not likely to have them all in one
place.

And apparently the Windows FS metadata caching sucks, and things fall
out of the cache for large trees. Color me not-very-surprised. It's
probably some size limit on the metadata that you can tweak. So I';m
sure there's some registry setting or other that would make windows
able to cache more than a few thousand filenames, and it would
probably improve performance a lot, but I do think preloadindex has
been around long enough that it could just be the default.

Of course, Jim should verify that preloadindex actually does solve his
problem.  With 20k+ files, it should max out the 20 IO threads for
preloading, and assuming the filesystem IO scales reasonably well, it
should fix the problem. But we do do a number of metadata ops
synchronously even with preloadindex, so things won't scale perfectly.

(In particular: do open each directory and do the readdir stuff and
try to open .gitignore whether it exists or not. So you'll get
synchronous IO for each directory, but at least the per-file IO to
check all the file stat data should scale).

 Linus
--
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: Rename conflicts in the index

Edward Thomson  writes:

> Junio C Hamano [mailto:gits...@pobox.com] wrote:
>> We do not gratuitously break existing implementations.  If no conflict is 
>> stored
>> as higher-stage index entries in an index that has your index extension, no
>> existing implementation can read a conflicted index written by your
>> implementation and have users resolve conflicts.
>
> I'm not suggesting that anybody stop writing >0 stage entries.

Ah, OK, then I misread your original message.  You said

> Having a single canonical location is preferable - if the index
> contains a CONF section (and the client supports it), it would use
> that.  Otherwise, the client would look at stage >0 entries.

which I read as "an index with this extension would not have higher
stage entries, an index without the extension records higher stage
entries".  As long as the format will be backward compatible to
allow existing users use existing tools to deal with cases the
existing tools can handle, then that is OK.  I didn't get that
impression which is where my "non starter" came from.

> What you've described is true only for a certain class of rename conflicts,
> for example the rename/edit conflict you've described above.

As you asked me to explain why it was a non starter, I only
illustrated with a "renamed trivially, with content level conflict"
example that shows why dropping higher-stage entries in the main
index would not be acceptable.  The previous message did not even
mean to cover any cases the *new* feature you have in mind is trying
to address.  Again, if it hurts existing users handling cases
existing tools used to handle, that makes it a non starter.

How new feature is designed, and extension is added to help that new
feature, is a different matter.  My original "That's a non starter"
message didn't even go that far.

In any case, the principle of "always record the state 'merge'
stopped to ask for help as higher stage entries to give existing
tools and users a chance to manually resolve, and augment with
optional extension to record additional information that might help,
but do not gratiutously waste bytes on redundant information" would
apply to other exotic cases you would want to tackle with the new
feature, I would think.

If one branch moves path A in the original to path B and the other
one moved it to path C, for example, we can record it in different
ways, even in the main index.

 * Path A may have only stage #1, while path B and C has only stage
   #2 and stage #3 (the user would have to notice these three
   correspond to each other, and resolve manually).

   You would want to annotate "B at stage #2 seems to have been at A
   in the original" (similarly for C#3) if you choose to do so.

 * You can choose to favor "our" choice, and have path B with three
   stages (if we guessed wrong and the user wants to move it to C,
   the user can resolve and then "git mv" the path).

   You would want to annotate "the other side wanted to have B at
   stage #3 at C" in that case.

 * Or you may want to have in the main index both B and C (but not
   A) with all three stages (the user would have to choose which
   one survives, but discarding the other side with "git rm" would
   be easy).

   You would want to annotate the origin of the stage #1 for path B
   and C (these were originally at A), stage #2 for B (the other
   branch wants to have it at C), stage #3 for C (we want to have it
   at B).

There may be other ways, and I do not offhand know what the current
merge-recursive implementation does, but both of the latter two
sound equally usable and reasonable ways, even without the
annotation.  And with your annotation that records different paths,
the conflict may become even easier to resolve.

I still do not need to duplicate  in the extensions to
do the above, or do I?

If the original path A was removed and a new path B was added, with
contents that are modified from A beyond recognition, at the merge
time you wouldn't know where B it came from or where A went, so
annotating A at stage #1 to say "it went to B" is a nonsense.  If
you have algorithm to do so [*1*], you would be better off detecting
it as a rename.

[Footnote]

*1* Instead of a three-way merge that inspects only the endpoints,
you might get a better rename trail if you looked at the
histories of both branches.  It would be a lot more expensive
than the simple three-way, but burning CPU cycles is better than
burning human neurons.
--
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: Segfault with merge-tree on multiple Git versions

On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:
> Charlie Smurthwaite  writes:
> 
> > Yes, I would need to be able to do this on a bare repo for my use case. 
> 
> And if it's on the server, you don't want this to be observable, so
> you don't want HEAD to move around. I don't know a better way than:
> 
>   $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo
>   $ cd /tmp/merge-repo
>   $ git pull URL incoming-branch
> 
> Cloning with --shared just writes a path into .git/objects/info/alternatives
> and it doesn't need to be on the same file system (unlike --local).
> 
> Since 'git merge-tree' just works with trees, it has less information
> than 'git merge'.

You could use a temporary index and do something like:

rm -f TMP_INDEX
GIT_INDEX_FILE=TMP_INDEX
export GIT_INDEX_FILE
git read-tree -m $base $ours $theirs &&
git merge-index git-merge-one-file -a

then inspect that with "git diff-index --cached $ours".

Note that this will fail if there are conflicts and I don't know what
git-merge-tree will do in that case.
--
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: propagating repo corruption across clone

On Wed, Mar 27, 2013 at 11:23:15AM -0700, Rich Fromm wrote:

> But I'm still somewhat confused about what is and is not checked under what
> conditions.  Consider the three statements:
> 
> # 1
> git clone --mirror myuser@myhost:my_repo
> 
> # 2
> git clone --mirror --config transfer.fsckObjects=true myuser@myhost:my_repo
> 
> # 3
> git clone --mirror myuser@myhost:my_repo && cd my_repo.git && git-fsck
> 
> Are 2 and 3 equivalent?  Or is there an increasing level of checking that
> occurs from 1 to 2, and from 2 to 3?  My guess is the latter, but perhaps
> this could be clearer in the man pages.

2 and 3 are not exactly equivalent, in that they are implemented
slightly differently, but I do not know offhand of any case that would
pass 2 but not 3. We do check reachability with transfer.fsckObjects.

-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 status takes 30 seconds on Windows 7. Why?

Linus Torvalds  writes:

> On Wed, Mar 27, 2013 at 12:04 PM, Jeff King  wrote:
>>
>> Yes, I think that's pretty much the case (though most of my
>> Git-on-Windows experience is from cygwin long ago, where the stat
>> performance was truly horrendous). Have you tried setting
>> core.preloadindex, which should run the stats in parallel?
>
> I wonder if preloadindex shouldn't be enabled by default.

I am surprised that we haven't done so.

Given that we haven't tweaked the parallelism or thread-cost
parameters since the inception of the mechanism in Nov 2008, I
suspect that we would see praises from some and grievances from
other corners of the user base for a while until we find acceptable
values for them, but I agree the feature has been in use
sufficiently by some people (heh, I just discovered that I don't
have it in my config), it can be the default.
--
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: Segfault with merge-tree on multiple Git versions

On Wed, Mar 27, 2013 at 07:45:21PM +, John Keeping wrote:

> On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:
> > Charlie Smurthwaite  writes:
> > 
> > > Yes, I would need to be able to do this on a bare repo for my use case. 
> > 
> > And if it's on the server, you don't want this to be observable, so
> > you don't want HEAD to move around. I don't know a better way than:
> > 
> >   $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo
> >   $ cd /tmp/merge-repo
> >   $ git pull URL incoming-branch
> > 
> > Cloning with --shared just writes a path into .git/objects/info/alternatives
> > and it doesn't need to be on the same file system (unlike --local).
> > 
> > Since 'git merge-tree' just works with trees, it has less information
> > than 'git merge'.
> 
> You could use a temporary index and do something like:
> 
>   rm -f TMP_INDEX
>   GIT_INDEX_FILE=TMP_INDEX
>   export GIT_INDEX_FILE
>   git read-tree -m $base $ours $theirs &&
>   git merge-index git-merge-one-file -a
> 
> then inspect that with "git diff-index --cached $ours".

That is precisely how we do it at GitHub. You probably want to add in
"--aggressive" to your read-tree to cover a few more simple cases. If
there are conflicts, we just bail and say "this can't be merged", and
expect the user to do it themselves using git.

-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

[PATCH v3 0/3] Recursion-free unpack_entry and packed_object_info

From: Thomas Rast 

Almost the same as last time.  Changed: the rename suggested by Junio

> The only little concern I may have is this cmp_* function tells us
> "I found it!" by returning true, which is counter-intuitive to the
> readers of the caller (not the callee).
> 
> I think it makes sense to compare delta-base-cache entries only for
> equality, so eq-delta-base-cache-entry might be a better name for
> it, perhaps?

and a small reword to patch 3's commit message to make it clearer at
which stage we unpack the deltas.


Thomas Rast (3):
  sha1_file: remove recursion in packed_object_info
  Refactor parts of in_delta_base_cache/cache_or_unpack_entry
  sha1_file: remove recursion in unpack_entry

 sha1_file.c | 411 +++-
 1 file changed, 266 insertions(+), 145 deletions(-)

-- 
1.8.2.344.g1440b22

--
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 v3 1/3] sha1_file: remove recursion in packed_object_info

packed_object_info() and packed_delta_info() were mutually recursive.
The former would handle ordinary types and defer deltas to the latter;
the latter would use the former to resolve the delta base.

This arrangement, however, leads to trouble with threaded index-pack
and long delta chains on platforms where thread stacks are small, as
happened on OS X (512kB thread stacks by default) with the chromium
repo.

The task of the two functions is not all that hard to describe without
any recursion, however.  It proceeds in three steps:

- determine the representation type and size, based on the outermost
  object (delta or not)

- follow through the delta chain, if any

- determine the object type from what is found at the end of the delta
  chain

The only complication stems from the error recovery.  If parsing fails
at any step, we want to mark that object (within the pack) as bad and
try getting the corresponding SHA1 from elsewhere.  If that also
fails, we want to repeat this process back up the delta chain until we
find a reasonable solution or conclude that there is no way to
reconstruct the object.  (This is conveniently checked by t5303.)

To achieve that within the pack, we keep track of the entire delta
chain in a stack.  When things go sour, we process that stack from the
top, marking entries as bad and attempting to re-resolve by sha1.  To
avoid excessive malloc(), the stack starts out with a small
stack-allocated array.  The choice of 64 is based on the default of
pack.depth, which is 50, in the hope that it covers "most" delta
chains without any need for malloc().

It's much harder to make the actual re-resolving by sha1 nonrecursive,
so we skip that.  If you can't afford *that* recursion, your
corruption problems are more serious than your stack size problems.

Reported-by: Stefan Zager 
Signed-off-by: Thomas Rast 
---
 sha1_file.c | 135 +---
 1 file changed, 84 insertions(+), 51 deletions(-)

diff --git a/sha1_file.c b/sha1_file.c
index 16967d3..2c8b549 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1639,50 +1639,6 @@ static off_t get_delta_base(struct packed_git *p,
return base_offset;
 }
 
-/* forward declaration for a mutually recursive function */
-static int packed_object_info(struct packed_git *p, off_t offset,
- unsigned long *sizep, int *rtype);
-
-static int packed_delta_info(struct packed_git *p,
-struct pack_window **w_curs,
-off_t curpos,
-enum object_type type,
-off_t obj_offset,
-unsigned long *sizep)
-{
-   off_t base_offset;
-
-   base_offset = get_delta_base(p, w_curs, &curpos, type, obj_offset);
-   if (!base_offset)
-   return OBJ_BAD;
-   type = packed_object_info(p, base_offset, NULL, NULL);
-   if (type <= OBJ_NONE) {
-   struct revindex_entry *revidx;
-   const unsigned char *base_sha1;
-   revidx = find_pack_revindex(p, base_offset);
-   if (!revidx)
-   return OBJ_BAD;
-   base_sha1 = nth_packed_object_sha1(p, revidx->nr);
-   mark_bad_packed_object(p, base_sha1);
-   type = sha1_object_info(base_sha1, NULL);
-   if (type <= OBJ_NONE)
-   return OBJ_BAD;
-   }
-
-   /* We choose to only get the type of the base object and
-* ignore potentially corrupt pack file that expects the delta
-* based on a base with a wrong size.  This saves tons of
-* inflate() calls.
-*/
-   if (sizep) {
-   *sizep = get_size_from_delta(p, w_curs, curpos);
-   if (*sizep == 0)
-   type = OBJ_BAD;
-   }
-
-   return type;
-}
-
 int unpack_object_header(struct packed_git *p,
 struct pack_window **w_curs,
 off_t *curpos,
@@ -1709,6 +1665,25 @@ int unpack_object_header(struct packed_git *p,
return type;
 }
 
+static int retry_bad_packed_offset(struct packed_git *p, off_t obj_offset)
+{
+   int type;
+   struct revindex_entry *revidx;
+   const unsigned char *sha1;
+   revidx = find_pack_revindex(p, obj_offset);
+   if (!revidx)
+   return OBJ_BAD;
+   sha1 = nth_packed_object_sha1(p, revidx->nr);
+   mark_bad_packed_object(p, sha1);
+   type = sha1_object_info(sha1, NULL);
+   if (type <= OBJ_NONE)
+   return OBJ_BAD;
+   return type;
+}
+
+
+#define POI_STACK_PREALLOC 64
+
 static int packed_object_info(struct packed_git *p, off_t obj_offset,
  unsigned long *sizep, int *rtype)
 {
@@ -1716,31 +1691,89 @@ static int packed_object_info(struct packed_git *p, 
off_t obj_offset,
unsigned long size;
off_t curpos = obj_offset;
enum object_type type

[PATCH v3 3/3] sha1_file: remove recursion in unpack_entry

Similar to the recursion in packed_object_info(), this leads to
problems on stack-space-constrained systems in the presence of long
delta chains.

We proceed in three phases:

1. Dig through the delta chain, saving each delta object's offsets and
   size on an ad-hoc stack.

2. Unpack the base object at the bottom.

3. Unpack and apply the deltas from the stack.

Signed-off-by: Thomas Rast 
---
 sha1_file.c | 231 +++-
 1 file changed, 150 insertions(+), 81 deletions(-)

diff --git a/sha1_file.c b/sha1_file.c
index da41f51..f9191aa 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1943,68 +1943,6 @@ static void add_delta_base_cache(struct packed_git *p, 
off_t base_offset,
 static void *read_object(const unsigned char *sha1, enum object_type *type,
 unsigned long *size);
 
-static void *unpack_delta_entry(struct packed_git *p,
-   struct pack_window **w_curs,
-   off_t curpos,
-   unsigned long delta_size,
-   off_t obj_offset,
-   enum object_type *type,
-   unsigned long *sizep)
-{
-   void *delta_data, *result, *base;
-   unsigned long base_size;
-   off_t base_offset;
-
-   base_offset = get_delta_base(p, w_curs, &curpos, *type, obj_offset);
-   if (!base_offset) {
-   error("failed to validate delta base reference "
- "at offset %"PRIuMAX" from %s",
- (uintmax_t)curpos, p->pack_name);
-   return NULL;
-   }
-   unuse_pack(w_curs);
-   base = cache_or_unpack_entry(p, base_offset, &base_size, type, 0);
-   if (!base) {
-   /*
-* We're probably in deep shit, but let's try to fetch
-* the required base anyway from another pack or loose.
-* This is costly but should happen only in the presence
-* of a corrupted pack, and is better than failing outright.
-*/
-   struct revindex_entry *revidx;
-   const unsigned char *base_sha1;
-   revidx = find_pack_revindex(p, base_offset);
-   if (!revidx)
-   return NULL;
-   base_sha1 = nth_packed_object_sha1(p, revidx->nr);
-   error("failed to read delta base object %s"
- " at offset %"PRIuMAX" from %s",
- sha1_to_hex(base_sha1), (uintmax_t)base_offset,
- p->pack_name);
-   mark_bad_packed_object(p, base_sha1);
-   base = read_object(base_sha1, type, &base_size);
-   if (!base)
-   return NULL;
-   }
-
-   delta_data = unpack_compressed_entry(p, w_curs, curpos, delta_size);
-   if (!delta_data) {
-   error("failed to unpack compressed delta "
- "at offset %"PRIuMAX" from %s",
- (uintmax_t)curpos, p->pack_name);
-   free(base);
-   return NULL;
-   }
-   result = patch_delta(base, base_size,
-delta_data, delta_size,
-sizep);
-   if (!result)
-   die("failed to apply delta");
-   free(delta_data);
-   add_delta_base_cache(p, base_offset, base, base_size, *type);
-   return result;
-}
-
 static void write_pack_access_log(struct packed_git *p, off_t obj_offset)
 {
static FILE *log_file;
@@ -2025,48 +1963,179 @@ static void write_pack_access_log(struct packed_git 
*p, off_t obj_offset)
 
 int do_check_packed_object_crc;
 
+#define UNPACK_ENTRY_STACK_PREALLOC 64
+struct unpack_entry_stack_ent {
+   off_t obj_offset;
+   off_t curpos;
+   unsigned long size;
+};
+
 void *unpack_entry(struct packed_git *p, off_t obj_offset,
-  enum object_type *type, unsigned long *sizep)
+  enum object_type *final_type, unsigned long *final_size)
 {
struct pack_window *w_curs = NULL;
off_t curpos = obj_offset;
-   void *data;
+   void *data = NULL;
+   unsigned long size;
+   enum object_type type;
+   struct unpack_entry_stack_ent 
small_delta_stack[UNPACK_ENTRY_STACK_PREALLOC];
+   struct unpack_entry_stack_ent *delta_stack = small_delta_stack;
+   int delta_stack_nr = 0, delta_stack_alloc = UNPACK_ENTRY_STACK_PREALLOC;
+   int base_from_cache = 0;
 
if (log_pack_access)
write_pack_access_log(p, obj_offset);
 
-   if (do_check_packed_object_crc && p->index_version > 1) {
-   struct revindex_entry *revidx = find_pack_revindex(p, 
obj_offset);
-   unsigned long len = revidx[1].offset - obj_offset;
-   if (check_pack_crc(p, &w_curs, obj_offset, len, revidx->nr)) {
-   const unsigned char *sha1 =
-

[PATCH v3 2/3] Refactor parts of in_delta_base_cache/cache_or_unpack_entry

The delta base cache lookup and test were shared.  Refactor them;
we'll need both parts again.  Also, we'll use the clearing routine
later.

Signed-off-by: Thomas Rast 
---
 sha1_file.c | 45 -
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/sha1_file.c b/sha1_file.c
index 2c8b549..da41f51 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1835,32 +1835,51 @@ static unsigned long pack_entry_hash(struct packed_git 
*p, off_t base_offset)
return hash % MAX_DELTA_CACHE;
 }
 
-static int in_delta_base_cache(struct packed_git *p, off_t base_offset)
+static struct delta_base_cache_entry *
+get_delta_base_cache_entry(struct packed_git *p, off_t base_offset)
 {
unsigned long hash = pack_entry_hash(p, base_offset);
-   struct delta_base_cache_entry *ent = delta_base_cache + hash;
+   return delta_base_cache + hash;
+}
+
+static int eq_delta_base_cache_entry(struct delta_base_cache_entry *ent,
+struct packed_git *p, off_t base_offset)
+{
return (ent->data && ent->p == p && ent->base_offset == base_offset);
 }
 
+static int in_delta_base_cache(struct packed_git *p, off_t base_offset)
+{
+   struct delta_base_cache_entry *ent;
+   ent = get_delta_base_cache_entry(p, base_offset);
+   return eq_delta_base_cache_entry(ent, p, base_offset);
+}
+
+static void clear_delta_base_cache_entry(struct delta_base_cache_entry *ent)
+{
+   ent->data = NULL;
+   ent->lru.next->prev = ent->lru.prev;
+   ent->lru.prev->next = ent->lru.next;
+   delta_base_cached -= ent->size;
+}
+
 static void *cache_or_unpack_entry(struct packed_git *p, off_t base_offset,
unsigned long *base_size, enum object_type *type, int keep_cache)
 {
+   struct delta_base_cache_entry *ent;
void *ret;
-   unsigned long hash = pack_entry_hash(p, base_offset);
-   struct delta_base_cache_entry *ent = delta_base_cache + hash;
 
-   ret = ent->data;
-   if (!ret || ent->p != p || ent->base_offset != base_offset)
+   ent = get_delta_base_cache_entry(p, base_offset);
+
+   if (!eq_delta_base_cache_entry(ent, p, base_offset))
return unpack_entry(p, base_offset, type, base_size);
 
-   if (!keep_cache) {
-   ent->data = NULL;
-   ent->lru.next->prev = ent->lru.prev;
-   ent->lru.prev->next = ent->lru.next;
-   delta_base_cached -= ent->size;
-   } else {
+   ret = ent->data;
+
+   if (!keep_cache)
+   clear_delta_base_cache_entry(ent);
+   else
ret = xmemdupz(ent->data, ent->size);
-   }
*type = ent->type;
*base_size = ent->size;
return ret;
-- 
1.8.2.344.g1440b22

--
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: Segfault with merge-tree on multiple Git versions

John Keeping  writes:

> You could use a temporary index and do something like:
>
>   rm -f TMP_INDEX
>   GIT_INDEX_FILE=TMP_INDEX
>   export GIT_INDEX_FILE
>   git read-tree -m $base $ours $theirs &&
>   git merge-index git-merge-one-file -a
>
> then inspect that with "git diff-index --cached $ours".

Good.

> Note that this will fail if there are conflicts and I don't know what
> git-merge-tree will do in that case.

I _think_ Charlies's use case is to detect trivial merges to tell
the requestee that a merge request can be done on site, so failing
is fine when there are conflicts.  merge-tree should report
conflicts as well.
--
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: propagating repo corruption across clone

On Wed, Mar 27, 2013 at 03:49:38PM -0400, Jeff King wrote:

> On Wed, Mar 27, 2013 at 11:23:15AM -0700, Rich Fromm wrote:
> 
> > But I'm still somewhat confused about what is and is not checked under what
> > conditions.  Consider the three statements:
> > 
> > # 1
> > git clone --mirror myuser@myhost:my_repo
> > 
> > # 2
> > git clone --mirror --config transfer.fsckObjects=true myuser@myhost:my_repo
> > 
> > # 3
> > git clone --mirror myuser@myhost:my_repo && cd my_repo.git && git-fsck
> > 
> > Are 2 and 3 equivalent?  Or is there an increasing level of checking that
> > occurs from 1 to 2, and from 2 to 3?  My guess is the latter, but perhaps
> > this could be clearer in the man pages.
> 
> 2 and 3 are not exactly equivalent, in that they are implemented
> slightly differently, but I do not know offhand of any case that would
> pass 2 but not 3. We do check reachability with transfer.fsckObjects.

Oh, and in the case of #1, I think we would already find corruption, in
that index-pack will expand and check the sha1 of each object we
receive. The transfer.fsckObjects check adds some semantic checks as
well (e.g., making sure author identities are well-formed).

Clone will not currently detect missing objects and reachability
without transfer.fsckObjects set, but that is IMHO a bug; fetch will
notice it, and clone should behave the same way.

-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 status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Linus Torvalds

On Wed, Mar 27, 2013 at 1:00 PM, Junio C Hamano  wrote:
>
> Given that we haven't tweaked the parallelism or thread-cost
> parameters since the inception of the mechanism in Nov 2008, I
> suspect that we would see praises from some and grievances from
> other corners of the user base for a while until we find acceptable
> values for them

Looking at the parameters again, I really think they are pretty sane,
and I don't think the numbers are all that likely to have shifted from
2008. The maximum thread value is quite reasonable: twenty threads is
sufficient to cover quite a bit of latency, and brings "several
seconds" down to "under half a second" for any truly IO-limited load,
while not being disastrous for the case where everything is in cache
and we only have a limited number of CPU cores.

And the "at least 500 files per thread" limit is eminently reasonable
too - smaller projects like git won't have more than five or so
threads.

So I'd be very surprised if the values need much tweaking. Sure, there
might be some extreme cases that might tune for some particular
patterns, and maybe we should make the values be tunable rather than
totally hardcoded, but I suspect there's limited up-side.

It might be interesting for the people who really like tuning, though.
So in addition to "index.preload=true", maybe an extended config
format like "index_preload=50,200" to say "maximum of fifty threads,
for every 200 files" could be done just so people could play around
with the numbers and see how much (if at all) they actually matter.

But I really don't think the original 20/500 rule is likely to be all
that bad for anybody. Unless there is some *really* sucky thread
library out there (ie fully user-space threads, so filename lookup
isn't actually parallelised at all), but at least for that case the
fix is to just say "ok, your threads aren't real threads, so just
disable index preloading entirely).

 Linus
--
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: Composing git repositories

Jonathan Nieder  writes:

> Ramkumar Ramachandra wrote:
>
>>Even then, working with one worktree embedded
>> inside another is something git never designed for: it explains why I
>> have to literally fight with git when using submodules
>
> Do you mean that you wish you could ignore subrepository boundaries
> and use commands like
>
>   git clone --recurse-submodules http://git.zx2c4.com/cgit
>   cd cgit
>   vi git/cache.h
>   ... edit edit edit ...
>   git add --recurse-submodules git/cache.h
>   git commit --recurse-submodules
>   git push --recurse-submodules
>
> , possibly with configuration to allow the --recurse-submodules to be
> implied, and have everything work out well?
> ...
> I think something like that is a goal for submodules in the long
> term,...

As you hinted with "complications" below, I have to wonder what
should happen when the above "git add" touches anything outside
"git" subdirectory.

But such an administrative details (the project boundary is
primarily not an implementation detail but is a social issue) aside,
I agree that overall it would be a good user experience.

I however do not see the implementation detail of having (or not
having) separate $GIT_DIR for component projects having anything to
do with the goal of that ideal.

Where and how do you envision the metainformation about the
component projects are stored in such a clone?  It does not have to
be cgit/.git, but you would need to somehow store things we store in
$GIT_DIR for cgit itself and git in the current system.  If you pick
one location to store both, I would imagine that it would still be
somewhere under the cgit directory.

As I said in another thread, your top-level may be only a part in
somebody else's project, and what you consider just a part of your
project may be the whole project to somebody else.  If you pick one
location to store both for the above clone, e.g. cgit/.git (it could
be cgit/.ram-git or any other name), embedding it in a yet larger
project (perhaps having both cgit and gitolite to give a one-stop
solution for hosting services) later would face the same issue as
Ram seemed to be complaining.  It needs to address what happens when
that cgit/.git (or whatever name) gets in the way in the scope of
the larger project.  That is why I said Ram's rant, using subjective
words like "elegant", without sound technical justification, did not
make much sense 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: [PATCH 5/9] add test for streaming corrupt blobs

On Mon, Mar 25, 2013 at 04:21:34PM -0400, Jeff King wrote:

> +# Convert byte at offset "$2" of object "$1" into '\0'
> +corrupt_byte() {
> + obj_file=$(obj_to_file "$1") &&
> + chmod +w "$obj_file" &&
> + printf '\0' | dd of="$obj_file" bs=1 seek="$2"
> +}

Hmm, this last line should probably be:

diff --git a/t/t1060-object-corruption.sh b/t/t1060-object-corruption.sh
index a84deb1..3f87051 100755
--- a/t/t1060-object-corruption.sh
+++ b/t/t1060-object-corruption.sh
@@ -12,7 +12,7 @@ corrupt_byte() {
 corrupt_byte() {
obj_file=$(obj_to_file "$1") &&
chmod +w "$obj_file" &&
-   printf '\0' | dd of="$obj_file" bs=1 seek="$2"
+   printf '\0' | dd of="$obj_file" bs=1 seek="$2" conv=notrunc
 }
 
 test_expect_success 'setup corrupt repo' '

The intent was to change a single byte, not truncate the file (though on
the plus side, that truncation is what found the other bugs).

-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 v3 3/3] sha1_file: remove recursion in unpack_entry

Thomas Rast  writes:

> Similar to the recursion in packed_object_info(), this leads to
> problems on stack-space-constrained systems in the presence of long
> delta chains.
>
> We proceed in three phases:
>
> 1. Dig through the delta chain, saving each delta object's offsets and
>size on an ad-hoc stack.
>
> 2. Unpack the base object at the bottom.
>
> 3. Unpack and apply the deltas from the stack.
>
> Signed-off-by: Thomas Rast 
> ---

Sounds sensible.

Do we keep the packfiles open that hold the deltas involved in the
chain so that they won't be removed by a concurrent repack?  I do
not think this rewrite changes anything with respect to that access
pattern, though.

Will replace and merge to 'next'.  Thanks.

>  sha1_file.c | 231 
> +++-
>  1 file changed, 150 insertions(+), 81 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index da41f51..f9191aa 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1943,68 +1943,6 @@ static void add_delta_base_cache(struct packed_git *p, 
> off_t base_offset,
>  static void *read_object(const unsigned char *sha1, enum object_type *type,
>unsigned long *size);
>  
> -static void *unpack_delta_entry(struct packed_git *p,
> - struct pack_window **w_curs,
> - off_t curpos,
> - unsigned long delta_size,
> - off_t obj_offset,
> - enum object_type *type,
> - unsigned long *sizep)
> -{
> - void *delta_data, *result, *base;
> - unsigned long base_size;
> - off_t base_offset;
> -
> - base_offset = get_delta_base(p, w_curs, &curpos, *type, obj_offset);
> - if (!base_offset) {
> - error("failed to validate delta base reference "
> -   "at offset %"PRIuMAX" from %s",
> -   (uintmax_t)curpos, p->pack_name);
> - return NULL;
> - }
> - unuse_pack(w_curs);
> - base = cache_or_unpack_entry(p, base_offset, &base_size, type, 0);
> - if (!base) {
> - /*
> -  * We're probably in deep shit, but let's try to fetch
> -  * the required base anyway from another pack or loose.
> -  * This is costly but should happen only in the presence
> -  * of a corrupted pack, and is better than failing outright.
> -  */
> - struct revindex_entry *revidx;
> - const unsigned char *base_sha1;
> - revidx = find_pack_revindex(p, base_offset);
> - if (!revidx)
> - return NULL;
> - base_sha1 = nth_packed_object_sha1(p, revidx->nr);
> - error("failed to read delta base object %s"
> -   " at offset %"PRIuMAX" from %s",
> -   sha1_to_hex(base_sha1), (uintmax_t)base_offset,
> -   p->pack_name);
> - mark_bad_packed_object(p, base_sha1);
> - base = read_object(base_sha1, type, &base_size);
> - if (!base)
> - return NULL;
> - }
> -
> - delta_data = unpack_compressed_entry(p, w_curs, curpos, delta_size);
> - if (!delta_data) {
> - error("failed to unpack compressed delta "
> -   "at offset %"PRIuMAX" from %s",
> -   (uintmax_t)curpos, p->pack_name);
> - free(base);
> - return NULL;
> - }
> - result = patch_delta(base, base_size,
> -  delta_data, delta_size,
> -  sizep);
> - if (!result)
> - die("failed to apply delta");
> - free(delta_data);
> - add_delta_base_cache(p, base_offset, base, base_size, *type);
> - return result;
> -}
> -
>  static void write_pack_access_log(struct packed_git *p, off_t obj_offset)
>  {
>   static FILE *log_file;
> @@ -2025,48 +1963,179 @@ static void write_pack_access_log(struct packed_git 
> *p, off_t obj_offset)
>  
>  int do_check_packed_object_crc;
>  
> +#define UNPACK_ENTRY_STACK_PREALLOC 64
> +struct unpack_entry_stack_ent {
> + off_t obj_offset;
> + off_t curpos;
> + unsigned long size;
> +};
> +
>  void *unpack_entry(struct packed_git *p, off_t obj_offset,
> -enum object_type *type, unsigned long *sizep)
> +enum object_type *final_type, unsigned long *final_size)
>  {
>   struct pack_window *w_curs = NULL;
>   off_t curpos = obj_offset;
> - void *data;
> + void *data = NULL;
> + unsigned long size;
> + enum object_type type;
> + struct unpack_entry_stack_ent 
> small_delta_stack[UNPACK_ENTRY_STACK_PREALLOC];
> + struct unpack_entry_stack_ent *delta_stack = small_delta_stack;
> + int delta_stack_nr = 0, delta_stack_alloc = UNPACK_ENTRY_STACK_PREALLOC;
> + int base_from_cache = 0;
>  
>   if (log_pack_access)
>

Re: [PATCH 5/9] add test for streaming corrupt blobs

Jeff King  writes:

> On Mon, Mar 25, 2013 at 04:21:34PM -0400, Jeff King wrote:
>
>> +# Convert byte at offset "$2" of object "$1" into '\0'
>> +corrupt_byte() {
>> +obj_file=$(obj_to_file "$1") &&
>> +chmod +w "$obj_file" &&
>> +printf '\0' | dd of="$obj_file" bs=1 seek="$2"
>> +}
>
> Hmm, this last line should probably be:
>
> diff --git a/t/t1060-object-corruption.sh b/t/t1060-object-corruption.sh
> index a84deb1..3f87051 100755
> --- a/t/t1060-object-corruption.sh
> +++ b/t/t1060-object-corruption.sh
> @@ -12,7 +12,7 @@ corrupt_byte() {
>  corrupt_byte() {
>   obj_file=$(obj_to_file "$1") &&
>   chmod +w "$obj_file" &&
> - printf '\0' | dd of="$obj_file" bs=1 seek="$2"
> + printf '\0' | dd of="$obj_file" bs=1 seek="$2" conv=notrunc
>  }
>  
>  test_expect_success 'setup corrupt repo' '
>
> The intent was to change a single byte, not truncate the file (though on
> the plus side, that truncation is what found the other bugs).

;-).  Thanks, I missed that.
--
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 (Mar 2013, #07; Tue, 26)

On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:

> [Cooking]
> [...]
> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>  - index-pack: always zero-initialize object_entry list
> 
>  "index-pack --fix-thin" used uninitialize value to compute delta
>  depths of objects it appends to the resulting pack.

Any reason this is still in pu? I'd have expected it to be fairly
uncontroversial and slated for maint.

> * jk/pkt-line-cleanup (2013-03-21) 20 commits
>  - do not use GIT_TRACE_PACKET=3 in tests
>  - remote-curl: always parse incoming refs
>  - remote-curl: move ref-parsing code up in file
>  - remote-curl: pass buffer straight to get_remote_heads
>  - teach get_remote_heads to read from a memory buffer
>  - pkt-line: share buffer/descriptor reading implementation
>  - pkt-line: provide a LARGE_PACKET_MAX static buffer
>  - pkt-line: move LARGE_PACKET_MAX definition from sideband
>  - pkt-line: teach packet_read_line to chomp newlines
>  - pkt-line: provide a generic reading function with options
>  - pkt-line: drop safe_write function
>  - pkt-line: move a misplaced comment
>  - write_or_die: raise SIGPIPE when we get EPIPE
>  - upload-archive: use argv_array to store client arguments
>  - upload-archive: do not copy repo name
>  - send-pack: prefer prefixcmp over memcmp in receive_status
>  - fetch-pack: fix out-of-bounds buffer offset in get_ack
>  - upload-pack: remove packet debugging harness
>  - upload-pack: do not add duplicate objects to shallow list
>  - upload-pack: use get_sha1_hex to parse "shallow" lines
> 
>  Cleans up pkt-line API, implementation and its callers to make them
>  more robust.  Even though I think this change is correct, please
>  report immediately if you find any unintended side effect.
> 
>  Will merge to 'master' in the 3rd batch (Risky).

I was kind of surprised to see this still in pu, too. I thought it was
supposed to cook in next for a while to shake out any interoperability
bugs (and it was in next previously). Did it get ejected after the
release and then never put back?

-Peff

PS I notice John Keeping has become quite active these days, and has
   stolen my initials. It makes searching for my topics in "What's
   Cooking" much harder (I read it linearly, but I take special notice
   of the "jk" topics).
--
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: Composing git repositories

Junio C Hamano wrote:

> I however do not see the implementation detail of having (or not
> having) separate $GIT_DIR for component projects having anything to
> do with the goal of that ideal.

Yeah, I think the current gitlink-instead-of-full-git-dir-for-submodules
implementation that can allow "git rm" to remove a submodule and
"git checkout --recurse-submodules" to later revive it is good.
--
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 (Mar 2013, #07; Tue, 26)

Jeff King  writes:

> I was kind of surprised to see this still in pu, too. I thought it was
> supposed to cook in next for a while to shake out any interoperability
> bugs (and it was in next previously). Did it get ejected after the
> release and then never put back?

Yes, I've been trying to concentrate on flushing safer and older
ones first to 'master', and I _think_ I am more or less finished
with that as of last night.  Many will come back to 'next' in
today's integration run.

>
> -Peff
>
> PS I notice John Keeping has become quite active these days, and has
>stolen my initials. It makes searching for my topics in "What's
>Cooking" much harder (I read it linearly, but I take special notice
>of the "jk" topics).
--
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 (Mar 2013, #07; Tue, 26)

Jeff King  writes:

> On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:
>
>> [Cooking]
>> [...]
>> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>>  - index-pack: always zero-initialize object_entry list
>> 
>>  "index-pack --fix-thin" used uninitialize value to compute delta
>>  depths of objects it appends to the resulting pack.
>
> Any reason this is still in pu? I'd have expected it to be fairly
> uncontroversial and slated for maint.

Me too, along with the other two we found in the same topic:

> * nd/index-pack-threaded-fixes (2013-03-19) 2 commits
>  - index-pack: guard nr_resolved_deltas reads by lock
>  - index-pack: protect deepest_delta in multithread code
>
>  "index-pack --verify-stat" used a few counters outside protection
>  of mutex, possibly showing incorrect numbers.

-- 
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

On Wed, Mar 27, 2013 at 01:50:29PM -0700, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > I was kind of surprised to see this still in pu, too. I thought it was
> > supposed to cook in next for a while to shake out any interoperability
> > bugs (and it was in next previously). Did it get ejected after the
> > release and then never put back?
> 
> Yes, I've been trying to concentrate on flushing safer and older
> ones first to 'master', and I _think_ I am more or less finished
> with that as of last night.  Many will come back to 'next' in
> today's integration run.

Thanks, I figured it was something like that, but was puzzled.

-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: Segfault with merge-tree on multiple Git versions


On 27/03/13 20:01, Jeff King wrote:

On Wed, Mar 27, 2013 at 07:45:21PM +, John Keeping wrote:


On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:

Charlie Smurthwaite  writes:


Yes, I would need to be able to do this on a bare repo for my use case.

And if it's on the server, you don't want this to be observable, so
you don't want HEAD to move around. I don't know a better way than:

   $ git clone --shared -b upstream-branch bare-repo.git /tmp/merge-repo
   $ cd /tmp/merge-repo
   $ git pull URL incoming-branch

Cloning with --shared just writes a path into .git/objects/info/alternatives
and it doesn't need to be on the same file system (unlike --local).

Since 'git merge-tree' just works with trees, it has less information
than 'git merge'.

You could use a temporary index and do something like:

rm -f TMP_INDEX
GIT_INDEX_FILE=TMP_INDEX
export GIT_INDEX_FILE
git read-tree -m $base $ours $theirs &&
git merge-index git-merge-one-file -a

then inspect that with "git diff-index --cached $ours".

That is precisely how we do it at GitHub. You probably want to add in
"--aggressive" to your read-tree to cover a few more simple cases. If
there are conflicts, we just bail and say "this can't be merged", and
expect the user to do it themselves using git.

-Peff


This may be ideal. I will compare it with merge-tree to see which will 
suit best. Thank you everyone for your help here.


Charlie
--
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] push: Alias pushurl from push rewrites

Jonathan Nieder wrote:
> Rob Hoelz wrote:

>> --- a/remote.c
>> +++ b/remote.c
>> @@ -465,7 +465,11 @@ static void alias_all_urls(void)
[...]
>> -remotes[i]->pushurl[j] = 
>> alias_url(remotes[i]->pushurl[j], &rewrites);
>> +char *copy = xstrdup(remotes[i]->pushurl[j]);
>> +remotes[i]->pushurl[j] = 
>> alias_url(remotes[i]->pushurl[j], &rewrites_push);
>> +if (!strcmp(copy, remotes[i]->pushurl[j]))
>> +remotes[i]->pushurl[j] = 
>> alias_url(remotes[i]->pushurl[j], &rewrites);
>> +free(copy);
>
> Interesting.
>
> Suppose I configure
> 
>   [url "git://anongit.myserver.example.com/"]
>   insteadOf = myserver.example.com:
>   [url "myserver:"]
>   pushInsteadOf = myserver.example.com:
>
> The above code would make the insteadOf rule apply instead of
> pushInsteadOf, even when pushing.

Sorry, typo.  The configuration in the example above should have been

[url "git://anongit.myserver.example.com/"]
insteadOf = myserver.example.com:
[url "myserver.example.com:"]
pushInsteadOf = myserver.example.com:

In other words, suppose I set url.*.insteadof to point to a faster
address for fetching alongside url.*.pushinsteadof requesting that the
original address should still be used for pushing.

Thanks again for tackling this.
Jonathan
--
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] merge-tree: fix "same file added in subdir"

When the same file is added with identical content at the top level,
git-merge-tree prints "added in both" with the details.  But if the file
is added in an existing subdirectory, threeway_callback() bails out early
because the two trees have been modified identically.

In order to detect this, we need to fall through and recurse into the
subtree in this case.

Signed-off-by: John Keeping 
---
 builtin/merge-tree.c  |  9 +++--
 t/t4300-merge-tree.sh | 17 +
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index e0d0b7d..ca97fbd 100644
--- a/builtin/merge-tree.c
+++ b/builtin/merge-tree.c
@@ -298,12 +298,17 @@ static int threeway_callback(int n, unsigned long mask, 
unsigned long dirmask, s
 {
/* Same in both? */
if (same_entry(entry+1, entry+2)) {
-   if (entry[0].sha1) {
+   if (entry[0].sha1 && !S_ISDIR(entry[0].mode)) {
/* Modified identically */
resolve(info, NULL, entry+1);
return mask;
}
-   /* "Both added the same" is left unresolved */
+   /*
+* "Both added the same" is left unresolved.  We also leave
+* "Both directories modified identically" unresolved in
+* order to catch changes where the same file (with the same
+* content) has been added to both directories.
+*/
}
 
if (same_entry(entry+0, entry+1)) {
diff --git a/t/t4300-merge-tree.sh b/t/t4300-merge-tree.sh
index d0b2a45..be0737e 100755
--- a/t/t4300-merge-tree.sh
+++ b/t/t4300-merge-tree.sh
@@ -298,4 +298,21 @@ test_expect_success 'turn tree to file' '
test_cmp expect actual
 '
 
+test_expect_success 'add identical files to subdir' '
+   cat >expected <<\EXPECTED &&
+added in both
+  our100644 43d5a8ed6ef6c00ff775008633f95787d088285d sub/ONE
+  their  100644 43d5a8ed6ef6c00ff775008633f95787d088285d sub/ONE
+EXPECTED
+
+   git reset --hard initial &&
+   mkdir sub &&
+   test_commit "sub-initial" "sub/initial" "initial" &&
+   test_commit "sub-add-a-b-same-A" "sub/ONE" "AAA" &&
+   git reset --hard sub-initial &&
+   test_commit "sub-add-a-b-same-B" "sub/ONE" "AAA" &&
+   git merge-tree sub-initial sub-add-a-b-same-A sub-add-a-b-same-B 
>actual &&
+   test_cmp expected actual
+'
+
 test_done
-- 
1.8.2.411.g65a544e

--
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 (Mar 2013, #07; Tue, 26)

Thomas Rast  writes:

> Jeff King  writes:
>
>> On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:
>>
>>> [Cooking]
>>> [...]
>>> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>>>  - index-pack: always zero-initialize object_entry list
>>> 
>>>  "index-pack --fix-thin" used uninitialize value to compute delta
>>>  depths of objects it appends to the resulting pack.
>>
>> Any reason this is still in pu? I'd have expected it to be fairly
>> uncontroversial and slated for maint.
>
> Me too, along with the other two we found in the same topic:
>
>> * nd/index-pack-threaded-fixes (2013-03-19) 2 commits
>>  - index-pack: guard nr_resolved_deltas reads by lock
>>  - index-pack: protect deepest_delta in multithread code
>>
>>  "index-pack --verify-stat" used a few counters outside protection
>>  of mutex, possibly showing incorrect numbers.

Yes.

Speaking of which... (cc'ed various people involved in the topics
listed below)

> [Stalled]

It may be time to discard all the stalled topics (without
prejudice), except for some.

> * jc/format-patch (2013-02-21) 2 commits
>  - format-patch: --inline-single
>  - format-patch: rename "no_inline" field
>
>  A new option to send a single patch to the standard output to be
>  appended at the bottom of a message.  I personally have no need for
>  this, but it was easy enough to cobble together.  Tests, docs and
>  stripping out more MIMEy stuff are left as exercises to interested
>  parties.
>
>  Not ready for inclusion.

Somebody may want to pick this up to give it finishing touches.

I am reasonably sure that some MIMEy stuff are still leaked to the
output.  From the UI point of view, this does not let you say

git format-patch --inline-single []

with omitted  defalting to HEAD (instead you have to say "-1").

> * po/help-guides (2013-03-03) 5 commits

I know Philip said a reroll is planned, so if it comes, it can be
requeued.

> * mb/gitweb-highlight-link-target (2012-12-20) 1 commit
>  - Highlight the link target line in Gitweb using CSS
>
>  Expecting a reroll.
>  $gmane/211935

Highlighting was cute but the anchor was not.

> [Cooking]
>
> * jc/merge-tag-object (2013-03-19) 1 commit
>  - merge: a random object may not necssarily be a commit

Probably we should eventually merge this as a bugfix to maintenance
track.

> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>  - index-pack: always zero-initialize object_entry list

This is in the same class as the ones you two were wondering about,
I think.

> * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
>   (merged to 'next' on 2013-03-19 at e68014a)
>  + difftool --dir-diff: symlink all files matching the working tree
>  + difftool: avoid double slashes in symlink targets
>  + git-difftool(1): fix formatting of --symlink description

I lost track of various discussions on "difftool" and its "symlink
so that the user can edit working tree files in the tool".

> * tr/line-log (2013-03-23) 6 commits
>  - Speed up log -L... -M
>  - log -L: :pattern:file syntax to find by funcname
>  - Implement line-history search (git log -L)
>  - Export rewrite_parents() for 'log -L'
>  - fixup
>  - Refactor parse_loc
>
>  Rerolled; collides with nd/magic-pathspecs.

Honestly I am not sure what to make of this one.  I'd say we should
merge this down as-is to 'master', expecting that in some future we
would fix "log --follow" to keep the refspecs per history traversal
path, so that this can be more naturally reimplemented.  Objections?


> * jc/push-2.0-default-to-simple (2013-03-18) 15 commits
>  - advice: Remove unused advice_push_non_ff_default
>  - t5570: do not assume the "matching" push is the default
>  - t5551: do not assume the "matching" push is the default
>  - t5550: do not assume the "matching" push is the default
>  - doc: push.default is no longer "matching"
>  - push: switch default from "matching" to "simple"
>  - t9401: do not assume the "matching" push is the default
>  - t9400: do not assume the "matching" push is the default
>  - t7406: do not assume the "matching" push is the default
>  - t5531: do not assume the "matching" push is the default
>  - t5519: do not assume the "matching" push is the default
>  - t5517: do not assume the "matching" push is the default
>  - t5516: do not assume the "matching" push is the default
>  - t5505: do not assume the "matching" push is the default
>  - t5404: do not assume the "matching" push is the default
>
>  Will cook in 'next' until Git 2.0.

At least we should reorder the three test patches near the tip to
come before the "switch the default", and perhaps squash the tip
one and "doc" patch to "switch the default" one, but other than
that, are we ready to commit to this?

> * jn/add-2.0-u-A-sans-pathspec (2013-03-20) 5 commits
>  - git add: -u/-A now affects the entire working tree
>  - add -A: only show pathless 'add -A' warning when changes exist outside cwd
>  - add -u: only show pathless 'add -u' warning when changes exist outside cw

which files will have conflicts between two branches?

2013-03-27 Thread J.V.

I have two local branches (tracked to remote) that are in sync (did a 
git pull on both branches from their corresponding remote).


Is this the best way to merge?

I would be merging local/branch1 => local/branch2 (test this branch) and 
then push local/branch2 => origin/branch1  (and would expect no merge 
conflicts if anyone has not checked in anything.


---
Also with two local branches, Is there a way to get a list of files (one 
line per file) of files that would have merge conflicts that would need 
to be resolved?


thanks

J.V.
--
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] push: Alias pushurl from push rewrites

Jonathan Nieder  writes:

> Sorry, typo.  The configuration in the example above should have been
>
>   [url "git://anongit.myserver.example.com/"]
>   insteadOf = myserver.example.com:
>   [url "myserver.example.com:"]
>   pushInsteadOf = myserver.example.com:
>
> In other words, suppose I set url.*.insteadof to point to a faster
> address for fetching alongside url.*.pushinsteadof requesting that the
> original address should still be used for pushing.

I didn't know we were even shooting for supporting the identity
mapping:

url.X.pushinsteadof=X

but that would certainly be nice.

By the way, it seems that the original commit 1c2eafb89bca (Add
url..pushInsteadOf: URL rewriting for push only, 2009-09-07)
wanted to explicitly avoid use of pushInsteadOf aliasing for a
pushURL and it is also documented in config.txt from day one.

I think the intent is "You have a normal URL, and a way to override
it explicitly with pushURL, or a way to rewrite it via the aliasing
the normal URL with pushInsteadOf. Either one or the other, but not
both, as having many levels of indirection would be confusing."

Which I can understand and sympathise.

In anay case, the change proposed in this thread seems to change
that, so the documentation would need to be updated.  Also the tests
the original commit adds explicitly checks that pushInsteadOf is
ignored, which may have to be updated (unless that test is already
broken).

--
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 (Mar 2013, #07; Tue, 26)

On Wed, Mar 27, 2013 at 02:47:25PM -0700, Junio C Hamano wrote:
> > * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
> >   (merged to 'next' on 2013-03-19 at e68014a)
> >  + difftool --dir-diff: symlink all files matching the working tree
> >  + difftool: avoid double slashes in symlink targets
> >  + git-difftool(1): fix formatting of --symlink description
> 
> I lost track of various discussions on "difftool" and its "symlink
> so that the user can edit working tree files in the tool".

Would it be easiest if I send a new series incorporating
jk/difftool-dirr-diff-edit-fix and the proposed change to not overwrite
modified working tree files, built on top of t7800-modernize?

The "overwrite modified working tree files" issue isn't new, but
jk/difftool-dir-diff-edit-fix makes it more likely to happen so it might
be best to include those in one topic, and building on
jk/t7800-modernize will avoid conflicts in the tests.
--
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 and GSoC 2013

2013-03-27 Thread Christian Couder

On Wed, Mar 27, 2013 at 7:52 PM, Jonathan Nieder  wrote:
> Jeff King wrote:
>
>> There was a big thread about a month ago on whether Git should do Google
>> Summer of Code this year[1].

I think we should do it.

It looks strange to me to say that students are great and at the same
time that we should not do it.

Let's give them and us one more chance do to well. This is the only
way we can improve.

Best regards,
Christian.
--
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 (Mar 2013, #07; Tue, 26)

John Keeping  writes:

> On Wed, Mar 27, 2013 at 02:47:25PM -0700, Junio C Hamano wrote:
>> > * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
>> >   (merged to 'next' on 2013-03-19 at e68014a)
>> >  + difftool --dir-diff: symlink all files matching the working tree
>> >  + difftool: avoid double slashes in symlink targets
>> >  + git-difftool(1): fix formatting of --symlink description
>> 
>> I lost track of various discussions on "difftool" and its "symlink
>> so that the user can edit working tree files in the tool".
>
> Would it be easiest if I send a new series incorporating
> jk/difftool-dirr-diff-edit-fix and the proposed change to not overwrite
> modified working tree files, built on top of t7800-modernize?

I am somewhat reluctant to rewind a topic that has been cooking in
'next' for over a week (the above says 19th).  Rebuilding the
style-fixes on top of the above is fine---that topic is much
younger.
--
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] use refnames instead of "left"/"right" in dirdiffs

2013-03-27 Thread Christoph Anton Mitterer

Currently, when a dir-diff is made with git-difftool the two revisions are
stored in two temporary directories ".../left" and ".../right".
Many difftools show these pathnames in ther UI and therefore it would be helpful
for users, if actual reference names specified as progam arguments was used
instead.

Reference names might contain slash / characters which are not allowed to be
part of a file name. These must therefore be encoded.

Also, reference names that would could possibly "break out" of the temporary
directory (e.g. "/foo", "foo/../bar" or "foo/././bar") must be sanitised.
* Added a subroutine escape_reference_to_single_directory_name() which encodes a
  reference name to a valid single directory name.
  Any occurance of a slash / is replaced by two backslashes \\.
  Having a backslash \ in a reference name should be forbidden, but just to be
  save from collisions, any occurance of a backslash \ is replaced by a
  backslash followed by an underscore \_ at first.

* Use this new function to construct the pathnames of the temporary directories
  for the two revisions in dir-diffs.

Signed-off-by: Christoph Anton Mitterer 

diff --git a/git-difftool.perl b/git-difftool.perl
index 12231fb..53e756d 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -83,6 +83,28 @@ sub exit_cleanup
exit($status | ($status >> 8));
 }
 
+sub escape_reference_to_single_directory_name
+{
+   # Git allows reference names (see git-check-ref-format(1)) which cannot
+   # be directly mapped to a single directory name.
+   #
+   # This subroutines replaces any occurance of a slash / by two
+   # backslashes \\.
+   # Thereby, break-out attempts like "/foo", "foo/../bar" or "foo/././bar"
+   # are prevented, too.
+   #
+   # Having a backslash \ in a reference name should be forbidden, but just
+   # to be save from collisions, any occurance of a backslash \ is replaced
+   # by a backslash followed by an underscore \_ at first.
+
+   my ($commit_name)  = @_;
+
+   $commit_name =~ s/\\/\\_/g;
+   $commit_name =~ s/\///g;
+
+   return $commit_name;
+}
+
 sub setup_dir_diff
 {
my ($repo, $workdir, $symlinks) = @_;
@@ -169,8 +191,13 @@ EOF
 
# Setup temp directories
my $tmpdir = tempdir('git-difftool.X', CLEANUP => 0, TMPDIR => 1);
-   my $ldir = "$tmpdir/left";
-   my $rdir = "$tmpdir/right";
+   my $ldir = "$tmpdir/" . 
escape_reference_to_single_directory_name($ARGV[0]);
+   my $rdir = "$tmpdir/";
+   if (@ARGV < 2) {
+   $rdir .= 'HEAD';
+   } else {
+   $rdir .= escape_reference_to_single_directory_name($ARGV[1]);
+   }
mkpath($ldir) or exit_cleanup($tmpdir, 1);
mkpath($rdir) or exit_cleanup($tmpdir, 1);
 



smime.p7s
Description: S/MIME cryptographic signature

jn/add-2.0-u-A-sans-pathspec (Re: What's cooking in git.git (Mar 2013, #07; Tue, 26))