On 31/05/2018 08:43, Jeff King wrote:
If there are zero parents (neither relevant nor irrelevant), is it still
TREESAME? I would say in theory yes.
Not sure - I think roots are such a special case that TREESAME
effectively doesn't matter. We always test for roots first.
So what I was propo
On 30/05/2018 00:04, Jeff King wrote:
Do we even need to do the parent rewriting here? By definition those
parents aren't interesting, and we're TREESAME to whatever is in
treesame_parents. So conceptually it seems like we just need a flag "I
found a treesame parent", but we only convert that in
On 29/05/2018 01:06, SZEDER Gábor wrote:
So, without investing nearly enough time to understand what is going
on, I massaged the above diffs into this:
Cool.
+ treesame_parents =
xmalloc(sizeof(*treesame_parents));
There's no need to actually record a list here.
On 24/05/2018 23:26, Kevin Bracey wrote:
On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote:
$ git log --oneline master..ba95710a3b -- ci/
ea44c0a594 Merge branch 'bw/protocol-v2' into
jt/partial-clone-proto-v2
In this case, we're hitting a merge commit
On 23/05/2018 20:35, Jeff King wrote:
On Wed, May 23, 2018 at 01:32:46PM -0400, Jeff King wrote:
On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote:
$ git log --oneline master..ba95710a3b -- ci/
ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2
I keep s
On 23/05/2018 20:35, Jeff King wrote:
There's more discussion in the thread at:
https://public-inbox.org/git/1366658602-12254-1-git-send-email-ke...@bracey.fi/
I haven't absorbed it all yet, but I'm adding Junio to the cc.
Just to ack that I've seen the discussion, but I can't identify th
On 04/10/2016 23:31, René Scharfe wrote:
So let's summarize; here's the effect of a raw qsort(3) call:
array == NULL nmemb bug QSORT following NULL check
- - --- -
0 0 no qsort is skipped
0 >0 no qsort is
On 04/10/2016 01:00, René Scharfe wrote:
Am 03.10.2016 um 19:09 schrieb Kevin Bracey:
As such, NULL checks can still be elided even with your change. If you
effectively change your example to:
if (nmemb > 1)
qsort(array, nmemb, size, cmp);
if (!array)
printf("
On 01/10/2016 19:19, René Scharfe wrote:
It's hard to imagine an implementation of qsort(3) that can't handle
zero elements. QSORT's safety feature is that it prevents the compiler
from removing NULL checks for the array pointer. E.g. the last two
lines in the following example could be optimiz
On 01/10/2016 19:19, René Scharfe wrote:
It's hard to imagine an implementation of qsort(3) that can't handle
zero elements. QSORT's safety feature is that it prevents the compiler
from removing NULL checks for the array pointer. E.g. the last two
lines in the following example could be optimi
On 07/06/2014 17:52, Philip Oakley wrote:
Just to say there has been a similar confusion about 'git reset'
reported on the Git Users group for the case of reset with added
(staged), but uncommitted changes being wiped out, which simlarly
reports on the difficulty of explaining some of the co
On 03/06/2014 00:54, Junio C Hamano wrote:
Not that I can think of a better way to update these descriptions,
and not that I am opposing to update these descriptions to make it
easier for new people to learn, but I am not sure if these "treat
ORIG_HEAD and the changes since that commit as separa
On 01/06/2014 07:26, Atsushi Nakagawa wrote:
Kevin Bracey wrote:
The original "git reset --hard" used to be a pretty top-level command.
It was used for aborting merges in particular. But I think it now
stands out as being one of the only really dangerous porcelain
commands, and I c
On 31/05/2014 08:46, Atsushi Nakagawa wrote:
`git checkout -B `
This is such an useful notion that I can fathom why there isn't a better,
first-tier, alternative.q
I'm 100% in agreement. "Reset current branch to X" is an extremely
common operation, and I use this all the time. But having to
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 wh
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 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 hand-upd
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
ha
On 11/09/2013 01:23, Junio C Hamano wrote:
Kevin Bracey 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 it.
Bisecting points at
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
-by: Kevin Bracey
---
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 --git a
ragraph.
Signed-off-by: Kevin Bracey
---
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-dif
On 21/05/2013 19:52, Junio C Hamano wrote:
Ramkumar Ramachandra writes:
The empty string '' looks ugly and inconsistent with the output of
@{}. Replace it with the string 'current branch'.
Wouldn't that be '*the* current branch'?
More importantly, doesn't "real_ref" have the name of the bra
On 17/05/2013 22:51, Junio C Hamano wrote:
Kevin Bracey 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' an
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
ESAME to 1 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 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
hecking the parents as well
t6012: update 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
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
sions.txt.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 50bbff7..55ddf33 100644
--- a/Documentation/rev-list-options.txt
+++
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
e followed.
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
---
Documentation/rev-list-options.txt | 3 +-
revision.c
evision lists.
Signed-off-by: Kevin Bracey
---
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/rev
lt following to test 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
---
revision.c | 2 +-
t/t6111-rev-list-treesame.sh | 12 ++--
2 files changed, 7 insertions(+),
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-treesam
. Merges at the boundary do not necessarily need
to be shown.
Signed-off-by: Kevin Bracey
---
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 1c75070..edb7e1c
l ensure alignment of the definition of
"bottom" with future patches.
Signed-off-by: Kevin Bracey
---
revision.c | 34 --
revision.h | 3 ++-
2 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/revision.c b/revision.c
index 4f7446c..6607dab 10064
11 failures, but creates a couple of new ones -
we are now showing some merges that don't need to be shown.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 6 +-
revision.c | 241 -
revision.h
hat touches
the paths we are following) are independent 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
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
reak the linear hash collision
search. But we can remove NULL decoration entries when rebuilding the
table.
Signed-off-by: Kevin Bracey
---
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
+
Signed-off-by: Kevin Bracey
---
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-ancestry-path.sh
issue in
my proposed history traversal 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
---
revision.c| 17 +
revision.h
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
On 13/05/2013 01:22, Junio C Hamano wrote:
Kevin Bracey 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 a
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 reg
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 \
master
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'
On 07/05/2013 00:24, Junio C Hamano wrote:
Kevin Bracey writes:
The documentation assures users that "A...B" is defined as 'r1 r2 --not
$(git merge-base --all r1 r2)'. This isn't in fact quite true, because
the calculated merge bases are not sent to add_rev_cmdline().
On 06/05/2013 23:36, Junio C Hamano wrote:
Kevin Bracey writes:
+#,---E--. *H--. * marks !TREESAME parent paths
+# /\ / \*
+# *A--*B---D--*F-*G-K-*L-*M
+# \ /* \ /
+#`-C-' `-*I-*J
+#
+# A cr
On 06/05/2013 23:45, Junio C Hamano wrote:
Kevin Bracey 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 that path
ults for
"A...B" compared to "A B ^AB_base".
So ensure that the calculated merge bases are sent to add_rev_cmdline(),
flagged as 'REV_CMD_MERGE_BASE'.
Signed-off-by: Kevin Bracey
---
revision.c | 9 +++--
revision.h | 2 ++
11 failures, but creates a couple of new ones -
we are now showing some merges that don't need to be shown.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 6 +-
revision.c | 241 -
revision.h
hat touches
the paths we are following) are independent 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
on in limited revision
lists - irrelevant merges from unlisted commits can be omitted.
Signed-off-by: Kevin Bracey
---
revision.c| 201 --
revision.h| 3 +-
t/t6019-rev-list-ancestry-path.sh | 12 ++-
t/t
reak the linear hash collision
search. But we can remove NULL decoration entries when rebuilding the
table.
Signed-off-by: Kevin Bracey
---
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
+
ESAME to 1 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.
quot;?
Junio C Hamano (1):
t6012: update test for tweaked full-history 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
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
e followed.
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
---
Documentation/rev-list-options.txt | 3 +-
revision.c
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
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-treesam
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
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 tha
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 gra
on in limited revision
lists - irrelevant merges from unlisted commits can be omitted.
Signed-off-by: Kevin Bracey
---
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
on in limited revision
lists - irrelevant merges from unlisted commits can be omitted.
Signed-off-by: Kevin Bracey
---
revision.c| 210 --
revision.h| 3 +-
t/t6019-rev-list-ancestry-path.sh | 12 ++-
3 files
ions.
Signed-off-by: Kevin Bracey
---
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-p
igher up the graph, I is INTERESTING 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
---
revision.c| 141 --
very
change to the file, including those 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-
hat touches
the paths we are following) are independent 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
scripting, and on
top of that something like this could really do 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):
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
reak the linear hash collision
search. But we can remove NULL decoration entries when rebuilding the
table.
Signed-off-by: Kevin Bracey
---
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
+
e followed.
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
---
Documentation/rev-list-options.txt | 3 +-
revision.c
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
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
* i
On 28/04/2013 01:36, Junio C Hamano wrote:
Kevin Bracey 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
ac
On 28/04/2013 02:02, Junio C Hamano wrote:
Kevin Bracey 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 came act
hat touches
the paths we are following) are independent 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
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
---
Documentation/rev
oving
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
---
Documentation/rev-list-options.txt | 2 +-
revision.c | 220 +
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 o
On 25/04/2013 19:51, Junio C Hamano wrote:
Kevin Bracey 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 step at a time
On 25/04/2013 04:59, Junio C Hamano wrote:
Junio C Hamano 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 more, but it fail
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
only if it is TREESAME to
_all_ parents. This means the command above locates a merge that dropped
"change".
Signed-off-by: Kevin Bracey
---
This would address my problem case - it passes existing tests, and covers
my (all-too-common) problem. But it would also need documentation change
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
---
builtin/revert.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin
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 lo
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", "
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 simplificati
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
---
builtin/checkout.c
same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.
Note 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 merge
ch without
this flaw.
Signed-off-by: Kevin Bracey
---
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-fil
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 2382b1f..39b7799 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -69,7 +69,7 @@ case &quo
Update style to match Documentation/CodingGuidelines.
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 255c07a..2382b1f 100755
--- a/git-merge
new base) appear in blue; changes that do not
appear in the rebased commit (from the new base, 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, s
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:" mess
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 ABCD is silly.
Doh. But anyway, we don'
On 14/03/2013 16:56, Junio C Hamano wrote:
Kevin Bracey 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 <|X>ABC<|D>EFH
VBase ?ABC?EF??H
1 - 100 of 120 matches
Mail list logo
