Jeff King writes:
> Interestingly, I would have thought that the first update-index call
> would "de-racify" the entry by rewriting the index. But we don't
> actually write, presumably because we eventually realize that there are
> no entries to update. But it might actually be worth doing the wr
On Thu, Apr 27, 2017 at 11:52:24PM +0100, Philip Oakley wrote:
> > But note that none of that should ever affect _what_ gets checked out at
> > a file or content level. It may only affect the timestamps on the
> > resulting files. And I think those timestamps are not something Git
> > makes any pr
"Philip Oakley" writes:
>> In the modern day, it might be useful if the "--working-tree-only"
>> mode added a new file as an intent-to-add entry to the index, but
>> that is not what "git apply (no other options)" (which is the gold
>
> did you mean `git add` ? Or am I missing something.
I did m
From: "Jeff King" Sent: Tuesday, April 25, 2017 4:22 AM
Just catching up - sorry it's late..
On Mon, Apr 24, 2017 at 04:43:28PM -0700, Stefan Beller wrote:
>> On the main list thare is a similar "issue" [1] regarding the
>> expectation for `git checkout`,
>> and importantly (for me) these col
From: "Junio C Hamano" Sent: Wednesday, April 26, 2017
3:51 AM
"Philip Oakley" writes:
As I recall Christoph was using checkout to copy a file (e.g. a
template file) from an older commit/revision into his worktree, and
was suprised that this (git checkout ) also _staged_ the
file, rather tha
Stefan Beller writes:
>> +'git checkout' --working-tree-only [--] ...::
>> + Similar to `git checkout [--] `, but
>> + the index file is left in the same state as it was before
>> + running this command.
>
> Adding this as a new mode seems like a "patch after the fact",
> wher
Stefan Beller writes:
> I assumed a use case like this:
>
> A user may want to extract a file from a given tree-ish via
> GIT_WORK_TREE=/tmp/place git checkout --
> without modifying the repository (i.e. index) at all. For this
> we'd need an option to modify the working tree only.
I s
On Tue, Apr 25, 2017 at 7:51 PM, Junio C Hamano wrote:
> "Philip Oakley" writes:
>
>> As I recall Christoph was using checkout to copy a file (e.g. a
>> template file) from an older commit/revision into his worktree, and
>> was suprised that this (git checkout ) also _staged_ the
>> file, rather
"Philip Oakley" writes:
> As I recall Christoph was using checkout to copy a file (e.g. a
> template file) from an older commit/revision into his worktree, and
> was suprised that this (git checkout ) also _staged_ the
> file, rather than simply letting it be in a modified/untracked state.
This
On Mon, Apr 24, 2017 at 7:12 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> A similar bug report
>> https://public-inbox.org/git/CAG0BQX=wvpkJ=pqwv-nbmhupv8yzvd_kykzjmsfwq9xstz2...@mail.gmail.com/
>>
>> "checkout --recurse-submodules" (as mentioned in that report)
>> made it into Git by n
From: "Stefan Beller"
On Mon, Apr 24, 2017 at 4:33 PM, Philip Oakley
wrote:
This is almost the same as just reported by 'vvs' [1]
https://public-inbox.org/git/CAM1zWBtfgHT=pT0pidQo1HD=dfrxlg3gnauvs0vzkvyfg1b...@mail.gmail.com/,
originally on the 'git user' list
https://groups.google.com/foru
On Mon, Apr 24, 2017 at 11:22:42PM -0400, Jeff King wrote:
> > > It also has a similarity to
> > > https://public-inbox.org/git/1492287435.14812.2.ca...@gmail.com/
> > > regarding
> > > how checkout operates.
>
> I didn't look too deeply into this one, but it really looks like
> somebody caring
On Mon, Apr 24, 2017 at 04:43:28PM -0700, Stefan Beller wrote:
> >> On the main list thare is a similar "issue" [1] regarding the expectation
> >> for `git checkout`,
> >> and importantly (for me) these collected views regarding the "Git Data
> >> Protection and
> >> Management Principles" is no
Stefan Beller writes:
> A similar bug report
> https://public-inbox.org/git/CAG0BQX=wvpkJ=pqwv-nbmhupv8yzvd_kykzjmsfwq9xstz2...@mail.gmail.com/
>
> "checkout --recurse-submodules" (as mentioned in that report)
> made it into Git by now, but this bug goes unfixed, still.
I do not mind reverting t
On Mon, Apr 24, 2017 at 4:33 PM, Philip Oakley wrote:
> This is almost the same as just reported by 'vvs' [1]
> https://public-inbox.org/git/CAM1zWBtfgHT=pT0pidQo1HD=dfrxlg3gnauvs0vzkvyfg1b...@mail.gmail.com/,
> originally on the 'git user' list
> https://groups.google.com/forum/?hl=en#!topic/git
From: "Stefan Beller"
On Mon, Apr 24, 2017 at 1:06 AM, Orgad Shaneh wrote:
Hi,
I've noticed a strange behavior with submodule/content conflict. My
current Git version is 2.12.2, but the problem exists since I
remember.
Branch A has a submodule.
In branch B which diverged from A, I replaced t
On Mon, Apr 24, 2017 at 1:06 AM, Orgad Shaneh wrote:
> Hi,
>
> I've noticed a strange behavior with submodule/content conflict. My
> current Git version is 2.12.2, but the problem exists since I
> remember.
>
> Branch A has a submodule.
> In branch B which diverged from A, I replaced the submodule
Hi,
I've noticed a strange behavior with submodule/content conflict. My
current Git version is 2.12.2, but the problem exists since I
remember.
Branch A has a submodule.
In branch B which diverged from A, I replaced the submodule with its contents.
Now, every time I merge A into B, and A had cha
18 matches
Mail list logo
