@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 mes
Matthieu Moy writes:
> Alexander Nestorov 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
On 19 June 2013 01:00, Alexander Nestorov 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
> Date: Wed, 19 Jun 2013 09:55:42 +0200
> Subject: [PATCH] Add example f
Alexander Nestorov 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
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
Date: Wed, 19 Jun 2013 09:55:42 +0200
Subject: [PATCH] Add example for reseting based on content changes instead of
stat change
Alexander Nestorov 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 check
How about that:
+Reset only files who's content changed (instead of mtime modification)::
++
+
+$ git update-index --refresh <1>
+$ git reset --hard <2>
+
++
+<1> Make git realize which files actually changed instead of
+checking out al
Alexander Nestorov 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
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-
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 l
[ The rule here is to keep everyone Cced, not just git@vger ]
Alexander Nestorov writes:
> Indeed, "git update-index --refresh" before "git reset" did the trick :)
> Anyways, what about the proposal? Should it be implemented?
I'd say the current behavior is OK by default (it's not so common to
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
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 maj
Alexander Nestorov 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 -
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
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
Alexander Nestorov 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
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" > m
18 matches
Mail list logo
