Re: [PATCH 5/6] remote.c: introduce remote.pushdefault
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
Signed-off-by: Mihai Capotă mi...@mihaic.ro --- 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 repository name.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 :-(
On Tue, Mar 26, 2013 at 10:04 PM, Jeff King p...@peff.net 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
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
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
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 gauth...@ostervall.se
---
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
Re: merge help
On Tuesday, March 26, 2013 at 18:07 EDT, J.V. jvsr...@gmail.com 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 file' 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] commit commit [--] [path...] 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
The text is copied from Documentation/git-tag.txt. Signed-off-by: Christian Helmuth christian.helm...@genode-labs.com --- 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 msg:: --message=msg:: Use the given msg as the commit message. + If multiple `-m` options are given, their values are + concatenated as separate paragraphs. -t file:: --template=file:: -- 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 j...@szakmeister.net 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 gits...@pobox.com 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
[PATCH v2] log: Read gpg settings for signed commit verification
From: Jacob Sarvisjsar...@openspan.com 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 hbrig...@openspan.com --- 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.commailto:char...@atechmedia.com web. atechmedia.comhttp://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 pclo...@gmail.com writes: On Sat, Mar 23, 2013 at 10:13 AM, Duy Nguyen pclo...@gmail.com 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
On Wed, Mar 27, 2013 at 8:33 PM, Junio C Hamano gits...@pobox.com wrote: Sitaram Chamarty sitar...@gmail.com writes: On Wed, Mar 27, 2013 at 9:17 AM, Junio C Hamano gits...@pobox.com 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 some empty dir 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
Charlie Smurthwaite char...@atechmedia.com 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 gits...@pobox.com
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 gits...@pobox.com
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 commands.20888+1416,
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 char...@atechmedia.com 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 gits...@pobox.com
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 gits...@pobox.com
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 j...@keeping.me.uk
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: Composing git repositories
Ramkumar Ramachandra artag...@gmail.com 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ă mi...@mihaic.ro writes: Signed-off-by: Mihai Capotă mi...@mihaic.ro --- 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 hbrig...@openspan.com 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 Sarvisjsar...@openspan.com 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 hbrig...@openspan.com 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 hbrig...@openspan.com writes:
From: Jacob Sarvis jsar...@openspan.com
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 hbrig...@openspan.com
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
Hi, Le 27.03.2013 16:05, Junio C Hamano a écrit : Yann Droneaud ydrone...@opteya.com 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 normalper...@yhbt.net writes: Sebastian Schuberth sschube...@gmail.com wrote: This originates from an msysgit pull request, see: https://github.com/msysgit/git/pull/58 Signed-off-by: Eric Wieser wieser.e...@gmail.com Signed-off-by: Sebastian Schuberth sschube...@gmail.com Thanks, looks obviously correct. Signed-off-by: Eric Wong normalper...@yhbt.net ... 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 j...@keeping.me.uk 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 j...@keeping.me.uk
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?
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?
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?
On Wed, 27 Mar 2013 11:39:31 -0500 Jim Kinsman jakins...@gmail.com 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 artag...@gmail.com 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 p...@peff.net 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
Junio C Hamano [mailto:gits...@pobox.com] wrote: Edward Thomson ethom...@microsoft.com 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
Signed-off-by: Mihai Capotă mi...@mihaic.ro --- 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 char...@atechmedia.com 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 artag...@gmail.com 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
[PATCH v2] config: Consistent call style to gpg settings
From: Jacob Sarvis jsar...@openspan.com
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 jsar...@openspan.com
Signed-off-by: Hans Brigman hbrig...@openspan.com
---
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 hbrig...@openspan.com writes:
From: Jacob Sarvis jsar...@openspan.com
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 hbrig...@openspan.com
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
On Wed, 20 Mar 2013 07:35:58 -0700 Junio C Hamano gits...@pobox.com wrote: Rob Hoelz r...@hoelz.ro writes: On 3/19/13 7:08 PM, Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com 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
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 r...@hoelz.ro
---
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 rw:
+ test_config remote.r.url rw:testrepo
+ git push r refs/heads/master:refs/remotes/origin/master
+ (
+
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 ethom...@microsoft.com writes: Junio C Hamano [mailto:gits...@pobox.com] wrote: Edward Thomson ethom...@microsoft.com 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 artag...@gmail.com 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 char...@atechmedia.com 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
Charlie Smurthwaite char...@atechmedia.com 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
Junio C Hamano gits...@pobox.com wrote: Eric Wong normalper...@yhbt.net 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?
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 file... to update what will be committed) # (use git checkout -- file... 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 matthieu@grenoble-inp.fr wrote: Jim Kinsman jakins...@gmail.com 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
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
Re: propagating repo corruption across clone
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
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
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: message 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: previous message and it goes on and on and on. 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 richard_fr...@yahoo.com 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
Charlie Smurthwaite char...@atechmedia.com 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?
On Wed, Mar 27, 2013 at 12:04 PM, Jeff King p...@peff.net 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 ethom...@microsoft.com 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 mode, SHA-1 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 char...@atechmedia.com 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 torva...@linux-foundation.org writes: On Wed, Mar 27, 2013 at 12:04 PM, Jeff King p...@peff.net 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 char...@atechmedia.com 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 tr...@inf.ethz.ch 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 sza...@google.com
Signed-off-by: Thomas Rast tr...@student.ethz.ch
---
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 =
[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 tr...@student.ethz.ch
---
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 =
-
Re: git status takes 30 seconds on Windows 7. Why?
On Wed, Mar 27, 2013 at 1:00 PM, Junio C Hamano gits...@pobox.com 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 jrnie...@gmail.com 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: What's cooking in git.git (Mar 2013, #07; Tue, 26)
Jeff King p...@peff.net 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 p...@peff.net 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 p...@peff.net 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 char...@atechmedia.com 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
which files will have conflicts between two branches?
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 jrnie...@gmail.com 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.base.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
On Wed, Mar 27, 2013 at 7:52 PM, Jonathan Nieder jrnie...@gmail.com 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 j...@keeping.me.uk 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
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 m...@christoph.anton.mitterer.name
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))
Junio C Hamano wrote:
On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:
* 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 cwd
- add: make warn_pathless_add() a no-op after first call
- add: make pathless 'add [-u|-A]' warning a file-global function
Replaces jc/add-2.0-u-A-sans-pathspec topic by not warning against
add -u/-A that is ran without pathspec when there is no change
outside the current directory.
I recall we had a lengthy discussion on this, but how committed are
we on the progression of this series? Are the bottom four ready to
be merged to 1.8.3, or do they need more polishing?
I wanted to add tests and then other tasks took over. Sorry. Probably
best to get the bottom four in next and add tests on top later.
I have the following squashed in locally.
-- 8 --
Subject: fixup! add -u: only show pathless 'add -u' warning when changes exist
outside cwd
Define ADD_CACHE_IMPLICIT_DOT in cache.h alongside the other add_to_index
flags. This way, authors of patches adding new flags that might want to
use the same bit can know to be careful.
Requested-by: Jeff King p...@peff.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks,
Jonathan
builtin/add.c | 1 -
cache.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/add.c b/builtin/add.c
index ad59182..9f35df7 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -139,7 +139,6 @@ static void update_callback(struct diff_queue_struct *q,
}
}
-#define ADD_CACHE_IMPLICIT_DOT 32
int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
{
struct update_callback_data data;
diff --git a/cache.h b/cache.h
index e493563..5de3480 100644
--- a/cache.h
+++ b/cache.h
@@ -459,6 +459,7 @@ extern int remove_file_from_index(struct index_state *,
const char *path);
#define ADD_CACHE_IGNORE_ERRORS4
#define ADD_CACHE_IGNORE_REMOVAL 8
#define ADD_CACHE_INTENT 16
+#define ADD_CACHE_IMPLICIT_DOT 32 /* internal to git add -u/-A */
extern int add_to_index(struct index_state *, const char *path, struct stat *,
int flags);
extern int add_file_to_index(struct index_state *, const char *path, int
flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned
char *sha1, const char *path, int stage, int refresh);
--
1.8.2.rc3
--
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
On Wed, 27 Mar 2013 15:07:18 -0700 Junio C Hamano gits...@pobox.com wrote: Jonathan Nieder jrnie...@gmail.com 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.base.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). My use case is that I use Github for my personal development. I have a prefix for my personal repos (hoelzro: - git://github.com/hoelzro for fetch, g...@github.com:hoelzro/ for push) and one for all other Git repos (github: - git://github.com/) I have a few projects where I work in a fork, but I want to fetch updates from the original project. So my url for the origin remote is github:org/project, but my pushurl is hoelzro:project. This behavior in Git currently doesn't allow me to work that way. I used to work with two remotes; origin for my repo and base for the official one, but I've found that I prefer this other way. The test that checked that pushInsteadOf + pushurl shouldn't work as I expect was actually broken; I have removed it, updated the documentation, and sent a new patch to the list. -Rob -- 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 03:15:44PM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk 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. Sadly that's easier said than done, since it just introduces further conflicts as jk/difftool-dir-diff-edit-fix doesn't include da/difftool-fixes (now in master). So I think the best thing may be to: 1) take only the middle patch from jk/t7800-modernize for now (which fixes a test failure on Windows and shouldn't conflict with anything else) and discard the other two patches there, to be re-sent after other topics in flight graduate 2) add the don't overwrite modified working tree files patch built on top of jk/difftool-dir-diff-edit-fix (presumably as a new topic) -- 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
On Wed, 27 Mar 2013 15:47:35 -0700 Jonathan Nieder jrnie...@gmail.com wrote: Hi, Rob Hoelz wrote: On Wed, 27 Mar 2013 11:23:45 -0700 Jonathan Nieder jrnie...@gmail.com wrote: 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? Are you sure? The message you are replying to is nonsense, due to a typo while editing. Did you see my followup? Sorry for the confusion, Jonathan My mistake; I had not seen it! I thought you may have found a bug in my implementation, so I wanted to double check. =) -Rob -- 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: My mistake; I had not seen it! I thought you may have found a bug in my implementation, so I wanted to double check. =) Well, I had found an unfortunate consequence of the implementation that uses an unnecessary copy. :) Will follow up to the updated patch. -- 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] merge-tree: fix same file added in subdir
On Wed, Mar 27, 2013 at 03:42:40PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
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 j...@keeping.me.uk
The rationale the above description gives is internally consistent,
but it is rather sad to see this optimization go. The primary
motivation behind this program, which does not use the usual
unpack-trees machinery, is to allow us to cull the identical result
at a shallow level of the traversal when the both sides changed (not
added) a file deep in a subdirectory hierarchy.
The patch makes me wonder if we should go the other way around,
resolving the both added identically case at the top cleanly
without complaint.
I don't use merge-tree so I have no opinion on this, just wanted to fix
an inconsistency :-)
I'll try to have a look at doing the other change tomorrow if no one
else gets there first.
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
--
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
Am 27.03.2013 18:02, schrieb Ramkumar Ramachandra: Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com 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. Submodules work pretty well, no matter if you call them a hack. And what you call a workaround allows us to move, remove and recreate submodules, which is one of *the* major inconveniences submodules currently have. 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). Unless you acknowledge that submodules are a different repo, you'll always run into problems. I believe future enhancements will make this less tedious, but in the end they will stay separate repos (which is the whole point, you'd want to use a different approach - e.g. subtree - if you want to put stuff from different upstreams into a single repo without keeping the distinction where all that came from). 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. What else than a commit object should that be??? Submodules are there to have a different upstream for a part of your work tree, and that means a commit in that repo is the only sane thing to record in the superproject. A lot of thought has been put into this, and it is definitely a good choice [1]. 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. How? The submodules suck, we should try a completely different approach thingy comes up from time to time, but so far nobody could provide a viable alternative to what we currently do. And apart from that, let's not forget we identified some valuable improvements to submodules in this thread: *) Get rid of the toplevel requirement *) Add functionality to relocate the object store out of the work tree (either git submodule to-gitfile or something similar, maybe even as a separate script in contrib) *) Add an option to git submodule add (and/or maybe a config option) to relocate the object store immediately on adding an already present submodule All of those are topics I like to see materialize, and you are welcome to tackle them. [1]: http://article.gmane.org/gmane.comp.version-control.git/151857/ -- 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
On Wed, 27 Mar 2013 15:56:56 -0700 Jonathan Nieder jrnie...@gmail.com wrote: Rob Hoelz wrote: My mistake; I had not seen it! I thought you may have found a bug in my implementation, so I wanted to double check. =) Well, I had found an unfortunate consequence of the implementation that uses an unnecessary copy. :) Will follow up to the updated patch. I actually wanted to talk about the copy thing. I realize that this could have been avoided by simply saving a pointer to the old string and performing a comparison, but I figured if the implementation for alias_url were changed in the future to use realloc or something, it could potentially return the original char * with its contents altered. So, by copying the string, we can avoid strange bugs in the future. -Rob -- 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] use refnames instead of left/right in dirdiffs
On Wed, Mar 27, 2013 at 11:13:17PM +0100, Christoph Anton Mitterer wrote:
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 m...@christoph.anton.mitterer.name
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.
That's not going to work well on Windows, is it? Anything with two dots
in is already forbidden so we don't need to worry about that; I'm not
sure we need to remove forward slashes at all, until we consider the
commit containing syntax ':/fix nasty bug' or 'master^{/fix bug}'.
I'm more concerned with specifiers containing '^', '@', '{', ':' - see
'SPECIFYING REVISIONS' in git-rev-parse(1) for the full details of
what's acceptable. At some point I think it may be better to fall back
to the SHA1 of the relevant commit.
+ #
+ # 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]);
+ }
I don't think this approach is general enough, since git-difftool
accepts the same range of arguments that git-diff does.
We need to walk over @ARGV here, ignore anything starting with '-', stop
when we reach '--' and handle the arguments found in there including the
three acceptable range forms:
commit commit
commit..commit
commit...commit
replacing missing commits with HEAD.
mkpath($ldir) or exit_cleanup($tmpdir, 1);
mkpath($rdir) or exit_cleanup($tmpdir, 1);
--
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
On Wed, Mar 27, 2013 at 05:48:45PM -0500, Rob Hoelz wrote: On Wed, 27 Mar 2013 15:07:18 -0700 Junio C Hamano gits...@pobox.com wrote: Jonathan Nieder jrnie...@gmail.com 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.base.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). My use case is that I use Github for my personal development. I have a prefix for my personal repos (hoelzro: - git://github.com/hoelzro for fetch, g...@github.com:hoelzro/ for push) and one for all other Git repos (github: - git://github.com/) I have a few projects where I work in a fork, but I want to fetch updates from the original project. So my url for the origin remote is github:org/project, but my pushurl is hoelzro:project. This behavior in Git currently doesn't allow me to work that way. I used to work with two remotes; origin for my repo and base for the official one, but I've found that I prefer this other way. The test that checked that pushInsteadOf + pushurl shouldn't work as I expect was actually broken; I have removed it, updated the documentation, and sent a new patch to the list. There's an argument for either behavior as valid. My original patch specifically documented and tested for the opposite behavior, namely that pushurl overrides any pushInsteadOf, because I intended pushInsteadOf as a fallback if you don't have an explicit pushurl set. For instance, you could use pushInsteadOf to rewrite a family of anonymous git URLs to corresponding pushable repositories, but then use an explicit pushurl to override that for a specific repository. This change would break the ability to use pushurl for its original intended purpose, namely having a local repository where fetch comes from one remote repo and push goes to another. One use case of mine: I have a .gitconfig in my git-managed home directory which sets pushInsteadOf so that I can clone via git:// and immediately have working push. I work with a number of systems that don't have inbound access to each other but do have outbound access to the network; on some of these satellite boxes, I can't push changes directly to the server pushInsteadOf points to, so I can explicitly set pushurl in .git/config for that repository, which overrides the pushInsteadOf. This change would break that configuration. - Josh Triplett -- 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
On Wed, Mar 27, 2013 at 04:09:43PM -0700, Josh Triplett wrote: On Wed, Mar 27, 2013 at 05:48:45PM -0500, Rob Hoelz wrote: On Wed, 27 Mar 2013 15:07:18 -0700 Junio C Hamano gits...@pobox.com wrote: Jonathan Nieder jrnie...@gmail.com 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.base.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). My use case is that I use Github for my personal development. I have a prefix for my personal repos (hoelzro: - git://github.com/hoelzro for fetch, g...@github.com:hoelzro/ for push) and one for all other Git repos (github: - git://github.com/) I have a few projects where I work in a fork, but I want to fetch updates from the original project. So my url for the origin remote is github:org/project, but my pushurl is hoelzro:project. This behavior in Git currently doesn't allow me to work that way. I used to work with two remotes; origin for my repo and base for the official one, but I've found that I prefer this other way. The test that checked that pushInsteadOf + pushurl shouldn't work as I expect was actually broken; I have removed it, updated the documentation, and sent a new patch to the list. There's an argument for either behavior as valid. My original patch specifically documented and tested for the opposite behavior, namely that pushurl overrides any pushInsteadOf, because I intended pushInsteadOf as a fallback if you don't have an explicit pushurl set. For instance, you could use pushInsteadOf to rewrite a family of anonymous git URLs to corresponding pushable repositories, but then use an explicit pushurl to override that for a specific repository. This change would break the ability to use pushurl for its original intended purpose, namely having a local repository where fetch comes from one remote repo and push goes to another. One use case of mine: I have a .gitconfig in my git-managed home directory which sets pushInsteadOf so that I can clone via git:// and immediately have working push. I work with a number of systems that don't have inbound access to each other but do have outbound access to the network; on some of these satellite boxes, I can't push changes directly to the server pushInsteadOf points to, so I can explicitly set pushurl in .git/config for that repository, which overrides the pushInsteadOf. This change would break that configuration. Clarifying this use case a bit: note that it's been a while since I had many such boxes, so I don't actually have any systems currently using that pushurl configuration. Still a regression in defined behavior, though. Why not just use insteadOf for your personal github prefix hoelzro:, and both insteadOf and pushInsteadOf for github: in general? Then, a repository cloned via github: would work for pull and push (if you have push access), and you can change pushurl to your personal github alias if needed. Though, as Junio said, the modern push-updates-remote-heads behavior of git means that both of our configurations arguably seem wrong, and we should both just use separate remotes for separate repos. - Josh Triplett -- 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
Josh Triplett wrote: I have a .gitconfig in my git-managed home directory which sets pushInsteadOf so that I can clone via git:// and immediately have working push. I work with a number of systems that don't have inbound access to each other but do have outbound access to the network; on some of these satellite boxes, I can't push changes directly to the server pushInsteadOf points to, so I can explicitly set pushurl in .git/config for that repository, which overrides the pushInsteadOf. This change would break that configuration. Would it? As long as your pushurl does not start with git://, I think your configuration would still work fine. After this patch, neither pushInsteadOf nor pushUrl overrides the other one. The rule is: 1. First, get the URL from the remote's configuration, based on whether you are fetching or pushing. (At this step, in your setup git chooses the URL specified with pushurl in your .git/config.) 2. Next, apply the most appropriate url.*.insteadOf or url.*.pushInsteadOf rule, based on whether you are fetching or pushing. (At this step, no rewrite rules apply, so the URL is used as is.) -- 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] git help config: s/insn/instruction/
insn appears to be an in-code abbreviation and should not appear in manual/help pages. --- Documentation/config.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c1f435f..f79184c 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -555,7 +555,7 @@ core.commentchar:: (default '#'). sequence.editor:: - Text editor used by `git rebase -i` for editing the rebase insn file. + Text editor used by `git rebase -i` for editing the rebase instruction file. The value is meant to be interpreted by the shell when it is used. It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable. When not configured the default commit message editor is used instead. -- 1.8.2 -- 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] http-backend: respect GIT_NAMESPACE with dumb clients
Filter the list of refs returned via the dumb HTTP protocol according
to the active namespace, consistent with other clients of the
upload-pack service.
Signed-off-by: John Koleszar jkoles...@google.com
---
http-backend.c | 8 +---
t/lib-httpd/apache.conf | 5 +
t/t5561-http-backend.sh | 4
t/t556x_common | 16
4 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index f50e77f..b9896b0 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -361,17 +361,19 @@ static void run_service(const char **argv)
static int show_text_ref(const char *name, const unsigned char *sha1,
int flag, void *cb_data)
{
+ const char *name_nons = strip_namespace(name);
struct strbuf *buf = cb_data;
struct object *o = parse_object(sha1);
if (!o)
return 0;
- strbuf_addf(buf, %s\t%s\n, sha1_to_hex(sha1), name);
+ strbuf_addf(buf, %s\t%s\n, sha1_to_hex(sha1), name_nons);
if (o-type == OBJ_TAG) {
o = deref_tag(o, name, 0);
if (!o)
return 0;
- strbuf_addf(buf, %s\t%s^{}\n, sha1_to_hex(o-sha1), name);
+ strbuf_addf(buf, %s\t%s^{}\n, sha1_to_hex(o-sha1),
+ name_nons);
}
return 0;
}
@@ -402,7 +404,7 @@ static void get_info_refs(char *arg)
} else {
select_getanyfile();
- for_each_ref(show_text_ref, buf);
+ for_each_namespaced_ref(show_text_ref, buf);
send_strbuf(text/plain, buf);
}
strbuf_release(buf);
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 938b4cf..ad85537 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -61,6 +61,11 @@ Alias /auth/dumb/ www/auth/dumb/
SetEnv GIT_COMMITTER_NAME Custom User
SetEnv GIT_COMMITTER_EMAIL cus...@example.com
/LocationMatch
+LocationMatch /smart_namespace/
+ SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
+ SetEnv GIT_HTTP_EXPORT_ALL
+ SetEnv GIT_NAMESPACE ns
+/LocationMatch
ScriptAliasMatch /smart_*[^/]*/(.*) ${GIT_EXEC_PATH}/git-http-backend/$1
ScriptAlias /broken_smart/ broken-smart-http.sh/
Directory ${GIT_EXEC_PATH}
diff --git a/t/t5561-http-backend.sh b/t/t5561-http-backend.sh
index b5d7fbc..5a19d61 100755
--- a/t/t5561-http-backend.sh
+++ b/t/t5561-http-backend.sh
@@ -134,6 +134,10 @@ POST /smart/repo.git/git-receive-pack HTTP/1.1 200 -
###
GET /smart/repo.git/info/refs?service=git-receive-pack HTTP/1.1 403 -
POST /smart/repo.git/git-receive-pack HTTP/1.1 403 -
+
+### namespace test
+###
+GET /smart_namespace/repo.git/info/refs HTTP/1.1 200
EOF
test_expect_success 'server request log matches test results' '
sed -e
diff --git a/t/t556x_common b/t/t556x_common
index 82926cf..cb9eb9d 100755
--- a/t/t556x_common
+++ b/t/t556x_common
@@ -120,3 +120,19 @@ test_expect_success 'http.receivepack false' '
GET info/refs?service=git-receive-pack 403 Forbidden
POST git-receive-pack 403 Forbidden
'
+test_expect_success 'backend respects namespaces' '
+ log_div namespace test
+ config http.uploadpack true
+ config http.getanyfile true
+
+ GIT_NAMESPACE=ns export GIT_NAMESPACE
+ git push public master:master
+ (cd $HTTPD_DOCUMENT_ROOT_PATH/repo.git
+ git for-each-ref | grep /$GIT_NAMESPACE/ /dev/null
+ )
+
+ git ls-remote public exp
+ curl $HTTPD_URL/smart_namespace/repo.git/info/refs act
+ test_cmp exp act
+ (grep /ns/ exp false || true)
+'
--
1.8.1.3
--
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 help config: s/insn/instruction/
Matthias Krüger matthias.krue...@famsik.de writes: insn appears to be an in-code abbreviation and should not appear in manual/help pages. --- Thanks; sign-off? -- 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
