git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v2 6/9] commit: encapsulate determine_whence() for sequencer
Date: Fri, 06 Dec 2019 10:24:01 -0800	[thread overview]
Message-ID: <xmqqwob9wbwe.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20191206160614.631724-7-phillip.wood123@gmail.com> (Phillip Wood's message of "Fri, 6 Dec 2019 16:06:11 +0000")

Phillip Wood <phillip.wood123@gmail.com> writes:

> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> Working out which command wants to create a commit requires detailed
> knowledge of the sequencer internals and that knowledge is going to
> increase in subsequent commits. With that in mind lets encapsulate that
> knowledge in sequencer.c rather than spreading it into builtin/commit.c.
>
> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> ---
>  builtin/commit.c |  5 +----
>  sequencer.c      | 13 ++++++++++++-
>  sequencer.h      |  3 ++-
>  3 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 3b463522be..d8d4c8e419 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -178,10 +178,7 @@ static void determine_whence(struct wt_status *s)
>  {
>  	if (file_exists(git_path_merge_head(the_repository)))
>  		whence = FROM_MERGE;
> -	else if (file_exists(git_path_cherry_pick_head(the_repository)))
> -		whence = file_exists(git_path_seq_dir()) ?
> -			FROM_CHERRY_PICK_MULTI : FROM_CHERRY_PICK_SINGLE;
> -	else
> +	else if (!sequencer_determine_whence(the_repository, &whence))
>  		whence = FROM_COMMIT;
>  	if (s)
>  		s->whence = whence;
> diff --git a/sequencer.c b/sequencer.c
> index 4e0370277b..98e007556c 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -40,7 +40,7 @@ static const char cherry_picked_prefix[] = "(cherry picked from commit ";
>  
>  GIT_PATH_FUNC(git_path_commit_editmsg, "COMMIT_EDITMSG")
>  
> -GIT_PATH_FUNC(git_path_seq_dir, "sequencer")
> +static GIT_PATH_FUNC(git_path_seq_dir, "sequencer")
>  
>  static GIT_PATH_FUNC(git_path_todo_file, "sequencer/todo")
>  static GIT_PATH_FUNC(git_path_opts_file, "sequencer/opts")
> @@ -5256,3 +5256,14 @@ int todo_list_rearrange_squash(struct todo_list *todo_list)
>  
>  	return 0;
>  }
> +
> +int sequencer_determine_whence(struct repository *r, enum commit_whence *whence)
> +{
> +	if (file_exists(git_path_cherry_pick_head(r))) {
> +		*whence = file_exists(git_path_seq_dir()) ?
> +			FROM_CHERRY_PICK_MULTI : FROM_CHERRY_PICK_SINGLE;
> +		return 1;
> +	}
> +
> +	return 0;
> +}

I am not sure if this is a good move---determine_whence() that can
tell not just we are in the middle of cherry-pick (either a single
or multi) but also during a merge may be at the right abstraction
level.  Why would we want to invent a separate function that says "I
dunno" during a merge, instead of moving the logic for merge to the
new helper as well?  The original determine_whence that takes
wt_status and populates it still has to call the new helper either
way.  Also for the matter FROM_COMMIT may also want to be part of
the helper.  This all depends on the new callers you plan to invent,
of course.

Not part of this topic, but the call to file_exists() may want to
become a call to dir_exists() as git-path-seq-dir is clearly a
directory and cannot be a file, right?

  reply	other threads:[~2019-12-06 18:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-22 23:30 [PATCH 0/3] commit: fix advice for empty commits during rebases Johannes Schindelin via GitGitGadget
2019-10-22 23:30 ` [PATCH 1/3] cherry-pick: add test for `--skip` advice in `git commit` Johannes Schindelin via GitGitGadget
2019-10-22 23:30 ` [PATCH 2/3] sequencer: export the function to get the path of `.git/rebase-merge/` Johannes Schindelin via GitGitGadget
2019-10-22 23:30 ` [PATCH 3/3] commit: give correct advice for empty commit during a rebase Johannes Schindelin via GitGitGadget
2019-10-23  2:45   ` Junio C Hamano
2019-10-24 10:15   ` Phillip Wood
2019-10-25 11:48     ` Johannes Schindelin
2019-10-25 14:01       ` Phillip Wood
2019-11-08  5:28         ` Junio C Hamano
2019-11-08 14:09           ` Johannes Schindelin
2019-11-11 16:13             ` Phillip Wood
2019-10-23  3:02 ` [PATCH 0/3] commit: fix advice for empty commits during rebases Junio C Hamano
2019-10-25 12:11   ` Johannes Schindelin
2019-10-29  2:05     ` Junio C Hamano
2019-10-29 13:00       ` Johannes Schindelin
2019-12-06 16:06 ` [PATCH v2 0/9] " Phillip Wood
2019-12-06 16:06   ` [PATCH v2 1/9] t3404: use test_cmp_rev Phillip Wood
2019-12-06 17:39     ` Junio C Hamano
2019-12-06 16:06   ` [PATCH v2 2/9] cherry-pick: add test for `--skip` advice in `git commit` Phillip Wood
2019-12-06 16:06   ` [PATCH v2 3/9] cherry-pick: check commit error messages Phillip Wood
2019-12-06 16:06   ` [PATCH v2 4/9] sequencer: write CHERRY_PICK_HEAD for reword and edit Phillip Wood
2019-12-06 16:06   ` [PATCH v2 5/9] commit: use enum value for multiple cherry-picks Phillip Wood
2019-12-06 18:13     ` Junio C Hamano
2019-12-06 16:06   ` [PATCH v2 6/9] commit: encapsulate determine_whence() for sequencer Phillip Wood
2019-12-06 18:24     ` Junio C Hamano [this message]
2019-12-18 14:26       ` Phillip Wood
2019-12-06 16:06   ` [PATCH v2 7/9] commit: give correct advice for empty commit during a rebase Phillip Wood
2019-12-06 16:06   ` [PATCH v2 8/9] [RFC] rebase: fix advice when a fixup creates an empty commit Phillip Wood
2020-02-26 19:45     ` Elijah Newren
2019-12-06 16:06   ` [PATCH v2 9/9] [RFC] rebase -i: leave CHERRY_PICK_HEAD when there are conflicts Phillip Wood
2019-12-18 14:35     ` Phillip Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqwob9wbwe.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood123@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).