From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Edward Thomson <ethomson@edwardthomson.com>, git@vger.kernel.org
Subject: Re: [PATCH] add: add --chmod=+x / --chmod=-x options
Date: Fri, 27 May 2016 11:35:00 -0700 [thread overview]
Message-ID: <xmqqinxzqrhn.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1605250923120.4449@virtualbox> (Johannes Schindelin's message of "Wed, 25 May 2016 09:46:17 +0200 (CEST)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I wonder, however, whether it would be "cleaner" to simply make this an
> OPT_STRING and perform the validation after the option parsing.
Yes, I think I touched on this in my comments in a bit more detail.
> Hmm. This change uses up 2 out of 31 available bits. I wonder whether a
> better idea would be to extend struct update_callback_data to include a
> `force_mode` field, pass a parameter of the same name to
> add_files_to_cache() and then handle that in the update_callback().
Maybe. I am not sure if it is a good idea to do lstat(2) on the
calling side, though. Assuming it is, your "something like this"
needs to be duplicated for the codepath that adds a new file, which
is separate from the one we see below (i.e. add_files()).
> Something like this:
>
> case DIFF_STATUS_MODIFIED:
> - case DIFF_STATUS_TYPE_CHANGED:
> + case DIFF_STATUS_TYPE_CHANGED: {
> + struct stat st;
> + if (lstat(path, &st))
> + die_errno("unable to stat '%s'", path);
> + if (S_ISREG(&st.st_mode) && data->force_mode)
> + st.st_mode = data->force_mode;
> - if (add_file_to_index(&the_index, path, data->flags)) {
> + if (add_to_index(&the_index, path, &st, data->flags)) {
> if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
> die(_("updating files failed"));
> data->add_errors++;
> }
> break;
> + }
next prev parent reply other threads:[~2016-05-27 18:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-25 2:06 [PATCH] add: add --chmod=+x / --chmod=-x options Edward Thomson
2016-05-25 7:36 ` Junio C Hamano
2016-05-25 12:19 ` Johannes Schindelin
2016-05-25 16:10 ` Junio C Hamano
2016-05-25 16:49 ` Johannes Schindelin
2016-05-25 16:00 ` Junio C Hamano
2016-05-27 4:41 ` Edward Thomson
2016-05-27 5:12 ` Mike Hommey
2016-05-27 6:36 ` Junio C Hamano
2016-05-27 18:30 ` Junio C Hamano
2016-05-31 22:06 ` Edward Thomson
2016-05-25 7:46 ` Johannes Schindelin
2016-05-27 18:35 ` Junio C Hamano [this message]
2016-05-25 7:51 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2016-05-31 22:08 Edward Thomson
2016-05-31 22:34 ` Junio C Hamano
2016-06-01 7:23 ` Johannes Schindelin
2016-06-01 10:19 ` Johannes Schindelin
2016-06-01 16:00 ` Junio C Hamano
2016-06-07 22:59 ` Edward Thomson
2016-06-08 0:39 ` Junio C Hamano
2016-06-08 11:46 ` Duy Nguyen
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqinxzqrhn.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=ethomson@edwardthomson.com \
--cc=git@vger.kernel.org \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.