Re: [PATCH jk/checkout-attribute-lookup] t2003: work around path mangling issue on Windows

Am 3/20/2013 18:10, schrieb Junio C Hamano: > Johannes Sixt writes: > >> From: Johannes Sixt >> >> MSYS bash considers the part "/g" in the sed expression "s/./=/g" as an >> absolute path after an assignment, and mangles it to a C:/something >> string. Do not attract bash's attention by avoiding

Re: gitk says "file name too long"

Use LongPathTool. If u had problem with files i suggest this software. http://LongPathTool.com -- View this message in context: http://git.661346.n2.nabble.com/gitk-says-file-name-too-long-tp4632510p7580237.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this

Re: [PATCH] do not use GIT_TRACE_PACKET=3 in tests

Am 3/20/2013 18:43, schrieb Jeff King: > Now that we are using the GIT_TRACE mechanism, we can > improve both scripts by asking git to write directly to a > file rather than a descriptor. That fixes the hang in t5700, > and should allow t5503 to successfully run on Windows. Well spotted, and, righ

Re: [PATCH v2 00/45] parse_pathspec and :(glob) magic

On Thu, Mar 21, 2013 at 12:33:26PM +0700, Duy Nguyen wrote: > > I am still getting this out of 7300, though. > > I still can't reproduce it. But I think I found a bug that > miscalculates prefix length from absolute paths. Does this "fix" your > test? > > -- 8< -- > diff --git a/setup.c b/setup.c

Nike Schuhe bestellen

Wenn Nike Schuhe kaufen eine Person allerlei will vor kurzem dachten zuvor, auch an die Zukunft denken! Beziehung ist nicht sehr gut, immer im Kampf, manchmal denke ich, ist nicht die Zeit, um Abschied zu nehmen, lachte Freunden und sagte, ich glaube, aber wirk

Re: [PATCH v2 00/45] parse_pathspec and :(glob) magic

On Wed, Mar 20, 2013 at 11:02:50AM -0700, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > > > Junio please pull the series from github [1] > > [1] https://github.com/pclouds/git/commits/parse-pathspec > > Please write it like this: > > https://github.com/pclouds/git parse-pathsp

Re: [PATCH] git-am: fix "Applying" message when applypatch-hook was run

applypatch-hook can modify the commit message. Display the updated commit message instead of the original one. Signed-off-by: Simon Ruderich --- On Thu, Mar 21, 2013 at 12:36:00AM +0100, Matthieu Moy wrote: > Please, read SubmittingPatches in the Documentation directory of Git's > source tree. Y

Mulberry Taschen Outlet

Die Luxus Taschen Deutschland Wärme der Sonne ausgestreckt den Schlamm Grün auf der Straße in jeder Straße, die Menschen alle zu Fuß gemütlichen Straße, Körperhaltung Zhongxiang. Nach 09.00 Uhr und fiel mit dem sanften Satz Feld. Hier werden die wichtigsten

Thomas Sabo Charms Sale

Eine Thomas Sabo Charms 2013 der Qing Ning Nachmittag neblig, ätherischen Zen tone "lotus Sprache Flüstern" zusammen mit einer Tasse grünem Tee Duft verströmt verfolgen mich um eine lange Zeit, und dass fast, aber nicht Aerosol, aber ich Augen allmählich zu verdün

Re: [PATCH] git-am: fix "Applying" message when applypatch-hook was run

Matthieu Moy writes: > Please, read SubmittingPatches in the Documentation directory of Git's > source tree. Your text above should be a commit message (hence, no > hello), and should not be below the --- line. > > Also, read about signed-off-by in the same document. > ... > This copy/paste a pie

Re: [PATCH] git-am: fix "Applying" message when applypatch-hook was run

Simon Ruderich writes: > --- > Hello, > > This patch fixes a minor issue with git-am. When the > applypatch-hook modifies the commit message, git-am displays the > original message. This patch updates the message to use the > modified version. Please, read SubmittingPatches in the Documentation

[PATCH] git-am: fix "Applying" message when applypatch-hook was run

--- Hello, This patch fixes a minor issue with git-am. When the applypatch-hook modifies the commit message, git-am displays the original message. This patch updates the message to use the modified version. Regards Simon git-am.sh | 8 1 file changed, 8 insertions(+) diff --git a/git-

Re: [PATCH v2 0/6] Support triangular workflows

From: "Ramkumar Ramachandra" Sent: Wednesday, March 20, 2013 12:44 PM This follows-up [1], with three important differences: 1. pushremote_get() and remote_get() share code better. Thanks Jeff. 2. All spelling mistakes have been corrected. Thanks Eric. 3. One new test for each of the new co

Re: [PATCH v3 3/4] t7800: modernize tests

On Wed, Mar 20, 2013 at 2:48 AM, Johannes Sixt wrote: > Am 2/21/2013 5:03, schrieb David Aguilar: >> test_expect_success PERL 'difftool -d' ' >> - diff=$(git difftool -d --extcmd ls branch) && >> - echo "$diff" | stdin_contains sub && >> - echo "$diff" | stdin_contains file >> + g

Re: FW: Windows. Git, and Dedupe

Am 20.03.2013 21:43, schrieb Josh Rowe: If you have Win8 or HyperV 2012, I can ship you a small NTFS .vhd with some deduped files. I'm not sure if that will be readable, but I would hazard a guess that it would be. It definitely will not be readable on Win7. It would be nice if you could uplo

Re: [PATCH] t3200 (branch): modernize style

Junio C Hamano writes: > Ramkumar Ramachandra writes: > >> Another random patch. Found it while grep'ping around. I thought I >> could automate my work, which would have been the case if it was >> consistently inconsistent. Unfortunately, it wasn't, and I ended up >> doing a lot of manual

Re: [PATCH] do not use GIT_TRACE_PACKET=3 in tests

On Wed, Mar 20, 2013 at 04:29:40PM -0400, Eric Sunshine wrote: > On Wed, Mar 20, 2013 at 1:43 PM, Jeff King wrote: > > Some test scripts use the GIT_TRACE mechanism to dump > > debugging information to descriptor 3 (and point it to a > > file using the shell). On Windows, however, bash is unable

Re: Which file is older in history?

Ramkumar Ramachandra writes: > I want to compare two files in a git repository and tell which one was > introduced into the repository earlier, assuming that they're in the > same history line (by ancestry, not timestamp). The naive way to do > this is to find the individual commits that introdu

Re: [BUG?] rebase -i: edit versus unmerged changes

Ramkumar Ramachandra writes: > Andrew Wong wrote: >> On 3/19/13, Ramkumar Ramachandra wrote: >>> I know that this is expected behavior, but is there an easy way to get >>> rid of this inconsistency? >> >> You can actually rely on "rebase" to run the appropriate command. > > Didn't Junio explicit

RE: FW: Windows. Git, and Dedupe

If you have Win8 or HyperV 2012, I can ship you a small NTFS .vhd with some deduped files. I'm not sure if that will be readable, but I would hazard a guess that it would be. It definitely will not be readable on Win7. I'm using: PS C:\> git version git version 1.8.0.msysgit.0 I don't see

Re: [PATCH] t3200 (branch): modernize style

Ramkumar Ramachandra writes: > Another random patch. Found it while grep'ping around. I thought I > could automate my work, which would have been the case if it was > consistently inconsistent. Unfortunately, it wasn't, and I ended up > doing a lot of manual janitorial work :| Thanks. It

Re: [BUG?] rebase -i: edit versus unmerged changes

Ramkumar Ramachandra wrote: > Andrew Wong wrote: >> You can actually rely on "rebase" to run the appropriate command. > > Didn't Junio explicitly mention that this is undesirable earlier (from > the point of view of `rebase -i` design)? I missed the earlier discussion. Does the documentation (e.

Re: [PATCH] do not use GIT_TRACE_PACKET=3 in tests

On Wed, Mar 20, 2013 at 1:43 PM, Jeff King wrote: > Some test scripts use the GIT_TRACE mechanism to dump > debugging information to descriptor 3 (and point it to a > file using the shell). On Windows, however, bash is unable > to set up descriptor 3. We do not write our trace to the > file, and w

Re: [BUG?] rebase -i: edit versus unmerged changes

Andrew Wong wrote: > On 3/19/13, Ramkumar Ramachandra wrote: >> I know that this is expected behavior, but is there an easy way to get >> rid of this inconsistency? > > You can actually rely on "rebase" to run the appropriate command. Didn't Junio explicitly mention that this is undesirable earli

Re: [PATCH] t: don't redefine test_config() in various places

Junio C Hamano wrote: > Ramkumar Ramachandra writes: > >> test_config() is already a well-defined function in >> test-lib-functions.sh. Don't duplicate it unnecessarily in: >> >> t4018-diff-funcname.sh >> t7810-grep.sh >> t7811-grep-open.sh >> >> Signed-off-by: Ramkumar Ramachandra >> ---

Re: [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()

Jeff King wrote: >I > tend to read the tests in a top-down manner: a test is interesting > (usually because it fails), and then I want to see what it is doing, so > I look at any functions it calls, and so forth. > > What I usuall

Re: [PATCH] t3200 (branch): modernize style

Eric Sunshine wrote: > On Wed, Mar 20, 2013 at 8:30 AM, Ramkumar Ramachandra > wrote: >> Style is inconsistent throughout the file. Make the following >> changes: >> >> 1. Indent everything with tabs. >> >> 2. Put the opening quote (') for the test in the same line as >>test_expect_succcess,

Re: FW: Windows. Git, and Dedupe

Am 19.03.2013 22:36, schrieb Josh Rowe: Yes, Dedup is in fact a Server-only feature. Is there an easier way to reproduce the issue than registering and downloading the Windows Server 2012 evaluation version? It's not that hard, admittedly, but still. The reparse point could be decoded as

Re: [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()

Jeff King writes: > ... even though it is more typing, I would argue that: > > mk_empty testrepo && > git push testrepo ... > > is better, because the test script is more readable as a unit. > > None of this is that huge a deal to me (and yet I seem to have written a > page about it :) ), but

Re: [PATCH] t3200 (branch): modernize style

On Wed, Mar 20, 2013 at 8:30 AM, Ramkumar Ramachandra wrote: > Style is inconsistent throughout the file. Make the following > changes: > > 1. Indent everything with tabs. > > 2. Put the opening quote (') for the test in the same line as >test_expect_succcess, and the closing quote on a line

Re: [PATCH 4/6] remote.c: introduce a way to have different remotes for fetch/push

Ramkumar Ramachandra writes: > ... There is no implicit fallback (like > "origin"): it just falls back to the .remote codepath, if not > explicitly specified. That one sentence is enough to explain the apparent asymmetry, which bothered me. -- To unsubscribe from this list: send the line "unsu

Re: [PATCH 5/6] remote.c: introduce remote.pushdefault

Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: > >> This new configuration variable defines the default remote to push to, >> and overrides `branch..remote` for all branches. > > Micronit: I think this would be easier to explain if it came after > patch 6, since then you could say "In other w

Re: [PATCH v2 14/45] Guard against new pathspec magic in pathspec matching code

On Wed, Mar 20, 2013 at 8:16 AM, Nguyễn Thái Ngọc Duy wrote: > diff --git a/Documentation/technical/api-setup.txt > b/Documentation/technical/api-setup.txt > index 59a947e..f62528e 100644 > --- a/Documentation/technical/api-setup.txt > +++ b/Documentation/technical/api-setup.txt > @@ -28,3 +28,22

Re: [PATCH 4/6] remote.c: introduce a way to have different remotes for fetch/push

Junio C Hamano wrote: > Ramkumar Ramachandra writes: > >> if (name) >> name_given = 1; >> else { >> - name = default_remote_name; >> - name_given = explicit_default_remote_name; >> + if (pushremote_name) { >> + name

Re: [PATCH v2 06/45] Add parse_pathspec() that converts cmdline args to struct pathspec

On Wed, Mar 20, 2013 at 8:16 AM, Nguyễn Thái Ngọc Duy wrote: > +static void NORETURN unsupported_magic(const char *pattern, > + unsigned magic, > + unsigned short_magic) > +{ > + struct strbuf sb = STRBUF_INIT; > +

Re: [PATCH v2] index-pack: always zero-initialize object_entry list

On Wed, Mar 20, 2013 at 3:13 PM, Jeff King wrote: > On Wed, Mar 20, 2013 at 03:12:07PM -0400, Eric Sunshine wrote: > >> On Tue, Mar 19, 2013 at 12:17 PM, Jeff King wrote: >> > To ensure that all depths start at 0, that commit changed >> > calls to xmalloc the object_entry list into calls to >> >

Re: [PATCH v2] index-pack: always zero-initialize object_entry list

On Wed, Mar 20, 2013 at 03:12:07PM -0400, Eric Sunshine wrote: > On Tue, Mar 19, 2013 at 12:17 PM, Jeff King wrote: > > To ensure that all depths start at 0, that commit changed > > calls to xmalloc the object_entry list into calls to > > xcalloc. However, it forgot that we grow the list with >

Re: [PATCH v2] index-pack: always zero-initialize object_entry list

On Tue, Mar 19, 2013 at 12:17 PM, Jeff King wrote: > To ensure that all depths start at 0, that commit changed > calls to xmalloc the object_entry list into calls to > xcalloc. However, it forgot that we grow the list with > xrealloc later. These extra entries are used when we add an > object fro

Re: [PATCH] Documentation: merging a tag is a special case

Yann Droneaud writes: > When asking Git to merge a tag (such as a signed tag or annotated tag), > it will always create a merge commit even if fast-forward was possible. > It's like having --no-ff present on the command line. > > It's a difference from the default behavior described in git-merge.

Re: [PATCH 4/6] remote.c: introduce a way to have different remotes for fetch/push

Ramkumar Ramachandra writes: > if (name) > name_given = 1; > else { > - name = default_remote_name; > - name_given = explicit_default_remote_name; > + if (pushremote_name) { > + name = pushremote_name; > +

Re: USE_NSEC bug?

On Wed, Mar 20, 2013 at 11:52:28AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > So I think your real complaint is "configure does not set NO_NSEC > > properly", which is something worth fixing. > > Yes. > > I think our "Meh" was about "do we want to unify USE_NSEC and > NO_NSEC?" and

Re: [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()

On Wed, Mar 20, 2013 at 11:41:57AM -0700, Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: > > Jonathan Nieder wrote: > > >> I dunno. The helper functions at the top of this test are already > >> intimidating, so I guess I am looking for a way to avoid making that > >> problem worse. > [...]

Re: [PATCH] Documentation: merging a tag is a special case

Yann Droneaud wrote: > When asking Git to merge a tag (such as a signed tag or annotated tag), > it will always create a merge commit even if fast-forward was possible. > It's like having --no-ff present on the command line. Thanks. This looks good, modulo some nitpicks. [...] > --- a/Documenta

Re: [PATCH 5/6] remote.c: introduce remote.pushdefault

Jonathan Nieder writes: > Ramkumar Ramachandra wrote: > >> This new configuration variable defines the default remote to push to, >> and overrides `branch..remote` for all branches. > > Micronit: I think this would be easier to explain if it came after > patch 6, since then you could say "In othe

Re: USE_NSEC bug?

Jeff King writes: > So I think your real complaint is "configure does not set NO_NSEC > properly", which is something worth fixing. Yes. I think our "Meh" was about "do we want to unify USE_NSEC and NO_NSEC?" and nothing else. -- To unsubscribe from this list: send the line "unsubscribe git" in

Re: [PATCH] t: don't redefine test_config() in various places

Ramkumar Ramachandra writes: > test_config() is already a well-defined function in > test-lib-functions.sh. Don't duplicate it unnecessarily in: > > t4018-diff-funcname.sh > t7810-grep.sh > t7811-grep-open.sh > > Signed-off-by: Ramkumar Ramachandra > --- > Thanks, Junio. Heh, I've pushe

Re: [RFC] Add posibility to preload stat information.

On Wed, Mar 20, 2013 at 07:36:41PM +0100, Fredrik Gustafsson wrote: > > Yes, I would certainly like my git startup time to be improved. But I > > don't want to trade my hard drive's life for it. > > Does this really increase disk-reads? The fs-cache would make sure that > the disk reads is almos

Re: git merge behavior

Yann Droneaud writes: > But but do not take those remarks as a feature request. > I was just asking for clarification/comment on the behavior difference > between merging tag/tag object-id. If you are asking why things are as they are, the answer is simply because "git merge $(git rev-parse v1.2

Re: [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()

Ramkumar Ramachandra wrote: > Jonathan Nieder wrote: >> I dunno. The helper functions at the top of this test are already >> intimidating, so I guess I am looking for a way to avoid making that >> problem worse. [...] > My patch does not make the situation worse in any way: Um, yes it does. It

Re: [PATCH] t: don't redefine test_config() in various places

Ramkumar Ramachandra wrote: > Signed-off-by: Ramkumar Ramachandra > --- > Thanks, Junio. > > t/t4018-diff-funcname.sh | 5 - > t/t7810-grep.sh | 5 - > t/t7811-grep-open.sh | 5 - > 3 files changed, 15 deletions(-) Yeah, that looks like all of them. FWIW, Reviewed-by:

Re: [RFC] Add posibility to preload stat information.

On Wed, Mar 20, 2013 at 12:48:06PM -0400, Jeff King wrote: > Kind of gross, but I guess it is useful to some people. Yes it is. The questions is if it's gross enough to never leave my computer, or if someone else can find this useful. > > > +__git_recursive_stat () > > +{ > > + if test ! -e /t

Re: [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()

Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: > >> mk_test() creates a repository with the constant name "testrepo", and >> this may be limiting for tests that need to create more than one >> repository for testing. To fix this, create a new mk_test_with_name() >> which accepts the reposito

Re: [PATCH 2/6] t5516 (fetch-push): update test description

Ramkumar Ramachandra wrote: > When I want to add a test for branch..pushremote, I grep > for branch.*.pushurl, and open files with sensible names; I'm not > going to open up the file and read a long description of what tests it > already contains. Huh? The test_description is output for "./

Re: [RFC] Add posibility to preload stat information.

On Wed, Mar 20, 2013 at 11:19:38PM +0530, Ramkumar Ramachandra wrote: > I think it should be a separate script in contrib/ that people can > just `eval` in their shell configs; zsh has a chpwd() function for > example, which seems like the right place to put such a thing. I was trying to spare the

Re: [PATCH 2/6] t5516 (fetch-push): update test description

Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: > >> --- a/t/t5516-fetch-push.sh >> +++ b/t/t5516-fetch-push.sh >> @@ -1,6 +1,6 @@ >> #!/bin/sh >> >> -test_description='fetching and pushing, with or without wildcard' >> +test_description='fetching and pushing' > > I'm not thrilled with the de

Re: [PATCH 5/6] remote.c: introduce remote.pushdefault

Ramkumar Ramachandra wrote: > This new configuration variable defines the default remote to push to, > and overrides `branch..remote` for all branches. Micronit: I think this would be easier to explain if it came after patch 6, since then you could say "In other words, it is a default for branch.

Re: USE_NSEC bug?

On Wed, Mar 20, 2013 at 02:22:27PM -0400, Andrew Rodland wrote: > I think it would be good if NO_NSEC and USE_ST_TIMESPEC were > controlled by configure instead of config.mak, and it doesn't seem > like too tall of an order. There is no "instead of" here. The Makefile provides knobs which you can

Re: [PATCH 4/6] remote.c: introduce a way to have different remotes for fetch/push

Ramkumar Ramachandra wrote: > Currently, do_push() in push.c calls remote_get(), which gets the > configured remote for fetching and pushing. Replace this call with a > call to pushremote_get() instead, a new function that will return the > remote configured specifically for pushing. This functi

Re: [PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()

Ramkumar Ramachandra wrote: > mk_test() creates a repository with the constant name "testrepo", and > this may be limiting for tests that need to create more than one > repository for testing. To fix this, create a new mk_test_with_name() > which accepts the repository name as $1. Reimplement mk

Re: USE_NSEC bug?

On Wed, Mar 20, 2013 at 1:31 PM, Junio C Hamano wrote: > Jeff King writes: > >> And the cost is that we have another Makefile knob people need to tweak >> that would not otherwise need to be there. Which can be annoying, but is >> also not that huge a cost to deal with (we might want to improve t

Re: [PATCH 2/6] t5516 (fetch-push): update test description

Ramkumar Ramachandra wrote: > --- a/t/t5516-fetch-push.sh > +++ b/t/t5516-fetch-push.sh > @@ -1,6 +1,6 @@ > #!/bin/sh > > -test_description='fetching and pushing, with or without wildcard' > +test_description='fetching and pushing' I'm not thrilled with the description before or after. Would

Re: git merge behavior

Hi, Le mercredi 20 mars 2013 à 19:04 +0100, Yann Droneaud a écrit : > > > 2) git merge VS git merge > > > > > > If is an object (not a lightweight/reference tag), git merge > > > ... > > > But, if you use the tag object-id instead of its name, for example using > > > git merge `git parse-rev

Re: [PATCH 1/6] remote.c: simplify a bit of code using git_config_string()

Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: > >> --- a/remote.c >> +++ b/remote.c >> @@ -356,9 +356,7 @@ static int handle_config(const char *key, const char >> *value, void *cb) >> return 0; >> branch = make_branch(name, subkey - name); >>

Re: [PATCH 1/6] remote.c: simplify a bit of code using git_config_string()

Ramkumar Ramachandra wrote: > --- a/remote.c > +++ b/remote.c > @@ -356,9 +356,7 @@ static int handle_config(const char *key, const char > *value, void *cb) > return 0; > branch = make_branch(name, subkey - name); > if (!strcmp(subkey, ".remote"))

Re: git merge behavior

Hi, Le mardi 19 mars 2013 à 09:19 -0700, Junio C Hamano a écrit : > Yann Droneaud writes: > > > 1) there's no mention of the git merge behavior in git-merge.1 > Yes; we welcome documentation patches. > Sent. > > 2) git merge VS git merge > > > > If is an object (not a lightweight/referen

Re: [PATCH v2 00/45] parse_pathspec and :(glob) magic

Nguyễn Thái Ngọc Duy writes: > Junio please pull the series from github [1] > [1] https://github.com/pclouds/git/commits/parse-pathspec Please write it like this: https://github.com/pclouds/git parse-pathspec so that I can just say git fetch <> git diff nd/magic-paths

[PATCH] Documentation: merging a tag is a special case

When asking Git to merge a tag (such as a signed tag or annotated tag), it will always create a merge commit even if fast-forward was possible. It's like having --no-ff present on the command line. It's a difference from the default behavior described in git-merge.txt. It should be documented as a

Re: [RFC] Add posibility to preload stat information.

Fredrik Gustafsson wrote: > On Wed, Mar 20, 2013 at 10:45:22PM +0530, Ramkumar Ramachandra wrote: >> Fredrik Gustafsson wrote: >> > When entering a git working dir, optionally run a forked process that >> > stat all files in the whole workdir and therefore loads stat information >> > to RAM which w

Re: [RFC] Add posibility to preload stat information.

On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > So maybe just run "git status >/dev/null"? > > In the background? How often would it run? I do not think a single > lockfile solves anything. It may prevent simultaneous runs of two > such "prime the we

[PATCH] do not use GIT_TRACE_PACKET=3 in tests

Some test scripts use the GIT_TRACE mechanism to dump debugging information to descriptor 3 (and point it to a file using the shell). On Windows, however, bash is unable to set up descriptor 3. We do not write our trace to the file, and worse, we may interfere with other operations happening on des

Re: [RFC] Add posibility to preload stat information.

On Wed, Mar 20, 2013 at 10:45:22PM +0530, Ramkumar Ramachandra wrote: > Fredrik Gustafsson wrote: > > When entering a git working dir, optionally run a forked process that > > stat all files in the whole workdir and therefore loads stat information > > to RAM which will speedup things like git stat

Re: USE_NSEC bug?

Jeff King writes: > And the cost is that we have another Makefile knob people need to tweak > that would not otherwise need to be there. Which can be annoying, but is > also not that huge a cost to deal with (we might want to improve the > configure script or something, though). > > I admit I don

Re: [PATCH jk/pkt-line-cleanup] t5700-clone-reference: send trace to fd 2, not 3, to please Windows git

Jeff King writes: > Also, though I think your use of stderr is probably OK, might it be a > little more robust against future output changes to use: > > GIT_TRACE_PACKET=$PWD/$U.D git clone ... > > to write directly to the file. The original GIT_DEBUG_SEND_PACK did not > support such niceties,

Re: [PATCH jk/pkt-line-cleanup] t5700-clone-reference: send trace to fd 2, not 3, to please Windows git

On Wed, Mar 20, 2013 at 01:06:07PM -0400, Jeff King wrote: > On Wed, Mar 20, 2013 at 12:30:47PM +0100, Johannes Sixt wrote: > > > > I think that is OK, but I'm curious why this is a problem _now_, and not > > > with the code prior to 97a83fa8. The old GIT_DEBUG_SEND_PACK was also > > > just calli

Re: [RFC] Add posibility to preload stat information.

Jeff King writes: > So maybe just run "git status >/dev/null"? In the background? How often would it run? I do not think a single lockfile solves anything. It may prevent simultaneous runs of two such "prime the well" processes, but the same user may be working in two separate repositories.

Re: [PATCH jk/checkout-attribute-lookup] t2003: work around path mangling issue on Windows

Johannes Sixt writes: > From: Johannes Sixt > > MSYS bash considers the part "/g" in the sed expression "s/./=/g" as an > absolute path after an assignment, and mangles it to a C:/something > string. Do not attract bash's attention by avoiding the equals sign. If this breakage is about path man

Re: USE_NSEC bug?

On Wed, Mar 20, 2013 at 10:04:14AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > But maybe there is some subtle reason I'm missing for having the two > > options separate. > > The closest I found was c06ff4908bf9 (Record ns-timestamps if > possible, but do not use it without USE_NSEC,

Re: [PATCH jk/pkt-line-cleanup] t5700-clone-reference: send trace to fd 2, not 3, to please Windows git

On Wed, Mar 20, 2013 at 12:30:47PM +0100, Johannes Sixt wrote: > > I think that is OK, but I'm curious why this is a problem _now_, and not > > with the code prior to 97a83fa8. The old GIT_DEBUG_SEND_PACK was also > > just calling write() to descriptor 3. > > Before this change, both affected com

Re: USE_NSEC bug?

Jeff King writes: > But maybe there is some subtle reason I'm missing for having the two > options separate. The closest I found was c06ff4908bf9 (Record ns-timestamps if possible, but do not use it without USE_NSEC, 2009-03-04). commit c06ff4908bf9ad8bf2448439a3574321c9399b17 Author: Kjetil Ba

Re: [RFC] Add posibility to preload stat information.

On Wed, Mar 20, 2013 at 01:15:32PM +0100, Fredrik Gustafsson wrote: > When entering a git working dir, optionally run a forked process that > stat all files in the whole workdir and therefore loads stat information > to RAM which will speedup things like git status and so on. > > The feature is o

Re: [PATCH] sha1_file: remove recursion in packed_object_info

Thomas Rast writes: > So here's a nonrecursive version. Dijkstra is probably turning over > in his grave as we speak. > > I *think* I actually got it right. You seem to have lost the "if we cannot get delta base, this object is BAD" check where you measure the size of a deltified object, which

Re: Bug? git show behaves incorrectly when called on a stash object

Kirill Likhodedov writes: > The first gives the correct result, while the second doesn't show the > addition. > Is it a bug, or I'm just missing something? stash objects are commits with 2 parents (ie. merge commits). One commit is the HEAD you stashed from, and the other is the saved state of

Re: [PATCH 5/6] add -A: only show pathless 'add -A' warning when changes exist outside cwd

Jonathan Nieder writes: > In the spirit of the recent similar change for 'git add -u', avoid > pestering users that restrict their attention to a subdirectory and > will not be affected by the coming change in the behavior of pathless > 'git add -A'. > > Signed-off-by: Jonathan Nieder > --- > As

Re: [PATCH 4/6] add -u: only show pathless 'add -u' warning when changes exist outside cwd

Jonathan Nieder writes: > A common workflow in large projects is to chdir into a subdirectory of > interest and only do work there: > > cd src > vi foo.c > make test > git add -u > git commit > > The upcoming change to 'git add -u' behavior would not affect such a >

Bug? git show behaves incorrectly when called on a stash object

Hi, I experience difference in behavior between `git stash show stash@{0}` and `git show stash@{0}`: - # git stash show --name-status stash@{0} A a M conflict.js # git show --name-status stash@{0} commit 05aa170746dc4e060f10710a92a

[no subject]

Hello, I have information for you about an unclaimed funds in my department. Please get back to me if interested so I would brief you in details. Email:lmrle...@live.com Regards, Lan Lee -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.ker

Re: [PATCH v3 0/5] nd/branch-show-rebase-bisect-state updates

Duy Nguyen writes: >> I think the message should better say "before you started to bisect >> you were on 'jch'" or something instead. > > How about > > * (no branch, bisect started on jch) > > then? Sure. What you are showing is used only to decide where "git bisect reset" goes to, I think. --

Re: [PATCH] push: Alias pushurl from push rewrites

Rob Hoelz writes: > On 3/19/13 7:08 PM, Junio C Hamano wrote: >> Jonathan Nieder writes: >> >>> Junio C Hamano wrote: Jonathan Nieder writes: > Test nits: > ... > Hope that helps, > > Jonathan Nieder (3): > push test: use test_config where appropriate > push

Re: git branch based hook desigh

On Monday, March 18, 2013 at 00:27 EDT, Joydeep Bakshi wrote: > I have implemented git pre-received hook successfully. And it works on > the repo level. > Could anyone suggest how to call branch level hook please ?-- If you need to have different hook behaviors depending on the ref that's a

Re: [PATCH 6/6] remote.c: introduce branch..pushremote

Tay Ray Chuan wrote: > On Wed, Mar 20, 2013 at 8:45 PM, Ramkumar Ramachandra > wrote: >> This new configuration variable overrides `remote.pushdefault` and >> `branch..remote` for pushes. In a typical triangular-workflow >> setup, you would want to set `remote.pushdefault` to specify the >> remot

Re: [PATCH v2 0/6] Support triangular workflows

On Wed, Mar 20, 2013 at 8:44 PM, Ramkumar Ramachandra wrote: > remote.c: introduce remote.pushdefault > remote.c: introduce branch..pushremote Perhaps we should clarify how this differs from remote.pushurl in the documentation for it, in git-config and/or git-push. Maybe even include the desi

Re: [PATCH 6/6] remote.c: introduce branch..pushremote

On Wed, Mar 20, 2013 at 8:45 PM, Ramkumar Ramachandra wrote: > This new configuration variable overrides `remote.pushdefault` and > `branch..remote` for pushes. In a typical triangular-workflow > setup, you would want to set `remote.pushdefault` to specify the > remote to push to for all branches

[PATCH 6/6] remote.c: introduce branch..pushremote

This new configuration variable overrides `remote.pushdefault` and `branch..remote` for pushes. In a typical triangular-workflow setup, you would want to set `remote.pushdefault` to specify the remote to push to for all branches, and use this option to override it for a specific branch. Signed-of

[PATCH 4/6] remote.c: introduce a way to have different remotes for fetch/push

Currently, do_push() in push.c calls remote_get(), which gets the configured remote for fetching and pushing. Replace this call with a call to pushremote_get() instead, a new function that will return the remote configured specifically for pushing. This function tries to work with the string push

[PATCH 5/6] remote.c: introduce remote.pushdefault

This new configuration variable defines the default remote to push to, and overrides `branch..remote` for all branches. It is useful in the typical triangular-workflow setup, where the remote you're fetching from is different from the remote you're pushing to. Signed-off-by: Ramkumar Ramachandra

[PATCH 2/6] t5516 (fetch-push): update test description

The file was originally created in bcdb34f (Test wildcard push/fetch, 2007-06-08), and only contained tests that exercised wildcard functionality at the time. In subsequent commits, many other tests unrelated to wildcards were added but the test description was never updated. Fix this. Signed-of

[PATCH 3/6] t5516 (fetch-push): introduce mk_test_with_name()

mk_test() creates a repository with the constant name "testrepo", and this may be limiting for tests that need to create more than one repository for testing. To fix this, create a new mk_test_with_name() which accepts the repository name as $1. Reimplement mk_test() as a special case of this fun

[PATCH v2 0/6] Support triangular workflows

This follows-up [1], with three important differences: 1. pushremote_get() and remote_get() share code better. Thanks Jeff. 2. All spelling mistakes have been corrected. Thanks Eric. 3. One new test for each of the new configuration variables. The extra two parts [2/6] and [3/6] preprare the

[PATCH 1/6] remote.c: simplify a bit of code using git_config_string()

A small segment where handle_config() parses the branch.remote configuration variable can be simplified using git_config_string(). Signed-off-by: Ramkumar Ramachandra --- remote.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/remote.c b/remote.c index e53a6eb..45b69d6 10

Re: [PATCH v3 0/5] nd/branch-show-rebase-bisect-state updates

On Wed, Mar 20, 2013 at 1:37 AM, Junio C Hamano wrote: > I was running "git bisect start pu jch" (jch is a branch I do not > push out everywhere that is somewhere in the middle of > "master..pu"), and then after bisection finished, saw this: > > $ git branch --with 66887099e096f0258a5ef3b1e745

  1   2   >