[The copy of my message to the list bounced; trying to resend...]
Hi,
Thanks for flagging this problem, providing a clear testcase, and working on it.
On Fri, Jan 24, 2014 at 7:01 AM, Brad King wrote:
>
> Teach add_cacheinfo to optionally tolerate make_cache_entry failure when
> the reason is E
Hi,
On Mon, Aug 8, 2016 at 3:32 PM, Junio C Hamano wrote:
> * js/am-3-merge-recursive-direct (2016-08-01) 16 commits
> (merged to 'next' on 2016-08-05 at dc1c9bb)
> + merge-recursive: flush output buffer even when erroring out
> + merge_trees(): ensure that the callers release output buffer
>
Signed-off-by: Elijah Newren
---
git-merge-one-file.sh | 44 +++-
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 424b034..78efa00 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one
From: Elijah Newren
This almost works. It creates the correct merge commit, updates the
branch, but then if the repo is bare it leaves the index as it was before
the merge (and if the repo is non-bare it updates the index). I'm
totally lost as to why the testcase behaves differently i
x27;s a waste of time, if not also a bit weird.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index d4292de..06d31ed 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -62
Signed-off-by: Elijah Newren
---
git-merge-resolve.sh| 12 ++--
t/t6043-merge-index-only.sh | 4 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/git-merge-resolve.sh b/git-merge-resolve.sh
index c9da747..ed4a25b 100755
--- a/git-merge-resolve.sh
+++ b/git
Signed-off-by: Elijah Newren
---
t/t6043-merge-index-only.sh | 170
1 file changed, 170 insertions(+)
create mode 100755 t/t6043-merge-index-only.sh
diff --git a/t/t6043-merge-index-only.sh b/t/t6043-merge-index-only.sh
new file mode 100755
index
t? Even it's name is sitting there, mocking me. "Ha ha, I'm
read_tree_*trivial* and you can't figure me out." read_tree_trivial
is a jerk.
Elijah Newren (18):
Remove duplicate code
Avoid checking working copy when creating a virtual merge base
Document wei
g it.
...makes me wonder if I should add a testcase for unstaged and untracked
changes for each merge strategy while I'm at it. Hmmm...
Signed-off-by: Elijah Newren
---
t/t6044-merge-unrelated-index-changes.sh | 165 +++
1 file changed, 165 insertions(+
This is almost trivial to make work, because we already know that the
working tree will need no modifications, but lets test it for completeness
anyway.
Signed-off-by: Elijah Newren
---
t/t6043-merge-index-only.sh | 32
1 file changed, 32 insertions(+)
diff
Signed-off-by: Elijah Newren
---
t/t6043-merge-index-only.sh | 70 +
1 file changed, 70 insertions(+)
diff --git a/t/t6043-merge-index-only.sh b/t/t6043-merge-index-only.sh
index b8b22ab..67c8e92 100755
--- a/t/t6043-merge-index-only.sh
+++ b/t/t6043
Signed-off-by: Elijah Newren
---
builtin/merge-index.c | 9 -
builtin/merge.c | 2 +-
cache.h | 2 +-
merge.c | 4 +++-
sequencer.c | 2 +-
5 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/builtin/merge-index.c b/builtin/merge
Signed-off-by: Elijah Newren
---
t/t6043-merge-index-only.sh | 41 +
1 file changed, 41 insertions(+)
diff --git a/t/t6043-merge-index-only.sh b/t/t6043-merge-index-only.sh
index 4c3c40a..b01bf79 100755
--- a/t/t6043-merge-index-only.sh
+++ b/t/t6043
Signed-off-by: Elijah Newren
---
t/t6043-merge-index-only.sh | 34 ++
1 file changed, 34 insertions(+)
diff --git a/t/t6043-merge-index-only.sh b/t/t6043-merge-index-only.sh
index 84c6640..5eda6b3 100755
--- a/t/t6043-merge-index-only.sh
+++ b/t/t6043-merge-index
Subsequent commits will add implementation for each relevant merge strategy
Signed-off-by: Elijah Newren
---
Documentation/git-merge.txt | 14 ++
builtin/merge.c | 7 +++
git.c | 2 +-
merge-recursive.c | 1 +
merge-recursive.h
Signed-off-by: Elijah Newren
---
git-merge-octopus.sh | 5 +
t/t6044-merge-unrelated-index-changes.sh | 21 ++---
2 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index 8643f74..a1d7702 100755
Including both tests which can be handled without calling the actual
git-merge-resolve program (because the merge is trivially resolvable
without worrying about 3-way file merges), and ones that do need it to be
invoked.
Signed-off-by: Elijah Newren
---
t/t6043-merge-index-only.sh | 104
-only is passed or o->call_depth > 0, and make the portions of
merge-recursive that are about operating only on the index look at
o->index_only, and the portions that are about forcibly immediately
resolving conflicts check o->call_depth.
Signed-off-by: Elijah Newren
---
merge
file twice; removing it once is sufficient...especially since the
intervening line was working with a different file entirely.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index b880ae5..d4292de
Signed-off-by: Elijah Newren
---
git-merge-octopus.sh| 14 +++---
t/t6043-merge-index-only.sh | 4 ++--
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index a1d7702..e7915dc 100755
--- a/git-merge-octopus.sh
+++ b/git
From: Elijah Newren
Signed-off-by: Elijah Newren
---
builtin/merge.c | 1 +
builtin/pull.c | 4 ++--
cache.h | 1 +
merge.c | 4 +++-
sequencer.c | 2 +-
t/t6043-merge-index-only.sh | 6 +++---
6 files changed, 11
Hi,
On Fri, Apr 8, 2016 at 11:08 AM, Junio C Hamano wrote:
> Elijah Newren writes:
>
> The goal is stated rather vaguely--when you have a working tree and
> perform this "in index" merge, you would obviously update the index
> with the merge result and ...
Yes, I thin
On Fri, Apr 8, 2016 at 6:01 AM, Michael J Gruber
wrote:
> I haven't looked at your series thoroughly but immediately had to think
> of 'tr/remerge-diff' (on 'pu'), see
> http://permalink.gmane.org/gmane.comp.version-control.git/256591
>
> There, Thomas used index-only merge to reproduce an automat
On Thu, Apr 7, 2016 at 11:58 PM, Elijah Newren wrote:
> Luckily, I figured out that bug. So, that leaves just one case left
> that I can't seem to figure out: read_tree_trivial. So much better,
> right? Even it's name is sitting there, mocking me. "Ha ha, I'
Signed-off-by: Elijah Newren
---
git-merge-octopus.sh | 6 ++
t/t6044-merge-unrelated-index-changes.sh | 6 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index 8643f74..dc2fd1b 100755
--- a/git-merge
Newren (6):
Remove duplicate code
Avoid checking working copy when creating a virtual merge base
Add merge testcases for when index doesn't match HEAD
merge-octopus: Abort if index does not match HEAD
Add a testcase demonstrating a bug with trivial merges
builtin/merge.c: Fix a bug
file twice; removing it once is sufficient...especially since the
intervening line was working with a different file entirely.
Signed-off-by: Elijah Newren
Reviewed-by: Junio C Hamano
---
merge-recursive.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
x27;s a waste of time, if not also a bit weird.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index d4292de..06d31ed 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -62
rom merge_trivial() to fix
this issue. Since the indirect call to write_locked_index() was
conditional on cache_tree_fully_valid(), it won't be written twice.
Signed-off-by: Elijah Newren
---
builtin/merge.c | 8
t/t7605-merge-resolve.sh | 2 +-
2 files changed, 9 ins
igned-off-by: Elijah Newren
---
t/t6044-merge-unrelated-index-changes.sh | 153 +++
1 file changed, 153 insertions(+)
create mode 100755 t/t6044-merge-unrelated-index-changes.sh
diff --git a/t/t6044-merge-unrelated-index-changes.sh
b/t/t6044-merge-unrelated-
before the merge. Every attempt to repeat the merge beyond the
first will leave the index in the same weird out-of-sync state.
Signed-off-by: Elijah Newren
---
t/t7605-merge-resolve.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/t/t7605-merge-resolve.sh b/t/t7605
Hi,
On Tue, Apr 12, 2016 at 6:23 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> Elijah Newren (6):
>> Remove duplicate code
>> Avoid checking working copy when creating a virtual merge base
>> Add merge testcases for when index doesn't match HEAD
On Fri, Apr 22, 2016 at 1:05 PM, Ramsay Jones
wrote:
> Hi Ben, Junio,
>
> In the second case, t6036-*.sh, git bisect fingered commit b61f9d6e
> ("ll-merge: use a longer conflict marker for internal merge", 14-04-2016).
Yeah, the t6036 testcase 'git detects conflict w/
criss-cross+contrived resolu
On Wed, Apr 27, 2016 at 3:05 PM, Junio C Hamano wrote:
> Isn't what the test expects bogus in the first place? I'd suggest
> removing the test as "pointless waste of resource".
>
> Comments?
>
> -- >8 --
Yes, toss it; I find your arguments below compelling.
> Manual merge resolution by users fu
On Fri, Dec 7, 2018 at 6:14 PM Josh Wolfe wrote:
>
> git version 2.19.1
> steps to reproduce:
>
> # start in a brand new repo
> git init
>
> # create lots of unreachable loose objects
> for i in {1..1}; do git commit-tree -m "$(head -c 12 /dev/urandom
> | base64)" "$(git mktree <&-)" <&-; done
On Sun, Dec 9, 2018 at 12:04 PM Thomas Gummerer wrote:
>
> Here's the series I mentioned a couple of times on the list already,
> introducing a no-overlay mode in 'git checkout'. The inspiration for
> this came from Junios message in [*1*].
>
> Basically the idea is to also delete files when the
On Mon, Dec 10, 2018 at 7:50 AM Duy Nguyen wrote:
>
> On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
> >
> > Factor out the 'unlink_entry()' function from unpack-trees.c to
> > entry.c. It will be used in other places as well in subsequent
> > steps.
> >
> > As it's no longer a static fun
On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
>
> 'checkout_entry()' currently only supports creating new entries in the
> working tree, but not deleting them. Add the ability to remove
> entries at the same time if the entry is marked with the CE_WT_REMOVE
> flag.
>
> Currently this doe
On Mon, Dec 10, 2018 at 8:09 AM Duy Nguyen wrote:
>
> On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
> >
> > When marking cache entries for removal, and later removing them all at
> > once using 'remove_marked_cache_entries()', cache entries currently
> > have to be invalidated manually in
On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
>
> Currently 'git checkout' is defined as an overlay operation, which
> means that if in 'git checkout -- []' we have an
> entry in the index that matches , but that doesn't exist in
> , that entry will not be removed from the index or the
>
On Mon, Dec 10, 2018 at 10:19 AM Duy Nguyen wrote:
>
> On Mon, Dec 10, 2018 at 7:09 PM Elijah Newren wrote:
> > > > For the two current callsites, unpack-trees seems to do this
> > > > invalidation itself internally.
> > >
> > > I'm still
On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
>
> Add a new --cached option to git checkout, which works only on the
> index, but not the working tree, similar to what 'git reset
> -- ... does. Indeed the tests are adapted from the 'git
> reset' tests.
>
> In the longer term the idea is
On Mon, Dec 10, 2018 at 10:34 AM Duy Nguyen wrote:
>
> On Mon, Dec 10, 2018 at 7:25 PM Elijah Newren wrote:
> > > I'm not the unpack-trees man (I think that would still be Junio). And
> > > I'm not saying it's sane either. I think it's just some leftov
On Sun, Dec 9, 2018 at 12:42 AM Junio C Hamano wrote:
> Git 2.20 has been tagged. I'd expect that we would slow down to see
> how stable it is and queue only the brown-paper-bag fixes for a week
> or so, before opening the tree for the next cycle, rewinding the tip
> of 'next', etc.
Does this m
On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
>
> Currently when 'git checkout -- ...' is invoked with
> multiple pathspecs, where one or more of the pathspecs don't match
> anything, checkout errors out.
>
> This can be inconvenient in some cases, such as when using git
> checkout from a
On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
>
> Now that we have 'git checkout --no-overlay', we can use it in git
> stash, making the codepaths for 'git stash push' with and without
> pathspec more similar, and thus easier to follow.
>
> Signed-off-by: Thomas Gummerer
> ---
>
> As men
On Thu, Dec 6, 2018 at 11:48 PM Jeff King wrote:
>
> On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
>
> > Thanks! Strangely git log --follow does work.
>
> I suspect it would work even without --follow. When you limit a log
> traversal with a pathspec, like:
>
> git log foo
>
On Mon, Dec 10, 2018 at 1:18 PM Johannes Schindelin via GitGitGadget
wrote:
> The idea was brought up by Paul Morelle.
>
> To be honest, this idea of rescheduling a failed exec makes so much sense
> that I wish we had done this from the get-go.
>
> So let's do the next best thing: implement a co
On Mon, Dec 10, 2018 at 1:18 PM Johannes Schindelin via GitGitGadget
wrote:
>
> From: Johannes Schindelin
>
> A common use case for the `--exec` option is to verify that each commit
> in a topic branch compiles cleanly, via `git rebase -x make `.
>
> However, when an `exec` in such a rebase fails
On Mon, Dec 10, 2018 at 3:13 PM Johannes Schindelin via GitGitGadget
wrote:
>
> The idea was brought up by Paul Morelle.
>
> To be honest, this idea of rescheduling a failed exec makes so much sense
> that I wish we had done this from the get-go.
>
> So let's do the next best thing: implement a co
On Mon, Dec 10, 2018 at 7:07 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> Note that 'git checkout -p -- []' already works
> >> this way, so no changes are needed for the patch mode. We disallow
> >> 'git checkout --overlay -p&#x
On Mon, Dec 10, 2018 at 7:13 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > Elijah wanted another mode (and I agree) that modifies worktree but
> > leaves the index alone. This is most useful (or least confusing) when
> > used with and would be default in restore-files. I'm not
> > saying
t;error:" prefix from the builtin
version of rebase, and change the prefix from "error:" to "fatal:" in
the legacy script to match.
Signed-off-by: Elijah Newren
---
builtin/rebase.c | 10 +-
git-legacy-rebase.sh | 12 ++--
2 files changed, 11 insertions(+)
out by Duy
- Rebased on 2.20.0
Elijah Newren (8):
rebase: make builtin and legacy script error messages the same
rebase: fix incompatible options error message
t5407: add a test demonstrating how interactive handles --skip
differently
am, rebase--merge: do not overlook --skip'ed commits wi
treat it as an empty commit trivially squashed into
its parent.
This brings the rebase--am and rebase--merge backends in sync with the
behavior of the interactive rebase backend.
Signed-off-by: Elijah Newren
---
builtin/am.c | 9 +
git-rebase--merge.sh | 2 ++
t/
turning on topological sorting is actually a
performance improvement: by way of comparison, turning on --topo-order
made fast-export faster (see
https://public-inbox.org/git/20090211135640.ga19...@coredump.intra.peff.net/).
Signed-off-by: Elijah Newren
---
git-rebase--am.sh | 2 +
now REBASE-i.
Signed-off-by: Elijah Newren
---
.gitignore| 1 -
Documentation/git-rebase.txt | 17 +--
Makefile | 1 -
builtin/rebase.c | 15 ++-
git-legacy-rebase.sh | 43
git-rebase--merge.sh
giving us the following form:
if incompatible_opts:
if interactive:
show_error_about_interactive_and_am_incompatibilities
if rebase-merge:
show_error_about_merge_and_am_incompatibilities
Signed-off-by: Elijah Newren
---
git-legacy-rebase.sh | 20
1 file changed, 8
inery even though we have
no empty commits). A subsequent commit will remove the inconsistency in
--skip handling.
Signed-off-by: Elijah Newren
---
t/t5407-post-rewrite-hook.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/t/t5407-post-rewrite-hook.sh b/
y thoroughly in the rebase
man page (in the "Incompatible Options" section, with multiple links
throughout the document), and since I expect this list to change over
time, just simplify the error message.
Signed-off-by: Elijah Newren
---
builtin/rebase.c | 10 +++---
git-legacy
presence of a
"verbose" file in the state_dir, while the other was signalled by the
contents of a "quiet" file was just weirdly inconsistent. (This
inconsistency pre-dated the rewrite into C.) Make them consistent by
having them both key off the presence of the file.
Signed-off-by:
Hi Dscho,
On Tue, Dec 11, 2018 at 2:14 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Mon, 10 Dec 2018, Elijah Newren wrote:
>
> > On Mon, Dec 10, 2018 at 1:18 PM Johannes Schindelin via GitGitGadget
> > wrote:
> > >
> > > @@ -1195,6 +1201,9
On Fri, Dec 7, 2018 at 4:51 PM Steven Penny wrote:
>
> On Fri, Dec 7, 2018 at 11:04 AM wrote:
> > The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
> > is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
> > in the same way as it is done in 'Git for Win
On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen wrote:
>
> On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov
> wrote:
> >
> > Hi,
> > I have asked this question on SO
> > (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)
> > and usuall
On Tue, Dec 18, 2018 at 5:14 AM Jeff King wrote:
>
> On Mon, Dec 17, 2018 at 05:50:31PM -0500, Mark Kharitonov wrote:
>
> > Guys, having git merge --dry-run would be great, but I am OK with git
> > merge for real as long as its output is parseable.
Don't rely on that. merge output has changed oc
On Fri, Dec 28, 2018 at 10:04 AM Junio C Hamano wrote:
> Sorry for being slow to recover from the year-end slowness; the 2.20
> release being rather large-ish and needed brown-paper-bag fixes soon
> after it, my temporary trans-pacific migration, or me catching cold
> that I haven't shaken off, di
Hi Dscho,
On Thu, Jan 3, 2019 at 5:27 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
...
> > I was going to re-ping in early January. Anyway, it may be worth at
> > least updating your note to "reroll exists".
>
> It is early January! ;-)
Indeed...ping incoming. :-)
>
> Ciao,
> Dscho
On Tue, Dec 11, 2018 at 8:11 AM Elijah Newren wrote:
>
> This series continues the work of making rebase more self-consistent
> by removing inconsistencies between different backends. In
> particular, this series focuses on making the merge machinery behave
> like the intera
Hi,
On Mon, Jan 7, 2019 at 12:11 PM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > Elijah Newren writes:
> >
> >> On Tue, Dec 11, 2018 at 8:11 AM Elijah Newren wrote:
> >>>
> >>> This series continues the work of making rebase
Hi Junio,
A small update...
On Mon, Jan 7, 2019 at 12:39 PM Elijah Newren wrote:
> On Mon, Jan 7, 2019 at 12:11 PM Junio C Hamano wrote:
> > Junio C Hamano writes:
> >
> > > Elijah Newren writes:
> > >
> > >> On Tue, Dec 11, 2018 at 8:11 AM Elij
Hi Dscho,
On Wed, Jan 16, 2019 at 5:37 AM Johannes Schindelin via GitGitGadget
wrote:
>
> Unfortunately, Travis decided to change some things under the hood that
> affect the Windows build. As a consequence, master has not been tested in
> quite a while, even if the test runs pretended that it ha
Hi Dscho,
On Wed, Jan 16, 2019 at 5:37 AM Johannes Schindelin via GitGitGadget
wrote:
>
> From: Johannes Schindelin
>
> When Git determines whether a file has changed, it looks at the mtime,
> at the file size, and to detect changes even if the mtime is the same
> (on Windows, the mtime granular
Hi Dscho,
On Wed, Jan 16, 2019 at 12:31 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Wed, 16 Jan 2019, Elijah Newren wrote:
>
> > On Wed, Jan 16, 2019 at 5:37 AM Johannes Schindelin via GitGitGadget
> > wrote:
> > >
> > > From: Johannes Schind
On Fri, Jan 18, 2019 at 9:55 AM Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
> > I am about to submit a new iteration of my patch series, would it be too
> > much trouble for you to rebase on top? If it would be, let me know, then I
> > will rebase on top of yours.
>
> Or both of you k
On Fri, Jan 18, 2019 at 3:22 PM Junio C Hamano wrote:
> * en/rebase-merge-on-sequencer (2019-01-07) 8 commits
> - rebase: implement --merge via the interactive machinery
> - rebase: define linearization ordering and enforce it
> - git-legacy-rebase: simplify unnecessary triply-nested if
> - gi
Hi Dscho,
On Mon, Jan 21, 2019 at 8:10 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Tue, 11 Dec 2018, Elijah Newren wrote:
>
> > While 'quiet' and 'interactive' may sound like antonyms, the interactive
> > machinery actually has logic that im
Hi Dscho,
On Mon, Jan 21, 2019 at 8:07 AM Johannes Schindelin
wrote:
>
> Hi,
>
> On Tue, 11 Dec 2018, Elijah Newren wrote:
>
> > The post-rewrite hook is supposed to be invoked for each rewritten
> > commit. The fact that a commit was selected and processed by the
responses. In fact, I had somewhat
forgotten about this email.
> On Thu, 21 Jun 2018, Elijah Newren wrote:
>
> > Thanks for all the food for thought. This is awesome.
>
> :-)
>
> > On Thu, Jun 21, 2018 at 3:57 AM, Johannes Schindelin
> > wrote:
> > > On Wed,
Hi Dscho,
On Mon, Jan 21, 2019 at 1:01 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Mon, 21 Jan 2019, Johannes Schindelin wrote:
>
> > On Tue, 11 Dec 2018, Elijah Newren wrote:
> >
> > > Differences since v3 (full range-diff below):
> > >
On Mon, Jan 21, 2019 at 2:02 AM Duy Nguyen wrote:
>
> On Sat, Jan 19, 2019 at 10:45 PM Patrick Hogg wrote:
> >
> > ac77d0c37 ("pack-objects: shrink size field in struct object_entry",
> > 2018-04-14) added an extra usage of read_lock/read_unlock in the newly
> > introduced oe_get_size_slow for th
On Mon, Jan 21, 2019 at 11:52 PM Jeff King wrote:
>
> The Git Merge Contributor Summit is a little over a week away. If you're
> interested in coming but haven't signed up, please do! We have a few
> spaces available still. Details are in the previous announcement:
>
> http://public-inbox.org/gi
Duy, Patrick,
On Tue, Jan 22, 2019 at 9:52 AM Elijah Newren wrote:
>
> On Mon, Jan 21, 2019 at 2:02 AM Duy Nguyen wrote:
> >
> > On Sat, Jan 19, 2019 at 10:45 PM Patrick Hogg wrote:
> > >
> > > ac77d0c37 ("pack-objects: shrink size field in struct
Hello,
On Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl
wrote:
>
> Hi!
>
> Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that "--no-commit" no
> longer does what it did before (AFAIR, but I mostly did --no-ff merges in
> SLES11):
> Like this (sorry German):
>
> > git merge --no-commit loca
ned-off-by: Elijah Newren
---
The critical part of the patch is the few line change to
show_raw_diff(), the rest is plumbing to set that up.
This patch was based out of Peff's suggestion[1] to fix diff-tree to
do what I needed rather than bending fast-export to cover my usecase;
I've
Hi,
On Thu, Jan 24, 2019 at 6:19 PM brian m. carlson
wrote:
>
> On Thu, Jan 24, 2019 at 08:46:54AM -0800, Elijah Newren wrote:
> > The critical part of the patch is the few line change to
> > show_raw_diff(), the rest is plumbing to set that up.
> >
> > This
Hi,
On Fri, Jan 25, 2019 at 6:45 AM Derrick Stolee wrote:
>
> On 1/24/2019 11:46 AM, Elijah Newren wrote:
> > As an alternative, I considered perhaps trying to sell it as a bugfix
> > (how often do people use -M, -c, and --raw together and have renames
> > in merge comm
ned-off-by: Elijah Newren
---
Differences since v1: added a testcase, with and without -z
Documentation/diff-format.txt | 23 +---
Documentation/git-diff-tree.txt| 9 +--
Documentation/rev-list-options.txt | 5
combine-diff.c
On Fri, Jan 25, 2019 at 9:41 AM Derrick Stolee wrote:
>
> On 1/25/2019 11:54 AM, Elijah Newren wrote:
> > +test_expect_success '--combined-with-paths works with -z as well' '
> > + printf "0f9645804ebb04cc3eef91f799eb7fb
On Fri, Jan 25, 2019 at 11:29 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > The raw diff format for merges with -c or --cc will only list one
> > filename, even if rename detection is active and a rename was detected
> > for the given path. Examples:
>
On Fri, Jan 25, 2019 at 11:51 AM Eric Sunshine wrote:
>
> On Fri, Jan 25, 2019 at 12:52 PM Elijah Newren wrote:
> > On Fri, Jan 25, 2019 at 9:41 AM Derrick Stolee wrote:
> > > On 1/25/2019 11:54 AM, Elijah Newren wrote:
> > > > + printf "0f9645804ebb
On Fri, Jan 25, 2019 at 2:21 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Also, my first version of the patch actually showed all names, on all
> > lines, but I found the heavy repetition really annoying, and not in
> > keeping with how non-merge commits
y.c fuey.c phooey.c
Further, in patch format, this changes the from/to headers so that
instead of just having one "from" header, we get one for each parent.
For example, instead of having
--- a/phooey.c
+++ b/phooey.c
we would see
--- a/fooey.c
--- a/fuey.c
+++ b/phooey.c
Signed-o
t;error:" prefix from the builtin
version of rebase, and change the prefix from "error:" to "fatal:" in
the legacy script to match.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
builtin/rebase.c | 10 +-
git-legacy-rebase.sh | 12 ++-
inery even though we have
no empty commits). A subsequent commit will remove the inconsistency in
--skip handling.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
t/t5407-post-rewrite-hook.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/
turning on topological sorting is actually a
performance improvement: by way of comparison, turning on --topo-order
made fast-export faster (see
https://public-inbox.org/git/20090211135640.ga19...@coredump.intra.peff.net/).
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
git-
presence of a
"verbose" file in the state_dir, while the other was signalled by the
contents of a "quiet" file was just weirdly inconsistent. (This
inconsistency pre-dated the rewrite into C.) Make them consistent by
having them both key off the presence of the file.
Acked-by
treat it as an empty commit trivially squashed into
its parent.
This brings the rebase--am and rebase--merge backends in sync with the
behavior of the interactive rebase backend.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
builtin/am.c | 9 +
git-r
y thoroughly in the rebase
man page (in the "Incompatible Options" section, with multiple links
throughout the document), and since I expect this list to change over
time, just simplify the error message.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
builtin/rebase.c
f.bet/)
Elijah Newren (8):
rebase: make builtin and legacy script error messages the same
rebase: fix incompatible options error message
t5407: add a test demonstrating how interactive handles --skip
differently
am, rebase--merge: do not overlook --skip'ed commits with post-rew
giving us the following form:
if incompatible_opts:
if interactive:
show_error_about_interactive_and_am_incompatibilities
if rebase-merge:
show_error_about_merge_and_am_incompatibilities
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
git-legacy-rebase.sh | 20
1 - 100 of 1789 matches
Mail list logo
