On Sun, May 18, 2014 at 11:28:39PM +0300, Michael S. Tsirkin wrote:
> There's some special code in rebase -i to deal
> with --keep-empty.
> Add test for this combination.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Neil Horman
> ---
> t/t3404-rebase-interactive.
On Tue, May 28, 2013 at 09:32:59PM -0500, Felipe Contreras wrote:
> Junio C Hamano wrote:
> > Neil Horman writes:
> >
> > > On Mon, May 27, 2013 at 11:52:18AM -0500, Felipe Contreras wrote:
> > >> We should free objects before leaving.
> >
On Mon, May 27, 2013 at 11:52:19AM -0500, Felipe Contreras wrote:
> Pretty much what it says on the tin.
>
> Signed-off-by: Felipe Contreras
> ---
> Documentation/git-cherry-pick.txt | 3 +++
> builtin/revert.c| 2 ++
> sequencer.c | 5 -
> se
res = run_git_commit(defmsg, opts, allow);
> }
>
> +leave:
> free_message(&msg);
> free(defmsg);
>
> --
> 1.8.3.rc3.312.g47657de
>
>
Acked-by: Neil Horman
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 02, 2013 at 03:06:51PM -0400, Neil Horman wrote:
> On Tue, Apr 02, 2013 at 11:06:28AM -0700, Junio C Hamano wrote:
> > Neil Horman writes:
> >
> > > I've recently started looking into the possibility of having git support
> > > multiple in-prog
On Tue, Apr 02, 2013 at 11:06:28AM -0700, Junio C Hamano wrote:
> Neil Horman writes:
>
> > I've recently started looking into the possibility of having git support
> > multiple in-progress sequencers, and wanted to solicit opinions for how
> > best to
> >
Hey-
I've recently started looking into the possibility of having git support
multiple in-progress sequencers, and wanted to solicit opinions for how best to
do it. The use case is primarily for cherry-pick - i.e. I often have need to
cherry pick a large set of commits to an older kernel,
st $merges_option --pretty=oneline
> --abbrev-commit \
> while read -r shortsha1 rest
> do
>
> - if test -z "$keep_empty" && is_empty_commit $shortsha1
> + if test -z "$keep_empty" && is_empty_commit $shortsha1 && !
> is_merge
igned-off-by: Martin von Zweigbergk
Acked-by: Neil Horman
> ---
>
> Added another test for when the upstream already has an empty
> commit. The test case protects the current behavior; I just assume the
> current behavior is what we want.
>
> While writing the test case, I als
mp;
> - test $(git log --format=%s C..) = "D"
> + test "$(git log --format=%s C..)" = "D"
> +'
> +
> +test_expect_success 'rebase --keep-empty' '
> + git reset --hard D &&
> + git rebase --keep-empty C &&
On Mon, Aug 06, 2012 at 12:00:16PM +0100, Chris Webb wrote:
> 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
On Thu, Aug 02, 2012 at 11:38:51AM +0100, Chris Webb wrote:
> Scripts such as git rebase -i cannot currently cherry-pick commits which
> have an empty commit message, as git cherry-pick calls git commit
> without the --allow-empty-message option.
>
> Add an --allow-empty-message option to git cher
On Wed, Aug 01, 2012 at 10:52:34AM -0700, Junio C Hamano wrote:
> Chris Webb writes:
>
> [summary: this, when 59a8fde does not have any commit log message,
> refuses to commit]
>
Thanks for CC'ing me on this. I'm on vacation currently, but will look at this
in detail as soon as I'm back next we
rtsha1 "$rest"
> else
> sha1=$(git rev-parse $shortsha1)
> if test -z "$rebase_root"
> @@ -863,7 +866,7 @@ do
> if test f = "$preserve"
> then
> touch "$rewritten"/$
On Wed, Jul 18, 2012 at 09:10:06AM +0200, Johannes Sixt wrote:
> Am 7/18/2012 8:20, schrieb Martin von Zweigbergk:
> > On Fri, Apr 20, 2012 at 7:36 AM, Neil Horman wrote:
> >> pick_one () {
> >> ff=--ff
> >> +
> >> case &
15 matches
Mail list logo
