Hi,
I add 2 files that I want ignore on commits
git update-index --assume-unchanged configurations/local.defs
git update-index --assume-unchanged processor/default.defs
git diff -a
is clean
git diff .
is clean
git commit -a
nothing added to commit
but
git commit .
# Changes to be committ
Am 05.12.2014 07:12, schrieb Sérgio Basto:
Hi,
I add 2 files that I want ignore on commits
git update-index --assume-unchanged configurations/local.defs
git update-index --assume-unchanged processor/default.defs
git diff -a
is clean
git diff .
is clean
git commit -a
nothing added to commit
bu
On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt wrote:
> Actually, it's a user error. When you set --assume-unchanged, then you give
> a promise to git that you do not change the files, and git does not have to
> check itself whether there is a change.
>
> But since you did not keep your promise, yo
Hi,
On Sex, 2014-12-05 at 17:52 +0700, Duy Nguyen wrote:
> On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt wrote:
> > Actually, it's a user error. When you set --assume-unchanged, then you give
> > a promise to git that you do not change the files, and git does not have to
> > check itself whether
Sérgio Basto writes:
> On Sex, 2014-12-05 at 17:52 +0700, Duy Nguyen wrote:
>> On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt wrote:
>> > Actually, it's a user error. When you set --assume-unchanged, then you give
>> > a promise to git that you do not change the files, and git does not have to
Duy Nguyen writes:
> You are correct about the original idea behind --assume-unchanged. But
> over the time I think we bend over a bit and sort of support these use
> cases. For example, aecda37 (do not overwrite files marked "assume
> unchanged" - 2010-05-01). The change is one-liner, so I don't
From: "Junio C Hamano"
Sérgio Basto writes:
On Sex, 2014-12-05 at 17:52 +0700, Duy Nguyen wrote:
On Fri, Dec 5, 2014 at 1:55 PM, Johannes Sixt wrote:
> Actually, it's a user error. When you set --assume-unchanged, then
> you give
> a promise to git that you do not change the files, and git
"Philip Oakley" writes:
> The problem here is that there is no guidance on what those actions are
> that may make git 'notice'
I think the guidance the users need is the one j6t has given already
in the upthread: "If you are promising Git you are not going to
touch a path, do not touch it.
Junio C Hamano writes:
> If however you did something that made Git notice that you changed
> these paths marked with assume-unchanged bit anyway, then Git will,
> well, notice that they are not "unchanged" as you promised.
By the way, this cuts both ways. I would not bother checking with
the c
On Sex, 2014-12-05 at 10:30 -0800, Junio C Hamano wrote:
> Your promise is "these paths I will not modify" and in return you
> gain performance in "git status"
yeah so --assume-unchanged is for administrators of git , like I write
I change first and --assume-unchanged after and never change it
Sérgio Basto writes:
> On Sex, 2014-12-05 at 10:30 -0800, Junio C Hamano wrote:
>> Your promise is "these paths I will not modify" and in return you
>> gain performance in "git status"
>
> yeah so --assume-unchanged is for administrators of git ,...
Not at all.
Administrators would typically
From: "Junio C Hamano"
"Philip Oakley" writes:
The problem here is that there is no guidance on what those actions
are
that may make git 'notice'
I think the guidance the users need is the one j6t has given already
in the upthread: "If you are promising Git you are not going to
touch a
"Philip Oakley" writes:
> However the man page's statement 'When the "assume unchanged" bit is on,
> Git stops checking the working tree files for possible modifications, so
> you need to manually unset the bit to tell Git when you change the working
> tree file.' can easily be understood the way
On Sex, 2014-12-05 at 20:48 +, Philip Oakley wrote:
> The problem here is that there is no guidance on what those actions
> are
> that may make git 'notice'. The man page git-update-index isn't as
> clear
> as it could be. Using --really-refresh being one option that would
> make
> git notice,
From: "Sérgio Basto"
[..]
Part of the implied question is why "git commit ." would notice when
when "git commit -a" didn't appear to. So it's unclear as to what the
user should have expected.
I agree with this sentence, this is a bug because:
git commit -a ( and -a means all ) is incoherent w
15 matches
Mail list logo
