Re: dotfiles in git template dir are not copied

[Grégoire PARIS]

>There was no 'bug' either. It's just the way it is ;-)

Sure !

[PATCH] Document dotfiles exclusion on template copy

[Grégoire Paris]

Since there is no dotfile in the default template directory, there was
no point in making the check for . or .. more accurate when copying. Now
that you can customize the template directory, it would make sense, but
it's actually a good thing to at this because you would not want to have
your git directory copied in every git directory that is created should
you decide to put your template directory under version control. Plus, it
might be used as a feature by people who would want to exclude some
files.

Signed-off-by: Grégoire Paris <postmas...@greg0ire.fr>
---
Here is a better version.
 Documentation/git-init.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 9d27197..3c5a67f 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -116,8 +116,8 @@ does not exist, it will be created.
 TEMPLATE DIRECTORY
 --
 
-The template directory contains files and directories that will be copied to
-the `$GIT_DIR` after it is created.
+Files and directories in the template directory whose name do not start with a
+dot will be copied to the `$GIT_DIR` after it is created.
 
 The template directory will be one of the following (in order):
 
-- 
2.9.3

Re: [PATCH] Document dotfiles exclusion on template copy

[Grégoire PARIS]

  
-The template directory contains files and directories that will be copied to

-the `$GIT_DIR` after it is created.
+The template directory contains files and directories whose name do not start
+with a dot will be copied to the `$GIT_DIR` after it is created.
  
  The template directory will be one of the following (in order):
  

This sentence does not make any sense, I realize that now.

Re: dotfiles in git template dir are not copied

[Grégoire PARIS]

> Thanks for your guidance. I believe I just sent the patch to the 
mailing list.


I just retried with the Gmail SMTP, and now I am sure it worked. Sorry 
for the noobery.

[PATCH] Document dotfiles exclusion on template copy

[Grégoire Paris]

Since there is no dotfile in the default template directory, there was
no point in making the check for . or .. more accurate when copying. Now
that you can customize the template directory, it would make sense, but
it's actually a good thing to at this because you would not want to have
your git directory copied in every git directory that is created should
you decide to put your template directory under version control. Plus, it
might be used as a feature by people who would want to exclude some
files.

Signed-off-by: Grégoire Paris <postmas...@greg0ire.fr>
---
I hope I'm getting it right, this is my first time using format-patch and
send-email…
 Documentation/git-init.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 9d27197..7605742 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -116,8 +116,8 @@ does not exist, it will be created.
 TEMPLATE DIRECTORY
 --
 
-The template directory contains files and directories that will be copied to
-the `$GIT_DIR` after it is created.
+The template directory contains files and directories whose name do not start
+with a dot will be copied to the `$GIT_DIR` after it is created.
 
 The template directory will be one of the following (in order):
 
-- 
2.9.3

Re: dotfiles in git template dir are not copied

[Grégoire PARIS]

Thanks for your guidance. I believe I just sent the patch to the mailing 
list.

Re: dotfiles in git template dir are not copied

[Grégoire PARIS]

Le 17/02/2017 à 23:39, Philip Oakley a écrit :

From: "Grégoire PARIS" <postmas...@greg0ire.fr>

> You could, for example, have your template directory itself be a git
repository.

I can and I do and indeed, that might be the reason behind this.
I made a PR to document this : https://github.com/git/git/pull/325

While the PR is a simple one line change to the documention, the patch 
should be submitted to the list.

See Documenation/SubmittingPatches

Don't forget to Sign Off your patch (see the Developer's Certificate 
of Origin section).

--
Philip


Ok sorry, I'll fix this rightaway!
--
greg0ire

Re: dotfiles in git template dir are not copied

[Grégoire PARIS]

> I do not think we should change the behaviour
> to copy files whose names begin with a dot.

So bug turned feature it is :)

I amended my commit message accordingly.

In my case, my template dir is not at the root of the repository where 
it is versioned, so it would not be a problem for me, but I think some 
people might use this feature to add tests/docs without having them copied.


my template dir repository : https://github.com/greg0ire/git_template

Re: Re: dotfiles in git template dir are not copied

[Grégoire PARIS]

> You could, for example, have your template directory itself be a git 
repository.


I can and I do and indeed, that might be the reason behind this.
I made a PR to document this : https://github.com/git/git/pull/325

--
greg0ire

Re: Bypassing hooks while cherry-picking

[Grégoire PARIS]

Le 03/03/2016 23:55, Junio C Hamano a écrit :

Grégoire PARIS <postmas...@greg0ire.fr> writes:


Not sure how cherry-picking is managed, and whether commit is able to
see that we are doing a cherry-pick, and end it up properly. Anyway,
with Kevin's patch, we should be able to happily use cherry-pick

[Please do not top post]

It is somewhat sad to see such a response as that is backwards.

"cherry-pick --continue" originally was "I am done with the commit I
was asked to deal with, so please replay the next one", and in order
to "be done with" the commit, you would used "git commit" yourself,
with whatever necessary options (e.g. --no-verify, -s, -c) you want
to affect the behaviour of the "git commit".

It is a later invention that "cherry-pick --continue" additionally
creates a commit when the user, even though she claims to "be done
with", hasn't actually made the commit before going on to replay the
next one.  It was accepted as a short-cut as most of the time you do
not give any option to your "git commit" invocation, but probably
was a misguided invention--it made new people somehow think that
they are not allowed to run "git commit" to conclude the conflict
resolution, when in reality that is an acceptable and primary way
to do so and "--continue" is a mere short-hand.

As "git commit" does have options other than "--no-verify" that
affects the way it behaves, and can gain more such options in the
future, having to keep adding corresponding options to "cherry-pick
--continue --more-options" will not be a good solution in the longer
run.



Sorry for top-posting, I'll keep in mind to not do this.

You're describing very precisely how using cherry-pick --continue makes 
me feel. I checked again right now and even though there is a comment to 
make me understand that commit would do a great job at solving my 
problem (hint: and commit the result with 'git commit'), I failed to 
notice it.


I agree with you, adding every commit option is not a good solution… 
Maybe a good solution would be to display a special message when using 
cherry-pick --continue with unrecognized options? Like for instance


> hint: try git commit --no-verify, then git cherry-pick --continue to 
replay the next commit


What do you think?

--
greg0ire
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bypassing hooks while cherry-picking

[Grégoire PARIS]

Not sure how cherry-picking is managed, and whether commit is able to 
see that we are doing a cherry-pick, and end it up properly. Anyway, 
with Kevin's patch, we should be able to happily use cherry-pick


greg0ire

Le 03/03/2016 22:30, Junio C Hamano a écrit :

greg0ire  writes:


Steps to reproduce :

1. create a pre-commit hook
2. create a commit that fails the hook, and bypass the hook
3. checkout another branch
4. might be optional : create a conflicting change with the previously
created commit
5. cherry-pick the commit
6. might be optional : solve the conflick and use git cherry-pick --continue

Wouldn't "commit --no-verify" at that last step, instead of
"cherry-pick --continue", just work?



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bypassing hooks while cherry-picking

[Grégoire PARIS]

Oh great, glad to see that, good job!

greg0ire

Le 03/03/2016 22:17, Kevin Daudt a écrit :

On Tue, Mar 01, 2016 at 12:01:53PM +0100, greg0ire wrote:

Hello,

using git 2.1.4 here, and it seems there is no option to bypass pre-commit
hooks while cherry-picking, while git commit provides a --no-verify option.
I ended up doing this to disable hooks while cherry picking :

 test -f "$GIT_DIR"/CHERRY_PICK_HEAD && exit 0

Wouldn't it be best to add the --no-verify option to cherry-pick too?
I had a conflict when cherry-picking the commit, maybe this does not happen
otherwise?

Steps to reproduce :

1. create a pre-commit hook
2. create a commit that fails the hook, and bypass the hook
3. checkout another branch
4. might be optional : create a conflicting change with the previously
created commit
5. cherry-pick the commit
6. might be optional : solve the conflick and use git cherry-pick --continue

Regards,

--
greg0ire

Forgot to CC you, but I've submitted a patch[0] that adds this option.
The conflict does matter because otherwise the pre-commit hook does not
run.

Because they're now the rc-cycle, it might take a while before the patch
is accepted.


[0]:http://article.gmane.org/gmane.comp.version-control.git/288124


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html