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
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
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
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 which
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
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
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
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(&qu
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
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
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
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
On 01/06/2014 07:26, Atsushi Nakagawa wrote:
Kevin Bracey ke...@bracey.fi 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
On 31/05/2014 08:46, Atsushi Nakagawa wrote:
`git checkout -B current-branch-name tree-ish`
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
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 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 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
-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
.
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
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
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
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
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 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
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 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
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
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
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
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
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
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
*
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 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 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 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
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 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
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
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,
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
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
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
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
1 - 100 of 114 matches
Mail list logo
