git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Shourya Shukla <periperidip@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: christian.couder@gmail.com, git@vger.kernel.org,
	levraiphilippeblain@gmail.com
Subject: Re: [PATCH v2 1/1] rm: stage submodule removal from '.gitmodules' when using '--cached'
Date: Sun, 7 Mar 2021 22:16:44 +0530	[thread overview]
Message-ID: <20210307164644.GA8702@konoha> (raw)
In-Reply-To: <xmqqo8gb7vf9.fsf@gitster.g>

On 22/02 11:29, Junio C Hamano wrote:
> Shourya Shukla <periperidip@gmail.com> writes:
> 
> > +	if (git_config_rename_section_in_file(index_only ? GITMODULES_INDEX :
> > +					      GITMODULES_FILE, sect.buf, NULL) < 0) {
> 
> Also, is it really sufficient to pass GITMODULES_INDEX as the first
> argument to this function to tweak what is in the index?
> 
> git_config_copy_or_rename_section_in_file() which is the
> implementation of that helper seems to always want to work with a
> file that is on disk, by making unconditional calls to
> hold_lock_file_for_update(), fopen(), fstat(), chmod(), etc.
> 
> So I suspect that there are much more work needed.  

I am not able to comprehend _why_ we need so much more work. To me it
seems to work fine.

The flow now is something like:

1. If !index_only i.e., '--cached' is not passed then remove the entry
of the SM from the working tree copy of '.gitmodules' i.e.,
GITMODULES_FILE. If there are any unstaged mods in '.gitmodules', we do
not proceed with 'git rm'.

2. Now, delete the entry of the above SM from the index copy of the
'.gitmodules' i.e., GITMODULES_INDEX (irrespective of the value of
'index_only'). If there are any unstaged mods in '.gitmodules', we do
not proceed with 'git rm'.

3. Finally, after the deletion of the SM entry, we stage the changes
using 'stage_updated_gitmodules()'.

Also, before any of the above thing happens, we check if it is OK to
write the '.gitmodules' using 'is_staging_gitmodules_ok()'. All the
above behaviour is in line with the current behaviour of 'git rm'.

What exactly do we need to change then?

> It seems to me that the config editing API is one of the older and
> hackier parts of the system and requires quite a lot of work to
> teach it to work with anything but a on-disk file.  In the longer
> term, it may be a good thing to clean it up, but I suspect that it
> is way too much work for too little benefit to do so as a part of
> this topic, so an easier way out for now would be to:
> 
>  - write out the .gitmodules in the index to a temporary file (learn
>    how to correctly call entry.c::checkout_entry() by studying how
>    builtin/checkout-index.c::checkout_file() calls it, especially to
>    a temporary file with the --temp option).
> 
>  - use git_config_rename_section_in_file() on that temporary file to
>    remove the section about the submodule.
> 
>  - read that temporary file back into memory and write it out as a
>    blob object by calling sha1-file.c::write_object_file().
> 
>  - add that back to the index as .gitmodules (studying how
>    builtin/update-index.c::add_cacheinfo() calls add_cache_entry()
>    would be a good way to learn how to do this).
> 
> The working tree side can stay as is, but as I said in the earlier
> message, I think you need to update the .gitmodules in the working
> tree and .gitmodules in the index separately (and without doing any
> equivalent of "git add .gitmodules").

But 'git rm' itself used to stage the changes i.e., 'git add'-ing them.

Regards,
Shourya Shukla


  reply	other threads:[~2021-03-07 16:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18 18:49 [RFC][PATCH 0/2] rm: changes in the '.gitmodules' are staged after using '--cached' Shourya Shukla
2021-02-18 18:49 ` [PATCH 1/2] " Shourya Shukla
2021-02-18 20:14   ` Philippe Blain
2021-02-18 20:39     ` Philippe Blain
2021-02-19 15:19     ` Shourya Shukla
2021-02-18 22:03   ` Junio C Hamano
2021-02-19 15:24     ` Shourya Shukla
2021-02-20  3:31       ` Junio C Hamano
2021-02-18 18:49 ` [PATCH 2/2] t3600: amend test 46 to check for '.gitmodules' modification Shourya Shukla
2021-02-18 20:21   ` Philippe Blain
2021-02-22 17:26 ` [PATCH v2 0/1] rm: stage submodule removal from '.gitmodules' Shourya Shukla
2021-02-22 17:26   ` [PATCH v2 1/1] rm: stage submodule removal from '.gitmodules' when using '--cached' Shourya Shukla
2021-02-22 18:58     ` Junio C Hamano
2021-03-05 17:58       ` Shourya Shukla
2021-03-05 21:39         ` Junio C Hamano
2021-02-22 19:29     ` Junio C Hamano
2021-03-07 16:46       ` Shourya Shukla [this message]
2021-03-07 20:29         ` Junio C Hamano
2021-03-09  7:13           ` Shourya Shukla
2021-03-09 20:47             ` Junio C Hamano

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=20210307164644.GA8702@konoha \
    --to=periperidip@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=levraiphilippeblain@gmail.com \
    /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).