Re: [PATCH] Unicode: update of combining code points

2014-04-16 Thread Kevin Bracey
On 16/04/2014 07:48, Torsten Bögershausen wrote: On 15.04.14 21:10, Peter Krefting wrote: Torsten Bögershausen: diff --git a/utf8.c b/utf8.c index a831d50..77c28d4 100644 --- a/utf8.c +++ b/utf8.c Is there a script that generates this code from the Unicode database files, or did you

Re: [PATCH] Unicode: update of combining code points

2014-04-17 Thread Kevin Bracey
On 16/04/2014 22:58, Torsten Bögershausen wrote: Excellent, thanks for the pointers. Running the script below shows that 0X00AD SOFT HYPHEN should have zero length (and some others too). I wonder if that is really the case, and which one of the last 2 lines in the script is the right one. What

Re: [PATCH v2] utf8.c: partially update to version 6.3

2014-04-17 Thread Kevin Bracey
On 17/04/2014 14:47, Torsten Bögershausen wrote: ./uniset/uniset +cat=Me +cat=Mn +cat=Cf -00AD +1160-11FF +200B c 200B isn't a special case any more, as its database properties have been changed, so you can slightly simplify this command (both in the commit message and the comments). And

Re: breakage in revision traversal with pathspec

2013-09-10 Thread Kevin Bracey
On 10/09/2013 20:19, Junio C Hamano wrote: I am grumpy X-. It appears that we introduced a large breakage during 1.8.4 cycle to the revision traversal machinery and made pathspec-limited git log pretty much useless. This command $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl reports

Re: breakage in revision traversal with pathspec

2013-09-11 Thread Kevin Bracey
On 11/09/2013 01:23, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: On 10/09/2013 20:19, Junio C Hamano wrote: This command $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl reports that a merge 766f0f8ef7 (which did not touch the specified path at all) touches

Re: breakage in revision traversal with pathspec

2013-09-11 Thread Kevin Bracey
On 11/09/2013 21:24, Jonathan Nieder wrote: Kevin Bracey wrote: On reflection I'm not sure what we should for the simple history view of v1.8.3.1..v1.8.4. We're not rewriting parents, so we don't get a chance to reconsider the merge as being zero-parent, and we do have this little section

Re: [PATCH 2/2] sha1_name: fix error message for @{N}, @{date}

2013-05-21 Thread Kevin Bracey
On 21/05/2013 19:52, Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com writes: The empty string '' looks ugly and inconsistent with the output of branch@{N}. Replace it with the string 'current branch'. Wouldn't that be '*the* current branch'? More importantly, doesn't real_ref

[PATCH] Documentation: Move git diff blob blob

2013-06-18 Thread Kevin Bracey
. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/git-diff.txt | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index a7b4620..78d6d50 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git

[PATCH] am: replace uses of --resolved with --continue

2013-06-26 Thread Kevin Bracey
-by: Kevin Bracey ke...@bracey.fi --- Documentation/git-am.txt | 4 ++-- Documentation/user-manual.txt | 2 +- git-am.sh | 8 t/t7512-status-help.sh| 4 ++-- wt-status.c | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff

[PATCH 2/2] p4merge: create a virtual base if none available

2013-03-06 Thread Kevin Bracey
a suggestion given in the original patch's discussion: generate a virtual base, consisting of the lines common to the two branches. It produces a much nicer 3-way diff view than either of the original forms, and than I suspect other mergetools are managing. Signed-off-by: Kevin Bracey ke

[PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool

2013-03-06 Thread Kevin Bracey
-to-front. Note that P4Merge now shows ours on the right for both diff and merge, unlike other diff/mergetools, which always have REMOTE on the right. But observe that REMOTE is the working tree (ie ours) for a diff, while it's another branch (ie theirs) for a merge. Signed-off-by: Kevin Bracey ke

[PATCH 0/2] Improve P4Merge mergetool invocation

2013-03-06 Thread Kevin Bracey
may have made some blunder there. Kevin Bracey (2): p4merge: swap LOCAL and REMOTE for mergetool p4merge: create a virtual base if none available git-mergetool--lib.sh | 14 ++ mergetools/p4merge| 4 ++-- 2 files changed, 16 insertions(+), 2 deletions(-) -- 1.8.2.rc2.5

Re: [PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool

2013-03-06 Thread Kevin Bracey
On 07/03/2013 02:36, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that the incoming branch is now in the left-hand, blue triangle pane, and the current branch is in the right-hand, green circle pane. Given

Re: [PATCH 2/2] p4merge: create a virtual base if none available

2013-03-07 Thread Kevin Bracey
On 07/03/2013 04:23, David Aguilar wrote: On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey ke...@bracey.fi wrote: +make_virtual_base() { + # Copied from git-merge-one-file.sh. I think the reasoning behind these patches is good. How do we feel about this duplication? Bad. Should

Re: [PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool

2013-03-07 Thread Kevin Bracey
On 07/03/2013 09:23, Junio C Hamano wrote: If p4merge GUI labels one side clearly as theirs and the other ours, and the way we feed the inputs to it makes the side that is actually ours appear in p4merge GUI labelled as theirs, then I do not think backward compatibility argument does not hold

[PATCH v2 1/3] mergetools/p4merge: swap LOCAL and REMOTE

2013-03-09 Thread Kevin Bracey
, or common to both) are in green. If Perforce had rebase, they'd probably not swap ours/theirs, but make P4Merge show common changes in blue, picking out our changes in green. We can't do that, so this is next best. Signed-off-by: Kevin Bracey ke...@bracey.fi --- mergetools/p4merge | 2 +- 1 file changed

[PATCH v2 3/3] git-merge-one-file: revise merge error reporting

2013-03-09 Thread Kevin Bracey
this flaw. Signed-off-by: Kevin Bracey ke...@bracey.fi --- git-merge-one-file.sh | 20 +++- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh index 1236fbf..70f36f1 100755 --- a/git-merge-one-file.sh +++ b/git-merge-one-file.sh

[PATCH v2 0/3] Improve P4Merge mergetool invocation

2013-03-09 Thread Kevin Bracey
, and I failed to come up with anything remotely elegant. Kevin Bracey (3): mergetools/p4merge: swap LOCAL and REMOTE mergetools/p4merge: create a base if none available git-merge-one-file: revise merge error reporting git-merge-one-file.sh | 38 -- git-sh

[PATCH v2 2/3] mergetools/p4merge: create a base if none available

2013-03-09 Thread Kevin Bracey
that if there are no differences at the same location, this technique can lead to automatic resolution without conflict, combining everything from the 2 files. As with the other merges using this technique, we assume the user will inspect the result before saving. Signed-off-by: Kevin Bracey ke...@bracey.fi --- git

[PATCH] Translate git_more_info_string consistently

2013-03-10 Thread Kevin Bracey
git help translated the See 'git help command' for more information... message, but git didn't. Signed-off-by: Kevin Bracey ke...@bracey.fi --- git.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git.c b/git.c index d33f9b3..e484644 100644 --- a/git.c +++ b/git.c @@ -536,7

[PATCH/RFC] Make help behaviour more consistent

2013-03-10 Thread Kevin Bracey
-ordered to match the manual page, and git and git-help manual pages edited to reflect the new help behaviour. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/git-help.txt | 22 +- Documentation/git.txt | 17 - builtin/help.c | 9

[PATCH] git.c: make usage match manual page

2013-03-11 Thread Kevin Bracey
Re-ordered option list in command-line usage to match the manual page. Also makes it less than 80-characters wide. Signed-off-by: Kevin Bracey ke...@bracey.fi --- git.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git.c b/git.c index d33f9b3..2a98624 100644 --- a/git.c

Re: [PATCH] git.c: make usage match manual page

2013-03-11 Thread Kevin Bracey
On 11/03/2013 21:58, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: Re-ordered option list in command-line usage to match the manual page. Also makes it less than 80-characters wide. Thanks (s/Re-ordered/reorder/ and s/makes/make/, though). Got it. But I'm going to reword

[PATCH] git.c: rearrange git synopsis to fit in 80 columns

2013-03-11 Thread Kevin Bracey
Make the command line use the narrower synopsis layout that the man page has used since commit 68e4b55. Signed-off-by: Kevin Bracey ke...@bracey.fi --- git.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git.c b/git.c index d33f9b3..2a98624 100644 --- a/git.c +++ b

Re: [PATCH/RFC] Make help behaviour more consistent

2013-03-11 Thread Kevin Bracey
On 11/03/2013 05:03, Junio C Hamano wrote: Hmm, I feel more confused than convinced after reading the above three times. Perhaps that is because I am too used to the way how git potty itself behaves, especially the part that git help git is the way to ask git (the first token on the command

[PATCH v3 2/3] mergetools/p4merge: create a base if none available

2013-03-12 Thread Kevin Bracey
that if there are no differences at the same location, this technique can lead to automatic resolution without conflict, combining everything from the 2 files. As with the other merges using this technique, we assume the user will inspect the result before saving. Signed-off-by: Kevin Bracey ke...@bracey.fi

[PATCH v3 3/3] git-merge-one-file: revise merge error reporting

2013-03-12 Thread Kevin Bracey
this flaw. Signed-off-by: Kevin Bracey ke...@bracey.fi --- git-merge-one-file.sh | 20 +++- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh index 0f164e5..78b07a8 100755 --- a/git-merge-one-file.sh +++ b/git-merge-one-file.sh

[PATCH v3 1/3] mergetools/p4merge: swap LOCAL and REMOTE

2013-03-12 Thread Kevin Bracey
, or common to both) are in green. If Perforce had rebase, they'd probably not swap ours/theirs, but make P4Merge show common changes in blue, picking out our changes in green. We can't do that, so this is next best. Signed-off-by: Kevin Bracey ke...@bracey.fi --- mergetools/p4merge | 2 +- 1 file changed

Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting

2013-03-14 Thread Kevin Bracey
On 13/03/2013 19:57, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: - echo Added $4 in both, but differently. + echo ERROR: Added $4 in both, but differently. + ret=1 The problem you identified may be worth fixing, but I do not think

Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting

2013-03-14 Thread Kevin Bracey
On 14/03/2013 16:56, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: Maybe the virtual base itself should be different. Maybe it should put a ??? marker in place of every unique line. So you get: Left ABCEFGH Right XABCDEFJH - Merge result |XABC|DEFG|JH VBase ?ABC?EF??H

Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting

2013-03-14 Thread Kevin Bracey
On 14/03/2013 19:31, Kevin Bracey wrote: On 14/03/2013 16:56, Junio C Hamano wrote: Well, yes, but I would assume that we would forcibly select normal diff here somehow, if we aren't already. We should be - turning ABCDEFGH vs ABCD into ABCDEFGH|EFGH= is silly. Doh. But anyway, we don't

[PATCH v2 0/3] git-merge-one-file error reporting

2013-03-24 Thread Kevin Bracey
Style clean up, as requested, followed by the fix to the both sides added handling for git-merge-one-file. This is based on v4 of my p4merge series, as they touch the same area. Kevin Bracey (3): git-merge-one-file: style cleanup git-merge-one-file: send ERROR: messages to stderr git-merge

[PATCH v4 1/2] mergetools/p4merge: swap LOCAL and REMOTE

2013-03-24 Thread Kevin Bracey
, or common to both) are in green. If Perforce had rebase, they'd probably not swap ours/theirs, but make P4Merge show common changes in blue, picking out our changes in green. We can't do that, so this is next best. Signed-off-by: Kevin Bracey ke...@bracey.fi Reviewed-by: David Aguilar dav...@gmail.com

[PATCH v2 3/3] git-merge-one-file: revise merge error reporting

2013-03-24 Thread Kevin Bracey
this flaw. Signed-off-by: Kevin Bracey ke...@bracey.fi --- git-merge-one-file.sh | 22 +++--- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh index 39b7799..e231d20 100755 --- a/git-merge-one-file.sh +++ b/git-merge-one-file.sh

[PATCH v4 2/2] mergetools/p4merge: create a base if none available

2013-03-24 Thread Kevin Bracey
that if there are no differences at the same location, this technique can lead to automatic resolution without conflict, combining everything from the 2 files. As with the other merges using this technique, we assume the user will inspect the result before saving. Signed-off-by: Kevin Bracey ke...@bracey.fi Reviewed

[PATCH] checkout: abbreviate hash in suggest_reattach

2013-04-08 Thread Kevin Bracey
After printing the list of left-behind commits (with abbreviated hashes), use an abbreviated hash in the suggested 'git branch' command; there's no point in outputting a full 40-character hex string in some friendly advice. Signed-off-by: Kevin Bracey ke...@bracey.fi --- builtin/checkout.c | 2

--simplify-merges breakage

2013-04-08 Thread Kevin Bracey
Commit 4b7f53d (simplify-merges: drop merge from irrelevant side branch) appears to have broken simplify-merges. [Credit to git bisect run - and now I see the report problems immediately message on the recent merge of that change.] I was trying to get my head around history simplification,

Locating merge that dropped a change

2013-04-09 Thread Kevin Bracey
This morning, I was struggling (not for the first time) to produce a Git command that would identify a merge commit that dropped a change. I could see where it was added, but couldn't automate finding out why it wasn't any longer in HEAD. All the permutations of --full-history, -m, -S, -G on

Re: Locating merge that dropped a change

2013-04-11 Thread Kevin Bracey
On 09/04/2013 21:00, Kevin Bracey wrote: So, how to automatically find a merge that ignored a known change? I think I've found the problem. It only doesn't work _if you specify the file_. Specifically, if I was missing an addition, my first attempt to find it would be git log -p -m

[PATCH] cherry-pick/revert: make usage say 'commit-ish...'

2013-04-22 Thread Kevin Bracey
The usage string for cherry-pick and revert has never been updated to reflect their ability to handle multiple commits. Other documentation is already correct. Signed-off-by: Kevin Bracey ke...@bracey.fi --- builtin/revert.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[RFC/PATCH] Make --full-history consider more merges

2013-04-22 Thread Kevin Bracey
to _all_ parents. This means the command above locates a merge that dropped change. Signed-off-by: Kevin Bracey ke...@bracey.fi --- This would address my problem case - it passes existing tests, and covers my (all-too-common) problem. But it would also need documentation changes and a new test

Re: [RFC/PATCH] Make --full-history consider more merges

2013-04-23 Thread Kevin Bracey
On 22/04/2013 22:49, Junio C Hamano wrote: So in addition to have some change and there is no same parent case, under _some_ condition we avoid marking a merge not worth showing (i.e. TREESAME) if there is any change. And the condition is !simplify_history and !simplify_merges, which would

Re: [RFC/PATCH] Make --full-history consider more merges

2013-04-25 Thread Kevin Bracey
On 25/04/2013 04:59, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: So, given all that, revised patch below: I tried to squeeze the minimum test I sent $gmane/220919 to the test suite. I think the do not use --parents option for this test switch needs to be cleaned up a bit

Re: [RFC/PATCH] Make --full-history consider more merges

2013-04-25 Thread Kevin Bracey
On 25/04/2013 19:51, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: Thanks for the test addition. Maybe we will be able to satisfy your greed in this series. There could be more worth doing here, and I think getting TREESAME precise is key. It is perfectly fine to do things one

Re: [RFC/PATCH] Make --full-history consider more merges

2013-04-26 Thread Kevin Bracey
On 25/04/2013 21:19, Junio C Hamano wrote: How many decorations are we talking about here? One for each merge commit in the entire history? Do we have a cue that can tell us when we are really done with a commit that lets us discard the associated data as we go on digging, keeping the size of

[RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges

2013-04-26 Thread Kevin Bracey
. This is achieved by storing per-parent TREESAME flags on the initial scan, so the combined flag can be easily recomputed. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/rev-list-options.txt | 2 +- revision.c | 220 - revision.h

[RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents

2013-04-26 Thread Kevin Bracey
In the event of an odd merge, we may find ourselves TREESAME to apparently redundant parents. Prevent simplify_merges() from removing every TREESAME parent - in the event of such a merge it's useful to see where we came actually from came. Signed-off-by: Kevin Bracey ke...@bracey.fi

[RFC/PATCH 3/3] simplify-merges: drop merge from irrelevant side branch

2013-04-26 Thread Kevin Bracey
from each other, and both need to be kept. That is incorrect; when the side branch 'x' never touches the paths, it should be removed to allow M to simplify down to the last commit on the main history that touches the paths. Suggested-by: Junio C Hamano gits...@pobox.com Signed-off-by: Kevin Bracey

Re: [RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents

2013-04-28 Thread Kevin Bracey
On 28/04/2013 02:02, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: In the event of an odd merge, we may find ourselves TREESAME to apparently redundant parents. Prevent simplify_merges() from removing every TREESAME parent - in the event of such a merge it's useful to see where we

Re: [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges

2013-04-28 Thread Kevin Bracey
On 28/04/2013 01:36, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: Historically TREESAME was set on a commit if it was TREESAME to _any_ of its parents. This is not optimal, as such a merge could still be worth showing, particularly if it is an odd -s ours merge that (possibly

Re: [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges

2013-04-29 Thread Kevin Bracey
On 28/04/2013 21:38, Junio C Hamano wrote: @@ -773,6 +861,9 @@ static void limit_to_ancestry(struct commit_list *bottom, struct commit_list *li * NEEDSWORK: decide if we want to remove parents that are * not marked with TMP_MARK from commit-parents for commits *

[PATCH v2 5/8] t6012: update test for tweaked full-history traversal

2013-04-30 Thread Kevin Bracey
From: Junio C Hamano gits...@pobox.com Signed-off-by: Junio C Hamano gits...@pobox.com --- 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

[PATCH v2 6/8] simplify-merges: never remove all TREESAME parents

2013-04-30 Thread Kevin Bracey
. This avoids producing a totally disjoint history from the default log when the default log is a better explanation of the end result, and aids visualisation of odd merges. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/rev-list-options.txt | 3 +- revision.c

[PATCH v2 1/8] decorate.c: compact table when growing

2013-04-30 Thread Kevin Bracey
search. But we can remove NULL decoration entries when rebuilding the table. Signed-off-by: Kevin Bracey ke...@bracey.fi --- decorate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/decorate.c b/decorate.c index 2f8a63e..7cb5d29 100644 --- a/decorate.c +++ b/decorate.c @@ -49,7

[PATCH v2 3/8] rev-list-options.txt: correct TREESAME for P

2013-04-30 Thread Kevin Bracey
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 ke...@bracey.fi --- Documentation/rev-list-options.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v2 0/8] History traversal refinements

2013-04-30 Thread Kevin Bracey
with an independent set of eyes checking that the claimed benefits actually match the results. (And that the claims are understandable.) Junio C Hamano (1): t6012: update test for tweaked full-history traversal Kevin Bracey (7): decorate.c: compact table when growing t6019: test file dropped in -s ours

[PATCH v2 7/8] simplify-merges: drop merge from irrelevant side branch

2013-04-30 Thread Kevin Bracey
from each other, and both need to be kept. That is incorrect; when the side branch 'x' never touches the paths, it should be removed to allow M to simplify down to the last commit on the main history that touches the paths. Suggested-by: Junio C Hamano gits...@pobox.com Signed-off-by: Kevin Bracey

[PATCH v2 4/8] revision.c: Make --full-history consider more merges

2013-04-30 Thread Kevin Bracey
changes' ultimate fate in merges. Also modify simplify_merges to recalculate TREESAME after removing a parent. This is achieved by storing per-parent TREESAME flags on the initial scan, so the combined flag can be easily recomputed. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/rev-list

[PATCH v2 8/8] revision.c: discount UNINTERESTING parents

2013-04-30 Thread Kevin Bracey
and thus privileged over F, so we don't care that J differs from F. So should we treat bottom commits as interesting for the rules above? Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c| 141 -- t/t6019-rev-list-ancestry-path.sh

[PATCH v2 2/8] t6019: test file dropped in -s ours merge

2013-04-30 Thread Kevin Bracey
-by: Kevin Bracey ke...@bracey.fi --- t/t6019-rev-list-ancestry-path.sh | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/t/t6019-rev-list-ancestry-path.sh b/t/t6019-rev-list-ancestry-path.sh index 39b4cb0..86ef908 100755 --- a/t/t6019-rev-list-ancestry-path.sh

[PATCH v2.1 8/8] revision.c: discount side branches when computing TREESAME

2013-05-02 Thread Kevin Bracey
revision lists - irrelevant merges from unlisted commits can be omitted. Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c| 210 -- revision.h| 3 +- t/t6019-rev-list-ancestry-path.sh | 12 ++- 3 files

[PATCH v2.2 8/8] revision.c: discount side branches when computing TREESAME

2013-05-02 Thread Kevin Bracey
revision lists - irrelevant merges from unlisted commits can be omitted. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Something went wrong with v2.1; it got based on an old version of the series. This one should apply to v2 correctly. revision.c| 216

Re: [PATCH v2 8/8] revision.c: discount UNINTERESTING parents

2013-05-02 Thread Kevin Bracey
On 01/05/2013 00:18, Junio C Hamano wrote: These rules paying more attention to UNINTERESTING do add a tricky wrinkle to behaviour. Because limited revision lists are conventionally expressed as A..B (ie B ^A), the bottom commit is UNINTERESTING. OK. Thus its connection to the INTERESTING

Re: [PATCH] revision.c: Fix a sparse warning

2013-05-04 Thread Kevin Bracey
On 04/05/2013 20:25, Ramsay Jones wrote: Sparse issues an 'sole_interesting' not declared. Should it be static? warning. In order to suppress the warning, since this symbol does not need more than file visibility, we simply add the static modifier to its declaration. Thanks! I'll include that

Re: [PATCH v2 8/8] revision.c: discount UNINTERESTING parents

2013-05-04 Thread Kevin Bracey
On 02/05/2013 23:05, Junio C Hamano wrote: Z...A===X---o---o---B \\/ W---Y OK, I think I understand it, and we are in agreement. For the purpose of the above paragraph, a side branch is what is not on the --ancestry-path, so all of the below examples

[PATCH v3 3/9] t6111: new TREESAME test set

2013-05-05 Thread Kevin Bracey
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 ke...@bracey.fi --- t/t6111-rev-list

[PATCH v3 6/9] t6012: update test for tweaked full-history traversal

2013-05-05 Thread Kevin Bracey
From: Junio C Hamano gits...@pobox.com Signed-off-by: Junio C Hamano gits...@pobox.com --- 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

[PATCH v3 7/9] simplify-merges: never remove all TREESAME parents

2013-05-05 Thread Kevin Bracey
. This avoids producing a totally disjoint history from the default log when the default log is a better explanation of the end result, and aids visualisation of odd merges. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/rev-list-options.txt | 3 +- revision.c

[PATCH v3 4/9] rev-list-options.txt: correct TREESAME for P

2013-05-05 Thread Kevin Bracey
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 ke...@bracey.fi --- Documentation/rev-list-options.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v3 0/9] History traversal refinements

2013-05-05 Thread Kevin Bracey
traversal Kevin Bracey (8): decorate.c: compact table when growing t6019: test file dropped in -s ours merge t6111: new TREESAME test set rev-list-options.txt: correct TREESAME for P revision.c: Make --full-history consider more merges simplify-merges: never remove all TREESAME parents

[PATCH v3 2/9] t6019: test file dropped in -s ours merge

2013-05-05 Thread Kevin Bracey
parent, so are treated as TREESAME and not shown. This is clearly undesirable in the case of merge L, which dropped our G.t by taking the non-ancestry-path version. Document this as a known failure, and expect H J L, the 3 merges along the path that had to chose G.t versions. Signed-off-by: Kevin

[PATCH v3 1/9] decorate.c: compact table when growing

2013-05-05 Thread Kevin Bracey
search. But we can remove NULL decoration entries when rebuilding the table. Signed-off-by: Kevin Bracey ke...@bracey.fi --- decorate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/decorate.c b/decorate.c index 2f8a63e..7cb5d29 100644 --- a/decorate.c +++ b/decorate.c @@ -49,7

[PATCH v3 8/9] simplify-merges: drop merge from irrelevant side branch

2013-05-05 Thread Kevin Bracey
from each other, and both need to be kept. That is incorrect; when the side branch 'x' never touches the paths, it should be removed to allow M to simplify down to the last commit on the main history that touches the paths. Suggested-by: Junio C Hamano gits...@pobox.com Signed-off-by: Kevin Bracey

[PATCH v3 9/9] revision.c: discount side branches when computing TREESAME

2013-05-05 Thread Kevin Bracey
revision lists - irrelevant merges from unlisted commits can be omitted. Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c| 201 -- revision.h| 3 +- t/t6019-rev-list-ancestry-path.sh | 12 ++- t/t6111-rev

[PATCH v3 5/9] revision.c: Make --full-history consider more merges

2013-05-05 Thread Kevin Bracey
are now showing some merges that don't need to be shown. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/rev-list-options.txt | 6 +- revision.c | 241 - revision.h | 1 + t/t6019-rev-list-ancestry

[PATCH v3 10/9] revision.c: treat A...B merge bases as if manually specified

2013-05-06 Thread Kevin Bracey
that the calculated merge bases are sent to add_rev_cmdline(), flagged as 'REV_CMD_MERGE_BASE'. Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c | 9 +++-- revision.h | 2 ++ t/t6111-rev-list-treesame.sh | 4 3 files changed, 13 insertions(+), 2

Re: [PATCH v3 5/9] revision.c: Make --full-history consider more merges

2013-05-07 Thread Kevin Bracey
On 06/05/2013 23:45, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: +struct treesame_state { + unsigned int nparents; + unsigned char treesame[FLEX_ARRAY]; +}; I have been wondering if we want to do one-bit (not one-byte) per parent but no biggie ;-) I did start down

Re: [RFC/PATCH 0/2] merge-base: add --merge-child option

2013-05-12 Thread Kevin Bracey
On 11/05/2013 15:23, John Keeping wrote: This is helpful when examining branches with disjoint roots, for example because one is periodically merged into a subtree of the other. $ git log --left-right F...E --not $(git merge-base --merge-child F E) F E Wouldn't

Re: [RFC/PATCH 0/2] merge-base: add --merge-child option

2013-05-12 Thread Kevin Bracey
On 12/05/2013 19:33, John Keeping wrote: On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote: You're right (and I was wrong in my reply to Junio's parallel message) ancestry path does seem to be what I want: $ git rev-list --ancestry-path --left-right --count \

Re: [RFC/PATCH 0/2] merge-base: add --merge-child option

2013-05-12 Thread Kevin Bracey
On 12/05/2013 19:58, John Keeping wrote: With the patch below, the --ancestry-path version drops to under 2 seconds. I'm not sure if this is a good idea though. It helps me say I know nothing that isn't on the ancestry path can be patch-identical, so don't bother checking if it is but it

Re: [RFC/PATCH 0/2] merge-base: add --merge-child option

2013-05-13 Thread Kevin Bracey
On 13/05/2013 01:22, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: git log --ancestry-path --left-right E...F --not $(git merge-base --all E F) which looks like we're having to repeat ourselves because it's not paying attention... You are half wrong; --left-right is about do

[PATCH 0/2] Make --ancestry-path A...B work

2013-05-13 Thread Kevin Bracey
there. And then hopefully this can proceed to next faster. (Dropping that commit will drop the only --ancestry-path A...B test in t6111, meaning no immediate dependencies. But the next version of that series will be sent with t6111 testing and expecting a pass due to this fix being in.) Kevin Bracey (2

[PATCH 2/2] revision.c: treat A...B merge bases as if manually specified

2013-05-13 Thread Kevin Bracey
refinements series. So ensure that the calculated merge bases are sent to add_rev_cmdline(), flagged with new 'whence' enum value REV_CMD_MERGE_BASE. Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c| 17 + revision.h| 1 + t/t6019

[PATCH 1/2] t6019: demonstrate --ancestry-path A...B breakage

2013-05-13 Thread Kevin Bracey
Signed-off-by: Kevin Bracey ke...@bracey.fi --- t/t6019-rev-list-ancestry-path.sh | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/t/t6019-rev-list-ancestry-path.sh b/t/t6019-rev-list-ancestry-path.sh index 39b4cb0..5287f6a 100755 --- a/t/t6019-rev-list

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

2013-05-16 Thread Kevin Bracey
search. But we can remove NULL decoration entries when rebuilding the table. Signed-off-by: Kevin Bracey ke...@bracey.fi --- decorate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/decorate.c b/decorate.c index 2f8a63e..7cb5d29 100644 --- a/decorate.c +++ b/decorate.c @@ -49,7

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

2013-05-16 Thread Kevin Bracey
From: Junio C Hamano gits...@pobox.com Signed-off-by: Junio C Hamano gits...@pobox.com --- 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

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

2013-05-16 Thread Kevin Bracey
from each other, and both need to be kept. That is incorrect; when the side branch 'x' never touches the paths, it should be removed to allow M to simplify down to the last commit on the main history that touches the paths. Suggested-by: Junio C Hamano gits...@pobox.com Signed-off-by: Kevin Bracey

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

2013-05-16 Thread Kevin Bracey
are now showing some merges that don't need to be shown. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/rev-list-options.txt | 6 +- revision.c | 241 - revision.h | 1 + t/t6019-rev-list-ancestry

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

2013-05-16 Thread Kevin Bracey
. Merges at the boundary do not necessarily need to be shown. Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c | 22 +++--- t/t6111-rev-list-treesame.sh | 4 ++-- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/revision.c b/revision.c index

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

2013-05-16 Thread Kevin Bracey
of the definition of bottom with future patches. Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c | 34 -- revision.h | 3 ++- 2 files changed, 18 insertions(+), 19 deletions(-) diff --git a/revision.c b/revision.c index 4f7446c..6607dab 100644 --- a/revision.c +++ b

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

2013-05-16 Thread Kevin Bracey
relevant_commit() instead of !UNINTERESTING, so it can proceed straight from D to B, thus finishing the traversal of that path. Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c | 2 +- t/t6111-rev-list-treesame.sh | 12 ++-- 2 files changed, 7 insertions(+), 7 deletions

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

2013-05-16 Thread Kevin Bracey
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 ke...@bracey.fi --- t/t6111-rev-list

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

2013-05-16 Thread Kevin Bracey
. Signed-off-by: Kevin Bracey ke...@bracey.fi --- revision.c| 171 +- t/t6019-rev-list-ancestry-path.sh | 12 ++- t/t6111-rev-list-treesame.sh | 8 +- 3 files changed, 164 insertions(+), 27 deletions(-) diff --git a/revision.c b

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

2013-05-16 Thread Kevin Bracey
. This avoids producing a totally disjoint history from the default log when the default log is a better explanation of the end result, and aids visualisation of odd merges. Signed-off-by: Kevin Bracey ke...@bracey.fi --- Documentation/rev-list-options.txt | 3 +- revision.c

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

2013-05-16 Thread Kevin Bracey
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 ke...@bracey.fi --- Documentation/rev-list-options.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v4 07/15] Documentation: avoid uninteresting

2013-05-16 Thread Kevin Bracey
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 00/15] History traversal refinements

2013-05-16 Thread Kevin Bracey
test for tweaked full-history traversal Kevin Bracey (13): decorate.c: compact table when growing t6019: test file dropped in -s ours merge t6111: new TREESAME test set t6111: add parents to tests rev-list-options.txt: correct TREESAME for P Documentation: avoid uninteresting revision.c

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

2013-05-16 Thread Kevin Bracey
From: Junio C Hamano gits...@pobox.com Signed-off-by: Junio C Hamano gits...@pobox.com --- 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

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

2013-05-16 Thread Kevin Bracey
Signed-off-by: Kevin Bracey ke...@bracey.fi --- 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

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

2013-05-16 Thread Kevin Bracey
parent, so are treated as TREESAME and not shown. This is clearly undesirable in the case of merge L, which dropped our G.t by taking the non-ancestry-path version. Document this as a known failure, and expect H J L, the 3 merges along the path that had to chose G.t versions. Signed-off-by: Kevin

  1   2   >