Re: [PATCH v5 1/2] cache.h: eliminate SHA-1 deprecation warnings on Mac OS X

On Wed, May 15, 2013 at 1:56 PM, Torsten Bögershausen wrote: > On 2013-05-15 09.11, David Aguilar wrote: >> + ifndef NO_APPLE_COMMON_CRYPTO >> + APPLE_COMMON_CRYPTO = YesPlease >> + endif >> NO_REGEX = YesPlease >> PTHREAD_LIBS = >> endif >> @@ -1389,10 +1396,16 @@

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

On Fri, May 17, 2013 at 1:04 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> This is what Linux's checkpatch throws: > > Perhaps it's time to include checkpatch.pl in our tree and update our > CodingGuidelines? checkpatch only works with a Linux tree, and it doesn't treat this alignm

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

Felipe Contreras wrote: > This is what Linux's checkpatch throws: Perhaps it's time to include checkpatch.pl in our tree and update our CodingGuidelines? -- 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

Wollen Sie eine stilvolle Tasche es?

Für Mulberry Taschen Outlet Geldbörsen verschiedenen Dimensionen gewählt werden müssen, Frauen finden immer man ihre Individualität und zusätzlich Gemütszustand passen. Sollten Sie nur entscheiden möchten Ihre Beauty-Produkte, Ihr Handy oder möglicherweise

Re: [PATCH 2/6] test-lib: refactor $GIT_SKIP_TESTS matching

Am 5/16/2013 22:50, schrieb Thomas Rast: > +match_pattern_list () { > + arg="$1" > + shift > + test -z "$*" && return 1 > + for pat in $@ You should have double-quotes around $@ here, but then you can just as well abbreviate to for pat and you don't need the 'test -z "$*'

Re: Random thoughts on "upstream"

On Thu, May 16, 2013 at 8:59 PM, Felipe Contreras wrote: > On Thu, May 16, 2013 at 8:31 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Felipe Contreras writes: >>> What happens if I want to push to 'refs/heads/topics/frotz-for-juno'? >>> >>> You would weigh pros-and-cons of sup

Re: Random thoughts on "upstream"

On Thu, May 16, 2013 at 8:31 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Felipe Contreras writes: >> >>> What happens if I want to push to 'refs/heads/topics/frotz-for-juno'? >> >> You would weigh pros-and-cons of supporting such a "single branch >> only" special case, and add a bran

Re: Random thoughts on "upstream"

Junio C Hamano writes: > Felipe Contreras writes: > >> What happens if I want to push to 'refs/heads/topics/frotz-for-juno'? > > You would weigh pros-and-cons of supporting such a "single branch > only" special case, and add a branch level override, and if the > benefit outweighs the cost of com

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

On Thu, May 16, 2013 at 6:54 PM, Felipe Contreras wrote: > There are 535 instances where parenthesis are not aligned. Do you > still think aligning open parenthesis is the "style of the project"? > > Please. You are rejecting this patch on a whim, and nothing more. And FTR. I shouldn't need to w

Re: [RFC] New kind of upstream branch: base branch

On Thu, May 16, 2013 at 2:35 PM, Philip Oakley wrote: > From: "Felipe Contreras" > Sent: Thursday, May 16, 2013 4:46 AM > >> On Wed, May 15, 2013 at 5:22 PM, Philip Oakley >> wrote: >> >>> Sound a reasonable idea. On some patches I was working on I had to [chose >>> to] add a tag for the base wh

Re: [PATCH 1/3] fetch: add --allow-local option

On Thu, May 16, 2013 at 6:24 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote: >>> Felipe Contreras writes: >>> > If you come from "git pull" is "git fetch" + "git merge", > and if your current branch is integrating with you

Re: Random thoughts on "upstream"

On Thu, May 16, 2013 at 6:17 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano wrote: >> >>> The value "upstream" for push.default does not make sense in the >>> context of a triangular workflow, as you may well base your work on >>> 'mast

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

On Thu, May 16, 2013 at 1:34 PM, Ramkumar Ramachandra wrote: > Junio C Hamano wrote: >> (defun linux-style () >> "C mode with adjusted defaults for use with the Linux kernel." >> (interactive) >> (c-set-style "K&R") > > There's actually a "linux" style you can inherit from. >

Re: Please pull one more gitk commit

Paul Mackerras writes: > If there is still time to get stuff in for 1.8.3, please pull my > gitk repository from the usual place to get the update to the > Swedish translations that I just received from Peter Krefting. Thanks, will do as the first thing in tomorrow's integration cycle. -- To uns

Re: [PATCH] Documentation/merge-options.txt: restore `-e` option

Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/8] remote-bzr: reorganize the way 'wanted' works

Felipe Contreras writes: >> I'll stop at 6/8 for now, as this is not urgent before the 1.8.3 >> release. > > I can send the conflict fix, or I can send a v2 of the 47-something > patches. I already have a few fixes on top that might make sense to > squash. Up to you. Probably neither at this poi

Please pull one more gitk commit

Junio, If there is still time to get stuff in for 1.8.3, please pull my gitk repository from the usual place to get the update to the Swedish translations that I just received from Peter Krefting. Thanks, Paul. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a mes

Re: [PATCH] gitk: Update Swedish translation (304t)

On Thu, May 16, 2013 at 08:16:30AM +0100, Peter Krefting wrote: > The patch is attached gzipped to avoid character encoding issues. Thanks, applied. Paul. -- 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 1/3] fetch: add --allow-local option

Felipe Contreras writes: > On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> If you come from "git pull" is "git fetch" + "git merge", and if your current branch is integrating with your local branch, >>> >>> How many times do I have to say that 'gi

Re: Random thoughts on "upstream"

Felipe Contreras writes: > On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano wrote: > >> The value "upstream" for push.default does not make sense in the >> context of a triangular workflow, as you may well base your work on >> 'master' from the upstream, which is a branch with a very generic >>

Re: [PATCH] Revert "remote-hg: update bookmarks when pulling"

Felipe Contreras writes: > On Thu, May 16, 2013 at 1:16 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Felipe Contreras writes: >>> This reverts commit 24317ef32ac3111ed00792f9b2921dc19dd28fe2. Different versions of Mercurial have different arguments for bookmar

[PATCH] Documentation/merge-options.txt: restore `-e` option

It looks like commit f8246281af9adb0fdddbcc90d2e19cb5cd5217e5 unintentionally removed the documentation for the `-e` option. Signed-off-by: Richard Hansen --- Documentation/merge-options.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/merge-options.txt b/D

Re: [PATCH 7/8] remote-bzr: reorganize the way 'wanted' works

On Thu, May 16, 2013 at 1:35 PM, Junio C Hamano wrote: > The series fails to apply (on top of the hotfix for 1.8.3 you sent > earlier today) at this point. It wants to remove the code added by > the hotfix but I do not see a corresponding check for listable, > which may make sense, as the log mes

Re: [PATCH 1/3] fetch: add --allow-local option

On Thu, May 16, 2013 at 1:04 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >>> If you come from "git pull" is "git fetch" + "git merge", >>> and if your current branch is integrating with your local branch, >> >> How many times do I have to say that 'git pull' is not 'git fetch' + >> 'gi

Re: [PATCH] Revert "remote-hg: update bookmarks when pulling"

On Thu, May 16, 2013 at 1:16 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Felipe Contreras writes: >> >>> This reverts commit 24317ef32ac3111ed00792f9b2921dc19dd28fe2. >>> >>> Different versions of Mercurial have different arguments for >>> bookmarks.updatefromremote(), while it shoul

Re: Random thoughts on "upstream"

On Thu, May 16, 2013 at 12:55 PM, Junio C Hamano wrote: > The value "upstream" for push.default does not make sense in the > context of a triangular workflow, as you may well base your work on > 'master' from the upstream, which is a branch with a very generic > purpose (e.g. "to advance the stat

Re: [PATCH] Revert "remote-hg: update bookmarks when pulling"

Felipe Contreras writes: > This reverts commit 24317ef32ac3111ed00792f9b2921dc19dd28fe2. > > Different versions of Mercurial have different arguments for > bookmarks.updatefromremote(), while it should be possible to call the > right function with the right arguments depending on the version, it'

Re: [PATCH 5/6] test-lib: allow prefixing a custom string before "ok N" etc.

On Thu, May 16, 2013 at 4:50 PM, Thomas Rast wrote: > This is not really meant for external use, but allows the next commit > to neatly distinguish between sub-tests and the main run. Maybe we do not care about standards for this library or for your use-case, but placing this prefix before the "{

Re: [PATCH 1/6] test-lib: enable MALLOC_* for the actual tests

Thomas Rast writes: > 1b3185f (MALLOC_CHECK: various clean-ups, 2012-09-14) moved around the > MALLOC_CHECK_ and MALLOC_PERTURB_ assignments, intending to limit > their effect to only the test runs. However, they were actually > enabled only during test cleanup. Call setup/teardown_malloc_check

Re: [PATCH 1/6] test-lib: enable MALLOC_* for the actual tests

2013/5/16 Thomas Rast : > 1b3185f (MALLOC_CHECK: various clean-ups, 2012-09-14) moved around the > MALLOC_CHECK_ and MALLOC_PERTURB_ assignments, intending to limit > their effect to only the test runs. However, they were actually > enabled only during test cleanup. Call setup/teardown_malloc_che

[RFC PATCH 6/6] test-lib: support running tests under valgrind in parallel

With the new --valgrind-parallel= option, we support running the tests in a single test script under valgrind in parallel using 'n' processes. This really follows the dumbest approach possible, as follows: * We spawn the test script 'n' times, using a throw-away TEST_OUTPUT_DIRECTORY. Each of

[PATCH 5/6] test-lib: allow prefixing a custom string before "ok N" etc.

This is not really meant for external use, but allows the next commit to neatly distinguish between sub-tests and the main run. Signed-off-by: Thomas Rast --- t/test-lib.sh | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/t/test-lib.sh b/t/test-li

[PATCH 3/6] test-lib: verbose mode for only tests matching a pattern

With the new --verbose-only= option, one can enable --verbose at a per-test granularity. The pattern is matched against the test number, e.g. ./t-basic.sh --verbose-only='2[0-2]' to see only the full output of test 20-22, while showing the rest in the one-liner format. This is arguably no

[PATCH 4/6] test-lib: valgrind for only tests matching a pattern

With the new --valgrind-only= option, one can enable --valgrind at a per-test granularity, exactly analogous to --verbose-only from the previous commit. The options are wired such that --valgrind implies --verbose (as before), but --valgrind-only= implies --verbose-only= unless --verbose is also i

[PATCH 2/6] test-lib: refactor $GIT_SKIP_TESTS matching

It's already used twice, and we will have more of the same kind of matching in a minute. Signed-off-by: Thomas Rast --- t/test-lib.sh | 41 - 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index 229f5f7..c5a80

[PATCH 1/6] test-lib: enable MALLOC_* for the actual tests

1b3185f (MALLOC_CHECK: various clean-ups, 2012-09-14) moved around the MALLOC_CHECK_ and MALLOC_PERTURB_ assignments, intending to limit their effect to only the test runs. However, they were actually enabled only during test cleanup. Call setup/teardown_malloc_check also around the evaluation of

[PATCH 0/6] --valgrind improvements

Peff and me discussed improving the usability of --valgrind testing. In particular, two ideas that came up were options for running only a subset of the tests in a file under --valgrind, and for running a single test script under valgrind while exploiting parallelism. So here's a little series. I

Re: [PATCH v10 09/14] git-clean: use a git-add-interactive compatible UI

Junio C Hamano writes: > Also please fix this one: > >> +for_each_string_list_item(item, (struct string_list >> *)stuff->stuff) { >> +if ((*chosen)[i] < 0) >> +(*chosen)[i] = 0; >> +strbuf_addf(&menu, "%s%2d: %s", (*

Re: [RFC] New kind of upstream branch: base branch

From: "Felipe Contreras" Sent: Thursday, May 16, 2013 4:46 AM On Wed, May 15, 2013 at 5:22 PM, Philip Oakley wrote: Sound a reasonable idea. On some patches I was working on I had to [chose to] add a tag for the base which made it easier to rebase later. And was the 'upstream' branch some

Re: [PATCH v10 09/14] git-clean: use a git-add-interactive compatible UI

Jiang Xin writes: > +static void print_highlight_menu_stuff(struct menu_stuff *stuff, int > **chosen) > +{ > + struct string_list menu_list = STRING_LIST_INIT_DUP; > + struct strbuf menu = STRBUF_INIT; > + int i; > + > + if (MENU_STUFF_TYPE_MENU_ITEM == stuff->type) { > + ...

Re: [PATCH v10 04/14] Refactor write_name_quoted_relative, remove unused params

Jiang Xin writes: > After substitude path_relative() in quote.c with relative_path() from > path.c, parameters (such as len and prefix_len) are obsolte in function s/obsolte/obsolete/; > write_name_quoted_relative(). Remove unused parameters from > write_name_quoted_relative() and related funct

Re: [PATCHv2] git-submodule.txt: Clarify 'init' and 'add' subcommands.

Am 16.05.2013 00:28, schrieb Dale R. Worley: > Describe how 'add' sets the submodule's logical name, which is used in > the configuration entry names. > > Clarify that 'init' only sets up the configuration entries for > submodules that have already been added elsewhere. Describe that > arguments

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

Junio C Hamano wrote: > (defun linux-style () > "C mode with adjusted defaults for use with the Linux kernel." > (interactive) > (c-set-style "K&R") There's actually a "linux" style you can inherit from. May I suggest looking at Documentation/CodingStyle in linux.git for thi

Re: [PATCH 7/8] remote-bzr: reorganize the way 'wanted' works

The series fails to apply (on top of the hotfix for 1.8.3 you sent earlier today) at this point. It wants to remove the code added by the hotfix but I do not see a corresponding check for listable, which may make sense, as the log message says, when the user specified a list of branches: If t

Re: [PATCH] Revert "remote-hg: update bookmarks when pulling"

Junio C Hamano writes: > Felipe Contreras writes: > >> This reverts commit 24317ef32ac3111ed00792f9b2921dc19dd28fe2. >> >> Different versions of Mercurial have different arguments for >> bookmarks.updatefromremote(), while it should be possible to call the >> right function with the right argume

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

Felipe Contreras writes: > You find it sensible, I don't. And when people disagree, that's what > the guideline is for. If you really need it to be spelled out, I would say it would be something like this: (defun linux-style () "C mode with adjusted defaults for use with the Linux ke

Re: [PATCH 1/3] fetch: add --allow-local option

Felipe Contreras writes: >> If you come from "git pull" is "git fetch" + "git merge", >> and if your current branch is integrating with your local branch, > > How many times do I have to say that 'git pull' is not 'git fetch' + > 'git merge'? > > You must think everybody has 'merge.defaulttoupstr

Random thoughts on "upstream"

I do agree that separating - where to push to, and - where to fetch for integrating with is a necessary step for supporting triangular workflow better. The "upstream" is that on top of which you build your work. You clone from there to bootstrap yourself, you add your work (which may include

Re: Cannot push anything via export transport helper after push fails.

В Sat, 11 May 2013 08:57:14 -0500 Felipe Contreras пишет: > On Sat, May 11, 2013 at 7:29 AM, Andrey Borzenkov wrote: > > I noticed that using git-remote-bzr, but as far as I can tell this is > > generic for all transport helpers using fast-export. > > > > > > > > What happened was "git push" fai

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

On Thu, May 16, 2013 at 11:49 AM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, May 16, 2013 at 11:19 AM, Junio C Hamano wrote: >>> Felipe Contreras writes: >>> I find it extremely annoying that an obviously correct patch is not merged... >>> >>> A patch that receives

Re: [PATCH 1/3] fetch: add --allow-local option

On Thu, May 16, 2013 at 11:38 AM, Junio C Hamano wrote: > Felipe Contreras writes: > >> That doesn't change the fact that 'git fetch .' does not make any >> sense whatsoever. The user *will* get confused when (s)he does 'git >> fetch' and nothing happens. The problem is not solved. >> >> % git ch

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

Felipe Contreras writes: > On Thu, May 16, 2013 at 11:19 AM, Junio C Hamano wrote: >> Felipe Contreras writes: >> >>> I find it extremely annoying that an obviously correct patch is not >>> merged... >> >> A patch that receives "this breaks style" comments > > *Invalid* "this breaks style" comm

Re: [PATCH] Revert "remote-hg: update bookmarks when pulling"

Felipe Contreras writes: > This reverts commit 24317ef32ac3111ed00792f9b2921dc19dd28fe2. > > Different versions of Mercurial have different arguments for > bookmarks.updatefromremote(), while it should be possible to call the > right function with the right arguments depending on the version, it'

Re: [PATCH 1/3] fetch: add --allow-local option

Felipe Contreras writes: > That doesn't change the fact that 'git fetch .' does not make any > sense whatsoever. The user *will* get confused when (s)he does 'git > fetch' and nothing happens. The problem is not solved. > > % git checkout -b fixes master > % git fetch > % git branch -u master > %

Re: [PATCH] branch: add show-tracking option

Felipe Contreras writes: > On Thu, May 16, 2013 at 11:17 AM, Junio C Hamano wrote: > >> *1* indented because this is dependent of @{u}; showing ahead/behind >> without showing @{u} would not make any sense. > > That's what 'git branch -v' does. OK, perhaps people know (or do not have to kno

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

On Thu, May 16, 2013 at 11:19 AM, Junio C Hamano wrote: > Felipe Contreras writes: > >> I find it extremely annoying that an obviously correct patch is not >> merged... > > A patch that receives "this breaks style" comments *Invalid* "this breaks style" comments, because it doesn't break any sty

Re: [PATCH] branch: add show-tracking option

Felipe Contreras writes: > On Thu, May 16, 2013 at 11:17 AM, Junio C Hamano wrote: > >> *1* indented because this is dependent of @{u}; showing ahead/behind >> without showing @{u} would not make any sense. > > That's what 'git branch -v' does. Yes. I thought you wanted "just @{u} without

Re: [PATCH] remote-bzr: fix cloning of non-listable repos

Felipe Contreras writes: > Commit 95b0c60 (remote-bzr: add support for bzr repos) introduced a > regression by assuming all bzr remote repos are listable, but they are > not. > > If they are not listable they are basically useless, so let's assume > there is no bzr repo. > > Reported-by: Thorsten

Re: [PATCH] branch: add show-tracking option

On Thu, May 16, 2013 at 11:17 AM, Junio C Hamano wrote: > *1* indented because this is dependent of @{u}; showing ahead/behind > without showing @{u} would not make any sense. That's what 'git branch -v' does. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 1/3] fetch: add --allow-local option

On Thu, May 16, 2013 at 10:58 AM, Junio C Hamano wrote: > I _think_ the real reason you want a "git fetch" while on "mywork" > to go to 'origin' is because you are building your "master" off of > somebody else's work that comes from 'origin', and you want to check > what has changed to see what y

Re: [PATCH 3/4] {fast-export,transport-helper}: style cleanups

Felipe Contreras writes: > I find it extremely annoying that an obviously correct patch is not > merged... A patch that receives "this breaks style" comments and its author stubbornly refusing to fix what others pointed out, especially when the patch itself _is_ about style, cannot be "an obviou

Re: [PATCH] branch: add show-tracking option

Duy Nguyen writes: > On Thu, May 16, 2013 at 3:40 PM, Michael J Gruber > wrote: >>> What if I want something in - except some in -vv? I think to avoid >>> option explosion, maybe we can adopt --pretty=format:xxx from "git >>> log" and let the user decideswhat (and how) to display. "pretty" c

[PATCH v4 02/15] t6019: test file dropped in -s ours merge

In preparation for upcoming TREESAME work, check the result for G.t, which is dropped in "-s ours" merge L. The default rev-list is empty, as expected - it follows the first parent path where it never existed. Unfortunately, --ancestry-path is also empty. Merges H J and L are all TREESAME to 1 par

Re: [PATCH 1/3] fetch: add --allow-local option

Felipe Contreras writes: > So that it becomes possible to override the behavior when the remote > tracked is '.'; if it is, we default back to 'origin'. I know I was the stupid one who originally suggested this, but I think this is a wrong direction to go. I do not think it solves your "I do no

[PATCH v4 05/15] t6111: add parents to tests

Signed-off-by: Kevin Bracey --- t/t6111-rev-list-treesame.sh | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/t/t6111-rev-list-treesame.sh b/t/t6111-rev-list-treesame.sh index 1e4a550..4d74d3c 100755 --- a/t/t6111-rev-list-treesame.sh ++

[PATCH v4 00/15] History traversal refinements

No new functionality or bug fixes since v3, just tidying: * Tests now use Junio's parent-checking functionality * BOTTOM flags now set in a neater fashion (I think), separating it out from the cmdline stuff. * Creation and use of BOTTOM flag now split into 4 separate commits - last version was

[PATCH v4 04/15] t6111: allow checking the parents as well

From: Junio C Hamano Signed-off-by: Junio C Hamano --- t/t6111-rev-list-treesame.sh | 30 +- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/t/t6111-rev-list-treesame.sh b/t/t6111-rev-list-treesame.sh index b2bca77..1e4a550 100755 --- a/t/t6111-rev-lis

[PATCH v4 07/15] Documentation: avoid "uninteresting"

The documentation of --boundary uses the term "uninteresting", which is not used or defined anywhere else in the documentation. This is unhelpful and confusing to anyone who hasn't seen the UNINTERESTING flag in the source code. Change to use "excluded", as per revisions.txt. Signed-off-by: Kevin

[PATCH v4 06/15] rev-list-options.txt: correct TREESAME for P

In the example given, P is not TREESAME to E. This doesn't affect the current result, but it will matter when we change behaviour. Signed-off-by: Kevin Bracey --- Documentation/rev-list-options.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/rev-list-optio

[PATCH v4 10/15] simplify-merges: never remove all TREESAME parents

When simplifying an odd merge, such as one that used "-s ours", we may find ourselves TREESAME to apparently redundant parents. Prevent simplify_merges() from removing every TREESAME parent; if this would happen reinstate the first TREESAME parent - the one that the default log would have followed.

[PATCH v4 13/15] revision.c: discount side branches when computing TREESAME

Use the BOTTOM flag to define relevance for pruning. Relevant commits are those that are !UNINTERESTING or BOTTOM, and this allows us to identify irrelevant side branches (UNINTERESTING && !BOTTOM). If a merge has relevant parents, and it is TREESAME to them, then do not let irrelevant parents cau

[PATCH v4 15/15] revision.c: make default history consider bottom commits

Previously, the default history treated bottom commits the same as any other UNINTERESTING commit, which could force it down side branches. Consider the following history: *A--*B---D--*F * marks !TREESAME parent paths \ /* `-C-' When requesting "B..F", B is UNINTERESTIN

[PATCH v4 03/15] t6111: new TREESAME test set

Some side branching and odd merging to illustrate various flaws in revision list scans, particularly when limiting the list. Many expected failures, which will be gone by the end of the "history traversal refinements" series. Signed-off-by: Kevin Bracey --- t/t6111-rev-list-treesame.sh | 184 ++

[PATCH v4 14/15] revision.c: don't show all merges for --parents

When using --parents or --children, get_commit_action() previously showed all merges, even if TREESAME to both parents. This was intended to tie together the topology of the rewritten parents, but it was excessive - in fact we only need to show merges that have two or more relevant parents. Merges

[PATCH v4 12/15] revision.c: add BOTTOM flag for commits

When performing edge-based operations on the revision graph, it can be useful to be able to identify the INTERESTING graph's connection(s) to the bottom commit(s) specified by the user. Conceptually when the user specifies "A..B" (== B ^A), they are asking for the history from A to B. The first co

[PATCH v4 08/15] revision.c: Make --full-history consider more merges

History simplification previously always treated merges as TREESAME if they were TREESAME to any parent. While this was consistent with the default behaviour, this could be extremely unhelpful when searching detailed history, and could not be overridden. For example, if a merge had ignored a chang

[PATCH v4 11/15] simplify-merges: drop merge from irrelevant side branch

Reimplement commit 4b7f53da on top of the new simplify-merges infrastructure, tightening the condition to only consider root parents; the original version incorrectly dropped parents that were TREESAME to anything. Original log message follows. The merge simplification rule stated in 6546b59 (rev

[PATCH v4 09/15] t6012: update test for tweaked full-history traversal

From: Junio C Hamano Signed-off-by: Junio C Hamano --- t/t6012-rev-list-simplify.sh | 29 +++-- 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh index dd6dc84..4e55872 100755 --- a/t/t6012-rev-list

[PATCH v4 01/15] decorate.c: compact table when growing

When growing the table, take the opportunity to "compact" it by removing entries with NULL decoration. Users may have "removed" decorations by passing NULL to insert_decoration. An object's table entry can't actually be removed during normal operation, as it would break the linear hash collision s

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

Junio C Hamano writes: > Felipe Contreras writes: > >> It doesn't make sense to push to the upstream branch, so create new >> configurations for the notion of 'downstream' branch, which is basically >> the branch to push to by default. > > It doesn't? That depends. > > To people coming from (an

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

On Thu, May 16, 2013 at 8:52 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> Does branch..merge overrides remote..fetch? No. They >> complement each other. > > I often wonder if you are reading what you're responding to: And I wonder if you care if what you say is actually true. > r

Re: [RFC/PATCH] branch: show me the hot branches

Duy Nguyen wrote: > I tried a more generic approach a while ago. > > http://thread.gmane.org/gmane.comp.version-control.git/188705 Looks good. Why didn't you polish it for inclusion? It's a very useful feature in my opinion: the default git branch output is quite horrible. I want to make sort,

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

Felipe Contreras wrote: > Does branch..merge overrides remote..fetch? No. They > complement each other. I often wonder if you are reading what you're responding to: remote..fetch is operated on by fetch, while branch..merge is operated on by merge; they are really orthogonal. > The same that 'gi

Re: [PATCH] color: set color.ui to auto by default

Matthieu Moy wrote: > Err, you're comming a bit late ;-). See my patch, posted yesterday, for > the same topic. Ah, too much email :| Your patch looks good. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info

Re: [RFC/PATCH 2/3] pull: trivial cleanups

On Thu, May 16, 2013 at 6:54 AM, Antoine Pelisse wrote: > On Thu, May 16, 2013 at 11:36 AM, Felipe Contreras > wrote: >> Actually trying that command: >> >> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*' >> fatal: Refusing to fetch into current branch >> refs/heads/fc/fa

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

On Thu, May 16, 2013 at 6:31 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> Would I be able to do: >> >> % git branch --set-upstream-to origin/master --set-downstream-to >> github/fc/master >> >> ? >> >> Would I see these branches when I do 'git branch -vv'? >> Would I be able to do

Re: [PATCH] color: set color.ui to auto by default

Ramkumar Ramachandra writes: > This is a good default. Users who don't want color can look for "color" > in the git-config(1), and turn it off. Err, you're comming a bit late ;-). See my patch, posted yesterday, for the same topic. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubs

Re: Segmentation fault with latest git (070c57df)

Ramkumar Ramachandra wrote: > sam wrote: >> gdb /usr/bin/git core > > What exactly are you doing? Is core aliased to something? Sorry about that. I just realized you're loading a core dump. Please tell us how to reproduce this, or give us the backtrace with debugging symbols. -- To unsubscribe

Re: Segmentation fault with latest git (070c57df)

sam wrote: > gdb /usr/bin/git core What exactly are you doing? Is core aliased to something? > [...] > Core was generated by `git apply --verbose --check --ignore-whitespace > --directory=/home/sam/P'. What is this? Can you give us clear instructions on how to reproduce the segfault? -- To uns

[PATCH] color: set color.ui to auto by default

This is a good default. Users who don't want color can look for "color" in the git-config(1), and turn it off. Signed-off-by: Ramkumar Ramachandra --- color.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/color.c b/color.c index e8e2681..f672885 100644 --- a/color.c +++ b/

Re: [PATCH 1/3] fetch: add --allow-local option

On Thu, May 16, 2013 at 5:32 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> Answer: because 'git fetch .' doesn't make any sense. So if >> 'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'. > > I agree that 'git fetch .' is currently not useful (and I am not > aga

[PATCH] Revert "remote-hg: update bookmarks when pulling"

This reverts commit 24317ef32ac3111ed00792f9b2921dc19dd28fe2. Different versions of Mercurial have different arguments for bookmarks.updatefromremote(), while it should be possible to call the right function with the right arguments depending on the version, it's safer to restore the old behavior

Re: [PATCHv2 04/10] remote: Reject remote names containing '/'

Johan Herland wrote: > FWIW, I've abandoned this patch, and don't care much about multi-level > remote names anymore. They work in current git, and they will sort-of > work with remote ref namespaces as well, although you will have to use > full refnames when referring to their remote-tracking refs

Re: [PATCH 1/3] prompt: introduce GIT_PS1_STATESEPARATOR

Junio C Hamano wrote: > It is simpler to use 'default values', no? > > local z=${GIT_PS1_STATESEPARATOR-" "} There don't seem to be any more comments. If there are no issues, could you fix this up locally before queueing? Thanks. -- To unsubscribe from this list: send the line "unsubscri

Re: [RFC/PATCH 2/3] pull: trivial cleanups

On Thu, May 16, 2013 at 11:36 AM, Felipe Contreras wrote: > Actually trying that command: > > % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*' > fatal: Refusing to fetch into current branch > refs/heads/fc/fast-export/cleanup of non-bare repository > fatal: The remote end h

Re: [RFC/PATCH 3/3] push: add separate 'downstream' branch

Felipe Contreras wrote: > Would I be able to do: > > % git branch --set-upstream-to origin/master --set-downstream-to > github/fc/master > > ? > > Would I see these branches when I do 'git branch -vv'? > Would I be able to do 'git push next@{downstream}'? Hm, losing this functionality in the name

Re: [PATCHv2 04/10] remote: Reject remote names containing '/'

On Thu, May 16, 2013 at 11:48 AM, Ramkumar Ramachandra wrote: > Johan Herland wrote: >> The disambiguation can probably be resolved, although the resulting >> code will obviously be somewhat more cumbersome and ugly (and IMHO the >> current code is plenty of that already...). Combine this with the

Re: English/German terminology, git.git's de.po, and pro-git

Dear translators, Here's the main point in this discussion: The translation is not for us! The translation is for those who don't speak much English and who don't know the English git terminology very well. By definition, this target audience is not present here on this mailing list and in this

Re: [PATCH 1/3] fetch: add --allow-local option

Felipe Contreras wrote: > Answer: because 'git fetch .' doesn't make any sense. So if > 'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'. I agree that 'git fetch .' is currently not useful (and I am not against changing its behavior), but my question pertains to why you are re

Re: [PATCH 1/3] fetch: add --allow-local option

On Thu, May 16, 2013 at 4:58 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> Why would I do that? When I do 'git rebase' I want to rebase on top of >> 'master', not 'origin/master' (or whatever the upstream of 'master' >> is). > > Ah, so you want @{u} to point to refs/heads/master, bu

  1   2   >