Re: [Request] Git reset should be able to ignore file permissions

2013-06-20 Thread Alexander Nestorov
@Matthieu
 Ok, I'm replacing with Reset only files which actually changed (not
those with only stat information change)

@Junio
 I'm not sure what you're asking, sorry, I'm not able to understand
your question.
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-19 Thread Alexander Nestorov
Ok, this is how it looks. If everything is ok, I'm sending it to the ML

From 262bdfb5cc84fec7c9b74dc92bb604f9d168ef9a Mon Sep 17 00:00:00 2001
From: Alexander Nestorov alexander...@gmail.com
Date: Wed, 19 Jun 2013 09:55:42 +0200
Subject: [PATCH] Add example for reseting based on content changes instead of
 stat changes

---
 Documentation/git-reset.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index a404b47..da639e9 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -289,6 +289,18 @@ $ git reset --keep start3
 3 But you can use reset --keep to remove the unwanted commit after
 you switched to branch2.

+Reset only files who's content changed (instead of stat information)::
++
+
+$ git update-index --refresh   1
+$ git reset --hard 2
+
++
+1 Make Git realize which files actually changed instead of
+checking out all files whether their content changed or only
+their mtime changed.
+2 Now git reset --hard will checkout only the files that
+actually changed.

 DISCUSSION
 --
--
1.8.1.msysgit.1
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-19 Thread Matthieu Moy
Alexander Nestorov alexander...@gmail.com writes:

 Ok, this is how it looks. If everything is ok, I'm sending it to the ML

Please, read Documentation/SubmittingPatches (you lack a sign-off and if
you think the patch is ready, you should Cc Junio). Also, it's better to
have the commit headers directly as mail headers (git send-email is your
friend).

 +Reset only files who's content changed (instead of stat information)::

That's still not 100% accurate. Actual mode changes would trigger a
rewrite of the file. Perhaps stg like

Reset only files which actually changed (not those with only stat information 
change)::

(Sorry for nitpicking so much)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-19 Thread Hilco Wijbenga
On 19 June 2013 01:00, Alexander Nestorov alexander...@gmail.com wrote:
 Ok, this is how it looks. If everything is ok, I'm sending it to the ML

 From 262bdfb5cc84fec7c9b74dc92bb604f9d168ef9a Mon Sep 17 00:00:00 2001
 From: Alexander Nestorov alexander...@gmail.com
 Date: Wed, 19 Jun 2013 09:55:42 +0200
 Subject: [PATCH] Add example for reseting based on content changes instead of
  stat changes

 ---
  Documentation/git-reset.txt | 12 
  1 file changed, 12 insertions(+)

 diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
 index a404b47..da639e9 100644
 --- a/Documentation/git-reset.txt
 +++ b/Documentation/git-reset.txt
 @@ -289,6 +289,18 @@ $ git reset --keep start3
  3 But you can use reset --keep to remove the unwanted commit after
  you switched to branch2.

 +Reset only files who's content changed (instead of stat information)::

You should use whose here instead of who's.

 ++
 +
 +$ git update-index --refresh   1
 +$ git reset --hard 2
 +
 ++
 +1 Make Git realize which files actually changed instead of
 +checking out all files whether their content changed or only
 +their mtime changed.
 +2 Now git reset --hard will checkout only the files that
 +actually changed.

  DISCUSSION
  --
 --
 1.8.1.msysgit.1
 --
 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
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-19 Thread Junio C Hamano
Matthieu Moy matthieu@grenoble-inp.fr writes:

 Alexander Nestorov alexander...@gmail.com writes:

 Ok, this is how it looks. If everything is ok, I'm sending it to the ML

 Please, read Documentation/SubmittingPatches (you lack a sign-off and if
 you think the patch is ready, you should Cc Junio). Also, it's better to
 have the commit headers directly as mail headers (git send-email is your
 friend).

 +Reset only files who's content changed (instead of stat information)::

 That's still not 100% accurate. Actual mode changes would trigger a
 rewrite of the file. Perhaps stg like

 Reset only files which actually changed (not those with only stat information 
 change)::

 (Sorry for nitpicking so much)

I do not think the above clarifies anything to be of much help.

If you _know_ what actually changed means, i.e. either contents or
the executable-ness changed, then (not those ...) does not help
you at all.

If you don't, then only stat information change will invite I did
chmod -x and the file does not have any actual change. confusion.

If this addition is to help people who do not know what actually
changed means, that part needs to be clarified, no?


--
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


[Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Alexander Nestorov
Recently I had to write some automation scripts and I found
that git reset --hard actually restores each file's permissions.

That is causing both the created and the last-modified dates
of the file to get changed to the time of the git reset.

This behavior is easy to demonstrate:

echo test  myfile
chmod 777 myfile
git add myfile  git commit -m Test  git push
chmod 775 myfile
git reset --hard origin/master

After the git reset --hard command, the entire file was
checkout-ed. Instead, git should be able to check if the
content of the file changed and only if it did, check it out.

I do realize that checking the content of each file in a big
repo could result in a slow operation, but there should be a
switch/argument/option to make git reset actually check the
content of each file instead of blindly replacing it.

After reading man a few times I didn't saw any option
that'd let me do this; the only solution I'm able to think about
is actually restoring the permissions of each file to the ones
git thinks they should have before doing the git reset.

Maybe I'm wrong and there is a way for doing what I want, if
so, please correct me.
But if there isn't, should this be implemented? Are there any
reasons for not doing it?


Thank you for your attention
Regards

--
alexandernst
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Matthieu Moy
Alexander Nestorov alexander...@gmail.com writes:

 echo test  myfile
 chmod 777 myfile
 git add myfile  git commit -m Test  git push
 chmod 775 myfile
 git reset --hard origin/master

This doesn't tell what the permissions are in origin/master.

If the last line was git reset --hard HEAD, then it wouldn't touch
myfile (it's executable in the worktree and in HEAD, so Git doesn't need
to change it). Neither the x bit, nor the ctime or mtime.

If you reset the file to a point where it was not executable, then Git
changes its executable bit, and I don't see why it would do otherwise:
Git tracks the executable bit, so when you say reset the file to how it
was in this revision, this includes the content and executability.

Reading your message, I don't understand why you need to be able to
ignore the x bit.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Alexander Nestorov
Git does preserve file permissions, that is, git is aware of the
permissions you can set with chmod.

I'm not trying to ignore the x bit, what I'm trying to do is make
git reset checkout only the files that actually changed instead
of checking out all the files with different permissions than the
ones git thinks they should have.

Said with other word: when you run git reset, git does a status
and checkouts all the files that showed up from the status.
That's exactly what I'm trying to avoid, as status is aware of both
content changes and permissions changes.
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread John Keeping
On Tue, Jun 18, 2013 at 03:25:22PM +0200, Alexander Nestorov wrote:
 Recently I had to write some automation scripts and I found
 that git reset --hard actually restores each file's permissions.
 
 That is causing both the created and the last-modified dates
 of the file to get changed to the time of the git reset.
 
 This behavior is easy to demonstrate:
 
 echo test  myfile
 chmod 777 myfile
 git add myfile  git commit -m Test  git push
 chmod 775 myfile
 git reset --hard origin/master
 
 After the git reset --hard command, the entire file was
 checkout-ed. Instead, git should be able to check if the
 content of the file changed and only if it did, check it out.

Does git reset --keep behave in the same way?  I would expect it to
leave permissions as they were.
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Matthieu Moy
Alexander Nestorov alexander...@gmail.com writes:

 I'm not trying to ignore the x bit, what I'm trying to do is make
 git reset checkout only the files that actually changed instead
 of checking out all the files with different permissions than the
 ones git thinks they should have.

Ah, OK, you want git reset --hard to just do a chmod, which would not
touch the file's mtime (but only the ctime).

Then, it's even easier to demonstrate: just touch instead of chmod.
Indeed:

$ touch myfile; sleep 2
$ strace -f git reset --hard 21 | grep myfile
lstat(myfile, {st_mode=S_IFREG|0755, st_size=5, ...}) = 0
lstat(myfile, {st_mode=S_IFREG|0755, st_size=5, ...}) = 0
unlink(myfile)= 0
open(myfile, O_WRONLY|O_CREAT|O_EXCL, 0777) = 4

(sleep 2 is needed in the demonstration to avoid the racy git
safeties, but it's not really important)

Git doesn't even try to read the file content: once it detected that the
stat information changed, it rewrite the file without looking at its
content. It's faster this way for files that actually changed.

 Said with other word: when you run git reset, git does a status
 and checkouts all the files that showed up from the status.

No, it's indeed the opposite: status re-checks the content of changed
files, and update the stat-cache in the index accordingly if the content
actually didn't change.

Runing git status before git reset --hard should solve your problem.
The part of git status of interest is git update-index --refresh:

$ touch myfile; sleep 2
$ git update-index --refresh
$ strace -f git reset --hard 21 | grep myfile
lstat(myfile, {st_mode=S_IFREG|0755, st_size=5, ...}) = 0
$

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Alexander Nestorov
Git reset --keep is not an option as it will abort the operation if
there are local changes,
which is exactly what I want to do: replace files with local changes
but leave file
permissions as they are.
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Alexander Nestorov
Indeed, git update-index --refresh before git reset did the trick :)
Anyways, what about the proposal? Should it be implemented?

Thank you
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Alexander Nestorov
Sorry for not keeping everyone Cced, I wasn't aware of the rules.

Yes, writing about that in the docs seems more reasonable than patching reset,
as as you said, that'd just run update-index before the reset.
Let me get at home and I'll try to push a change :)

Regards
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Alexander Nestorov
I'm home, 
https://github.com/alexandernst/git/commit/61f0a7d558e3cbae308fabdff66bd87569d6aa18
Is that good? Should I PR?
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Matthieu Moy
Alexander Nestorov alexander...@gmail.com writes:

 I'm home, 
 https://github.com/alexandernst/git/commit/61f0a7d558e3cbae308fabdff66bd87569d6aa18
 Is that good?

Please, post your patches inline, it eases review. More generally, read
Documentation/SubmittingPatches.

+Ignore file permissions::

It's not only about permissions, and it does not ignore them, it just
notices when there's actually no change although the mtime has changed.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: [Request] Git reset should be able to ignore file permissions

2013-06-18 Thread Matthieu Moy
Alexander Nestorov alexander...@gmail.com writes:

 How about that:

 +Reset only files who's content changed (instead of mtime modification)::

Much better, yes. I'd say stat information instead of mtime (that's
what used in the description of update-index --refresh, and is a bit
more accurate since Git also checks the inode number IIRC).

 +
 +$ git update-index --refresh   1
 +$ git reset --hard 2
 +
 ++
 +1 Make git realize which files actually changed instead of

s/git/Git/ when talking about The Git system (as opposed to The git
command). git-gui or other Git clients would also see the index change.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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