Re: [PATCH v3] Teach git to change to a given directory using -C option

On Wed, Sep 4, 2013 at 2:36 AM, Nazri Ramliy wrote: > On Wed, Sep 4, 2013 at 6:46 AM, Junio C Hamano wrote: >> I do not care too deeply either way, but I am curious if there was a >> reason why you changed the earlier to ? Somehow, >> when we _know_ a path has to be a directory, I find it easie

Re: [PATCH v3] Teach git to change to a given directory using -C option

On Wed, Sep 4, 2013 at 6:46 AM, Junio C Hamano wrote: > I do not care too deeply either way, but I am curious if there was a > reason why you changed the earlier to ? Somehow, > when we _know_ a path has to be a directory, I find it easier on the > readers to spell that out, instead of saying "t

Re: [PATCH v3 2/2] submodule: don't print status output with ignore=all

"brian m. carlson" writes: > Tests are included which verify that this change has no effect on git > submodule > summary without the --for-status option. I still don't understand why this is needed. Why do we want "git status" and "git submodule summary" to display different information? Wasn't

German translation errors

Hi, when I fetch from remote repositories, git tells me about new branches and tags by saying "[neuer Branch]" or "[neuer Tag]". While "Branch" translates to "Zweig" in german, the german word "Tag" actually means "day", so git is telling me something about a "new day" for every new tag. Should

[Bug?] MERGE_HEAD lost with git checkout master

Hi, At $dayjob we have some simple "code quality" checks that we run to make sure that things are heading in the right direction. These are usually run as part of our automated builds but people occasionally run them when merging updates from other teams or preparing to merge to the integration br

Re: Officially start moving to the term 'staging area'

On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras wrote: > It has been discussed many times in the past that 'index' is not an > appropriate description for what the high-level user does with it, and > it has been agreed that 'staging area' is the best term. I realize Git is not a democracy, but

Re: Officially start moving to the term 'staging area'

On Thu, Aug 29, 2013 at 6:10 PM, Felipe Contreras wrote: > On Thu, Aug 29, 2013 at 4:55 PM, Drew Northup wrote: >> On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano wrote: >>> Felipe Contreras writes: >>> It has been discussed many times in the past that 'index' is not an appropriate de

Re: [PATCH 3/4] rev-parse test: use test_cmp instead of "test" builtin

Junio C Hamano wrote: > After applying this patch and running "git show | grep test_cmp_rev_output", > I notice that the second is always "git rev-parse ". Do > we still need to eval these, or would it be sufficient to do > > test_cmp_rev_output () { > git rev-parse --veri

Re: Officially start moving to the term 'staging area'

On Fri, Aug 30, 2013 at 1:16 AM, Piotr Krukowiecki wrote: > Drew Northup napisał: >>I agree with Junio. This effort is better spent making the >>documentation clearer and more succinct. The reality is that a user >>needs to build a model in their mind of what they are doing which maps >>enough (c

Re: Stalled git cloning and possible solutions

On Friday, August 30, 2013 03:48:44 AM you wrote: > "V.Krishn" writes: > > On Friday, August 30, 2013 02:40:34 AM you wrote: > >> V.Krishn wrote: > >> > Quite sometimes when cloning a large repo stalls, hitting Ctrl+c > >> > cleans what been downloaded, and process needs re-start. > >> > > >> > I

Re: Get back to me

i have a business proposal for you, write me back for more info. -Sent from my ipad. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] Teach git to change to a given directory using -C option

On Tue, Sep 3, 2013 at 6:46 PM, Junio C Hamano wrote: > Nazri Ramliy writes: > >> -- >8 -- >> diff --git a/Documentation/git.txt b/Documentation/git.txt >> index 83edf30..6105cb0 100644 >> --- a/Documentation/git.txt >> +++ b/Documentation/git.txt >> @@ -9,7 +9,7 @@ git - the stupid content track

Re: [PATCH v2 1/7] glossary: mention 'treeish' as an alternative to 'tree-ish'

Richard Hansen writes: > The documentation contains a mix of the two spellings, so include both > in the glossary so that a search for either will lead to the > definition. > > Signed-off-by: Richard Hansen > --- I hate to say this after seeing you doing a thorough job in this series, but becau

Re: [PATCH 4/4] t: branch: improve test rollback

Felipe Contreras writes: > On Tue, Sep 3, 2013 at 2:32 PM, Junio C Hamano wrote: >> Felipe Contreras writes: > >>> test_expect_success 'refuse --edit-description on unborn branch for now' ' >>> + test_when_finished "git checkout -" && >> >> I am not sure if this is a good change. Dependin

What's cooking in git.git (Sep 2013, #01; Tue, 3)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of 'next' has been rewound. I ejected a handful of topics that have been cooking there while rebuilding it, but it is not because I foun

Re: [PATCH 0/3] Reject non-ff pulls by default

Felipe Contreras writes: > On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> >>> Junio already sent a similar patch, but I think this is simpler. >> >> I agree that this is simpler, but I am not sure if the behaviour is >> necessarily better (note that this i

Re: [PATCH 4/4] t: branch: improve test rollback

On Tue, Sep 3, 2013 at 5:59 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Tue, Sep 3, 2013 at 2:32 PM, Junio C Hamano wrote: >>> Felipe Contreras writes: >> test_expect_success 'refuse --edit-description on unborn branch for now' ' + test_when_finished "git checkou

Re: [PATCH 0/3] Reject non-ff pulls by default

On Tue, Sep 3, 2013 at 5:38 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano wrote: >>> Felipe Contreras writes: >>> Junio already sent a similar patch, but I think this is simpler. >>> >>> I agree that this is simpler, but I am not

Re: [PATCH v3] Teach git to change to a given directory using -C option

Nazri Ramliy writes: > -- >8 -- > Subject: [PATCH] Teach git to change to a given directory using -C option > > This is similar in spirit to to "make -C dir ..." and "tar -C dir ...". > > Currently it takes more effort (keypresses) to invoke git command in a > different directory than the current

Re: [PATCH] revision: introduce --exclude= to tame wildcards

On Tue, Sep 3, 2013 at 10:45 AM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Fri, Aug 30, 2013 at 6:55 PM, Junio C Hamano wrote: >>> People often find "git log --branches" etc. that includes _all_ >>> branches is cumbersome to use when they want to grab most but except >>> some. Th

Re: [PATCH 4/4] t: branch: improve test rollback

On Tue, Sep 3, 2013 at 2:32 PM, Junio C Hamano wrote: > Felipe Contreras writes: >> test_expect_success 'refuse --edit-description on unborn branch for now' ' >> + test_when_finished "git checkout -" && > > I am not sure if this is a good change. Depending on the outcome of > the "git chec

Re: [PATCH 2/4] rev-parse test: use test_must_fail, not "if ; then false; fi"

> rev-parse test: use test_must_fail, not "if ; then false; fi" That is way more than 50 characters, and doesn't tell me why you want to do that. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More major

Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Tue, Sep 3, 2013 at 12:31 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> There are two ways to fix an inconsistency, the other way is to fix >> test_cmp. But that would be a change, and change is not welcome in >> Git. > > If you want to do "test_cmp $actual $expect", you would have

Re: [PATCH 0/3] Reject non-ff pulls by default

On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Junio already sent a similar patch, but I think this is simpler. > > I agree that this is simpler, but I am not sure if the behaviour is > necessarily better (note that this is different from saying "I think >

Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Tue, Sep 3, 2013 at 12:04 PM, Jonathan Nieder wrote: > SZEDER Gábor wrote: >> On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote: > >>> There are two ways to fix an inconsistency, the other way is to fix >>> test_cmp. But that would be a change, and change is not welcome in >>> Gi

Re: [PATCH] git send-email: include [anything]-by: signatures

Jeff King writes: > On Wed, Sep 04, 2013 at 12:01:49AM +0300, Michael S. Tsirkin wrote: > >> > The question of course is the first point Peff raised. I am not >> > sure offhand what the right per-project customization interface >> > would be. A starting point might be something like: >> > >> >

Re: [PATCH 3/4] rev-parse test: use test_cmp instead of "test" builtin

On Tue, Sep 3, 2013 at 12:07 PM, Jonathan Nieder wrote: > test_expect_success 'start^0' ' > - test $(cat .git/refs/tags/start) = $(git rev-parse start^0) > + test_cmp_rev_output tags/start "git rev-parse start^0" > ' Backwards and yodaish this is. -- Felipe Contreras -- To unsubs

Re: [PATCH] git send-email: include [anything]-by: signatures

On Tue, Sep 03, 2013 at 05:03:52PM -0400, Jeff King wrote: > On Wed, Sep 04, 2013 at 12:01:49AM +0300, Michael S. Tsirkin wrote: > > > > The question of course is the first point Peff raised. I am not > > > sure offhand what the right per-project customization interface > > > would be. A startin

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

On Tue, Sep 03, 2013 at 10:12:18AM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" writes: > > > I always want my diffs to show header files first, > > then .c files, then the rest. Make it possible to > > set orderfile though a config option to achieve this. > > > > Signed-off-by: Michael S.

Re: [PATCH] git send-email: include [anything]-by: signatures

On Wed, Sep 04, 2013 at 12:01:49AM +0300, Michael S. Tsirkin wrote: > > The question of course is the first point Peff raised. I am not > > sure offhand what the right per-project customization interface > > would be. A starting point might be something like: > > > > --cc-trailer=signed-off

Re: [PATCH] git send-email: include [anything]-by: signatures

On Tue, Sep 03, 2013 at 10:06:19AM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" writes: > > > On Tue, Sep 03, 2013 at 02:35:35AM -0400, Jeff King wrote: > >> On Sat, Aug 31, 2013 at 10:22:50PM +0300, Michael S. Tsirkin wrote: > >> > >> > On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael S

Re: [PATCH 2/1 alt] peel_onion: do not assume length of x_type globals

Jeff King writes: > If you _really_ wanted to abstract it, you could make commit_type a > macro and use string concatenation along with prefixcmp. But that is > going in the direction of less readable, I think. :) ;-) we are on the same wave-length. Thanks, will apply. > > This has probably co

[PATCH 2/1 alt] peel_onion: do not assume length of x_type globals

When we are parsing "rev^{foo}", we check "foo" against the various global type strings, like "commit_type", "tree_type", etc. This is nicely abstracted, but then we destroy the abstraction completely by using magic numbers that must match the length of the type strings. We could avoid these magic

Re: [PATCH v4] peel_onion(): add support for ^{tag}

Richard Hansen writes: > diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh > index eaefc77..15973f2 100755 > --- a/t/t1511-rev-parse-caret.sh > +++ b/t/t1511-rev-parse-caret.sh > @@ -54,6 +54,13 @@ test_expect_success 'ref^{tree}' ' > test_must_fail git rev-parse blob-tag

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

Christopher Durkin writes: > Add another item to the search drop-down (author/committer/etc) > to search for file names instead of file content. Output is similar > to the grep contents output, with each entry linking to the file. > --- Missing sign-off. > gitweb/gitweb.perl | 59 > ++

Re: [PATCH v3 2/2] submodule: don't print status output with ignore=all

Am 01.09.2013 22:06, schrieb brian m. carlson: > git status prints information for submodules, but it should ignore the status > of > those which have submodule..ignore set to all. Fix it so that it does > properly ignore those which have that setting either in .git/config or in > .gitmodules. >

[PATCH 2/1] peel_onion: do not assume length of x_type globals

When we are parsing "rev^{foo}", we check "foo" against the various global type strings, like "commit_type", "tree_type", etc. This is nicely abstracted, but then we destroy the abstraction completely by using magic numbers that must match the length of the type strings. We can avoid these magic n

[PATCH v4] peel_onion(): add support for ^{tag}

Complete the ^{} family of object descriptors by having ^{tag} dereference until a tag object is found (or fail if unable). At first glance this may not seem very useful, as commits, trees, and blobs cannot be peeled to a tag, and a tag would just peel to itself. However, this can be used to ensu

Re: [PATCH 2/2] fast-export: refactor get_tags_and_duplicates()

Junio C Hamano writes: > Felipe Contreras writes: > >> Split into a separate helper function get_commit() so that the part that >> finds the relevant commit, and the part that does something with it >> (handle tag object, etc.) are in different places. >> >> No functional changes. > > Actually,

gitweb patch, no response

I submitted a small feature addition patch for gitweb (see http://article.gmane.org/gmane.comp.version-control.git/232327/match=gitweb) a couple of weeks ago. I didn't get any responses, good or bad. Was there something wrong with my submission in terms of formatting? Something else that I missed?

Re: [PATCH 3/4] rev-parse test: use test_cmp instead of "test" builtin

Jonathan Nieder writes: > Use test_cmp instead of passing two command substitutions to the > "test" builtin. This way: > > - when tests fail, they can print a helpful diff if run with >"--verbose" > > - the argument order "test_cmp expect actual" feels natural, >unlike test = that se

Re: [PATCH v3 2/2] submodule: don't print status output with ignore=all

Jens, I see 1/2 is the same as the previous one you already acked. Does this update to 2/2 look good to you? Sorry, but I lost track of the discussion that led to this reroll, hence a ping. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to major

Re: [PATCH v3] peel_onion(): add support for ^{tag}

On 2013-09-03 15:03, Eric Sunshine wrote: > On Tue, Sep 3, 2013 at 1:37 PM, Richard Hansen wrote: >> diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh >> index eaefc77..5771cbd 100755 >> --- a/t/t1511-rev-parse-caret.sh >> +++ b/t/t1511-rev-parse-caret.sh >> @@ -54,6 +61,26 @@ t

Re: [PATCH 2/2] fast-export: refactor get_tags_and_duplicates()

Felipe Contreras writes: > Split into a separate helper function get_commit() so that the part that > finds the relevant commit, and the part that does something with it > (handle tag object, etc.) are in different places. > > No functional changes. Actually, the old code used to use commit unch

Re: [PATCH] revision: introduce --exclude= to tame wildcards

Am 03.09.2013 18:03, schrieb Junio C Hamano: > Johannes Sixt writes: >> So I like the relative simplicity of this approach. Here is a bit of >> documentation. > > Oh, thanks for helping. An example or two may also help, and using > your original "I have branches and wip/" situation would be good

Re: gitweb patch, no response

Christopher Durkin writes: > I submitted a small feature addition patch for gitweb (see > http://article.gmane.org/gmane.comp.version-control.git/232327/match=gitweb) > a couple of weeks ago. > > I didn't get any responses, good or bad. Was there something wrong > with my submission in terms of f

Re: [PATCH v2] peel_onion(): add support for ^{tag}

On Tue, Sep 03, 2013 at 02:36:39PM -0400, Richard Hansen wrote: > I have a patch submission question: Is it OK that I didn't use the > '--in-reply-to' argument to 'git send-email' when I sent the v3 reroll? > Should I have marked it as a reply to the v2 email? Or should I have > marked it as a

Re: [PATCH v3 3/4] get rid of "git submodule summary --for-status"

Am 29.08.2013 21:54, schrieb Jens Lehmann: > Am 29.08.2013 15:05, schrieb Matthieu Moy: >> The --for-status option was an undocumented option used only by >> wt-status.c, which inserted a header and commented out the output. We can >> achieve the same result within wt-status.c, without polluting th

Re: [PATCH 4/4] t: branch: improve test rollback

Felipe Contreras writes: > After every test the environment should be as close as to how it was > before as possible. > > Signed-off-by: Felipe Contreras > --- Very good in general; a few points (not "the patch breaks things", but more like "tests after the patch are still depending on the prev

Re: [PATCH 1/4] t: branch: trivial style fix

The first three are trivially correct and good changes. I still have to read the last one, but wanted to give a Thanks before doing so, which would take more time. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH v3] peel_onion(): add support for ^{tag}

On Tue, Sep 3, 2013 at 1:37 PM, Richard Hansen wrote: > diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh > index eaefc77..5771cbd 100755 > --- a/t/t1511-rev-parse-caret.sh > +++ b/t/t1511-rev-parse-caret.sh > @@ -54,6 +61,26 @@ test_expect_success 'ref^{tree}' ' > test_

Re: [PATCH v5 2/2] Add new @ shortcut for HEAD

Felipe Contreras writes: > diff --git a/sha1_name.c b/sha1_name.c > index 93197b9..b8ece6e 100644 > --- a/sha1_name.c > +++ b/sha1_name.c > @@ -1004,6 +1004,26 @@ int get_sha1_mb(const char *name, unsigned char *sha1) > return st; > } > > +/* parse @something syntax, when 'something' is

Re: [PATCH v5 1/2] sha1-name: pass len argument to interpret_branch_name()

Felipe Contreras writes: > This is useful to make sure we don't step outside the boundaries of what > we are interpreting at the moment. For example while interpreting > foobar@{u}~1, the job of interpret_branch_name() ends right before ~1, > but there's no way to figure that out inside the funct

Re: [PATCH v2] peel_onion(): add support for ^{tag}

On 2013-09-03 03:05, Jeff King wrote: > FWIW, this makes sense to me. Thank you for the feedback. I posted a reroll of the patch that you've already replied to, but for the benefit of others searching the mailing list archive, v3 can be found at

Re: [PATCH] Make setup_git_env() resolve .git file when $GIT_DIR is not specified

Nguyễn Thái Ngọc Duy writes: > This makes reinitializing on a .git file repository work. > > This is probably the only case that setup_git_env() (via > set_git_dir()) is called on a .git file. Other cases in > setup_git_dir_gently() and enter_repo() both cover .git file case > explicitly because

Re: [PATCH v2] git p4: implement view spec wildcards with "p4 where"

kazuki saitoh writes: > Currently, git p4 does not support many of the view wildcards, > such as * and %%n. It only knows the common ... mapping, and > exclusions. > > Redo the entire wildcard code around the idea of > directly querying the p4 server for the mapping. For each > commit, invoke "

Re: [PATCH v3] peel_onion(): add support for ^{tag}

On Tue, Sep 03, 2013 at 01:37:33PM -0400, Richard Hansen wrote: > --- > Changes since v2 (2013-09-02, see > ): > * add a test case (hopefully I didn't go overboard) Personally I was thinking just test_must_fail git rev-parse HEAD

Re: contrib/credential/netrc/git-credential-netrc: Use of uninitialized value in string

On Tue, Sep 03, 2013 at 11:23:14AM -0400, Ted Zlatanov wrote: > Yes, you're right. Something like the following (untested) could work > and does the wildcards, which I will make into a proper patch and test > if it looks OK to you. > > Ted > > diff --git a/contrib/credential/netrc/git-credentia

Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

Junio C Hamano writes: > Felipe Contreras writes: > >> There are two ways to fix an inconsistency, the other way is to fix >> test_cmp. But that would be a change, and change is not welcome in >> Git. > > If you want to do "test_cmp $actual $expect", you would have to > first "fix" people's expe

[PATCH v3] peel_onion(): add support for ^{tag}

Complete the ^{} family of object descriptors by having ^{tag} dereference until a tag object is found (or fail if unable). At first glance this may not seem very useful, as commits, trees, and blobs cannot be peeled to a tag, and a tag would just peel to itself. However, this can be used to ensu

Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

Felipe Contreras writes: > There are two ways to fix an inconsistency, the other way is to fix > test_cmp. But that would be a change, and change is not welcome in > Git. If you want to do "test_cmp $actual $expect", you would have to first "fix" people's expectation that "diff A B" produces a c

Re: [PATCH] pager: turn on "cat" optimization for DEFAULT_PAGER

Jeff King writes: > I'll venture my opinion. We should do this: > > -- >8 -- > Subject: pager: turn on "cat" optimization for DEFAULT_PAGER > > If the user specifies a pager of "cat" (or the empty > string), whether it is in the environment or from config, we > automagically optimize it out to me

Re: git fetch --reference

Yann Droneaud writes: > So what's the best way to do a git fetch , copying objects from > another local repository > to resolve delta ? IMHO the best way is to add a remote for the local repository, fetch from it, then fetch from . Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fin

Re: [PATCH] {fetch,receive}-pack: drop unpack-objects, delay loosing objects until the end

On Tue, Sep 03, 2013 at 06:56:23PM +0700, Nguyen Thai Ngoc Duy wrote: > > ...but the cost is paid by total pack size, not number of objects. So if > > I am pushing up a commit with a large uncompressible blob, I've > > effectively doubled my disk I/O. It would make more sense to me for > > index-p

Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Tue, Sep 03, 2013 at 10:04:19AM -0700, Jonathan Nieder wrote: > > It depends on the change, I suppose. I agree, changing 3k+ lines just > > to avoid yoda conditions... I doubt the gain worth the code churn. > > Especially when the idiom being changed is not even being made better. > ;-) Yes

Re: [PATCH 0/3] Reject non-ff pulls by default

Felipe Contreras writes: > Junio already sent a similar patch, but I think this is simpler. I agree that this is simpler, but I am not sure if the behaviour is necessarily better (note that this is different from saying "I think the behaviour of this patch is worse"). The motivation I read from

[PATCH 4/4] rev-parse test: use standard test functions for setup

From: Felipe Contreras Save the reader from learning specialized t6* setup functions where familiar commands like test_commit, "git checkout --orphan", and "git merge" will do. While at it, wrap the setup commands in a test assertion so errors can be caught and stray output suppressed when runni

[PATCH v2 4/4] rev-parse test: use standard test functions for setup

From: Felipe Contreras Save the reader from learning specialized t6* setup functions where familiar commands like test_commit, "git checkout --orphan", and "git merge" will do. While at it, wrap the setup commands in a test assertion so errors can be caught and stray output suppressed when runni

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

"Michael S. Tsirkin" writes: > I always want my diffs to show header files first, > then .c files, then the rest. Make it possible to > set orderfile though a config option to achieve this. > > Signed-off-by: Michael S. Tsirkin > --- I admit that I was the guilty one who introduced the orderfil

[PATCH 3/4] rev-parse test: use test_cmp instead of "test" builtin

Use test_cmp instead of passing two command substitutions to the "test" builtin. This way: - when tests fail, they can print a helpful diff if run with "--verbose" - the argument order "test_cmp expect actual" feels natural, unlike test = that seems a little backwards - the exit stat

Re: [PATCH] git send-email: include [anything]-by: signatures

"Michael S. Tsirkin" writes: > On Tue, Sep 03, 2013 at 02:35:35AM -0400, Jeff King wrote: >> On Sat, Aug 31, 2013 at 10:22:50PM +0300, Michael S. Tsirkin wrote: >> >> > On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael S. Tsirkin wrote: >> > > Consider [anything]-by: a valid signature. >> > > Th

[PATCH 2/4] rev-parse test: use test_must_fail, not "if ; then false; fi"

From: Felipe Contreras This way, if rev-parse segfaults then the test will fail instead of treating it the same way as a controlled failure. Signed-off-by: Felipe Contreras Signed-off-by: Jonathan Nieder --- t/t6101-rev-parse-parents.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-

[PATCH 1/4] rev-parse test: modernize quoting and whitespace

From: Felipe Contreras Instead of cramming everything in one line, put the test body in an indented block after the opening test_expect_success line and quote and put the closing quote on a line by itself. Use single-quote instead of double-quote to quote the test body for more useful --verbose

[PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

SZEDER Gábor wrote: > On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote: >> There are two ways to fix an inconsistency, the other way is to fix >> test_cmp. But that would be a change, and change is not welcome in >> Git. > > It depends on the change, I suppose. I agree, changing 3

git fetch --reference

Hi, I surprised myself trying to run git fetch --reference in the hope git would use my to resolve objects present in but not in my current repository ... just like git clone --reference directory> : --reference If the reference repository is on the local machine, automatical

Re: [PATCH] branch: use $curr_branch_short more

Felipe Contreras writes: >> Subject: branch: use $curr_branch_short more > > Why? I don't think that summary explains the reason for being for this > patch, also, it starts with branch: instead of pull: > > Subject: pull: trivial simplification > > With that summary, people would have an easier t

Re: [PATCH] revision: introduce --exclude= to tame wildcards

Johannes Sixt writes: > Am 31.08.2013 01:55, schrieb Junio C Hamano: >> People often find "git log --branches" etc. that includes _all_ >> branches is cumbersome to use when they want to grab most but except >> some. The same applies to --tags, --all and --glob. >> >> Teach the revision machine

[PATCH v4 2/4] transport-helper: add no-private-update capability

Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update remote helper namespace), a 'push' operation on a remote helper updates the private ref by default. This is often a good thing, but it can also be desirable to disable this update to force the next 'pull' to re-import the pus

Re: [PATCH] revision: introduce --exclude= to tame wildcards

Felipe Contreras writes: > On Fri, Aug 30, 2013 at 6:55 PM, Junio C Hamano wrote: >> People often find "git log --branches" etc. that includes _all_ >> branches is cumbersome to use when they want to grab most but except >> some. The same applies to --tags, --all and --glob. > > This idea looks

Re: Remote's 'currently active branch' not HEAD?

Andreas Krey writes: > On Tue, 03 Sep 2013 15:02:50 +, Michael Schubert wrote: > ... >> > happen to have the HEAD *commit* as their tip. >> >> Yes, it picks the first of those: >> >> http://thread.gmane.org/gmane.comp.version-control.git/168144 > > Thanks for the pointer. > > And pity, the

Re: contrib/credential/netrc/git-credential-netrc: Use of uninitialized value in string

On Tue, 27 Aug 2013 16:05:51 -0400 Jeff King wrote: JK> On Mon, Aug 26, 2013 at 08:56:23PM -0700, Junio C Hamano wrote: >> Antoine Pelisse writes: >> >> > I've tried to use the netrc credential with git-send-email >> > (v1.8.4-rc2), and I've had the following log (running with -d -v): >> >> P

Re: netrc credential helper promotion out of contrib?

On Tue, 20 Aug 2013 12:28:39 -0700 Junio C Hamano wrote: JCH> Ted Zlatanov writes: >> A while has passed since contrib/credential/netrc was added. Is it OK to >> promote it to be part of the main installation? JCH> I gave it a quick glance, and it seems to be cleanly written, except JCH> that

Re: [PATCH v2] Document pack v4 format

On Tue, Sep 3, 2013 at 6:49 PM, Duy Nguyen wrote: > On Tue, Sep 3, 2013 at 1:46 PM, Nicolas Pitre wrote: >> So... looks like pack v4 is now "functional". >> >> However something is still wrong as it operates about 6 times slower >> than pack v3. >> >> Anyone wishes to investigate? > > You recurse

Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote: > On Tue, Sep 3, 2013 at 6:10 AM, SZEDER Gábor wrote: > > On Tue, Sep 03, 2013 at 05:45:06AM -0500, Felipe Contreras wrote: > >> On Tue, Sep 3, 2013 at 3:03 AM, Jeff King wrote: > >> > On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZED

Re: Remote's 'currently active branch' not HEAD?

On Tue, 03 Sep 2013 15:02:50 +, Michael Schubert wrote: ... > > happen to have the HEAD *commit* as their tip. > > Yes, it picks the first of those: > > http://thread.gmane.org/gmane.comp.version-control.git/168144 Thanks for the pointer. And pity, the patches didn't make it that time eithe

Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Tue, Sep 3, 2013 at 6:10 AM, SZEDER Gábor wrote: > On Tue, Sep 03, 2013 at 05:45:06AM -0500, Felipe Contreras wrote: >> On Tue, Sep 3, 2013 at 3:03 AM, Jeff King wrote: >> > On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote: >> > >> >> > I wonder if we should have a: >> >> > >> >> >

Re: Remote's 'currently active branch' not HEAD?

On Tue, Sep 03, 2013 at 02:37:33PM +0200, Andreas Krey wrote: > On Tue, 03 Sep 2013 13:48:31 +, Andreas Krey wrote: > ... > > I now have a sample repo that reproduces this behaviour. > > Unpack tar file, clone, see clone having 'wrong' branch > > checked out, apparently independent of the trans

Re: Remote's 'currently active branch' not HEAD?

On Tue, 03 Sep 2013 13:48:31 +, Andreas Krey wrote: ... > I now have a sample repo that reproduces this behaviour. > Unpack tar file, clone, see clone having 'wrong' branch > checked out, apparently independent of the transport: Ouch, it looks like 'git clone' doesn't actually know the 'curren

Re: [PATCH v3 8/8] update-ref: add test cases covering --stdin signature

On 09/03/2013 04:16 AM, Eric Sunshine wrote: > When you decomposed the monolithic test from v1 into individual tests, > you dropped a couple cases ("fatal: unknown option'" and "fatal: > unterminated single-quote"). Was this intentional? Yes. The v3 patch 7 changed the set of error messages to be

Re: [PATCH v2 6/8] refs: add update_refs for multiple simultaneous updates

On 09/03/2013 12:43 AM, Michael Haggerty wrote: > Hmmm, I see that you changed the signature of update_refs() to take an > array of pointers. My suggestion was unclear, but I didn't mean that > the function signature had to be changed. [snip] > However, your approach is also fine. Okay. Thanks f

[PATCH v3] Teach git to change to a given directory using -C option

On Tue, Sep 3, 2013 at 3:42 PM, Eric Sunshine wrote: > No wish to bike-shed, however, I find "effective directory" somewhat > difficult to digest due to its jargony feel. It also seems ambiguous > (to me) since "previous effective directory" may mean "directory when > git was run" or "directory se

Re: [PATCH] {fetch,receive}-pack: drop unpack-objects, delay loosing objects until the end

On Tue, Sep 3, 2013 at 1:49 PM, Jeff King wrote: >> - by going through index-pack first, then unpack, we pay extra cost >>for completing a thin pack into a full one. But compared to fetch's >>total time, it should not be noticeable because unpack-objects is >>only called when the pack

Re: [PATCH v2] Document pack v4 format

On Tue, Sep 3, 2013 at 1:46 PM, Nicolas Pitre wrote: > So... looks like pack v4 is now "functional". > > However something is still wrong as it operates about 6 times slower > than pack v3. > > Anyone wishes to investigate? You recurse in decode_entries too deep.I check the first 1 decode_ent

Re: Remote's 'currently active branch' not HEAD?

On Tue, 03 Sep 2013 12:46:52 +, Andreas Krey wrote: ... > I have a strange behaviour from a bare repo I inherited; > when I clone from that one (ssh) the branch checked out > is *not* the one referenced in HEAD in the remote repo, I now have a sample repo that reproduces this behaviour. Unpack

Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Tue, Sep 03, 2013 at 05:45:06AM -0500, Felipe Contreras wrote: > On Tue, Sep 3, 2013 at 3:03 AM, Jeff King wrote: > > On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote: > > > >> > I wonder if we should have a: > >> > > >> > test_cmp_args () { > >> > echo "$1" >expect && >

Remote's 'currently active branch' not HEAD?

Hi everyone, I have a strange behaviour from a bare repo I inherited; when I clone from that one (ssh) the branch checked out is *not* the one referenced in HEAD in the remote repo, but apparently some variation of the alphabetically first or temporally last, or the last *new* branch pushed. Wher

Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Tue, Sep 3, 2013 at 3:03 AM, Jeff King wrote: > On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote: > >> > I wonder if we should have a: >> > >> > test_cmp_args () { >> > echo "$1" >expect && >> > echo "$1" >actual && >> > test_cmp expect actual >> >

Loan At 2% Interest Rate

Are you in need of a financial assistant or you have been denied by Banks or Financial firms of a loan.Contact E-mail: alliancewestfinanc...@wildblue.net -- 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

Re: [PATCH v3 07/11] Documentation/replace: tell that -f option bypasses the type check

On Mon, Sep 2, 2013 at 11:50 PM, Philip Oakley wrote: > > From: "Christian Couder" > >> You mean something like the following: >> >> $ cat ./graft2replace.sh >> #!/bin/bash >> >> while read orig parents >> do >>printf "%s" "git cat-file commit $orig" >>printf "%s" " | perl -n -e

Re: [PATCH] git send-email: include [anything]-by: signatures

On Tue, Sep 03, 2013 at 02:35:35AM -0400, Jeff King wrote: > On Sat, Aug 31, 2013 at 10:22:50PM +0300, Michael S. Tsirkin wrote: > > > On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael S. Tsirkin wrote: > > > Consider [anything]-by: a valid signature. > > > This includes Tested-by: Acked-by: Revie

  1   2   >