Trying again from plain old gmail which I think does not send a
multipart content.
On Fri, Nov 7, 2014 at 11:06 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
Is this also related to git checkout $rev . not removing removed files?
What you say about the difference in implementation
, not an implementation glitch.
Pardon HTML, misspellings and grammos, typed on a tablet.
On Nov 7, 2014 11:10 PM, Martin von Zweigbergk martinv...@gmail.com
wrote:
Trying again from plain old gmail which I think does not send a
multipart content.
On Fri, Nov 7, 2014 at 11:06 PM, Martin von Zweigbergk
First of all, thanks again for spending time on this.
On Sat, Nov 8, 2014 at 12:30 AM, Jeff King p...@peff.net wrote:
On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
So just to be clear, the behavior we want is that:
echo foo some-new-path
git add some-new-path
git
On Sat, Aug 24, 2013 at 9:19 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Thomas Ackermann wrote:
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1784,17 +1784,6 @@ repository that you pulled from.
fast-forwards,fast-forward; instead, your branch will just be
Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
---
While trying to use patch-id instead of
--ignore-if-in-upstream/--cherry-pick/cherry/etc, I noticed that
patch-id ignores empty patches and I was surprised that tests still
pass. This test case would be useful to protect
Add test cases for 'git rebase --keep-empty' with and without an
empty commit already in upstream. The empty commit that is about to
be rebased should be kept in both cases.
Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
---
Added another test for when the upstream already
A while ago when I was looking at revision.c, I was surprised to see
that commits are sorted even when --no-walk is passed, but as 8e64006
(Teach revision machinery about --no-walk, 2007-07-24) points out,
this can be useful for doing
$ git log --abbrev-commit --pretty=oneline --decorate --all
On Fri, Aug 10, 2012 at 2:38 PM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
There is also cherry-pick/revert, which I _think_ does not really want
the revisions sorted.
Yes, I think sequencer.c::prepare_revs() is wrong
On Mon, Aug 13, 2012 at 12:17 AM, Junio C Hamano gits...@pobox.com wrote:
y...@google.com writes:
[Administrivia: I somehow doubt y...@google.com would reach you, and
futzed with the To: line above]
:-( Sorry, sendemail.from now set. (I apparently answered y instead
of just enter to accept
On Mon, Aug 13, 2012 at 10:05 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
... so is a migration desired? Or just
change the default for --no-walk from sorted to unsorted in git
2.0?
I think the proper support for Johannes's case
On Mon, Aug 13, 2012 at 1:05 PM, Junio C Hamano gits...@pobox.com wrote:
y...@google.com writes:
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
'git cherry-pick' internally sets the --reverse option while walking
revisions, so that 'git cherry-pick branch@{u}..branch' will apply
On Mon, Aug 13, 2012 at 3:21 PM, Junio C Hamano gits...@pobox.com wrote:
* Let's do this before I forget...; came up in discussion $gmane/203370
Thanks! That definitely confused me (and I suppose I stupidly didn't
test with a proper range).
Documentation/rev-list-options.txt | 29
On Mon, Aug 13, 2012 at 4:05 PM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 6a4b635..dc501ee 100644
--- a/Documentation/rev-list-options.txt
On Mon, Aug 13, 2012 at 4:53 PM, Junio C Hamano gits...@pobox.com wrote:
Stephen Boyd bebar...@gmail.com writes:
Can we throw up a big warning or just outright fail if someone types
'n' or 'y' and hits enter for the in-reply-to question in
git-send-email? I saw a git-send-email sent patch
On Mon, Aug 13, 2012 at 2:05 PM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
To connect to the other mail I sent on this thread (in parallel with
yours), do you think git cherrry-pick HEAD HEAD~1 should apply the
commits in the same
On Wed, Aug 15, 2012 at 10:16 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
So all of the above case give the right result in the end as long
as the timestamps are chronological, and case 1) gives the right
result regardless
On Wed, Aug 15, 2012 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes:
Makes sense, I'll try to implement it that way. I was afraid that
we would need to call prepare_revision_walk() once first and then
if we afterwards find out
On Wed, Aug 15, 2012 at 1:02 PM, Junio C Hamano gits...@pobox.com wrote:
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 6a4b635..9404d08 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -578,16 +578,33 @@
to martinv...@gmail.com (not y...@google.com
;-) which saves a few keystrokes and matches some of my other
accounts, so these patches will be the first ones from the new
address.
Martin von Zweigbergk (3):
teach log --no-walk=unsorted, which avoids sorting
demonstrate broken 'git cherry-pick three one
or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
Documentation/rev-list-options.txt | 12
builtin/log.c | 2 +-
builtin
Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't
currently work. Add a test case to demonstrate it.
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3508-cherry-pick-many-commits.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t3508
://thread.gmane.org/gmane.comp.version-control.git/164794
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
builtin/revert.c| 2 +-
sequencer.c | 4 +++-
t/t3508-cherry-pick-many-commits.sh | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff
(Resending as plain text, sorry about duplicate, Junio.)
On Thu, Aug 30, 2012 at 4:13 PM, Junio C Hamano gits...@pobox.com wrote:
In many scripted Porcelain commands, we find this idiom:
if test $(git rev-parse --verify A) = $(git merge-base A B)
then
... A is an ancestor of
On Fri, Aug 31, 2012 at 10:58 AM, Junio C Hamano gits...@pobox.com wrote:
And git blame $path probably should expect $path is something that
appear in the tree of HEAD; apparently it does not.
That probably makes sense. For anyone deciding to implement that, note
that git blame -C [-C [-C]]
|| usage
+ action=${1##--}
+ ;;
It looks like this could be trivially combined with the previous case
arm, making the match --continue|--skip|--abort|--edit-todo).
--8--
Author: Martin von Zweigbergk martinv...@gmail.com
rebase usage: subcommands can
On Mon, Sep 17, 2012 at 10:23 PM, Andrew Wong andrew.k...@gmail.com wrote:
On 09/18/12 00:58, Martin von Zweigbergk wrote:
On Mon, Sep 17, 2012 at 6:28 PM, Andrew Wong andrew.k...@gmail.com wrote:
+ test M = $(git cat-file commit HEAD^ | sed -ne \$p)
+ test L = $(git cat-file
Add more test cases to check that the topology after a rebase is as
expected. Conflicts are not considered, but patch-equivalence is.
---
Tests pass and fail as indicated by the suffix
(_success/_failure). Your input especially appreciated on whether you
agree with the intent of the test cases.
On Tue, Sep 18, 2012 at 12:51 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
do you agree
that 'rebase --onto does not re-apply patches in onto' is desirable?
This depends on how you look at --onto. Recall the most typical and
the original
[+Chris Webb regarding git rebase --root]
First of all, thanks for a meticulous review!
On Tue, Sep 18, 2012 at 12:53 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 9/18/2012 8:31, schrieb Martin von Zweigbergk:
Since here and in the following tests the test cases and test descriptions
On Thu, Sep 27, 2012 at 5:20 AM, Chris Webb ch...@arachsys.com wrote:
You're right that rebase --root without --onto always creates a brand new
root as a result of the implementation using a sentinel commit. Clearly this
is what's wanted with --interactive
That's not as clear as one might
On Tue, Oct 16, 2012 at 12:58 PM, Damien Robert
damien.olivier.robert+gm...@gmail.com wrote:
Now feature is rebased against master. How would you rebase the branches
patch1, patch2 and build so that they keep the same layout?
I tried to rebase patch1 and patch2, hoping that rebase -p build
Hi,
I think I have some patches at home that instead teach 'git am' the
--keep-empty flag. Does that make sense? It's been a while since I
looked at it, but I'll try to take a look tonight (PST).
Martin
On Tue, May 28, 2013 at 6:29 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi,
As Junio asked in the previous iteration, shouldn't this have been in
the first patch?
On Tue, May 28, 2013 at 9:16 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
We are not in am mode.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-rebase--cherrypick.sh | 10
Same here: should this have been in the first patch? If not, do you
know for how long it has been broken (since which commit)?
On Tue, May 28, 2013 at 9:16 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-rebase.sh | 1 +
Actually, are all of 2/8 - 7/8 fixes for things that broke in patch 1/8?
On Tue, May 28, 2013 at 9:16 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
We don't use the 'rebase-apply'.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-rebase--cherrypick.sh | 4
On Tue, May 28, 2013 at 10:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 29, 2013 at 12:33 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
As Junio asked in the previous iteration, shouldn't this have been in
the first patch?
No, the first patch is splitting
:-)
On Tue, May 28, 2013 at 11:05 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 29, 2013 at 12:51 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Tue, May 28, 2013 at 10:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
One change splits, the other
---
t/t3401-rebase-partial.sh | 24
t/t3420-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 58f4823..7ba1797 100755
---
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch topic from tag created by test_commit
---
t/t3406-rebase-message.sh | 30 +-
1 file changed, 9 insertions(+), 21
Helped-by: Johannes Sixt j...@kdbg.org
---
t/lib-rebase.sh | 15
t/t3420-rebase-topology-linear.sh | 78 +++
2 files changed, 93 insertions(+)
create mode 100755 t/t3420-rebase-topology-linear.sh
diff --git a/t/lib-rebase.sh
---
t/t3420-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3420-rebase-topology-linear.sh
b/t/t3420-rebase-topology-linear.sh
index 40fe264..2429aa8 100755
--- a/t/t3420-rebase-topology-linear.sh
+++
t3406 is supposed to test messages from rebase operation, so let's
move tests in t3400 that fit that description into 3406. Most of the
functionality they tested, except for the messages, has now been
subsumed by t3420.
---
t/t3400-rebase.sh | 22 --
---
t/t3400-rebase.sh | 31 +
t/t3401-rebase-partial.sh | 45 ---
t/t3404-rebase-interactive.sh | 10 +-
t/t3409-rebase-preserve-merges.sh | 53
t/t3425-rebase-topology-merges.sh | 250 ++
5 files changed, 252
---
t/lib-rebase.sh | 17
t/t3420-rebase-topology-linear.sh | 85 +++
2 files changed, 102 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 62b3887..16eeb1c 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@
After way too long, here is finally a new version of the tests I sent
at: http://thread.gmane.org/gmane.comp.version-control.git/205796.
I have split the test up into two files. They stil take quite some
time to run.
Martin von Zweigbergk (7):
add simple tests of consistency across rebase
On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
+# f
+# /
+# a---b---c---g---h
+# \
+# d---G---i
...
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase
On Wed, May 29, 2013 at 12:31 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto --root with merge-base does not
go to root
+ reset_rebase
On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 30, 2013 at 12:30 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/29/2013 8:39, schrieb Martin von Zweigbergk
On Wed, May 29, 2013 at 11:40 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 30, 2013 at 1:14 AM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Wed, May 29, 2013 at 10:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 30, 2013 at 12:30 AM, Martin
On Thu, May 30, 2013 at 5:54 AM, Johannes Sixt j...@kdbg.org wrote:
Am 30.05.2013 07:30, schrieb Martin von Zweigbergk:
On Wed, May 29, 2013 at 12:09 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
+# f
+# /
+# a---b---c---g---h
On Wed, May 29, 2013 at 12:57 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
+# a---b---c
+# \ \
+# d---e \
+#\ \ \
+# n---o---w---v
+# \
+# z
+#TODO
Patches are now expected to be dropped iff they are on upstream. I've
also followed all of Johannes's other suggestions except for the one
about topo-order.
Martin von Zweigbergk (7):
add simple tests of consistency across rebase types
add tests for rebasing with patch-equivalence present
Helped-by: Johannes Sixt j...@kdbg.org
---
t/lib-rebase.sh | 15
t/t3420-rebase-topology-linear.sh | 78 +++
2 files changed, 93 insertions(+)
create mode 100755 t/t3420-rebase-topology-linear.sh
diff --git a/t/lib-rebase.sh
---
t/t3401-rebase-partial.sh | 24
t/t3420-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 58f4823..7ba1797 100755
---
---
t/lib-rebase.sh | 17
t/t3420-rebase-topology-linear.sh | 85 +++
2 files changed, 102 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 62b3887..16eeb1c 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@
t3406 is supposed to test messages from rebase operation, so let's
move tests in t3400 that fit that description into 3406. Most of the
functionality they tested, except for the messages, has now been
subsumed by t3420.
---
t/t3400-rebase.sh | 22 --
---
t/t3400-rebase.sh | 31 +
t/t3401-rebase-partial.sh | 45 ---
t/t3404-rebase-interactive.sh | 10 +-
t/t3409-rebase-preserve-merges.sh | 53
t/t3425-rebase-topology-merges.sh | 252 ++
5 files changed, 254
---
t/t3420-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3420-rebase-topology-linear.sh
b/t/t3420-rebase-topology-linear.sh
index 81e3d59..659a7b3 100755
--- a/t/t3420-rebase-topology-linear.sh
+++
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch topic from tag created by test_commit
---
t/t3406-rebase-message.sh | 30 +-
1 file changed, 9 insertions(+), 21
---
The reason is that this check is incomplete:
test_revision_subjects 'd i e u' HEAD~2 HEAD^2 HEAD^ HEAD
Nice catch! This should fix it. I couldn't use the method you
suggested because of how test_revision_subjects works (repeated
revisions are ignored), but this makes the check stricter
On Tue, May 28, 2013 at 11:39 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
create mode 100755 t/t3420-rebase-topology-linear.sh
Just FYI, there's another test case with the same number
(t3420-rebase-autostash) in pu. I don't know how you normally handle
such cases.
--
To unsubscribe
On Mon, Jun 3, 2013 at 11:05 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
On Tue, May 28, 2013 at 11:39 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
create mode 100755 t/t3420-rebase-topology-linear.sh
Just FYI, there's another
t3406 is supposed to test messages from rebase operation, so let's
move tests in t3400 that fit that description into 3406. Most of the
functionality they tested, except for the messages, has now been
subsumed by t3420.
---
t/t3400-rebase.sh | 22 --
The only change since v4 should be that t3420 was renamed t3421.
Martin von Zweigbergk (7):
add simple tests of consistency across rebase types
add tests for rebasing with patch-equivalence present
add tests for rebasing of empty commits
add tests for rebasing root
add tests
---
t/lib-rebase.sh | 17
t/t3421-rebase-topology-linear.sh | 85 +++
2 files changed, 102 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 62b3887..16eeb1c 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@
---
t/t3401-rebase-partial.sh | 24
t/t3421-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 58f4823..7ba1797 100755
---
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch topic from tag created by test_commit
---
t/t3406-rebase-message.sh | 30 +-
1 file changed, 9 insertions(+), 21
---
t/t3421-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index 81e3d59..659a7b3 100755
--- a/t/t3421-rebase-topology-linear.sh
+++
Helped-by: Johannes Sixt j...@kdbg.org
---
t/lib-rebase.sh | 15
t/t3421-rebase-topology-linear.sh | 78 +++
2 files changed, 93 insertions(+)
create mode 100755 t/t3421-rebase-topology-linear.sh
diff --git a/t/lib-rebase.sh
---
t/t3400-rebase.sh | 31 +
t/t3401-rebase-partial.sh | 45 ---
t/t3404-rebase-interactive.sh | 10 +-
t/t3409-rebase-preserve-merges.sh | 53
t/t3425-rebase-topology-merges.sh | 258 ++
5 files changed, 260
On Mon, Jun 3, 2013 at 3:28 PM, Junio C Hamano gits...@pobox.com wrote:
+
+# checks that the revisions in $2 represent a linear range with the
+# subjects in $1
+test_linear_range () {
+ ! { git log --format=%p $2 | sane_grep ;}
An interesting way to spell:
test $(git rev-list
On Mon, Jun 3, 2013 at 11:15 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/4/2013 7:14, schrieb Martin von Zweigbergk:
On Mon, Jun 3, 2013 at 3:28 PM, Junio C Hamano gits...@pobox.com wrote:
+
+# checks that the revisions in $2 represent a linear range with the
+# subjects in $1
On Tue, Jun 4, 2013 at 10:18 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
---
+#TODO: make all flavors of rebase use --topo-order
+test_run_rebase success 'e n o' ''
+test_run_rebase success 'e n o' -m
+test_run_rebase success 'n o e' -i
I
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3401-rebase-partial.sh | 24
t/t3421-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh b/t
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/lib-rebase.sh | 17
t/t3421-rebase-topology-linear.sh | 85 +++
2 files changed, 102 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 1e0ff28..4b74ae4
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/lib-rebase.sh | 16
t/t3421-rebase-topology-linear.sh | 78 +++
2 files changed, 94 insertions(+)
create mode 100755 t/t3421
t3406 is supposed to test messages from rebase operation, so let's
move tests in t3400 that fit that description into 3406. Most of the
functionality they tested, except for the messages, has now been
subsumed by t3420.
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3400
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3421-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index f19f0d0..e67add6 100755
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch topic from tag created by test_commit
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3406-rebase-message.sh | 30
Changes since v5:
* Improved test_linear_range
* Changed TODOs to be about consistency, not --topo-order
Martin von Zweigbergk (7):
add simple tests of consistency across rebase types
add tests for rebasing with patch-equivalence present
add tests for rebasing of empty commits
add
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3400-rebase.sh | 31 +
t/t3401-rebase-partial.sh | 45 ---
t/t3404-rebase-interactive.sh | 10 +-
t/t3409-rebase-preserve-merges.sh | 53
t/t3425-rebase-topology-merges.sh | 258
On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
You need two sides to have an argument.
I disagree. Unless you mean than, whenever a part behaves in a
hostile and
Yes, sorry. I find this whole story quite amusing (albeit distracting
and unnecessary), but sorry for adding to the spam. I'll be quiet now.
On Mon, Jun 10, 2013 at 11:33 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
martinv
On Sun, Jun 9, 2013 at 9:40 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t3425-rebase-topology-merges.sh | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git
On Thu, Jun 13, 2013 at 11:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
@@ -82,7 +82,7 @@ static int reset_index(const unsigned char *sha1, int
reset_type, int quiet)
if (unpack_trees(nr, desc, opts))
return -1;
- if (reset_type == MIXED ||
On Thu, Jun 13, 2013 at 3:29 PM, Junio C Hamano gits...@pobox.com wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
A more troublesome is that nobody seems to check the return value of
this function. If head-name, onto or orig-head is missing, is that
an error condition that should make
On Tue, Jun 18, 2013 at 12:28 AM, Johannes Sixt j.s...@viscovery.net wrote:
The recently introduced tests used uppercase letters to denote
cherry-picks of commits having the corresponding lowercase letter names.
The helper functions also set up tags with the names of the commits.
But this
On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder jrnie...@gmail.com wrote:
In other words, HEAD always either points to an unborn or existing
branch or an existing commit. It's not clear to me what it would
mean to detach from an unborn branch.
I think it should mean that the next commit
On Tue, Nov 27, 2012 at 12:25 PM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
simplify a lot of things (maybe I'm biased because of the things I
have happened to work on?)
Yes. Do not waste time on it.
Yes, no way I would waste time on that; I
When run on an unborn branch, git reset currently fails with:
fatal: Failed to resolve 'HEAD' as a valid ref.
Fix this by interpreting it as a reset to the empty tree.
If --patch is given, we currently pass the revision specifier, as
given on the command line, to interactive_reset(). On an
I decided to address this before cherry-pick on unborn branch. RFC
mostly because I'm not sure about the user interface. When we have
agreed on that, I will add documentation.
Martin von Zweigbergk (2):
reset: learn to reset to tree
reset: learn to reset on unborn branch
builtin/reset.c
In cases where HEAD is not supposed to be updated, there is no reason
that git reset should require a commit, a tree should be enough. So
make git reset $rev^{tree} work just like git reset $rev, except
that the former will not update HEAD (since there is no commit to
point it to).
Disallow
On Thu, Nov 29, 2012 at 10:47 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
In cases where HEAD is not supposed to be updated, there is no reason
that git reset should require a commit, a tree should be enough. So
make git reset $rev^{tree
On Thu, Nov 29, 2012 at 11:13 AM, Junio C Hamano gits...@pobox.com wrote:
[...]These
two commands, reset and checkout, share that the source we grab
the blobs out of only need to be a tree and does not have to be a
commit, and the only difference between them is where the blobs we
grabbed out
On Tue, Nov 27, 2012 at 11:12 PM, Junio C Hamano gits...@pobox.com wrote:
You have to special case the edges whichever way you go. [...]
If I understand you correctly, you're saying that revision walking
would need a different special case. This is the most obvious
difference, it seems. git
On Thu, Nov 29, 2012 at 2:00 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
Slightly off topic, but another difference (or somehow another aspect
of the same difference?) that has tripped me up a few times is that
git checkout $rev . only affects added and modified files (in $rev
On Sat, Dec 1, 2012 at 1:24 AM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
On Thu, Nov 29, 2012 at 2:00 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
Slightly off topic, but another difference (or somehow another aspect
of the same
On Tue, Dec 4, 2012 at 9:46 PM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
More importantly, when is it desirable not to delete deleted entries?
When I am trying to check out contents of Documentation/ directory
as of an older edition because
On Sun, Dec 9, 2012 at 3:04 PM, Junio C Hamano gits...@pobox.com wrote:
Martin von Zweigbergk martinv...@gmail.com writes:
git reset currently returns 0 (if successful) while git reset
$pathspec returns 0 iff the index matches HEAD after resetting (on
all paths, not just those matching
On Wed, Nov 23, 2011 at 12:49 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Philippe Vaucher philippe.vauc...@gmail.com writes:
Optional: a new mode would be introduced for consistency:
--worktree (or maybe --tree): only updates the worktree but not the index
That would be an alias
1 - 100 of 200 matches
Mail list logo
