From: "Scott R. Godin" <scottg.wp-hackers@mhg2.com>
To: git@vger.kernel.org
Subject: Re: [RFE] pre/post-stash hooks
Date: Wed, 24 Feb 2010 14:31:55 -0500 [thread overview]
Message-ID: <hm3urb$1nf$1@dough.gmane.org> (raw)
In-Reply-To: <hlmi1o$fk5$1@ger.gmane.org>
giving this a bump since I haven't received any replies on it yet, and
it's a valid question, IMHO.
On 02/19/2010 12:33 PM, Scott R. Godin wrote:
> While I had known about git stash, and just never used it, I'd finally
> gotten to the point where it was needed, only to discover something that
> I found interesting.
>
> My use case may a bit rare at the moment, I'll admit, but not at all
> far-fetched, and probably growing in usage as time goes on.
>
> In contrib/hooks is the script 'setgitperms.perl' which, when added to
> pre-commit, post-merge, and post-checkout, makes sure to track the file
> permissions fully, not just +/-x. This can be vitally important for
> webdevelopers who must keep certain permissions on certain directories,
> such as for e-commerce solutions like Magento, etc, so that the clients
> may upload new product images through the interface rather than via ftp.
>
> However when I recently used stash to push some changes aside while I
> did something else first, and then ran git stash pop, I realized that
> there weren't any hooks that would enable setgitperms.perl to be
> ensuring/tracking the file permissions are applied correctly after stash
> usage.
>
> Granted that full directory/file permissions may not be all that
> important to some of you coders, but I can assure you that web
> developers may not see it that way.
>
> Again granted, I could probably set up a Makefile, but not everyone
> knows how to do that (particularly those webdevelopers who aren't coders
> who would typically be familiar with Makefiles.
>
> Also granted I could probably find a way to work around this issue with
> an alias, but my thought is that I shouldn't have to.
>
> There are some of us who exist who have this funny thought that
> computers should be able to do things for us without us having to
> explicitly tell them to, specifically, every time. We'd prefer to set
> things up generally "just do this EVERY time for EVERYthing" and forget
> about it, and let the computer handle it. I'm sure you're familiar with
> us, since we are us. :-)
>
> So, with this in mind, in addition to requesting pre/post-stash hooks
> just for this alone, I'd like to solicit some thought from the rest of
> you as to potential possible usages/requirements for said hooks for
> reasons _other_ than running 'setgitperms.perl'
>
> Are there any reasons why pre/post-stash hooks _shouldn't_ exist?
>
> How difficult would it be to implement?
>
--
(please respond to the list as opposed to my email box directly,
unless you are supplying private information you don't want public
on the list)
next prev parent reply other threads:[~2010-02-24 19:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-19 17:33 [RFE] pre/post-stash hooks Scott R. Godin
2010-02-24 19:31 ` Scott R. Godin [this message]
2010-02-25 1:34 ` Chris Packham
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='hm3urb$1nf$1@dough.gmane.org' \
--to=scottg.wp-hackers@mhg2.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 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 NNTP newsgroup(s).