On Mon, Nov 25, 2013 at 12:53:45PM -0800, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > What I think needs fixing here first is that the ignore setting should not
> > apply to any diffs between HEAD and index. IMO, it should only apply
> > to the diff between worktree and index.
>
> Hmph. H
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> I have a feeling that the
>> current "not copy to fix it to a stable value, but look into
>> .gitmodules as a fallback" was not a designed behaviour for the
>> other properties, but was done by accident
Junio C Hamano wrote:
> I have a feeling that the
> current "not copy to fix it to a stable value, but look into
> .gitmodules as a fallback" was not a designed behaviour for the
> other properties, but was done by accident and/or laziness.
It was designed
Jens Lehmann writes:
> Am 25.11.2013 22:01, schrieb Junio C Hamano:
>> Jens Lehmann writes:
>>
>>> Looking good to me. Please add tests for "diff.ignoreSubmodules"
>>> and "submodule..ignore", the latter both in .gitmodules and
>>> .git/config. While doing some testing for this thread I found a
Am 25.11.2013 22:01, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> Looking good to me. Please add tests for "diff.ignoreSubmodules"
>> and "submodule..ignore", the latter both in .gitmodules and
>> .git/config. While doing some testing for this thread I found an
>> inconsistency in git show
Jens Lehmann writes:
> Looking good to me. Please add tests for "diff.ignoreSubmodules"
> and "submodule..ignore", the latter both in .gitmodules and
> .git/config. While doing some testing for this thread I found an
> inconsistency in git show which currently honors the submodule
> specific opti
Heiko Voigt writes:
> What I think needs fixing here first is that the ignore setting should not
> apply to any diffs between HEAD and index. IMO, it should only apply
> to the diff between worktree and index.
Hmph. How about "git diff $commit", the diff between the worktree and
a named commit
On Mon, Nov 25, 2013 at 11:57:45PM +0600, Sergey Sharybin wrote:
> Heiko, yeah sure see what you mean. Changing existing behavior is pretty PITA.
>
> Just one more question for now, are you referencing to the patch "[RFC
> PATCH] disable complete ignorance of submodules for index <-> HEAD
> diff"?
Heiko, yeah sure see what you mean. Changing existing behavior is pretty PITA.
Just one more question for now, are you referencing to the patch "[RFC
PATCH] disable complete ignorance of submodules for index <-> HEAD
diff"? Coz i tested it and seems it doesn't change behavior of
add/commit.
Also,
On Mon, Nov 25, 2013 at 03:02:51PM +0600, Sergey Sharybin wrote:
> Am i right the intention is to make it so `git add .` and `git commit
> .` doesn't include changes to submodule hash unless -f argument is
> provided?
Yes thats the goal. My patch currently only disables it when ignore is
set to al
Hey!
Sorry for the delayed reply.
Am i right the intention is to make it so `git add .` and `git commit
.` doesn't include changes to submodule hash unless -f argument is
provided?
On Sun, Nov 24, 2013 at 10:29 PM, Jens Lehmann wrote:
> Am 24.11.2013 01:52, schrieb Heiko Voigt:
>> Hi,
>>
>> On
Am 24.11.2013 01:52, schrieb Heiko Voigt:
> Hi,
>
> On Sat, Nov 23, 2013 at 09:10:44PM +0100, Jens Lehmann wrote:
>> Am 22.11.2013 23:09, schrieb Jonathan Nieder:
>>> Heiko Voigt wrote:
>>>
After that we can discuss whether add should add submodules that are
tracked but not shown. How ab
On Sat, Nov 23, 2013 at 09:32:45PM +0100, Jens Lehmann wrote:
> Am 22.11.2013 22:54, schrieb Heiko Voigt:
> > What I think needs fixing here first is that the ignore setting should not
> > apply to any diffs between HEAD and index. IMO, it should only apply
> > to the diff between worktree and inde
Hi,
On Sat, Nov 23, 2013 at 09:10:44PM +0100, Jens Lehmann wrote:
> Am 22.11.2013 23:09, schrieb Jonathan Nieder:
> > Heiko Voigt wrote:
> >
> >> After that we can discuss whether add should add submodules that are
> >> tracked but not shown. How about commit -a ? Should it also ignore the
> >> c
Am 22.11.2013 22:54, schrieb Heiko Voigt:
> What I think needs fixing here first is that the ignore setting should not
> apply to any diffs between HEAD and index. IMO, it should only apply
> to the diff between worktree and index.
Not only that. It should also apply to diffs between commits/trees
Am 22.11.2013 23:09, schrieb Jonathan Nieder:
> Heiko Voigt wrote:
>
>> After that we can discuss whether add should add submodules that are
>> tracked but not shown. How about commit -a ? Should it also ignore the
>> change? I am undecided here. There does not seem to be any good
>> decision. Fro
Heiko Voigt wrote:
> What I think needs fixing here first is that the ignore setting should not
> apply to any diffs between HEAD and index. IMO, it should only apply
> to the diff between worktree and index.
>
> When we have that the user does not see the submodule changed when
> normally working.
Jens Lehmann wrote:
> But the question is if that is the right thing to do: should
> diff.ignoreSubmodules and submodule..ignore only affect
> the diff family or also git log & friends? That would make
> users blind for submodule history (which they already are
> when using diff & friends, so that
Heiko Voigt wrote:
> After that we can discuss whether add should add submodules that are
> tracked but not shown. How about commit -a ? Should it also ignore the
> change? I am undecided here. There does not seem to be any good
> decision. From the users point of view we should probably not add i
Hi,
On Fri, Nov 22, 2013 at 10:01:44PM +0100, Jens Lehmann wrote:
> Hmm, looks like git show also needs to be fixed to honor the
> ignore setting from .gitmodules. It already does that for
> diff.ignoreSubmodules from either .git/config or git -c and
> also supports the --ignore-submodules command
> > For some reason, the
> > `git add .` is adding the ignored submodule to the index.
>
> The ignore setting is documented to only affect diff output
> (including what checkout, commit and status show as modified).
> While I agree that this behavior is confusing for Sergey and
> not optimal for th
Am 22.11.2013 19:11, schrieb Ramkumar Ramachandra:
> Sergey Sharybin wrote:
>> To reproduce the issue:
>>
>> - Run git submodule update --recursive to make sure their SHA is
>> changed. Then `git add /path/to/changed submodule` or just `git add .`
>> - Modify any file from the parent repository
>>
Am 22.11.2013 17:12, schrieb Ramkumar Ramachandra:
> Jeff King wrote:
>>> I just checked it out: it uses `git ls-files -m` to get the list of
>>> unstaged changes; `git diff --name-only HEAD --` will list staged
>>> changes as well.
>>
>> That diff command compares the working tree and HEAD; if you
Sergey Sharybin wrote:
> To reproduce the issue:
>
> - Run git submodule update --recursive to make sure their SHA is
> changed. Then `git add /path/to/changed submodule` or just `git add .`
> - Modify any file from the parent repository
> - Neither of `git status`, `git diff` and `git diff-files -
Ok, got it now.
To reproduce the issue:
- Run git submodule update --recursive to make sure their SHA is
changed. Then `git add /path/to/changed submodule` or just `git add .`
- Modify any file from the parent repository
- Neither of `git status`, `git diff` and `git diff-files --name-only`
will
Ah, didn't notice you're the author of that pull-request Ramkumar :)
So guess issue with arc can be considered solved now. But i'm still
collecting more details about how to manage to commit change addons
hash without arc command even (it happens to Campbell Barton really
often).
Will report back
Sergey Sharybin wrote:
> Ramkumar, not actually sure what you mean?
>
> For me `git diff --name-only HEAD --` ignores changes to submodules
> hash changes.
`git diff --name-only HEAD --` compares the worktree to HEAD (listing
both staged and unstaged changes); we want `git diff --name-only --`
to
Jeff King wrote:
>> I just checked it out: it uses `git ls-files -m` to get the list of
>> unstaged changes; `git diff --name-only HEAD --` will list staged
>> changes as well.
>
> That diff command compares the working tree and HEAD; if you are trying
> to match `ls-files -m`, you probably wanted
Ramkumar, not actually sure what you mean?
For me `git diff --name-only HEAD --` ignores changes to submodules
hash changes. Also apparently it became a known TODO for phabricator
developers [1].
Jeff, kinda trying to match yes. Just don't want changes to submodules
hash to be included.
So, afte
On Fri, Nov 22, 2013 at 06:38:47PM +0530, Ramkumar Ramachandra wrote:
> >> Does Arcanist use `git ls-files -m` to check?
> >
> > Yes, Arcanist uses `git ls-files -m` to check whether there're local
> > modifications. We might also contact phab developers asking to change
> > it to `git diff --name
Sergey Sharybin wrote:
> On Fri, Nov 22, 2013 at 5:16 PM, Ramkumar Ramachandra
> wrote:
>>
>> [+CC: Jens, the goto-guy for submodules]
>>
>> Sergey Sharybin wrote:
>> > Namely, `git ls-files -m` will show addons as modified, regardless
>> > ignore=all configuration. In the same time `git diff-inde
Hey,
Answers are inlined.
On Fri, Nov 22, 2013 at 5:16 PM, Ramkumar Ramachandra
wrote:
>
> [+CC: Jens, the goto-guy for submodules]
>
> Sergey Sharybin wrote:
> > Namely, `git ls-files -m` will show addons as modified, regardless
> > ignore=all configuration. In the same time `git diff-index --
[+CC: Jens, the goto-guy for submodules]
Sergey Sharybin wrote:
> Namely, `git ls-files -m` will show addons as modified, regardless
> ignore=all configuration. In the same time `git diff-index --name-only
> HEAD --` will show no changes at all.
This happens because diff-index handles submodules
33 matches
Mail list logo
