From: Thomas Gummerer <t.gummerer@gmail.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: git@vger.kernel.org,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Jeff King" <peff@peff.net>, "Jan Keromnes" <janx@linux.com>,
"Ingo Brückl" <ib@wupperonline.de>,
"Edward Thomson" <ethomson@edwardthomson.com>,
"Junio C Hamano" <gitster@pobox.com>,
"Ramsay Jones" <ramsay@ramsayjones.plus.com>
Subject: Re: [PATCH v4 4/4] add: modify already added files when --chmod is given
Date: Sat, 12 Aug 2017 13:30:10 +0100 [thread overview]
Message-ID: <20170812123010.GA4304@hank> (raw)
In-Reply-To: <3c61d9f6-e0fd-22a4-68e0-89fd9ce9b944@web.de>
On 08/07, René Scharfe wrote:
> Am 14.09.2016 um 23:07 schrieb Thomas Gummerer:
> > When the chmod option was added to git add, it was hooked up to the diff
> > machinery, meaning that it only works when the version in the index
> > differs from the version on disk.
> >
> > As the option was supposed to mirror the chmod option in update-index,
> > which always changes the mode in the index, regardless of the status of
> > the file, make sure the option behaves the same way in git add.
> >
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
>
> Sorry for replying almost a year late, hopefully you're still interested.
Thanks for still replying :)
> > ---
> > builtin/add.c | 47 ++++++++++++++++++++++++++++-------------------
> > builtin/checkout.c | 2 +-
> > builtin/commit.c | 2 +-
> > cache.h | 10 +++++-----
> > read-cache.c | 14 ++++++--------
> > t/t3700-add.sh | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
> > 6 files changed, 91 insertions(+), 34 deletions(-)
> >
> > diff --git a/builtin/add.c b/builtin/add.c
> > index b1dddb4..595a0b2 100644
> > --- a/builtin/add.c
> > +++ b/builtin/add.c
> > @@ -26,10 +26,25 @@ static int patch_interactive, add_interactive, edit_interactive;
> > static int take_worktree_changes;
> >
> > struct update_callback_data {
> > - int flags, force_mode;
> > + int flags;
> > int add_errors;
> > };
> >
> > +static void chmod_pathspec(struct pathspec *pathspec, int force_mode)
>
> "int force_mode" looks like a binary (or perhaps ternary) flag, but
> actually it is a character and can only have the values '-' or '+'.
> In builtin/update-index.c it's called "char flip" and we probably should
> define it like this here as well.
>
> > +{
> > + int i;
> > +
> > + for (i = 0; i < active_nr; i++) {
> > + struct cache_entry *ce = active_cache[i];
> > +
> > + if (pathspec && !ce_path_match(ce, pathspec, NULL))
> > + continue;
> > +
> > + if (chmod_cache_entry(ce, force_mode) < 0)
> > + fprintf(stderr, "cannot chmod '%s'", ce->name);
>
> This error message is missing a newline. In builtin/update-index.c we
> also show the attempted change (-x or +x); perhaps we want to do that
> here as well.
Thanks for catching this, both this and the above are worth changing
imo. I see Ramsay already provided a patch for this in
https://public-inbox.org/git/aa004526-3e0d-66d4-287f-30abd29758fc@ramsayjones.plus.com/.
Thanks Ramsay!
> Currently chmod_cache_entry() can only fail if ce is not a regular
> file or it's other parameter is neither '-' nor '+'. We rule out the
> latter already in the argument parsing code. The former can happen if
> we add a symlink, either explicitly or because it's in a directory
> we're specified.
>
> I wonder if we even need to report anything, or under which conditions.
> If you have a file named dir/file and a symlink named dir/symlink then
> the interesting cases are:
>
> git add --chmod=.. dir/symlink
> git add --chmod=.. dir/file dir/symlink
> git add --chmod=.. dir
>
> Warning about each case may be the most cautious thing to do, but
> documenting that --chmod has no effect on symlinks and keeping silent
> might be less annoying, especially in the last case. What do you
> think?
I'm not sure about this. While I do agree that it could be quite
annoying in the last case, it could potentially be a bit confusing to
not get any warning in the first case. I don't have a strong opinion
either way.
> > @@ -342,13 +354,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> > if (!show_only && ignore_missing)
> > die(_("Option --ignore-missing can only be used together with --dry-run"));
> >
> > - if (!chmod_arg)
> > - force_mode = 0;
> > - else if (!strcmp(chmod_arg, "-x"))
> > - force_mode = 0666;
> > - else if (!strcmp(chmod_arg, "+x"))
> > - force_mode = 0777;
> > - else
> > + if (chmod_arg && ((chmod_arg[0] != '-' && chmod_arg[0] != '+') ||
> > + chmod_arg[1] != 'x' || chmod_arg[2]))
> > die(_("--chmod param '%s' must be either -x or +x"), chmod_arg);
>
> That's the argument parsing code mentioned above. The strcmp-based
> checks look nicer to me btw. How about this?
>
> if (chmod_arg && strcmp(chmod_arg, "-x") && strcmp(chmod_arg, "+x"))
>
> But that's just nitpicking.
I think this looks nicer indeed, thanks! But it's probably not worth
a patch for just this unless we decide to change to not warn as you
mentioned above, and can fix this at the same time?
> René
prev parent reply other threads:[~2017-08-12 12:30 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 16:08 `make profile-install` fails in 2.9.3 Jan Keromnes
2016-09-01 16:25 ` Dennis Kaarsemaker
2016-09-01 20:07 ` Thomas Gummerer
2016-09-01 21:58 ` Jeff King
2016-09-01 22:16 ` Junio C Hamano
2016-09-01 22:20 ` Jeff King
2016-09-01 22:38 ` Junio C Hamano
2016-09-04 11:39 ` [PATCH 0/4] git add --chmod: always change the file Thomas Gummerer
2016-09-04 11:39 ` [PATCH 1/4] add: document the chmod option Thomas Gummerer
2016-09-05 7:44 ` Johannes Schindelin
2016-09-05 19:22 ` Thomas Gummerer
2016-09-07 16:44 ` Junio C Hamano
2016-09-04 11:39 ` [PATCH 2/4] update-index: use the same structure for chmod as add Thomas Gummerer
2016-09-04 11:39 ` [PATCH 3/4] read-cache: introduce chmod_index_entry Thomas Gummerer
2016-09-04 11:39 ` [PATCH 4/4] add: modify already added files when --chmod is given Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 0/4] git add --chmod: always change the file Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 1/4] add: document the chmod option Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 2/4] update-index: use the same structure for chmod as add Thomas Gummerer
2016-09-11 22:28 ` Junio C Hamano
2016-09-12 19:30 ` Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 3/4] read-cache: introduce chmod_index_entry Thomas Gummerer
2016-09-11 10:30 ` [PATCH v2 4/4] add: modify already added files when --chmod is given Thomas Gummerer
2016-09-12 21:08 ` [PATCH v3 0/4] git add --chmod: always change the file Thomas Gummerer
2016-09-12 21:08 ` [PATCH v3 1/4] add: document the chmod option Thomas Gummerer
2016-09-12 21:08 ` [PATCH v3 2/4] update-index: use the same structure for chmod as add Thomas Gummerer
2016-09-12 21:59 ` Junio C Hamano
2016-09-12 21:08 ` [PATCH v3 3/4] read-cache: introduce chmod_index_entry Thomas Gummerer
2016-09-12 21:08 ` [PATCH v3 4/4] add: modify already added files when --chmod is given Thomas Gummerer
2016-09-12 22:23 ` Junio C Hamano
2016-09-14 21:07 ` [PATCH v4 0/4] git add --chmod: always change the file Thomas Gummerer
2016-09-14 21:07 ` [PATCH v4 1/4] add: document the chmod option Thomas Gummerer
2016-09-14 21:07 ` [PATCH v4 2/4] update-index: add test for chmod flags Thomas Gummerer
2016-09-14 21:07 ` [PATCH v4 3/4] read-cache: introduce chmod_index_entry Thomas Gummerer
2016-09-14 21:46 ` Junio C Hamano
2016-09-14 22:54 ` Junio C Hamano
2016-09-15 18:49 ` Thomas Gummerer
2016-09-14 21:07 ` [PATCH v4 4/4] add: modify already added files when --chmod is given Thomas Gummerer
2016-09-14 21:54 ` Junio C Hamano
2017-08-07 21:40 ` René Scharfe
2017-08-12 12:30 ` Thomas Gummerer [this message]
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=20170812123010.GA4304@hank \
--to=t.gummerer@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=ethomson@edwardthomson.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ib@wupperonline.de \
--cc=janx@linux.com \
--cc=l.s.r@web.de \
--cc=peff@peff.net \
--cc=ramsay@ramsayjones.plus.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).