Re: [PATCH/WIP v2 03/19] am: implement skeletal builtin am
- From
Paul Tan <pyokagan@gmail.com>
- Date
- Jun 18, 2015, 08:44 UTC
- Message-ID
- <CACRoPnRfTCyTj=WnygzwSNu7s_2iGrtygPEh7u2d1Hqchd1ZxQ@mail.gmail.com>
- In-Reply-To
- <xmqqoakgamcj.fsf@gitster.dls.corp.google.com>
On Tue, Jun 16, 2015 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> Paul Tan <pyokagan@gmail.com> writes: > >>> The scripted Porcelain is spawned after applying patches 1-3 from >>> here, when you do not have _GIT_USE_BUILTIN_AM exported. Haven't >>> RUN_SETUP code did its thing by that time? >> >> Ah right, the RUN_SETUP code would have chdir()-ed to the working >> directory root, so git-am.sh will be unable to find the original >> working directory. To aid it, we would have to chdir() back to the >> original working directory, and unset GIT_DIR. > > I do not think that is a correct workaround, though. GIT_DIR may > have come from the end user, i.e. > > $ GIT_WORK_TREE=somewhere GIT_DIR=somewhere.else git am ...
Ah, forgot about that ><
Show 24 quoted lines
> As the RUN_SETUP|REQUIRE_WORK_TREE bit is merely a convenence in
> git.c, one workable way to keep these dual implementations is to do
> what built-in commands used to do before these were invented.
> Perhaps studying how cmd_diff(), which is run from git.c without
> either RUN_SETUP or NEED_WORK_TREE, and taking good bits from it
> would help. I think the implementation roughly would look like
> this:
>
> int cmd_am(int ac, const char **av, const char *prefix)
> {
> /*
> * NEEDSWORK: once we retire the dual-mode
> * implementation, this preamble can be removed...
> */
> if (... want to do scripted ...) {
> ... spawn the scripted thing ...
> }
> prefix = setup_git_directory();
> setup_work_tree();
> /* ... up to this point */
>
> ... your real "git am in C" comes here ...
> }
>Ah OK. Just to be sure, I took a look at run_builtin() in git.c, and indeed it only just does:
prefix = setup_git_directory(); trace_repo_setup(prefix); setup_work_tree();
which is not bad at all. Thanks.
Regards, Paul