Jeff King writes:
> On Mon, Jul 29, 2013 at 08:18:45AM -0700, Junio C Hamano wrote:
>
>> >if (file_exists(git_path("MERGE_HEAD")))
>> >whence = FROM_MERGE;
>> > - else if (file_exists(git_path("CHERRY_PICK_HEAD")))
>> > + else if (file_exists(git_path("CHERRY_PICK_HEAD"))) {
>>
On Mon, Jul 29, 2013 at 08:18:45AM -0700, Junio C Hamano wrote:
> > if (file_exists(git_path("MERGE_HEAD")))
> > whence = FROM_MERGE;
> > - else if (file_exists(git_path("CHERRY_PICK_HEAD")))
> > + else if (file_exists(git_path("CHERRY_PICK_HEAD"))) {
> > whence = F
Jeff King writes:
> Here it is in patch form, with an updated commit message that hopefully
> explains the rationale a bit better.
>
> -- >8 --
> Subject: [PATCH] commit: tweak empty cherry pick advice for sequencer
>
> When we refuse to make an empty commit, we check whether we
> are in a cherry
Jeff King writes:
> On Fri, Jul 26, 2013 at 05:40:36PM -0400, Jeff King wrote:
>
>> > Jeff King wrote:
>> >
>> > > Your patch is just swapping out "git reset" for "cherry-pick --abort",
>> > > so I think that is a good improvement in the meantime.
>> >
>> > Um, wasn't the idea of the original m
Jonathan Nieder wrote:
>> Your patch is just swapping out "git reset" for "cherry-pick --abort",
>> so I think that is a good improvement in the meantime.
>
> Um, wasn't the idea of the original message that you can run "git
> reset" and then "git cherry-pick --continue"?
No, and I don't know wher
Jeff King wrote:
> builtin/commit.c | 25 ++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
Overall, highly inelegant. The single-commit pick has been special
cased only because we needed to preserve backward compatibility: I
would hate for the detail to be user-visibl
On Fri, Jul 26, 2013 at 07:19:02PM -0400, Jeff King wrote:
> > Or
> >
> > If you wish to commit it anyway, use
> >
> > git commit --allow-empty
> >
> > If you wish to skip this commit, use
> >
> > git reset
> >
> > Then "git cherry-pick --continue" will
On Fri, Jul 26, 2013 at 04:08:57PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -63,8 +63,14 @@ N_("The previous cherry-pick is now empty, possibly due
> > to conflict resolution.\
> > "If you wish to commit it anyway, use:\n"
>
Jeff King wrote:
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -63,8 +63,14 @@ N_("The previous cherry-pick is now empty, possibly due to
> conflict resolution.\
> "If you wish to commit it anyway, use:\n"
> "\n"
> "git commit --allow-empty\n"
> +"\n");
> +static const char empty_
On Fri, Jul 26, 2013 at 06:43:59PM -0400, Jeff King wrote:
> I think instead we would want to leave the single-commit case alone, and
> for the multi-commit case add "...and then cherry-pick --continue". That
> message is generated from within git-commit, though; I guess it would
> need to learn a
On Fri, Jul 26, 2013 at 05:40:36PM -0400, Jeff King wrote:
> > Jeff King wrote:
> >
> > > Your patch is just swapping out "git reset" for "cherry-pick --abort",
> > > so I think that is a good improvement in the meantime.
> >
> > Um, wasn't the idea of the original message that you can run "git
On Fri, Jul 26, 2013 at 02:37:05PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Your patch is just swapping out "git reset" for "cherry-pick --abort",
> > so I think that is a good improvement in the meantime.
>
> Um, wasn't the idea of the original message that you can run "git
> rese
Jeff King wrote:
> Your patch is just swapping out "git reset" for "cherry-pick --abort",
> so I think that is a good improvement in the meantime.
Um, wasn't the idea of the original message that you can run "git
reset" and then "git cherry-pick --continue"?
Confused,
Jonathan
--
To unsubscribe
Jeff King wrote:
> Ah. I don't mind improving the message in the meantime, but it sounds
> like this is a deficiency in sequenced cherry-pick that needs addressed
> eventually.
I'm especially irked by how slow rebase--am is, and want to replace it.
--
To unsubscribe from this list: send the line "
On Sat, Jul 27, 2013 at 02:47:47AM +0530, Ramkumar Ramachandra wrote:
> > 2. Skip this commit and continue the rest of the cherry-pick sequence.
>
> Nope, this is unsupported afaik.
Ah. I don't mind improving the message in the meantime, but it sounds
like this is a deficiency in sequenced che
Jeff King wrote:
> Hmm. I don't think I've run across this message myself, so perhaps I do
> not understand the situation.
It's very simple.
# on branch master
$ git checkout -b test
$ git cherry-pick master
$ ls .git/sequencer
# missing
In the pseudo multi-pick case (I say "pseudo" be
On Fri, Jul 26, 2013 at 11:42:00PM +0530, Ramkumar Ramachandra wrote:
> When a cherry-pick results in an empty commit, git prints:
>
> The previous cherry-pick is now empty, possibly due to conflict resolution.
> If you wish to commit it anyway, use:
>
> git commit --allow-empty
>
>
When a cherry-pick results in an empty commit, git prints:
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:
git commit --allow-empty
Otherwise, please use 'git reset'
The last line is plain wrong in the case of a range
18 matches
Mail list logo
