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
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
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
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
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
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
.
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
-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
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
-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
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
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
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
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
, 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
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
, 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
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
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
-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
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
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
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
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
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
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
, 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
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
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
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
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
, 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
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
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
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
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,
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
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
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
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
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
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
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
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
. 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
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
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
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
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
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
*
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
.
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
.
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
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
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
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
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
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
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
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
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
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
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 \
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
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
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
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
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
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
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
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
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
. 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
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
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
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
.
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
.
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
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
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
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
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
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
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
On 15/05/2013 23:34, Felipe Contreras wrote:
I think I'm using 'upstream' for something it was not intended to, and
I think the current 'upstream' behavior should be split into
'upstream' and 'base'.
I found myself thinking the same thing. It's really convenient being
able to set your topic
On 17/05/2013 22:51, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
On 15/05/2013 23:34, Felipe Contreras wrote:
I think I'm using 'upstream' for something it was not intended to,
and
I think the current 'upstream' behavior should be split into
'upstream' and 'base'.
I found
1 - 100 of 114 matches
Mail list logo
