[PATCH v2 2/4] employ new explicit exists in index? API

2013-09-17 Thread Eric Sunshine
Each caller of index_name_exists() knows whether it is looking for a directory or a file, and can avoid the unnecessary indirection of index_name_exists() by instead calling index_dir_exists() or index_file_exists() directly. Invoking the appropriate search function explicitly will allow a

[PATCH v2 1/4] name-hash: refactor polymorphic index_name_exists()

2013-09-17 Thread Eric Sunshine
Depending upon the absence or presence of a trailing '/' on the incoming pathname, index_name_exists() checks either if a file is present in the index or if a directory is represented within the index. Each caller explicitly chooses the mode of operation by adding or removing a trailing '/' before

[PATCH v2 0/4] stop storing trailing slash in dir-hash

2013-09-17 Thread Eric Sunshine
This series changes name-hash to stop storing the (redundant) trailing slash with index_state.dir_hash entries. As an intentional side-effect, the series fixes [1] in a cleaner way (suggested by Junio [2]) than either [3] (680be044 in master) or [4]. Changes since v1 [5]: * Add

[PATCH v2 4/4] dir: revert work-around for retired dangerous behavior

2013-09-17 Thread Eric Sunshine
directory_exists_in_index_icase() dangerously assumed that it could access one character beyond the end of its directory argument, and that that character would unconditionally be '/'. 2eac2a4c (ls-files -k: a directory only can be killed if the index has a non-directory, 2013-08-15) added a

Re: 1.8.4 rebase regression?

2013-09-17 Thread Matthieu Moy
Matthieu Moy matthieu@grenoble-inp.fr writes: Patrick Welche pr...@cam.ac.uk writes: $ git diff ESC[1mdiff --cc glib/gmain.cESC[m ESC[1mindex 738e69c,5aaebd0..000ESC[m ESC[1m--- a/glib/gmain.cESC[m ESC[1m+++ b/glib/gmain.cESC[m ESC[36m@@@ -4953,32 -4921,32 +4953,48 @@@ESC[m

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Christian Couder
Hi, On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster toralf.foers...@gmx.de wrote: I'm bisecting a linux kernel issue and want to ignore all commits just touching something in ./drives/staging. Currently the only way would be to specify all dir/subdir combination under ./linux except that

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Matthieu Moy
Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one more bisection step if you don't exclude it. Actually, I think the same remark would

Re: [PATCH 1/2] relative_path should honor dos_drive_prefix

2013-09-17 Thread Jiang Xin
2013/9/13 Junio C Hamano gits...@pobox.com: Jiang Xin worldhello@gmail.com writes: 2013/9/13 Junio C Hamano gits...@pobox.com: For systems that need POSIX escape hatch for Apollo Domain ;-), we would need a bit more work. When both path1 and path2 begin with a double-dash, we would

[PATCH v3 2/3] relative_path should honor DOS and UNC paths

2013-09-17 Thread Jiang Xin
Tvangeste found that the relative_path function could not work properly on Windows if in and prefix have DOS driver prefix (such as C:/windows). And the relative_path function won't work properly if either in or prefix is a UNC path (like //host/share). ($gmane/234434) E.g., When execute:

[PATCH v3 1/3] test: use unambigous leading path (/foo) for mingw

2013-09-17 Thread Jiang Xin
In test cases for relative_path, path with one leading character (such as /a, /x) may be recogonized as a:/ or x:/ if there is such DOS drive on MINGW platform. Use an umambigous leading path /foo instead. Also change two leading slashes (//) to three leading slashes (///), otherwize it will be

[PATCH v3 3/3] Use simpler relative_path when set_git_dir

2013-09-17 Thread Jiang Xin
Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc. It will make git_dir shorter only if git_dir is inside work_tree, and this will increase performance. But my last refactor effort on relative_path function (commit v1.8.3-rc2-12-ge02ca72) changed that. Always use relative_path as

little suggestion for revert/checkout

2013-09-17 Thread Michele Paoli
hi I like your crash curse http://git.or.cz/course/svn.html (sorry for my bad English) a little suggestion for revert/checkout svn revert -R .--- git checkout id '*' best regards Michele Paoli -- --- Dott. Michele Paoli Innsbruck Medical

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Christian Couder
On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you want to exclude is exclusively touched by half the commits, it will only add one

Re: 1.8.4 rebase regression?

2013-09-17 Thread Patrick Welche
On Mon, Sep 16, 2013 at 01:18:48PM +0200, Matthieu Moy wrote: Patrick Welche pr...@cam.ac.uk writes: $ git diff ESC[1mdiff --cc glib/gmain.cESC[m ESC[1mindex 738e69c,5aaebd0..000ESC[m ESC[1m--- a/glib/gmain.cESC[m ESC[1m+++ b/glib/gmain.cESC[m ESC[36m@@@ -4953,32 -4921,32

Re: 1.8.4 rebase regression?

2013-09-17 Thread Patrick Welche
On Tue, Sep 17, 2013 at 09:15:43AM +0200, Matthieu Moy wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Patrick Welche pr...@cam.ac.uk writes: $ git diff ESC[1mdiff --cc glib/gmain.cESC[m ESC[1mindex 738e69c,5aaebd0..000ESC[m ESC[1m--- a/glib/gmain.cESC[m ESC[1m+++

Re: 1.8.4 rebase regression?

2013-09-17 Thread Matthieu Moy
Patrick Welche pr...@cam.ac.uk writes: Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by default. If I take 1.8.3.4 and git -c color.ui=always log, I see the same ESC codes = not a regression! I'll just have to sort my box out if I want colour. (The only oddity is that git

Re: 1.8.4 rebase regression?

2013-09-17 Thread Patrick Welche
On Tue, Sep 17, 2013 at 11:23:51AM +0200, Matthieu Moy wrote: Patrick Welche pr...@cam.ac.uk writes: Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by default. If I take 1.8.3.4 and git -c color.ui=always log, I see the same ESC codes = not a regression! I'll just have

Re: 1.8.4 rebase regression?

2013-09-17 Thread Matthieu Moy
Patrick Welche pr...@cam.ac.uk writes: On Tue, Sep 17, 2013 at 11:23:51AM +0200, Matthieu Moy wrote: Patrick Welche pr...@cam.ac.uk writes: Got it: the change between 1.8.3.4 and 1.8.4 is that colour is on by default. If I take 1.8.3.4 and git -c color.ui=always log, I see the same ESC

Re: Issue with sparse checkout

2013-09-17 Thread Duy Nguyen
On Tue, Sep 17, 2013 at 5:46 AM, Martin Gregory martin.greg...@adelaideinterim.com.au wrote: An additional note. I did git ls-files -v | grep ^S and I can see that the files that remain in the working version have the ^S bit set. So it does feel like a bug to me: why are files with ^S set

Re: sparse checkout file with windows line endings doesn't work

2013-09-17 Thread Duy Nguyen
On Mon, Sep 16, 2013 at 8:20 PM, Martin Gregory mart...@adelaideinterim.com.au wrote: Hi, Please see http://pastebin.com/zMXvvXuy It shows that if the .git/info/sparsecheckout file is in windows format (windows line ending) then it doesn't work. And it does work for me with CRLF endings

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Duy Nguyen
On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder christian.cou...@gmail.com wrote: On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect is a kind of binary search, if what you

[PATCH 1/2] perf-lib: split starting the test from the execution

2013-09-17 Thread Thomas Gummerer
Separate the execution part to make future changes to the tests simpler. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- t/perf/perf-lib.sh | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/t/perf/perf-lib.sh b/t/perf/perf-lib.sh index c61d535..95e483c

[PATCH 2/2] perf-lib: add test_perf_cleanup target

2013-09-17 Thread Thomas Gummerer
Currently there is no way to clean up the changes that have been made with test_perf for the next run. Add a way to reset the repository to the state before the test for testing commands that modify the git repository, e.g. for perf testing git add. Signed-off-by: Thomas Gummerer

Mail Back iF You Are Interested!

2013-09-17 Thread G.DANIELS
It is Private I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other

[PATCH] contacts: allow execution from other directories

2013-09-17 Thread Thomas Gummerer
Currently git-contacts only works if it is executed from the top level of the git repository. Enable the execution in sub directories of that repository. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com --- I have no experience in perl, so there may be nicer implementations. It works when

[PATCH] build: add default configuration

2013-09-17 Thread Felipe Contreras
For now simply add a few common aliases. co = checkout ci = commit rb = rebase st = status Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Makefile | 5 - gitconfig | 5 + 2 files changed, 9 insertions(+), 1 deletion(-) create mode 100644 gitconfig diff --git

[PATCH] Add core.mode configuration

2013-09-17 Thread Felipe Contreras
So that we can specify general modes of operation, specifically, add the 'next' mode, which makes Git pre v2.0 behave as Git v2.0. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- builtin/add.c | 3 +++ cache.h | 6 ++ config.c | 13 + environment.c |

Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

2013-09-17 Thread Junio C Hamano
Sebastian Schuberth sschube...@gmail.com writes: I think this is less favorable compared to my last proposed solution. That is only needed if you insist to use C preprocessor that does not understand include_next. That choice is a platform specific decision (even if you want to use such a

Re: [PATCH v2 1/3] test: use unambigous leading path (/foo) for mingw

2013-09-17 Thread Junio C Hamano
Torsten Bögershausen tbo...@web.de writes: Yes, there is a directoctory structure in / like this: /usr /bin /lib Then we have the drive letters mapped to single letters: /c/Documents and Settings /c/temp Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body

Re: [PATCH v3 2/3] relative_path should honor DOS and UNC paths

2013-09-17 Thread Junio C Hamano
Jiang Xin worldhello@gmail.com writes: diff --git a/compat/mingw.h b/compat/mingw.h index bd0a88b..06e9f49 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -311,6 +311,15 @@ int winansi_fprintf(FILE *stream, const char *format, ...) __attribute__((format #define

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Junio C Hamano
Michael S. Tsirkin m...@redhat.com writes: Actually, after I've looked at the code, diffcore_order is already already called for patch-id. That was a band-aid for an ill-thought-out orderfile misfeature to hide the breakage. You somehow make sure that you pass the same orderfile to diff

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Toralf Förster
On 09/17/2013 09:26 AM, Christian Couder wrote: Hi, On Mon, Sep 16, 2013 at 2:39 PM, Toralf Förster toralf.foers...@gmx.de wrote: I'm bisecting a linux kernel issue and want to ignore all commits just touching something in ./drives/staging. Currently the only way would be to specify all

Re: [PATCH 1/3] repack: rewrite the shell script in C

2013-09-17 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Is $GIT_OBJECT_DIRECTORY a standard variable, or should it be $GIT_DIR/objects? man git ;-) It has been there since early May 2005 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: [PATCH v2 0/4] stop storing trailing slash in dir-hash

2013-09-17 Thread Junio C Hamano
Eric Sunshine sunsh...@sunshineco.com writes: * Split v1 patch 1 into v2 patches 1 2 to ease review. (This is possible now that index_name_exists() retains its original behavior.) It really shows in [PATCH 2/4] that illustrates which callers were depending on the old calling convention; I

Re: [PATCH] contacts: allow execution from other directories

2013-09-17 Thread Eric Sunshine
On Tue, Sep 17, 2013 at 8:50 AM, Thomas Gummerer t.gumme...@gmail.com wrote: Currently git-contacts only works if it is executed from the top level of the git repository. Enable the execution in sub directories of that repository. Thanks. This was on my to-do list but fell off my radar when I

Bisect needing to be at repo top-level?

2013-09-17 Thread Burton, Ross
Hi, Why does git-bisect need to be ran from the top level of the working tree? It sources git-sh-setup.sh which sets GIT_DIR, which git-bisect.sh then appears to consistently use. Is there a reason for needing to be at the top-level, or is this an old and redundant message? Cheers, Ross -- To

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Junio C Hamano
Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I think. But it would be unfortunate if we have to do that unconditionally, though, as we may be buffering many

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 09:26:13AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: Actually, after I've looked at the code, diffcore_order is already already called for patch-id. That was a band-aid for an ill-thought-out orderfile misfeature to hide the

YOUR WIN INFORMATION

2013-09-17 Thread BBC
Your e-mail has won you £1,000,000.00 from BBC XMAS PROMO 1, Name 2, Country 3, Mobile No 4, Occupation Send Response to ( eruraf...@56788.com ) Prof. Peter --==Mailed via NDMCTSGH Webmail==-- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes: On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder christian.cou...@gmail.com wrote: On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Christian Couder christian.cou...@gmail.com writes: In practice though, as git bisect

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I think. But it would be unfortunate if we have

Re: Bisect needing to be at repo top-level?

2013-09-17 Thread Junio C Hamano
Burton, Ross ross.bur...@intel.com writes: Why does git-bisect need to be ran from the top level of the working tree? It sources git-sh-setup.sh which sets GIT_DIR, which git-bisect.sh then appears to consistently use. Is there a reason for needing to be at the top-level, or is this an old

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Piotr Krukowiecki
Junio C Hamano gits...@pobox.com napisał: Yeah, it is easy to say that git log -- A ':(exclude)A/B' A/B/C has two positive (A, A/B/C) and one negative (A/B), and then the most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is included. But to actually _design_ it, there are

Re: [PATCH 2/2] perf-lib: add test_perf_cleanup target

2013-09-17 Thread Junio C Hamano
Thomas Gummerer t.gumme...@gmail.com writes: +For performance tests that need cleaning up after them that should not +be timed, use + + test_perf_cleanup 'descriptive string' ' + command1 + command2 + ' ' + cleanupcommand1 +

Delete branch during fast-import

2013-09-17 Thread Jason Miller
I'm trying out a rather large subversion import, and am trying to figure out if there is a way to delete branches during a fast-import. Right now I can think of only 2 ways to handle this: 1) End the import, do a git branch -D and then resume the import. 2) Scan the entire repository history,

Re: Bisect needing to be at repo top-level?

2013-09-17 Thread Lukas Fleischer
On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote: Burton, Ross ross.bur...@intel.com writes: Why does git-bisect need to be ran from the top level of the working tree? It sources git-sh-setup.sh which sets GIT_DIR, which git-bisect.sh then appears to consistently use. Is

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Junio C Hamano
Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making it a bit more stable? That is one thing that needs to be done, I

Re: [PATCH 1/3] repack: rewrite the shell script in C

2013-09-17 Thread Junio C Hamano
Stefan Beller stefanbel...@googlemail.com writes: + struct option builtin_repack_options[] = { + OPT_BIT('a', NULL, pack_everything, + N_(pack everything in a single pack), ALL_INTO_ONE), + OPT_BIT('A', NULL, pack_everything, +

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Junio C Hamano
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: What about simply iterating over options in order in which they are specified and the last option that matches specifies the result? But isn't it very inconsistent from the way normal pathspec works? git log -- A B and git log -- B A

[BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Uwe Kleine-König
Hello, after these commands: $ git init $ mkdir subdir $ echo a subdir/a $ git add subdir/a $ git commit -m a $ echo more a subdir/a $ echo b subdir/b $ git add subdir/* $ git commit -m b $ git checkout HEAD^ --

Re: Bisect needing to be at repo top-level?

2013-09-17 Thread Burton, Ross
On 17 September 2013 18:27, Junio C Hamano gits...@pobox.com wrote: Burton, Ross ross.bur...@intel.com writes: Why does git-bisect need to be ran from the top level of the working tree? It sources git-sh-setup.sh which sets GIT_DIR, which git-bisect.sh then appears to consistently use. Is

Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

2013-09-17 Thread Sebastian Schuberth
On Tue, Sep 17, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote: Keeping the ugliness to deal with the platform issue (i.e. broken string.h) in one place (e.g. compat/mingw) is far more preferrable than having a similar ugliness in git-compat-util.h for people on all other platforms

Re: Bisect needing to be at repo top-level?

2013-09-17 Thread Junio C Hamano
Lukas Fleischer g...@cryptocrack.de writes: Imagine if you start from a subdirectory foo/ but the directory did not exist in the older part of the history of the project. When bisect needs to check out a revision that was older than the first revision that introduced that subdirectory, what

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Piotr Krukowiecki
On Tue, Sep 17, 2013 at 9:04 PM, Junio C Hamano gits...@pobox.com wrote: Piotr Krukowiecki piotr.krukowie...@gmail.com writes: What about simply iterating over options in order in which they are specified and the last option that matches specifies the result? But isn't it very

Locking files / git

2013-09-17 Thread Nicolas Adenis-Lamarre
Ooops. It seems that each time somebody says these two words together, people hate him, and he is scorned by friends and family. However, - gitolite implement it (but gitolite is not git). - In the documentation, each time the need is evocated, it is replace by do communication, don't use git for

Re: [PATCH 1/2] relative_path should honor dos_drive_prefix

2013-09-17 Thread Johannes Sixt
Am 17.09.2013 10:24, schrieb Jiang Xin: I have checked the behavior of UNC path on Windows (msysGit): * I can cd to a UNC path: cd //server1/share1/path * can cd to other share: cd ../../share2/path * and can cd to other server's share: cd ../../../server2/share/path

RE: Delete branch during fast-import

2013-09-17 Thread Felipe Contreras
Jason Miller wrote: I'm trying out a rather large subversion import, and am trying to figure out if there is a way to delete branches during a fast-import. Right now I can think of only 2 ways to handle this: 1) End the import, do a git branch -D and then resume the import. 2) Scan the

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Junio C Hamano
Uwe Kleine-König u.kleine-koe...@pengutronix.de writes: after these commands: $ git init $ mkdir subdir $ echo a subdir/a $ git add subdir/a $ git commit -m a $ echo more a subdir/a $ echo b subdir/b $ git add subdir/* $ git

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Jeff King
On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote: I could argue that the above intended behaviour is suboptimal and it should have been the resulting paths in the index and the work tree that match the given pathspec must be identical to that of the tree-ish. In the resulting

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Jeff King
On Tue, Sep 17, 2013 at 09:06:59PM +0200, Uwe Kleine-König wrote: $ git checkout HEAD^ -- subdir I'd expect that subdir/b is removed from the index as this file didn't exist in HEAD^ but git-status only reports: I'm not sure if this is intentional or not. The definition of git

Re: [PATCH 1/2] repack: rewrite the shell script in C

2013-09-17 Thread Stefan Beller
On 09/15/2013 05:31 PM, Stefan Beller wrote: Rene, thank you very much for the review! the parameter hex contains the pack- already. The remove_redundant_pack function is called in a loop iterating over elements of existing_packs, which is filled in get_non_kept_pack_filenames, which

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Jeff King
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote: Thinking about it some more, it's a best effort thing anyway, correct? So how about, instead of doing a hash over the whole input, we hash each chunk and XOR them together? This way it will be stable against chunk

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: So might it not be useful to tweak patch id to sort the diff, making

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote: I could argue that the above intended behaviour is suboptimal and it should have been the resulting paths in the index and the work tree that match the given pathspec must be identical to that of

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote: On Tue, Sep 17, 2013 at 11:14:01PM +0300, Michael S. Tsirkin wrote: On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700,

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Jeff King
On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote: I could argue that the above intended behaviour is suboptimal and it should have been the resulting paths in the index and the

Re: [PATCH 1/3] repack: rewrite the shell script in C

2013-09-17 Thread Junio C Hamano
Stefan Beller stefanbel...@googlemail.com writes: On 09/17/2013 08:17 PM, Junio C Hamano wrote: Stefan Beller stefanbel...@googlemail.com writes: + struct option builtin_repack_options[] = { + OPT_BIT('a', NULL, pack_everything, + N_(pack everything in

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 11:14:01PM +0300, Michael S. Tsirkin wrote: On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes:

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote: On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote: Thinking about it some more, it's a best effort thing anyway, correct? So how about, instead of doing a hash over the whole input, we hash each chunk

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Jeff King
On Wed, Sep 18, 2013 at 12:03:25AM +0300, Michael S. Tsirkin wrote: It may be esoteric enough not to worry about, though. By far the most common use of patch-ids is going to be in a single rev-list --cherry-pick situation where you are trying to omit commits during a rebase. I am

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Jeff King
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote: A problem with both schemes, though, is that they are not backwards-compatible with existing git-patch-id implementations. Could you clarify? We never send patch IDs on the wire - how isn't this compatible? I meant that

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote: I could argue that the above intended behaviour is suboptimal and it should have been the

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote: On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote: On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote: Thinking about it some more, it's a best effort thing anyway, correct? So how

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Junio C Hamano
Piotr Krukowiecki piotr.krukowie...@gmail.com writes: Ignoring (possible) inconsistency thing, I think they are easy to understand and use. Probably you are right (in the sense that I do not offhand think of a confusing and ambiguous set of positive and negative pathspecs; others may find

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Michael S. Tsirkin
On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote: On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote: A problem with both schemes, though, is that they are not backwards-compatible with existing git-patch-id implementations. Could you clarify? We never send

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Jeff King
On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote: Hrm. Probably not. It is almost a one-way merge going to the named tree (but limited by the pathspec), except that I think the current git-checkout code may provide some safety checks related to where we are coming from

Re: Locking files / git

2013-09-17 Thread Jeff King
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote: Ooops. It seems that each time somebody says these two words together, people hate him, and he is scorned by friends and family. And strangers on mailing lists. :) However, - gitolite implement it (but gitolite is not

Re: Locking files / git

2013-09-17 Thread Fredrik Gustafsson
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote: Ooops. It seems that each time somebody says these two words together, people hate him, and he is scorned by friends and family. For the moment, i want a first feedback, an intermediate between locking is bad and ok, but

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 01:40:17PM -0700, Junio C Hamano wrote: Taking the state of a subdirectory as a whole as content, the change we are discussing will make it more like rm -fr dir tar xf some-content dir to replace the directory wholesale, which I

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Jeff King
On Tue, Sep 17, 2013 at 03:00:41PM -0700, Junio C Hamano wrote: So given that, is it fair to say that a one-way go here merge, limited by pathspec, is the closest equivalent? Sorry, but it is unclear to me what you mean by one-way go here merge. Do you mean oneway_merge() in

Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

2013-09-17 Thread Junio C Hamano
Sebastian Schuberth sschube...@gmail.com writes: On Tue, Sep 17, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote: Keeping the ugliness to deal with the platform issue (i.e. broken string.h) in one place (e.g. compat/mingw) is far more preferrable than having a similar ugliness in

Re: [BUG?] git checkout $commit -- somedir doesn't drop files

2013-09-17 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Tue, Sep 17, 2013 at 03:00:41PM -0700, Junio C Hamano wrote: So given that, is it fair to say that a one-way go here merge, limited by pathspec, is the closest equivalent? Sorry, but it is unclear to me what you mean by one-way go here merge. Do you

re[2]: Issue with sparse checkout

2013-09-17 Thread Martin Gregory
Hi Duy, Thanks for taking a look. So it does feel like a bug to me: why are files with ^S set remaining in the working version after git read-tree -mu HEAD ? I don't know. Maybe the bits are set, but then the remove operation fails (silently). I tried to reproduce on

Re: [PATCH] diff: add a config option to control orderfile

2013-09-17 Thread Junio C Hamano
Jeff King p...@peff.net writes: I am mostly thinking of the problems we had with the kup tool, which expected stability across diffs that would be signed by both kernel.org. But as far as I know, they do not use patch-id. More details in case you are curious (including me arguing that we

re[2]: sparse checkout file with windows line endings doesn't work

2013-09-17 Thread Martin Gregory
Hi Duy, Thanks again for taking a look at these two reports. And it does work for me with CRLF endings (again tested on Linux). Yes, will do. I will try, myself, on Linux, as well. It seems quite conceivable its the sort of thing that only happens under Windows. Regards, Martin -- To

Re: RFC: git bisect should accept paths-to-be-excluded

2013-09-17 Thread Duy Nguyen
On Wed, Sep 18, 2013 at 12:02 AM, Junio C Hamano gits...@pobox.com wrote: Interaction with git grep --depth I am not sure how that affects anything. Conceptually, isn't --depth an independent axis to filter out paths that have too many components after given positive pathspec elements? E.g.

[PATCH v2 6/6] clone: test the new HEAD detection logic

2013-09-17 Thread Junio C Hamano
Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t5601-clone.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh index 0629149..ccda6df 100755 --- a/t/t5601-clone.sh +++ b/t/t5601-clone.sh @@ -285,4 +285,15 @@ test_expect_success

[PATCH v2 5/6] connect: annotate refs with their symref information in get_remote_head()

2013-09-17 Thread Junio C Hamano
Signed-off-by: Junio C Hamano gits...@pobox.com --- connect.c | 60 1 file changed, 60 insertions(+) diff --git a/connect.c b/connect.c index e4c7ae6..a53ef6d 100644 --- a/connect.c +++ b/connect.c @@ -6,6 +6,7 @@ #include

[PATCH v2 0/6] Removing the guesswork of HEAD in clone

2013-09-17 Thread Junio C Hamano
This reworks the old idea from 2008 ($gmane/102039) to teach upload-pack to say where symbolic refs are pointing at in the initial ref advertisement as a new capability sym, and allow git clone to take advantage of that knowledge when deciding what branch to point at with the HEAD of the newly

[PATCH v2 2/6] upload-pack: send symbolic ref information as capability

2013-09-17 Thread Junio C Hamano
One long-standing flaw in the pack transfer protocol was that there was no way to tell the other end which branch HEAD points at. With a new sym capability (e.g. sym=HEAD:refs/heads/master; can be repeated more than once to represent symbolic refs other than HEAD, such as

[PATCH v2 3/6] upload-pack: send non-HEAD symbolic refs

2013-09-17 Thread Junio C Hamano
With the same mechanism as used to tell where HEAD points at to the other end, we can tell the target of other symbolic refs as well. Signed-off-by: Junio C Hamano gits...@pobox.com --- upload-pack.c | 1 + 1 file changed, 1 insertion(+) diff --git a/upload-pack.c b/upload-pack.c index

[PATCH v2 1/6] upload-pack.c: do not pass confusing cb_data to mark_our_ref()

2013-09-17 Thread Junio C Hamano
The callee does not use cb_data, and the caller is an intermediate function in a callchain that later wants to use the cb_data for its own use. Clarify the code by breaking the dataflow explicitly by not passing cb_data down to mark_our_ref(). Signed-off-by: Junio C Hamano gits...@pobox.com ---

[PATCH v2 4/6] connect.c: make parse_feature_value() static

2013-09-17 Thread Junio C Hamano
Signed-off-by: Junio C Hamano gits...@pobox.com --- cache.h | 1 - connect.c | 3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cache.h b/cache.h index 85b544f..2c853ba 100644 --- a/cache.h +++ b/cache.h @@ -1098,7 +1098,6 @@ extern struct ref **get_remote_heads(int in,

[PATCH] contacts: fix to work in subdirectories

2013-09-17 Thread Eric Sunshine
Unlike other git commands which work correctly at the top-level or in a subdirectory, git-contacts fails when invoked in a subdirectory. This is because it invokes git-blame with pathnames relative to the top-level, but git-blame interprets the pathnames as relative to the current directory. Fix

Re: [PATCH v2 2/6] upload-pack: send symbolic ref information as capability

2013-09-17 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: static void upload_pack(void) { + struct string_list symref = STRING_LIST_INIT_DUP; + + head_ref_namespaced(find_symref, symref); + if (advertise_refs || !stateless_rpc) { reset_timeout(); -

[PATCH v3 4/7] upload-pack: send non-HEAD symbolic refs

2013-09-17 Thread Junio C Hamano
With the same mechanism as used to tell where HEAD points at to the other end, we can tell the target of other symbolic refs as well. Signed-off-by: Junio C Hamano gits...@pobox.com --- upload-pack.c | 1 + 1 file changed, 1 insertion(+) diff --git a/upload-pack.c b/upload-pack.c index

[PATCH v3 7/7] clone: test the new HEAD detection logic

2013-09-17 Thread Junio C Hamano
Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t5601-clone.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh index 0629149..ccda6df 100755 --- a/t/t5601-clone.sh +++ b/t/t5601-clone.sh @@ -285,4 +285,15 @@ test_expect_success

[PATCH v3 0/7] Removing the guesswork of HEAD in clone

2013-09-17 Thread Junio C Hamano
This reworks the old idea from 2008 ($gmane/102039) to teach upload-pack to say where symbolic refs are pointing at in the initial ref advertisement as a new capability symref, and allows git clone to take advantage of that knowledge when deciding what branch to point at with the HEAD of the newly

[PATCH v3 6/7] connect: annotate refs with their symref information in get_remote_head()

2013-09-17 Thread Junio C Hamano
By doing this, clients of upload-pack can now reliably tell what ref a symbolic ref points at; the updated test in t5505 used to expect failure due to the ambiguity and made sure we give diagnostics, but we no longer need to be so pessimistic. Make sure we correctly learn which branch HEAD points

  1   2   >