Junio C Hamano gits...@pobox.com wrote:
Chris, do you remember if there was a reason why it was a bad idea
to teach the normal rebase codepath to handle --root? I think we
would have needed to allow am to apply a creation patch and start
a new history on an unborn branch in order to do so,
Thomas Rast t...@thomasrast.ch wrote:
Please take a closer look at the last two test cases that specify the
expected behaviour of rebasing a branch that tracks the empty tree.
At this point they expect the Nothing to do error (aborts with
untouched history). This is consistent with rebasing
Fabian Ruch baf...@gmail.com wrote:
you're the original author of the code touched by this patch. Is the
second -q option really a simple copy-and-paste of the first or am I
overlooking something here? I'd like to confirm this as, in retrospect,
I feel a bit uncertain about the hasty claim in
Felipe Contreras felipe.contre...@gmail.com writes:
Implemented now. I'm not handling the 'tip' revision, but most likely
it's also the '.' revision. In this case a fake 'master' bookmark will
be created to track that revision.
Hi Felipe. Sorry for the slow response, I've been snowed under
log --graph
@ changeset: 2:ca09651009cb
| tag: tip
| parent: 0:9f552c53d116
| user:Chris Webb ch...@arachsys.com
| date:Tue Oct 30 09:33:38 2012 +
| summary: two
|
| o changeset: 1:58fad8998339
|/ user:Chris Webb ch
Chris Webb ch...@arachsys.com writes:
The first is really a symptom of a general difference between hg and git: an
hg
repository can have multiple heads, whereas a git repo has exactly one head.
By this I mean an hg repository without bookmarks or branches can still have
multiple heads
Felipe Contreras felipe.contre...@gmail.com writes:
Yes, it seems this is an API issue; repo.branchtip doesn't exist in
python 2.2.
Hi. Presumably this is a problem with old mercurial not a problem with old
python as mentioned in the commit?
Both issues should be fixed now :)
They are
Chris Webb ch...@arachsys.com writes:
A common idiom when working with hg bookmarks is to completely ignore the
(not very useful) hg branches (i.e. all commits are on the default hg
branch) and have a bookmark for each line of development used exactly as a
git branch would
Martin von Zweigbergk martinv...@gmail.com writes:
For consistency, it seems like git rebase -p --root should always be
a no-op, while git rebase [-i/-m] --root should be no-op if the
history has no merges. Also, since git rebase -i tries to
fast-forward through existing commits, it seems
Martin von Zweigbergk martinv...@gmail.com writes:
On Tue, Sep 18, 2012 at 12:53 AM, Johannes Sixt j.s...@viscovery.net wrote:
Why? Is it more like --root implies --force?
It doesn't currently exactly imply --force, but the effect is the
same. Also see my reply to Junio's email in this
Neil Horman nhor...@tuxdriver.com writes:
Having read over this thread, I think this is definately the way to go. As
discussed having cherry-pick stop and give the user a chance to fix empty
history messages by default, and providing a switch to override that behavior
makes sense to me.
Junio C Hamano gits...@pobox.com writes:
My recommendation, backed by the above line of thought, is to add
support for the --allow-empty-message option to both rebase [-i]
and cherry-pick, defaulting to false.
Thanks for the very detailed analysis and advice Junio. I like your
suggested
be overridden.
Signed-off-by: Chris Webb ch...@arachsys.com
---
Documentation/git-cherry-pick.txt | 5 +
builtin/revert.c | 2 ++
sequencer.c | 3 +++
sequencer.h | 1 +
t/t3505-cherry-pick-empty.sh | 5 +
5 files changed
Whilst doing some extra sanity checking of my git-rebase--interactive.sh
patch yesterday, I came across a behaviour which has been present for some
time, but seems surprising. You can reproduce with
$ git init -q foo cd foo
$ touch one git add one git commit -q -m one
$ touch two git
Johannes Sixt j...@kdbg.org writes:
Am 24.07.2012 14:17, schrieb Chris Webb:
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bef7bc0..0d2056f 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -493,25 +493,28 @@ do_next
Chris Webb ch...@arachsys.com writes:
If we have a conflict in the middle of a chain of fixup/squashes, as far as
I can see, we have a HEAD with all the previous successful fixups applied,
conflict markers for the current failed pick, and when the conflict has been
resolved, git rebase
Johannes Sixt j...@kdbg.org writes:
One subtlety to watch out for is when commit messages are edited. That is,
if you edit the proposed message at 'rebase --continue' after the first
squash failed, is the new text preserved until the last squash? I *think*
that previously that was the case.
no parent.
Fix rebase -i to use commit --amend for fixup and squash instead, and
add a test for the case of a fixup of the root commit.
Signed-off-by: Chris Webb ch...@arachsys.com
---
Sorry, I should have spotted this issue when I did the original root-rebase
series. I've checked that this patch
, it will still abort later if an
empty message is saved from the editor. (That check was already present
and necessary to prevent a non-empty commit message being edited to an
empty one.)
Signed-off-by: Chris Webb ch...@arachsys.com
---
builtin/commit.c |2 +-
1 file changed, 1 insertion(+), 1
Junio C Hamano gits...@pobox.com writes:
Yeah, it is a bug that exists only because nobody sane uses empty
message commits, let alone tries to amend such commits, hence went
unnoticed for a long time.
Quite. I only noticed it because this is the default behaviour of Github
gists and I wanted
-off-by: Chris Webb ch...@arachsys.com
---
builtin/commit.c |2 +-
t/t7501-commit.sh | 15 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index f43eaaf..6515da2 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -640,7
21 matches
Mail list logo
