Junio C Hamano 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, but I am no
Thomas Rast 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 only empty
Fabian Ruch 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 the log mess
Felipe Contreras 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 with work and
have only ju
Chris Webb 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 be.
>
> On suc
Felipe Contreras 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 indeed, and it now works nice
Chris Webb 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, wher
echo two >foo && hg commit -m two
created new head
$ hg log --graph
@ changeset: 2:ca09651009cb
| tag: tip
| parent: 0:9f552c53d116
| user:Chris Webb
| date:Tue Oct 30 09:33:38 2012 +
| summary: two
|
| o changeset:
Martin von Zweigbergk 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 like "git reba
Martin von Zweigbergk writes:
> On Tue, Sep 18, 2012 at 12:53 AM, Johannes Sixt 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 thread.
>
> Maybe Chris has some
Neil Horman 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. That said, shouldn't
be overridden.
Signed-off-by: Chris Webb
---
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, 16 insertions
Junio C Hamano 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 --allow-empty-
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 &&
Johannes Sixt 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.
Hi. Yes, d
Chris Webb 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 --c
Johannes Sixt 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
>
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
---
Sorry, I should have spotted this issue when I did the original root-rebase
series. I've checked that this patch doesn't br
e.
Signed-off-by: Chris Webb
---
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 +640,7 @@
Junio C Hamano 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 to replace th
n empty commit message.
Unless --allow-empty-message is in force, 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
---
builtin/commit.
21 matches
Mail list logo
