git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* Bug report
@ 2012-10-04  4:35 John Whitney
  2012-10-04 14:19 ` Phil Hord
  2012-10-04 15:21 ` Andrew Wong
  0 siblings, 2 replies; 52+ messages in thread
From: John Whitney @ 2012-10-04  4:35 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

Hi all!

I just ran into a problem that I'm pretty sure is a bug in git. Just 
read and run this (fairly trivial) shell script to replicate.

Thanks!
    ---John Whitney


[-- Attachment #2: git_failure.sh --]
[-- Type: application/x-sh, Size: 1186 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-04  4:35 Bug report John Whitney
@ 2012-10-04 14:19 ` Phil Hord
  2012-10-04 16:10   ` John Whitney
  2012-10-04 15:21 ` Andrew Wong
  1 sibling, 1 reply; 52+ messages in thread
From: Phil Hord @ 2012-10-04 14:19 UTC (permalink / raw)
  To: John Whitney; +Cc: git

On Thu, Oct 4, 2012 at 12:35 AM, John Whitney <jjw@emsoftware.com> wrote:
> I just ran into a problem that I'm pretty sure is a bug in git. Just read
> and run this (fairly trivial) shell script to replicate.

When you added "* text=auto" in the .gitattributes file, you changed
what git considers to be the checked-in file content state for
test.txt.  The file contents in your working directory do not match
what git expects to check in.  Therefore, the file appears to be
different.  If you commit the file "changes" the problem goes away.

This is more of a workaround than an a satisfying explanation.  If you
then checkout the original HEAD commit (but with .gitattributes
present) you will see the problem appear again.  But in a sense,
adding .gitattributes this way is an act of foot-shooting.   The best
way forward may be to normalize your repository by removing all CR's
from files in history.  If you do not have this freedom, your best bet
may be to normalize the repo in the current commit and move on.

Others with more intimate insight into the CRLF journey in git's past
may have better advice.

Phil

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-04  4:35 Bug report John Whitney
  2012-10-04 14:19 ` Phil Hord
@ 2012-10-04 15:21 ` Andrew Wong
  2012-10-04 16:16   ` John Whitney
  1 sibling, 1 reply; 52+ messages in thread
From: Andrew Wong @ 2012-10-04 15:21 UTC (permalink / raw)
  To: John Whitney; +Cc: git

On 10/04/2012 12:35 AM, John Whitney wrote:
> I just ran into a problem that I'm pretty sure is a bug in git. Just 
> read and run this (fairly trivial) shell script to replicate.
I tried your steps on a Mac, but I wasn't able to produce the issue. 
Perhaps I don't have the right CRLF configs to trigger the issue. I've 
tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What git 
version are you using? And, if any, what are your configs for 
"core.eol", "core.safecrlf", and "core.autocrlf" ?

What Phil said also makes sense though.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-04 14:19 ` Phil Hord
@ 2012-10-04 16:10   ` John Whitney
  2012-10-06 13:31     ` Jeff King
  0 siblings, 1 reply; 52+ messages in thread
From: John Whitney @ 2012-10-04 16:10 UTC (permalink / raw)
  To: Phil Hord; +Cc: git

Phil,

Thank you for your response. I do see the dilemma, but having
no possible "unmodified" state is extremely inconvenient and,
as shown, breaks basic git operations.

I guess my thought is that if git doesn't allow CRs to be checked
in, then it should strip the CRs when checking the file out, and
consider that form (or both forms) as "unmodified". It just
doesn't make sense to me that files are considered modified
immediately after checkout.

Any thoughts as to why this would not work?

    ---John

On 10/4/12 9:19 AM, Phil Hord wrote:
> On Thu, Oct 4, 2012 at 12:35 AM, John Whitney <jjw@emsoftware.com> wrote:
>> I just ran into a problem that I'm pretty sure is a bug in git. Just read
>> and run this (fairly trivial) shell script to replicate.
> When you added "* text=auto" in the .gitattributes file, you changed
> what git considers to be the checked-in file content state for
> test.txt.  The file contents in your working directory do not match
> what git expects to check in.  Therefore, the file appears to be
> different.  If you commit the file "changes" the problem goes away.
>
> This is more of a workaround than an a satisfying explanation.  If you
> then checkout the original HEAD commit (but with .gitattributes
> present) you will see the problem appear again.  But in a sense,
> adding .gitattributes this way is an act of foot-shooting.   The best
> way forward may be to normalize your repository by removing all CR's
> from files in history.  If you do not have this freedom, your best bet
> may be to normalize the repo in the current commit and move on.
>
> Others with more intimate insight into the CRLF journey in git's past
> may have better advice.
>
> Phil
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-04 15:21 ` Andrew Wong
@ 2012-10-04 16:16   ` John Whitney
  2012-10-04 16:28     ` John Whitney
  2012-10-04 17:01     ` Andrew Wong
  0 siblings, 2 replies; 52+ messages in thread
From: John Whitney @ 2012-10-04 16:16 UTC (permalink / raw)
  To: Andrew Wong; +Cc: git

Andrew,

Thanks for checking this on your machine.

This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my script a CR
is appended to test.txt. On the Mac, you can generate this
in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
just download and run the script like this: "sh git_failure.sh"

    ---John


On 10/4/12 10:21 AM, Andrew Wong wrote:
> On 10/04/2012 12:35 AM, John Whitney wrote:
>> I just ran into a problem that I'm pretty sure is a bug in git. Just 
>> read and run this (fairly trivial) shell script to replicate.
> I tried your steps on a Mac, but I wasn't able to produce the issue. 
> Perhaps I don't have the right CRLF configs to trigger the issue. I've 
> tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What git 
> version are you using? And, if any, what are your configs for 
> "core.eol", "core.safecrlf", and "core.autocrlf" ?
>
> What Phil said also makes sense though.
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-04 16:16   ` John Whitney
@ 2012-10-04 16:28     ` John Whitney
  2012-10-04 17:01     ` Andrew Wong
  1 sibling, 0 replies; 52+ messages in thread
From: John Whitney @ 2012-10-04 16:28 UTC (permalink / raw)
  To: Andrew Wong; +Cc: git

Andrew,

I forgot to say that all of the config settings
are not changed from the default.

    ---John


On 10/4/12 11:16 AM, John Whitney wrote:
> Andrew,
>
> Thanks for checking this on your machine.
>
> This problem occurs on Mac, Windows, and Linux, and
> with multiple versions of git. Note that in my script a CR
> is appended to test.txt. On the Mac, you can generate this
> in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
> just download and run the script like this: "sh git_failure.sh"
>
>    ---John
>
>
> On 10/4/12 10:21 AM, Andrew Wong wrote:
>> On 10/04/2012 12:35 AM, John Whitney wrote:
>>> I just ran into a problem that I'm pretty sure is a bug in git. Just 
>>> read and run this (fairly trivial) shell script to replicate.
>> I tried your steps on a Mac, but I wasn't able to produce the issue. 
>> Perhaps I don't have the right CRLF configs to trigger the issue. 
>> I've tried it on v1.7.9.6, which came with Xcode, and v1.7.7. What 
>> git version are you using? And, if any, what are your configs for 
>> "core.eol", "core.safecrlf", and "core.autocrlf" ?
>>
>> What Phil said also makes sense though.
>>
>
>


-- 
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-04 16:16   ` John Whitney
  2012-10-04 16:28     ` John Whitney
@ 2012-10-04 17:01     ` Andrew Wong
  1 sibling, 0 replies; 52+ messages in thread
From: Andrew Wong @ 2012-10-04 17:01 UTC (permalink / raw)
  To: John Whitney; +Cc: git

On 10/04/2012 12:16 PM, John Whitney wrote:
> This problem occurs on Mac, Windows, and Linux, and
> with multiple versions of git. Note that in my script a CR
> is appended to test.txt. On the Mac, you can generate this
> in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
> just download and run the script like this: "sh git_failure.sh"
Ah, yes. I can reproduce the problem. I was pasting the lines from your 
script. And I saw a new line in the shell when I pasted, so I thought 
the ^M was kept properly. But somewhere during the pasting, the ^M must 
have got translated to a \n automatically. Silly me.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-04 16:10   ` John Whitney
@ 2012-10-06 13:31     ` Jeff King
  2012-10-07  2:23       ` John Whitney
  0 siblings, 1 reply; 52+ messages in thread
From: Jeff King @ 2012-10-06 13:31 UTC (permalink / raw)
  To: John Whitney; +Cc: Phil Hord, git

On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:

> Thank you for your response. I do see the dilemma, but having
> no possible "unmodified" state is extremely inconvenient and,
> as shown, breaks basic git operations.

But you have asked for an impossible state. You have said "this file
cannot have CR when you check it in, because we erase them". And yet the
version of the file in HEAD has CRs in it. So it must appear modified
with respect to HEAD.  And the solution is to make a commit with the
normalized content.

You said in your test script:

  # Committing test.txt or clearing .gitattributes does clear
  # the "modified" status, but those options are undesirable

Why is the commit undesirable? You have decided that CRs will no longer
be tolerated in your repository (by setting .gitattributes). Now you
need to record that change in history with a commit that strips out the
CRs.

> I guess my thought is that if git doesn't allow CRs to be checked
> in, then it should strip the CRs when checking the file out, and
> consider that form (or both forms) as "unmodified". It just
> doesn't make sense to me that files are considered modified
> immediately after checkout.

It is not about having CRs in the working tree file. Those are now
considered uninteresting and stripped by git when comparing to the HEAD.
The problem is that what's in your _repository_ has CRs.

I wonder if this is a fundamental misunderstanding of how the CRLF
handling in git works. It is not "magically make me not care about line
endings anymore". It is "the canonical version in the repo is LF-only.
Strip anything coming into the repository to match that, and
(optionally) add CR to anything going out to the filesystem for my
convenience". But you need a flag day to update the in-repository
versions to the new scheme.

-Peff

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-06 13:31     ` Jeff King
@ 2012-10-07  2:23       ` John Whitney
  2012-10-07 23:52         ` Jeff King
  0 siblings, 1 reply; 52+ messages in thread
From: John Whitney @ 2012-10-07  2:23 UTC (permalink / raw)
  To: Jeff King; +Cc: Phil Hord, git

On 10/6/12 8:31 AM, Jeff King wrote:
> On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:
>
>> Thank you for your response. I do see the dilemma, but having
>> no possible "unmodified" state is extremely inconvenient and,
>> as shown, breaks basic git operations.
> But you have asked for an impossible state. You have said "this file
> cannot have CR when you check it in, because we erase them". And yet the
> version of the file in HEAD has CRs in it. So it must appear modified
> with respect to HEAD.  And the solution is to make a commit with the
> normalized content.
I guess I'd really like to see git ignore all line endings of text files 
in the repository. Text files would then never be marked as "modified" 
for this reason and there would be no need to "fix" the line endings. I 
think that should be the default, but just having the option would be nice.

> You said in your test script:
>
>    # Committing test.txt or clearing .gitattributes does clear
>    # the "modified" status, but those options are undesirable
>
> Why is the commit undesirable? You have decided that CRs will no longer
> be tolerated in your repository (by setting .gitattributes). Now you
> need to record that change in history with a commit that strips out the
> CRs.
In some cases it's undesirable. In my example, all I want to do is merge 
in the change that deletes the file, so I don't want to have to add that 
extra commit when I'm just going to delete the file anyway. It's also 
very inconvenient to have to deal with this issue when you're in the 
middle of a complex rebase operation.

>> I guess my thought is that if git doesn't allow CRs to be checked
>> in, then it should strip the CRs when checking the file out, and
>> consider that form (or both forms) as "unmodified". It just
>> doesn't make sense to me that files are considered modified
>> immediately after checkout.
> It is not about having CRs in the working tree file. Those are now
> considered uninteresting and stripped by git when comparing to the HEAD.
> The problem is that what's in your _repository_ has CRs.
Yes, but does that really have to be an issue? Is there any technical or 
practical reason you can think of that the repository shouldn't ignore 
those CRs?

> I wonder if this is a fundamental misunderstanding of how the CRLF
> handling in git works. It is not "magically make me not care about line
> endings anymore". It is "the canonical version in the repo is LF-only.
> Strip anything coming into the repository to match that, and
> (optionally) add CR to anything going out to the filesystem for my
> convenience". But you need a flag day to update the in-repository
> versions to the new scheme.
>
> -Peff
You're right, we can't magically avoid all the line ending issues that 
people will run into. In this case, though, I think git can sidestep a 
fairly obnoxious problem. My example was simple, but when you've got 
multiple branches that need to be rebased/merged, it can get pretty 
hairy. The repository will never be truly "clean" unless you rewrite the 
whole thing (using filter-branch, for instance).

Maybe my above suggestion is more of a feature request than a bug, but 
there is the obvious bug that after changing .gitattributes, git still 
doesn't notice that files are "modified" until you modify them again in 
some way (touch works). I only noticed the CRs in our own repository 
after I tried to rebase a branch and got strange errors. To make git 
notice all the files, I had to "find . -type f -exec touch {} \;".

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-07  2:23       ` John Whitney
@ 2012-10-07 23:52         ` Jeff King
  2012-10-09 17:17           ` John Whitney
  0 siblings, 1 reply; 52+ messages in thread
From: Jeff King @ 2012-10-07 23:52 UTC (permalink / raw)
  To: John Whitney; +Cc: Phil Hord, git

On Sat, Oct 06, 2012 at 09:23:59PM -0500, John Whitney wrote:

> >You said in your test script:
> >
> >   # Committing test.txt or clearing .gitattributes does clear
> >   # the "modified" status, but those options are undesirable
> >
> >Why is the commit undesirable? You have decided that CRs will no longer
> >be tolerated in your repository (by setting .gitattributes). Now you
> >need to record that change in history with a commit that strips out the
> >CRs.
> In some cases it's undesirable. In my example, all I want to do is
> merge in the change that deletes the file, so I don't want to have to
> add that extra commit when I'm just going to delete the file anyway.

Yes, but that is conflating two operations. You only don't want to do
the commit because you are anticipating what is coming next (the
cherry-picked deletion). But if you want to conflate, then you could
also realize that you can simply delete the file, CRs or no, and you do
not need to care about its modified state.

I think a much stronger argument for your position is that the cherry
pick would not happen without a conflict after such a commit, because it
would be deleting files with two different sets of content (the
cherry-pick would want to delete the CR version, but you would not have
that version).

In other words, you want the cherry-pick to happen and ignore the
modification that could be committed, because you know the modification
is not relevant (but git does not). But there is not a way to do that
(even once you overcome the confusion), because the usual way to do so
is to drop the local modification with "git reset" (which would not work
in this case).

> >It is not about having CRs in the working tree file. Those are now
> >considered uninteresting and stripped by git when comparing to the HEAD.
> >The problem is that what's in your _repository_ has CRs.
> Yes, but does that really have to be an issue? Is there any technical
> or practical reason you can think of that the repository shouldn't
> ignore those CRs?

It's significantly less efficient. Right now git only has to do the
conversion when updating the index cache of what's on the filesystem
(i.e., when it would be doing a sha1 over the file contents _anyway_).
And then it can compare sha1s internally, because it knows that all of
the sha1s it has computed are for the canonical in-repo versions of the
file.

If we assume that the in-repo file might need to have CRs stripped, then
we need to actually follow up every sha1 mismatch with an actual content
diff in order to discover if it really is different or not. We could
cache the "true" sha1 of the canonical stripped version to avoid this,
but now we are getting much more complex. In most cases it is sufficient
to just commit the cleaned up contents and then never worry about it
again.

> You're right, we can't magically avoid all the line ending issues
> that people will run into. In this case, though, I think git can
> sidestep a fairly obnoxious problem. My example was simple, but when
> you've got multiple branches that need to be rebased/merged, it can
> get pretty hairy. The repository will never be truly "clean" unless
> you rewrite the whole thing (using filter-branch, for instance).

Right. Git's current approach is very hairy when you are looking at
history that crosses a CRLF flag-day boundary. It's definitely a
weakness of the canonicalization approach. But other approaches also
have downsides; I don't want to catalogue them all here, but you can
certainly search the archive for various discussions and flamewars about
how line endings are handled.

> Maybe my above suggestion is more of a feature request than a bug,

Fair enough. I think your complaint is real, but I think nobody has been
clever enough yet to devise a solution that does not have too many other
downsides. And of course you are free to propose such an approach if you
have thought of one. :)

> but there is the obvious bug that after changing .gitattributes, git
> still doesn't notice that files are "modified" until you modify them
> again in some way (touch works). I only noticed the CRs in our own
> repository after I tried to rebase a branch and got strange errors.
> To make git notice all the files, I had to "find . -type f -exec
> touch {} \;".

I think the idea has been floated before of unconditionally refreshing
the index when you update the crlf config via "git config". But of
course that can only fix a fraction of the cases. You might edit it with
an editor. Or they may be new lines in .gitattributes. Or a change of
wildcard lines in .gitattributes.

Really, the issue is that the index contains a cache of what's in the
files that is considered valid unless the stat information of the file
changes. But that is obviously not the full story, as the
canonicalization rules (CRLF handling or smudge/clean filters) can
change, too, and that is not considered as part of the cache's validity.
Doing it "right" would mean that anytime the attributes or config files
changed, we would consider the cache entry dirty and re-read (and
re-canonicalize) the file.

But that has either:

  1. Bad complexity. It means our cache validity needs to know about
     exactly which rules were applied to yield the cached sha1. And
     those rules can be complex, consisting of wildcard matching,
     cross-referencing custom filters from config, etc.

  2. Bad performance. If you instead just invalidate cached sha1s when
     the gitattributes or .git/config file changes, you catch way too
     many cases. E.g., if you checkout a branch that changes
     .gitattributes, we have to re-read every file in the repository,
     even though most of them will not be affected.

So I think it's possible to handle this case correctly, but doing it
right is quite complex. So we have the "just manually poke the files
when you make such a change". Which is a horrible user experience, but
works OK in practice (and many people do not run into it at all, because
on new projects they set the filter attributes very early on, before
they have an existing history).

IOW, no, it is not pretty, but these are all known issues that nobody
has felt it worth tackling yet.

-Peff

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-07 23:52         ` Jeff King
@ 2012-10-09 17:17           ` John Whitney
  2012-10-09 19:00             ` John Whitney
  0 siblings, 1 reply; 52+ messages in thread
From: John Whitney @ 2012-10-09 17:17 UTC (permalink / raw)
  To: Jeff King; +Cc: Phil Hord, git

On 10/7/12 6:52 PM, Jeff King wrote:
>> Yes, but does that really have to be an issue? Is there any technical 
>> or practical reason you can think of that the repository shouldn't 
>> ignore those CRs? 
> It's significantly less efficient. Right now git only has to do the
> conversion when updating the index cache of what's on the filesystem
> (i.e., when it would be doing a sha1 over the file contents _anyway_).
> And then it can compare sha1s internally, because it knows that all of
> the sha1s it has computed are for the canonical in-repo versions of the
> file.
>
> If we assume that the in-repo file might need to have CRs stripped, then
> we need to actually follow up every sha1 mismatch with an actual content
> diff in order to discover if it really is different or not. We could
> cache the "true" sha1 of the canonical stripped version to avoid this,
> but now we are getting much more complex. In most cases it is sufficient
> to just commit the cleaned up contents and then never worry about it
> again.
>
>> You're right, we can't magically avoid all the line ending issues
>> that people will run into. In this case, though, I think git can
>> sidestep a fairly obnoxious problem. My example was simple, but when
>> you've got multiple branches that need to be rebased/merged, it can
>> get pretty hairy. The repository will never be truly "clean" unless
>> you rewrite the whole thing (using filter-branch, for instance).
> Right. Git's current approach is very hairy when you are looking at
> history that crosses a CRLF flag-day boundary. It's definitely a
> weakness of the canonicalization approach. But other approaches also
> have downsides; I don't want to catalogue them all here, but you can
> certainly search the archive for various discussions and flamewars about
> how line endings are handled.
>
>> Maybe my above suggestion is more of a feature request than a bug,
> Fair enough. I think your complaint is real, but I think nobody has been
> clever enough yet to devise a solution that does not have too many other
> downsides. And of course you are free to propose such an approach if you
> have thought of one. :)
>
>> but there is the obvious bug that after changing .gitattributes, git
>> still doesn't notice that files are "modified" until you modify them
>> again in some way (touch works). I only noticed the CRs in our own
>> repository after I tried to rebase a branch and got strange errors.
>> To make git notice all the files, I had to "find . -type f -exec
>> touch {} \;".
> I think the idea has been floated before of unconditionally refreshing
> the index when you update the crlf config via "git config". But of
> course that can only fix a fraction of the cases. You might edit it with
> an editor. Or they may be new lines in .gitattributes. Or a change of
> wildcard lines in .gitattributes.
>
> Really, the issue is that the index contains a cache of what's in the
> files that is considered valid unless the stat information of the file
> changes. But that is obviously not the full story, as the
> canonicalization rules (CRLF handling or smudge/clean filters) can
> change, too, and that is not considered as part of the cache's validity.
> Doing it "right" would mean that anytime the attributes or config files
> changed, we would consider the cache entry dirty and re-read (and
> re-canonicalize) the file.
>
> But that has either:
>
>    1. Bad complexity. It means our cache validity needs to know about
>       exactly which rules were applied to yield the cached sha1. And
>       those rules can be complex, consisting of wildcard matching,
>       cross-referencing custom filters from config, etc.
>
>    2. Bad performance. If you instead just invalidate cached sha1s when
>       the gitattributes or .git/config file changes, you catch way too
>       many cases. E.g., if you checkout a branch that changes
>       .gitattributes, we have to re-read every file in the repository,
>       even though most of them will not be affected.
>
> So I think it's possible to handle this case correctly, but doing it
> right is quite complex. So we have the "just manually poke the files
> when you make such a change". Which is a horrible user experience, but
> works OK in practice (and many people do not run into it at all, because
> on new projects they set the filter attributes very early on, before
> they have an existing history).
>
> IOW, no, it is not pretty, but these are all known issues that nobody
> has felt it worth tackling yet.
>
> -Peff

Thank you very much for your detailed explanations. I suspected that 
efficiency concerns might be preventing a clean solution.

How about this idea... When git stores files, it could include a bit of 
metadata that tells it whether the file is a binary blob or text. 
(Perhaps it already does this?) If a binary blob (in the repository) is 
being compared with a text file (on the filesystem), git could 
re-process the blob and get the "sha1 of the canonical stripped 
version". In all other situations, the original SHA1 should be correct, 
since git already removes CRs from the line endings in files it 
recognizes as text.

I would think that this solution would have no performance penalty for 
"fixed" repositories. (It would only have a small performance hit when 
binary blobs are compared against text files, which is rare even in 
broken repositories.) Git could even throw a warning like: "File xyz.txt 
was originally stored as a binary blob."

What do you think?

    ---John

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-09 17:17           ` John Whitney
@ 2012-10-09 19:00             ` John Whitney
  0 siblings, 0 replies; 52+ messages in thread
From: John Whitney @ 2012-10-09 19:00 UTC (permalink / raw)
  To: Jeff King; +Cc: Phil Hord, git

On 10/9/12 12:17 PM, John Whitney wrote:
> Thank you very much for your detailed explanations. I suspected that 
> efficiency concerns might be preventing a clean solution.
>
> How about this idea... When git stores files, it could include a bit 
> of metadata that tells it whether the file is a binary blob or text. 
> (Perhaps it already does this?) If a binary blob (in the repository) 
> is being compared with a text file (on the filesystem), git could 
> re-process the blob and get the "sha1 of the canonical stripped 
> version". In all other situations, the original SHA1 should be 
> correct, since git already removes CRs from the line endings in files 
> it recognizes as text.
>
> I would think that this solution would have no performance penalty for 
> "fixed" repositories. (It would only have a small performance hit when 
> binary blobs are compared against text files, which is rare even in 
> broken repositories.) Git could even throw a warning like: "File 
> xyz.txt was originally stored as a binary blob."
>
> What do you think?
>
>    ---John
>
I'm going to reply to myself, to save you the trouble of replying. 
(You've been very helpful and I do appreciate it.)

I guess the problem with this idea is that git doesn't have any way to 
distinguish between binary blobs and text files in the repository. I 
think it would be useful information, but I guess that bridge burned a 
long time ago. So any metadata would have to be stored separately. Jeff, 
that's roughly equivalent to your idea of caching, which would take a 
lot of work to implement.

Thank you so much for helping me to understand the reason git behaves 
the way it does. It's a great tool!

    ---John

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug Report
       [not found]         ` <AS1P190MB175022A7F1264807ECA464A8ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM>
@ 2022-04-21 17:52           ` Torsten Bögershausen
  0 siblings, 0 replies; 52+ messages in thread
From: Torsten Bögershausen @ 2022-04-21 17:52 UTC (permalink / raw)
  To: Daniel Habenicht; +Cc: 'brian m. carlson', rsbecker, git

On Thu, Apr 21, 2022 at 03:29:20PM +0000, Daniel Habenicht wrote:
> Hi Torsten,
>
> thanks for your answer.
> As I explained in the reproduction, I now know why this is happening and I successfully resolved it for my repository.
> I just wanted raise awareness that it is not self-explanatory to non-professional users.
>
> I would suggest two changes:
>
>   1.  Warn the user on commit of the .gitattributes that he also needs to renormalize the repository (or even better, do that by default).
>   2.  Include the information about the need for a renormalization commit on checkouts/restores/reset if there are still files not updated (shown as modified).
>
> Regarding the "Users which are confused may put their frustration aside and read the documentation".
> I think most users won't make the connection for the first 3 google searches, if the problem arises only several commits after the gitattributes change, or if the repository gets cloned by a new user.
>
>
> Cheers,
> Daniel
>

(Sorry for the top-posting before, this list uses bottom-posting)

I still hope that users who are able to find the feature of the
.gitattributes file(s) are able to find out about the renormalaztion as well.
And you are not the first one who runs into this problem, if that is of any
comfort.

Now, back to your suggestions:
The way Git works does not seam to allow a reliable detection of files
that are "modified" after a checkout/restore/reset when .gitattributes
change. (Someone may correct me if this is wrong.
It is related/connected to the timestamps of "the index"
and the files in the working tree and the fact that "git add" will
need to store a new version of the file in the repo e.g CRLF -> LF)

Automatically doing a renormalization seems to be an impossible thing:
The commit as such is atomic, including all files in the working tree
with their line endings and the .gitattributes file itself.
Changing things here seems the wrong way to go, at least for me.

Showing a hint when a .gitattributes file is commited may be more feasable.
I haven't digged which part of the code would be the best place.

Patches and ideas are welcome

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug Report
  2022-04-21 13:20     ` Daniel Habenicht
@ 2022-04-21 14:39       ` Torsten Bögershausen
       [not found]         ` <AS1P190MB175022A7F1264807ECA464A8ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM>
  0 siblings, 1 reply; 52+ messages in thread
From: Torsten Bögershausen @ 2022-04-21 14:39 UTC (permalink / raw)
  To: Daniel Habenicht; +Cc: 'brian m. carlson', rsbecker, git


Hej Daniel,

 $ git clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git
 $ cd bug-reproduction.git-repo.git
 $ git ls-files --eol
 i/none  w/none  attr/                   .gitattributes
 i/lf    w/lf    attr/                   README.md
 i/crlf  w/crlf  attr/text eol=lf        test.cs

Your repo needs to be re-normalized:
 $ git add --renormalize .
 $ git status
 On branch main
 Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
          modified:   test.cs

That is all that needs to be done.

Users which are confused may put their frustration aside,
and read the documentation:

https://git-scm.com/docs/gitattributes

especially the part about the line endings and normalization,
search for "renormalize".

I don't know, if there is something we can do that makes live easier,
but if yes: suggestions are more than welcome.

So yes, thanks for the report.




On Thu, Apr 21, 2022 at 01:20:37PM +0000, Daniel Habenicht wrote:
> Hi Randall and Brian, 
>
> thanks for the fast response.
> @Randall: I also tried it with autocrlf=input and it still reproduces. I included it in the reproduction. I also added more examples for confusing behaviour.
>
>
> Here is the full bug report: 
> (You can view a Markdown rendered version of this reproduction at: https://github.com/DanielHabenicht/bug-reproduction.git-repo)
>
> # Description
>
> When changing the `.gitattributes` file not all changes to the checked in files are apparent.
> They only get updated on a new clone or when refreshing the index - that's somehow expected.
> But it creates confusion and unexpected behavior if they are not updated together with the `.gitattributes` changes.
> It can make easy changes between branches impossible, break the flow of squashing commits or lead to confusing state of everlasting uncommited change.
> These edge cases for confusing behaviour I have added below.
>
> # Reproduction
>
> 1. Checkout with the following `.gitconfig` settings set:
>
> ```gitconfig
> # .gitconfig
> [core]
>     autocrlf = false
> # Or
>     autocrlf = input
> ```
>
> 2. Clone the repository
> ```bash
> git clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git
> ```
>
> 3. `test.cs` should be shown as `modified`
>
> > This is confusing to the user, he just checked the repo out and did not change a thing. At least there should be a warning?
>
> ```
> git status
> On branch main
> Your branch is up to date with 'origin/main'.
>
> Changes not staged for commit:
>   (use "git add <file>..." to update what will be committed)
>   (use "git restore <file>..." to discard changes in working directory)
>         modified:   test.cs
>
> no changes added to commit (use "git add" and/or "git commit -a")
> ```
>
> 5. Running any git command like the ones below will not remove the changed file:
>
> ```bash
> git rm --cached -r .
> git reset --hard
> git add --renormalize .
> ```
>
> > This as well is very confusing and there is no indication on why this is happening and there are still modified files after everything should be reset.
> > Keep in mind that this could have happened in error and could be happening to a totally unrelated (to the inital `.gitattributes` change) user.
>
> 6. Running `git diff` is even more confusing, and doing as the warning suggests (`warning: CRLF will be replaced by LF in test.cs. The file will have its original line endings in your working directory`) and replacing `CRLF` by `LF` does silence the warning but does not change the diff itself:
>
> ```diff
> warning: CRLF will be replaced by LF in test.cs.
> The file will have its original line endings in your working directory
> diff --git b/test.cs a/test.cs
> index 1e230ed..5464a2d 100644
> --- b/test.cs
> +++ a/test.cs
> @@ -1,11 +1,11 @@
> -using System.Diagnostics.CodeAnalysis;
> -using System.Linq;
> -using Xunit;
> -using Moq;
> -
> -
> -
> -namespace Tests
> -{
> -
> -}
> +using System.Diagnostics.CodeAnalysis;^M
> +using System.Linq;^M
> +using Xunit;^M
> +using Moq;^M
> +^M
> +^M
> +^M
> +namespace Tests^M
> +{^M
> +^M
> +}^M
> ```
>
> > This is showing the exact opposite of what git is really doing. Actually it replaces the line encoding of the index (i/crlf) with the right encoding (i/lf) (see **[1]**)
> > From the git user perspective everything is in great shape, the file is LF, as it should be, but still git complains about a change that is not visible to the user without background knowledge about gitattributes and the git index.
>
> 8. Try changing the branch to a modified copy with `git checkout some-changes` is not possible (also with the recommended command). The only solution would be to commit - nothing else helps (but thats not really a solution). :
>
> ```bash
> error: Your local changes to the following files would be overwritten by checkout:
>         test.cs
> Please commit your changes or stash them before you switch branches.
> Aborting
> ```
>
> > This makes changing branches harder, as it can't be force reset and git will always complain about files being overwritten.
> > It also break the flow for squashing commits as you would need to manually intervene (and add a commit) if someone forgot to commit all files after a .gitattributes change and only recognized it at a later date.
>
>
> **[1]**: I hope this answer explained it right to me: https://stackoverflow.com/a/71937898/9277073.
> But it is rather unintuitive to me, and possibly other users, as there seems to be a hidden middle layer leading to this problem. See the graph at the github repo)
>
>
>
> Cheers,
> Daniel
>
>
>
>
> Daniel Habenicht
>
>
> From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
> Sent: Thursday, April 21, 2022 00:34
> To: 'brian m. carlson' <sandals@crustytoothpaste.net>; 'Daniel Habenicht' <daniel-habenicht@outlook.de>
> Cc: git@vger.kernel.org <git@vger.kernel.org>
> Subject: RE: Bug Report
>  
> On April 20, 2022 5:31 PM, brian m. carlson wrote:
> >On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:
> >> Hi there,
> >>
> >> I think I found a bug or at least some unexpected behavior. Please
> >> have a look at the following reproduction repo:
> >>
> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDanielHabenicht%2Fbug-reproduction.git-repo%2Fblob%2Fmain&amp;data=05%7C01%7C%7C145ae6f595d54ac7b5fd08da231de43c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637860908535410706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=HXFm4sBZ5yQGQPkBlkzKhkgDJOXBqSlgETkrhGxgkmI%3D&amp;reserved=0
> >> /README.md
> >
> >You're more likely to get someone to look at this if you post the actual text to the
> >list.  While I might be willing to look at it on GitHub, other folks won't, and I
> >probably won't get a chance to look at this issue anytime soon.
>
> The only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.
>
> Daniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.
>
> --Randall
>
> --
> Brief whoami: NonStop&UNIX developer since approximately
> UNIX(421664400)
> NonStop(211288444200000000)
> -- In real life, I talk too much.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug Report
  2022-04-20 22:34   ` rsbecker
@ 2022-04-21 13:20     ` Daniel Habenicht
  2022-04-21 14:39       ` Torsten Bögershausen
  0 siblings, 1 reply; 52+ messages in thread
From: Daniel Habenicht @ 2022-04-21 13:20 UTC (permalink / raw)
  To: 'brian m. carlson', rsbecker; +Cc: git

Hi Randall and Brian, 

thanks for the fast response. 
@Randall: I also tried it with autocrlf=input and it still reproduces. I included it in the reproduction. I also added more examples for confusing behaviour. 


Here is the full bug report: 
(You can view a Markdown rendered version of this reproduction at: https://github.com/DanielHabenicht/bug-reproduction.git-repo)

# Description 

When changing the `.gitattributes` file not all changes to the checked in files are apparent.
They only get updated on a new clone or when refreshing the index - that's somehow expected. 
But it creates confusion and unexpected behavior if they are not updated together with the `.gitattributes` changes. 
It can make easy changes between branches impossible, break the flow of squashing commits or lead to confusing state of everlasting uncommited change.
These edge cases for confusing behaviour I have added below. 

# Reproduction 

1. Checkout with the following `.gitconfig` settings set:

```gitconfig
# .gitconfig
[core]
    autocrlf = false
# Or
    autocrlf = input
```

2. Clone the repository
```bash
git clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git
```

3. `test.cs` should be shown as `modified`

> This is confusing to the user, he just checked the repo out and did not change a thing. At least there should be a warning?
   
```
git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   test.cs

no changes added to commit (use "git add" and/or "git commit -a")
```

5. Running any git command like the ones below will not remove the changed file:

```bash
git rm --cached -r .
git reset --hard
git add --renormalize .
```

> This as well is very confusing and there is no indication on why this is happening and there are still modified files after everything should be reset. 
> Keep in mind that this could have happened in error and could be happening to a totally unrelated (to the inital `.gitattributes` change) user. 

6. Running `git diff` is even more confusing, and doing as the warning suggests (`warning: CRLF will be replaced by LF in test.cs. The file will have its original line endings in your working directory`) and replacing `CRLF` by `LF` does silence the warning but does not change the diff itself:

```diff
warning: CRLF will be replaced by LF in test.cs.
The file will have its original line endings in your working directory
diff --git b/test.cs a/test.cs
index 1e230ed..5464a2d 100644
--- b/test.cs
+++ a/test.cs
@@ -1,11 +1,11 @@
-using System.Diagnostics.CodeAnalysis;
-using System.Linq;
-using Xunit;
-using Moq;
-
-
-
-namespace Tests
-{
-
-}
+using System.Diagnostics.CodeAnalysis;^M
+using System.Linq;^M
+using Xunit;^M
+using Moq;^M
+^M
+^M
+^M
+namespace Tests^M
+{^M
+^M
+}^M
```

> This is showing the exact opposite of what git is really doing. Actually it replaces the line encoding of the index (i/crlf) with the right encoding (i/lf) (see **[1]**)
> From the git user perspective everything is in great shape, the file is LF, as it should be, but still git complains about a change that is not visible to the user without background knowledge about gitattributes and the git index. 

8. Try changing the branch to a modified copy with `git checkout some-changes` is not possible (also with the recommended command). The only solution would be to commit - nothing else helps (but thats not really a solution). : 

```bash
error: Your local changes to the following files would be overwritten by checkout:
        test.cs
Please commit your changes or stash them before you switch branches.
Aborting
```

> This makes changing branches harder, as it can't be force reset and git will always complain about files being overwritten.
> It also break the flow for squashing commits as you would need to manually intervene (and add a commit) if someone forgot to commit all files after a .gitattributes change and only recognized it at a later date.


**[1]**: I hope this answer explained it right to me: https://stackoverflow.com/a/71937898/9277073. 
But it is rather unintuitive to me, and possibly other users, as there seems to be a hidden middle layer leading to this problem. See the graph at the github repo)



Cheers,
Daniel




Daniel Habenicht


From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Sent: Thursday, April 21, 2022 00:34
To: 'brian m. carlson' <sandals@crustytoothpaste.net>; 'Daniel Habenicht' <daniel-habenicht@outlook.de>
Cc: git@vger.kernel.org <git@vger.kernel.org>
Subject: RE: Bug Report 
 
On April 20, 2022 5:31 PM, brian m. carlson wrote:
>On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:
>> Hi there,
>>
>> I think I found a bug or at least some unexpected behavior. Please
>> have a look at the following reproduction repo:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDanielHabenicht%2Fbug-reproduction.git-repo%2Fblob%2Fmain&amp;data=05%7C01%7C%7C145ae6f595d54ac7b5fd08da231de43c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637860908535410706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=HXFm4sBZ5yQGQPkBlkzKhkgDJOXBqSlgETkrhGxgkmI%3D&amp;reserved=0
>> /README.md
>
>You're more likely to get someone to look at this if you post the actual text to the
>list.  While I might be willing to look at it on GitHub, other folks won't, and I
>probably won't get a chance to look at this issue anytime soon.

The only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.

Daniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.

--Randall

--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* RE: Bug Report
  2022-04-20 21:30 ` brian m. carlson
@ 2022-04-20 22:34   ` rsbecker
  2022-04-21 13:20     ` Daniel Habenicht
  0 siblings, 1 reply; 52+ messages in thread
From: rsbecker @ 2022-04-20 22:34 UTC (permalink / raw)
  To: 'brian m. carlson', 'Daniel Habenicht'; +Cc: git

On April 20, 2022 5:31 PM, brian m. carlson wrote:
>On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:
>> Hi there,
>>
>> I think I found a bug or at least some unexpected behavior. Please
>> have a look at the following reproduction repo:
>>
>> https://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main
>> /README.md
>
>You're more likely to get someone to look at this if you post the actual text to the
>list.  While I might be willing to look at it on GitHub, other folks won't, and I
>probably won't get a chance to look at this issue anytime soon.

The only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.

Daniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.

--Randall

--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.


^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug Report
  2022-04-20 19:45 Daniel Habenicht
@ 2022-04-20 21:30 ` brian m. carlson
  2022-04-20 22:34   ` rsbecker
  0 siblings, 1 reply; 52+ messages in thread
From: brian m. carlson @ 2022-04-20 21:30 UTC (permalink / raw)
  To: Daniel Habenicht; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:
> Hi there,
> 
> I think I found a bug or at least some unexpected behavior. 
> Please have a look at the following reproduction repo: 
> 
> https://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main/README.md

You're more likely to get someone to look at this if you post the actual
text to the list.  While I might be willing to look at it on GitHub,
other folks won't, and I probably won't get a chance to look at this
issue anytime soon.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Bug Report
@ 2022-04-20 19:45 Daniel Habenicht
  2022-04-20 21:30 ` brian m. carlson
  0 siblings, 1 reply; 52+ messages in thread
From: Daniel Habenicht @ 2022-04-20 19:45 UTC (permalink / raw)
  To: git

Hi there,

I think I found a bug or at least some unexpected behavior. 
Please have a look at the following reproduction repo: 

https://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main/README.md



[System Info]
git version:
git version 2.33.1.windows.1
cpu: x86_64
built from commit: 05d80adb775077d673fab685009ede4a1003ed92
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19042 
compiler info: gnuc: 10.3
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>


[Enabled Hooks]
None

Also reproduced on: 
[System Info] 
git version:
git version 2.35.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.4.0-1074-azure #77~18.04.1-Ubuntu SMP Wed Mar 30 15:36:02 UTC 2022 x86_64
compiler info: gnuc: 9.4
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/bash


Cheers,
Daniel

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Bug Report
@ 2021-12-01 22:31 Josh Rampersad
  0 siblings, 0 replies; 52+ messages in thread
From: Josh Rampersad @ 2021-12-01 22:31 UTC (permalink / raw)
  To: git


Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

Navigated to a non-default branch of the repo.
I wanted a list of tagged commits for a specific tag pattern relating to a
package in my repo.
Ran the command: `git log origin/master --no-walk --grep='my-package' --tags='*my-package*' --decorate-refs='*my-package*'  --format='format:%ct %H %D'`
The output was as expected with the tags not relating to my-package being filtered out from the output by the decorate-refs option.
I then, wanted to pipe this output to a separate program.


What did you expect to happen? (Expected behavior)

I expected that the piped output would be the same as the output in my terminal.

What happened instead? (Actual behavior)

The filtering I got from the decorate-refs flag was no longer being applied. Thus giving me a bunch of tags I did not want

What's different between what you expected and what actually happened?

Whether the decorate-refs option worked as expected.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.31.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT
2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101 x86_64
compiler info: clang: 12.0.0 (clang-1200.0.32.29)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2021-11-12  6:59   ` Theodore Li
@ 2021-11-12 14:05     ` Paul Smith
  0 siblings, 0 replies; 52+ messages in thread
From: Paul Smith @ 2021-11-12 14:05 UTC (permalink / raw)
  To: Theodore Li; +Cc: git

On Fri, 2021-11-12 at 01:59 -0500, Theodore Li wrote:
> Yes, though other patterns like !/*/ don't need the quotes. I thought
> it worked the same way without the quotes in earlier versions, but
> after testing with version 2.32.0, it seems like the behavior is the
> same. Guess I remembered wrong.

It's important to realize that in a POSIX-style shell (as you'll find
on GNU/Linux or MacOS, or in the Git for Windows shell), wildcard
expansion is performed _by the shell_ before the program is even
invoked.  It's not performed by the program itself (in this case, Git).

In a POSIX-style shell it works like this (by default): first the shell
will try to expand the wildcards in your command line by matching them
for files.  If any match, the wildcard expression is replaced on the
command line.  If no files match, then the wildcard expression is
passed to the command without change.

So if you run:

  git sparse-checkout /*

then the shell will check if any files match the wildcard /*: since
clearly you will get matches for this expression, they will be expanded
and the shell will actually run:

  git sparse-checkout /bin /boot /cdrom /dev /...

Note, Git does not receive any indication that there ever was a
wildcard expression here!

On the other hand if you run:

  git sparse-checkout /blah/*/blah

(assuming you don't have any files on your system that match this
wildcard) then it won't match and the shell will run:

  git sparse-checkout /blah/*/blah

Now Git can examine this wildcard and do an appropriate thing with it.

In short, if you want to be _sure_ that a wildcard expression is passed
to the command and not expanded by the shell, you must always quote it:

  git sparse-checkout "/*"

If you don't quote it then it may or may not do what you intended,
depending on whether the wildcard happens to match any files.


^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2021-11-12  4:29 ` Junio C Hamano
@ 2021-11-12  6:59   ` Theodore Li
  2021-11-12 14:05     ` Paul Smith
  0 siblings, 1 reply; 52+ messages in thread
From: Theodore Li @ 2021-11-12  6:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Yes, though other patterns like !/*/ don't need the quotes. I thought
it worked the same way without the quotes in earlier versions, but
after testing with version 2.32.0, it seems like the behavior is the
same. Guess I remembered wrong.

On Thu, Nov 11, 2021 at 11:30 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Theodore Li <teddy.litheodore@gmail.com> writes:
>
> > Thank you for filling out a Git bug report!
> > Please answer the following questions to help us understand your issue.
> >
> > What did you do before the bug happened? (Steps to reproduce your issue)
> > After cloning a remote repository with the --no-checkout option and
> > executing git sparse-checkout init, the bug occurs with any
> > sparse-checkout command with the /* pattern (i.e. git sparse-checkout
> > set /*).
> >
> > What did you expect to happen? (Expected behavior)
> > The contents of .git/info/sparse-checkout and the output of git
> > sparse-checkout list should be '/*'
> >
> > What happened instead? (Actual behavior)
> > Instead, the output is the contents of the user's local root directory
> > (i.e. /bin, /boot, /cdrom, etc.).
>
> A blind guess, as I do not use sparse patterns, but perhaps you did
> not quote the "/*' pattern, i.e. you typed
>
>     $ git sparse-checkout set /*
>
> where you would have got a better behaviour if you typed
>
>     $ git sparse-checkout set "/*"
>
> ?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2021-11-12  4:22 bug report Theodore Li
@ 2021-11-12  4:29 ` Junio C Hamano
  2021-11-12  6:59   ` Theodore Li
  0 siblings, 1 reply; 52+ messages in thread
From: Junio C Hamano @ 2021-11-12  4:29 UTC (permalink / raw)
  To: Theodore Li; +Cc: git

Theodore Li <teddy.litheodore@gmail.com> writes:

> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
> After cloning a remote repository with the --no-checkout option and
> executing git sparse-checkout init, the bug occurs with any
> sparse-checkout command with the /* pattern (i.e. git sparse-checkout
> set /*).
>
> What did you expect to happen? (Expected behavior)
> The contents of .git/info/sparse-checkout and the output of git
> sparse-checkout list should be '/*'
>
> What happened instead? (Actual behavior)
> Instead, the output is the contents of the user's local root directory
> (i.e. /bin, /boot, /cdrom, etc.).

A blind guess, as I do not use sparse patterns, but perhaps you did
not quote the "/*' pattern, i.e. you typed

    $ git sparse-checkout set /*

where you would have got a better behaviour if you typed

    $ git sparse-checkout set "/*"

?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* bug report
@ 2021-11-12  4:22 Theodore Li
  2021-11-12  4:29 ` Junio C Hamano
  0 siblings, 1 reply; 52+ messages in thread
From: Theodore Li @ 2021-11-12  4:22 UTC (permalink / raw)
  To: git

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
After cloning a remote repository with the --no-checkout option and
executing git sparse-checkout init, the bug occurs with any
sparse-checkout command with the /* pattern (i.e. git sparse-checkout
set /*).

What did you expect to happen? (Expected behavior)
The contents of .git/info/sparse-checkout and the output of git
sparse-checkout list should be '/*'

What happened instead? (Actual behavior)
Instead, the output is the contents of the user's local root directory
(i.e. /bin, /boot, /cdrom, etc.).

What's different between what you expected and what actually happened?
It should set sparse-checkout to the pattern /*, corresponding to the
remote repository's root directory instead of adding all the folders
and files in the root directory of the user's local machine.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.33.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
compiler info: gnuc: 9.3
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug Report
  2020-03-27 11:53 Bug Report James Yeoman
@ 2020-03-27 12:59 ` Pratyush Yadav
  0 siblings, 0 replies; 52+ messages in thread
From: Pratyush Yadav @ 2020-03-27 12:59 UTC (permalink / raw)
  To: James Yeoman; +Cc: git, Paul Mackerras

Hi James,

On 27/03/20 11:53AM, James Yeoman wrote:
> gitk and git-gui are both not respecting git config.
> 
> When I set the diff.algorithm global config to patience, the command
> line git respects the config. However, both gitk and git-gui don't.
> When I use "git status -vv" to get a diff of the working directory,
> the diff produced respects the algorithm choice. The diff of the
> working directory in gitk and git-gui both still use the default diff
> algorithm, rather than the algorithm from the config.
 
Thanks for reporting. Can you please send steps to produce a simple 
scenario where the diff from two algorithms is different so I can test 
why git-gui is not respecting the config. Make them as minimal as 
possible.

Also, +Cc Paul, the gitk maintainer.

-- 
Regards,
Pratyush Yadav

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Bug Report
@ 2020-03-27 11:53 James Yeoman
  2020-03-27 12:59 ` Pratyush Yadav
  0 siblings, 1 reply; 52+ messages in thread
From: James Yeoman @ 2020-03-27 11:53 UTC (permalink / raw)
  To: git

gitk and git-gui are both not respecting git config.

When I set the diff.algorithm global config to patience, the command
line git respects the config. However, both gitk and git-gui don't.
When I use "git status -vv" to get a diff of the working directory,
the diff produced respects the algorithm choice. The diff of the
working directory in gitk and git-gui both still use the default diff
algorithm, rather than the algorithm from the config.

-- 




^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
       [not found] <CA+2sEepTyrK-iH+VBHVF1i9DuYVzDkTNxuM0-yoWbkC9N4f8HA@mail.gmail.com>
@ 2019-04-15 15:18 ` Nick Steinhauser
  0 siblings, 0 replies; 52+ messages in thread
From: Nick Steinhauser @ 2019-04-15 15:18 UTC (permalink / raw)
  To: git

user$ git checkout -b "environment-logging"
Switched to a new branch ' environment-logging'
user$ git status
On branch  environment-logging
nothing to commit, working tree clean
user$ git checkout develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
user$ git branch -D environment-logging
error: branch 'environment-logging' not found.


Regular space:
user$ git branch -D " environment-logging"
error: branch ' environment-logging' not found.


Nonbreaking space:
user$ git branch -D " environment-logging"
Deleted branch  environment-logging (was 267ffff).


Non breaking space inserted into my branch name. Above is copy pasted
from terminal with only the user name and directory altered and
extraneous commands removed. Note the space in the std out of the
first command but not included in the command itself. Whereas in the
last command I explicitly typed the nonbreaking space and it does
appear as a visible space. I do not know how to reproduce.


Thanks,

Nick

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2017-08-30 21:25 Bug report Aleksandar Pavic
  2017-08-31  6:36 ` Kevin Daudt
@ 2017-09-02  8:49 ` Jeff King
  1 sibling, 0 replies; 52+ messages in thread
From: Jeff King @ 2017-09-02  8:49 UTC (permalink / raw)
  To: Aleksandar Pavic; +Cc: git

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:

>  I have a file
> 
>  app/Controller/CustomerCardVerificationController.php
> 
> And when I take a look at changes log, I get this (no matter which tool I
> use):
> 
> 2017-07-31 19:41 dule             o membership renew payment email
> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
> 2017-03-16 15:59 Aleksandar Pavic o paypal
> 2017-03-10 13:34 Aleksandar Pavic o Production branch
> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>
> However if I manually browse thru revisions and open revision from
> 03/27/2017 07:05 PM
> 
> I can see the change in that file which is unlisted above, at revision
> ff9f4946e109bd234d438e4db1d319b1f6cb6580

How are you invoking the log? Are you doing:

  git log app/Controller/CustomerCardVerificationController.php

or similar? If that is the case, then history simplification may be
causing the results you see. And even you don't _see_ any merges in the
output, that is because they were simplified away. And the commit you
are looking for may have been on a side branch that was simplified away.

If you do:

  git log --full-history app/...

does the commit you are interested in show up? If so, then it was
removed due to history simplification. And if you are surprised that a
side branch was simplified away, that is most likely because there is a
mis-merge in your history (some merge which threw away the changes on a
side branch).

Try:

  git log --graph --oneline --name-status --full-history app/...

to see the whole shape of history, including which commits touched the
file.

You can read more about it in the "History Simplification" section of
"git help log".

-Peff

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2017-08-31  6:36 ` Kevin Daudt
  2017-08-31 14:19   ` Dov Grobgeld
@ 2017-08-31 16:23   ` Stephan Beyer
  1 sibling, 0 replies; 52+ messages in thread
From: Stephan Beyer @ 2017-08-31 16:23 UTC (permalink / raw)
  To: Kevin Daudt, Aleksandar Pavic; +Cc: git

On 08/31/2017 08:36 AM, Kevin Daudt wrote:
> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>  I have a file
>>
>>  app/Controller/CustomerCardVerificationController.php
>>
>> And when I take a look at changes log, I get this (no matter which tool I
>> use):
>>
>> 2017-07-31 19:41 dule             o membership renew payment email
>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>
>> However if I manually browse thru revisions and open revision from
>> 03/27/2017 07:05 PM
>>
>> I can see the change in that file which is unlisted above, at revision
>> ff9f4946e109bd234d438e4db1d319b1f6cb6580

I am not sure if I fully understand but I guess your commit ff9f4946e1
has been commited at detached HEAD.

You could do
	git log --oneline --graph master ff9f4946e1
to see where the "missing" commit lies.
And probably a
	git cherry-pick ff9f4946e1
might pick your missing feature.

Stephan

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2017-08-31 14:19   ` Dov Grobgeld
@ 2017-08-31 14:55     ` Aleksandar Pavic
  0 siblings, 0 replies; 52+ messages in thread
From: Aleksandar Pavic @ 2017-08-31 14:55 UTC (permalink / raw)
  To: Dov Grobgeld, Kevin Daudt; +Cc: git

Hm, thanks, but the link was not helpful, there are no merge commits to 
master branch.

Those changes should have not been undone, that's how we caught it, 
because 1 line peace of code introduced new feature (+-10% tolerance on 
credit card verification  amount).

So most likeley they were undone, but our tree is pretty simple, we have 
master and production branches.



On 31.08.2017. 16:19, Dov Grobgeld wrote:
> The following answer that I got back in 2015 from Jeff King might be
> relevant to your problem:
>
> https://marc.info/?l=git&m=144178948506788&w=2
>
> Regards,
> Dov
>
> On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt <me@ikke.info> wrote:
>> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>>   I have a file
>>>
>>>   app/Controller/CustomerCardVerificationController.php
>>>
>>> And when I take a look at changes log, I get this (no matter which tool I
>>> use):
>>>
>>> 2017-07-31 19:41 dule             o membership renew payment email
>>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>>
>>> However if I manually browse thru revisions and open revision from
>>> 03/27/2017 07:05 PM
>>>
>>> I can see the change in that file which is unlisted above, at revision
>>> ff9f4946e109bd234d438e4db1d319b1f6cb6580
>>>
>>> And I'm at master branch all the time...
>>>
>>> We wouldn't have noticed that if it weren't one important feature...
>>>
>> What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
>> return?
>>
>> Where did you find this commit?


^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2017-08-31  6:36 ` Kevin Daudt
@ 2017-08-31 14:19   ` Dov Grobgeld
  2017-08-31 14:55     ` Aleksandar Pavic
  2017-08-31 16:23   ` Stephan Beyer
  1 sibling, 1 reply; 52+ messages in thread
From: Dov Grobgeld @ 2017-08-31 14:19 UTC (permalink / raw)
  To: Kevin Daudt; +Cc: Aleksandar Pavic, git

The following answer that I got back in 2015 from Jeff King might be
relevant to your problem:

https://marc.info/?l=git&m=144178948506788&w=2

Regards,
Dov

On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt <me@ikke.info> wrote:
> On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>>  I have a file
>>
>>  app/Controller/CustomerCardVerificationController.php
>>
>> And when I take a look at changes log, I get this (no matter which tool I
>> use):
>>
>> 2017-07-31 19:41 dule             o membership renew payment email
>> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
>> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
>> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
>> 2017-03-16 15:59 Aleksandar Pavic o paypal
>> 2017-03-10 13:34 Aleksandar Pavic o Production branch
>> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
>>
>> However if I manually browse thru revisions and open revision from
>> 03/27/2017 07:05 PM
>>
>> I can see the change in that file which is unlisted above, at revision
>> ff9f4946e109bd234d438e4db1d319b1f6cb6580
>>
>> And I'm at master branch all the time...
>>
>> We wouldn't have noticed that if it weren't one important feature...
>>
>
> What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
> return?
>
> Where did you find this commit?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2017-08-30 21:25 Bug report Aleksandar Pavic
@ 2017-08-31  6:36 ` Kevin Daudt
  2017-08-31 14:19   ` Dov Grobgeld
  2017-08-31 16:23   ` Stephan Beyer
  2017-09-02  8:49 ` Jeff King
  1 sibling, 2 replies; 52+ messages in thread
From: Kevin Daudt @ 2017-08-31  6:36 UTC (permalink / raw)
  To: Aleksandar Pavic; +Cc: git

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote:
>  I have a file
> 
>  app/Controller/CustomerCardVerificationController.php
> 
> And when I take a look at changes log, I get this (no matter which tool I
> use):
> 
> 2017-07-31 19:41 dule             o membership renew payment email
> 2017-06-07 08:59 Dusan Tatic      o cc refund clean
> 2017-04-15 00:16 Miodrag Dragić   o refound admin payment
> 2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
> 2017-03-16 15:59 Aleksandar Pavic o paypal
> 2017-03-10 13:34 Aleksandar Pavic o Production branch
> 2017-03-10 13:01 Aleksandar Pavic I Migrating dev
> 
> However if I manually browse thru revisions and open revision from
> 03/27/2017 07:05 PM
> 
> I can see the change in that file which is unlisted above, at revision
> ff9f4946e109bd234d438e4db1d319b1f6cb6580
> 
> And I'm at master branch all the time...
> 
> We wouldn't have noticed that if it weren't one important feature...
> 

What does git branch --contains ff9f4946e109bd234d438e4db1d319b1f6cb6580
return?

Where did you find this commit?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Bug report
@ 2017-08-30 21:25 Aleksandar Pavic
  2017-08-31  6:36 ` Kevin Daudt
  2017-09-02  8:49 ` Jeff King
  0 siblings, 2 replies; 52+ messages in thread
From: Aleksandar Pavic @ 2017-08-30 21:25 UTC (permalink / raw)
  To: git

  I have a file

  app/Controller/CustomerCardVerificationController.php

And when I take a look at changes log, I get this (no matter which tool 
I use):

2017-07-31 19:41 dule             o membership renew payment email
2017-06-07 08:59 Dusan Tatic      o cc refund clean
2017-04-15 00:16 Miodrag Dragić   o refound admin payment
2017-03-20 12:02 Dusan Tatic      o CardVerification card connect
2017-03-16 15:59 Aleksandar Pavic o paypal
2017-03-10 13:34 Aleksandar Pavic o Production branch
2017-03-10 13:01 Aleksandar Pavic I Migrating dev

However if I manually browse thru revisions and open revision from 
03/27/2017 07:05 PM

I can see the change in that file which is unlisted above, at revision 
ff9f4946e109bd234d438e4db1d319b1f6cb6580

And I'm at master branch all the time...

We wouldn't have noticed that if it weren't one important feature...


^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2016-05-13  8:10             ` Jeff King
@ 2016-05-13 12:05               ` 李本超
  0 siblings, 0 replies; 52+ messages in thread
From: 李本超 @ 2016-05-13 12:05 UTC (permalink / raw)
  To: Jeff King; +Cc: Pranit Bauva, Git List

Thanks for your explanation

>
> The moment where I think you'd like to be notified is when we skipped
> doing anything with patch 1. You'd prefer it to say "woah, the other
> side of the rebase did the same thing as us".
Actually this is the problem where I want to be notified.

> But rebase does not do that by default, because the intent of rebase is
> that you are rebasing your work on an upstream which might be accepting
> part of your work as patches. So it is a feature that rebase says
> "already applied upstream -- let's ignore this one".
>
> I don't think there is a way to ask rebase not to ignore such
> already-applied patches. But I'm not sure if there should be, for two
> reasons:
>
>   1. You should consider just using "git merge" to merge the two
>      branches. That preserves more information about what actually
>      happened, and would find a conflict in a case like this.
>
>   2. Even with merging, you cannot assume that the end result is sane.
>      In your example, there is a textual conflict. But you can easily
>      come up with other examples where a merge is textually sound, but
>      has some semantic conflict (e.g., you update the signature of a
>      function but a colleague adds another call to it using the old
>      signature).
>
>      You have to examine and test the results of merges for sanity. And
>      likewise with rebases.
>
> -Peff
>
> [1] Actually, rebase does not even try to replay the first patch. When
>     it generates the list of commits, it ignores any whose "patch-id" is
>     the same as a commit on the other side. But the end effect is the
>     same.
Your explanation looks reasonable to me.

Thanks a lot for your time and patience. And @Pranit Bauva too.

By the way, many thanks for maintaining this outstanding software Git.


-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2016-05-13  7:41           ` 李本超
@ 2016-05-13  8:10             ` Jeff King
  2016-05-13 12:05               ` 李本超
  0 siblings, 1 reply; 52+ messages in thread
From: Jeff King @ 2016-05-13  8:10 UTC (permalink / raw)
  To: 李本超; +Cc: Pranit Bauva, Git List

On Fri, May 13, 2016 at 03:41:13PM +0800, 李本超 wrote:

> It does not warn me in this case. I replayed it again, below is my process:
> 
> [...setup...]

So after you setup steps you have:

  $ git log --decorate --oneline --raw

  * a3ce3bc (HEAD -> B) modify
  | :100644 100644 94954ab... 23509e0... M        README.md
  * ef702eb add one line too
  | :100644 100644 ce01362... 94954ab... M        README.md
  | * fa8b99e (master, A) add one line
  |/  
  |   :100644 100644 ce01362... 94954ab... M      README.md
  * cf2103b add readme
    :000000 100644 0000000... ce01362... A        README.md

Note that B^ (ef702eb) and A (fa8b99e) introduce the exact same change
(moving README.md from ce01362 to 94954ab). And master is at the same
commit as A (due to your fast-forward merge earlier).

So now when you run:

> $ git rebase master

Git will try to replay the commits on master..B on top of master, in
order.  Those commits are ef702eb and a3ce3bc (your commit names will
differ, because your name and timestamps will differ).

So it replays the first one, and sees that it the patch is a noop[1];
the tree in master already has the same end state. So we skip the patch.
And then we replay the second one, which applies cleanly.

The moment where I think you'd like to be notified is when we skipped
doing anything with patch 1. You'd prefer it to say "woah, the other
side of the rebase did the same thing as us".

But rebase does not do that by default, because the intent of rebase is
that you are rebasing your work on an upstream which might be accepting
part of your work as patches. So it is a feature that rebase says
"already applied upstream -- let's ignore this one".

I don't think there is a way to ask rebase not to ignore such
already-applied patches. But I'm not sure if there should be, for two
reasons:

  1. You should consider just using "git merge" to merge the two
     branches. That preserves more information about what actually
     happened, and would find a conflict in a case like this.

  2. Even with merging, you cannot assume that the end result is sane.
     In your example, there is a textual conflict. But you can easily
     come up with other examples where a merge is textually sound, but
     has some semantic conflict (e.g., you update the signature of a
     function but a colleague adds another call to it using the old
     signature).

     You have to examine and test the results of merges for sanity. And
     likewise with rebases.

-Peff

[1] Actually, rebase does not even try to replay the first patch. When
    it generates the list of commits, it ignores any whose "patch-id" is
    the same as a commit on the other side. But the end effect is the
    same.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2016-05-13  7:10         ` Pranit Bauva
@ 2016-05-13  7:41           ` 李本超
  2016-05-13  8:10             ` Jeff King
  0 siblings, 1 reply; 52+ messages in thread
From: 李本超 @ 2016-05-13  7:41 UTC (permalink / raw)
  To: Pranit Bauva; +Cc: Git List

It does not warn me in this case. I replayed it again, below is my process:

$ mkdir bug_test
$ cd bug_test/
$ git init
Initialized empty Git repository in /home/libenchao/tmp/bug_test/.git/
$ echo 'hello' > README.md
$ git add README.md
$ git commit -m 'Add README.md'
[master (root-commit) 9cdb3a8] Add README.md
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
$ git checkout -b A
Switched to a new branch 'A'
$ echo 'world' >> README.md
$ git commit -a -m 'Add one line'
[A 6f0b0a3] Add one line
 1 file changed, 1 insertion(+)
$ git checkout master
Switched to branch 'master'
$ git checkout -b B
Switched to a new branch 'B'
$ echo 'world' >> README.md
$ git commit -a -m 'Add one line too'
[B d89cf11] Add one line too
 1 file changed, 1 insertion(+)
$ vim README.md                        # in this line, I modify line 2
'world' to 'git'
$ cat README.md
hello
git
$ git commit -a -m 'Modify one line'
[B a674427] Modify one line
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git checkout master
Switched to branch 'master'
$ git merge A
Updating 9cdb3a8..6f0b0a3
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)
$ git checkout B
Switched to branch 'B'
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Modify one line
$ cat README.md
hello
git
$

2016-05-13 15:10 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> On Fri, May 13, 2016 at 12:27 PM, 李本超 <libenchao@gmail.com> wrote:
>> Yes, you got the right understanding of my problem.
>>
>> You are right, the git behavior is quite correct. But I met this
>> problem in my practical work:
>>
>> My colleague added a method but I didn't know. I also added the same method.
>> Then I found that I didn't need the method actually, so I deleted it.
>> My colleague merged to the master before me. When I wanted to merge, I found
>> conflicts with master. And I rebased to current master. And That method was
>> deleted finally without any warning or information.
>
> I am quite sure that there would be an output to show that there are
> conflicts and it would be suggesting you to first resolve the
> conflicts and there would also be markers in the file like ">>>>>" and
> "======" and the file would be marked with "both modified". After you
> resolve the conflicts, you can add the file by using git-add and then
> "git rebase --continue" to proceed. If you find out that there is some
> problem, then you can always use "git rebase --abort" to abort the
> rebase process and get to the initial state *perfectly* without any
> glitches.
>
>> Do you think Git should output something to warn the user or I just
>> use Git in a wrong way ?
>
> It does warn. I don't know how it got missed in your case. This is
> quite a common problem and even I have faced this quite for quite a
> lot of times now and it always did warn me.
>
>> Thanks.
>
> I will recommend you reading this article[1]. I know its a bit of a
> long read but it will help a lot.
>
> [1]: http://tedfelix.com/software/git-conflict-resolution.html
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2016-05-13  6:57       ` 李本超
@ 2016-05-13  7:10         ` Pranit Bauva
  2016-05-13  7:41           ` 李本超
  0 siblings, 1 reply; 52+ messages in thread
From: Pranit Bauva @ 2016-05-13  7:10 UTC (permalink / raw)
  To: 李本超; +Cc: Git List

On Fri, May 13, 2016 at 12:27 PM, 李本超 <libenchao@gmail.com> wrote:
> Yes, you got the right understanding of my problem.
>
> You are right, the git behavior is quite correct. But I met this
> problem in my practical work:
>
> My colleague added a method but I didn't know. I also added the same method.
> Then I found that I didn't need the method actually, so I deleted it.
> My colleague merged to the master before me. When I wanted to merge, I found
> conflicts with master. And I rebased to current master. And That method was
> deleted finally without any warning or information.

I am quite sure that there would be an output to show that there are
conflicts and it would be suggesting you to first resolve the
conflicts and there would also be markers in the file like ">>>>>" and
"======" and the file would be marked with "both modified". After you
resolve the conflicts, you can add the file by using git-add and then
"git rebase --continue" to proceed. If you find out that there is some
problem, then you can always use "git rebase --abort" to abort the
rebase process and get to the initial state *perfectly* without any
glitches.

> Do you think Git should output something to warn the user or I just
> use Git in a wrong way ?

It does warn. I don't know how it got missed in your case. This is
quite a common problem and even I have faced this quite for quite a
lot of times now and it always did warn me.

> Thanks.

I will recommend you reading this article[1]. I know its a bit of a
long read but it will help a lot.

[1]: http://tedfelix.com/software/git-conflict-resolution.html

Regards,
Pranit Bauva

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2016-05-13  6:37     ` Pranit Bauva
@ 2016-05-13  6:57       ` 李本超
  2016-05-13  7:10         ` Pranit Bauva
  0 siblings, 1 reply; 52+ messages in thread
From: 李本超 @ 2016-05-13  6:57 UTC (permalink / raw)
  To: Pranit Bauva; +Cc: Git List

Yes, you got the right understanding of my problem.

You are right, the git behavior is quite correct. But I met this
problem in my practical work:

My colleague added a method but I didn't know. I also added the same method.
Then I found that I didn't need the method actually, so I deleted it.
My colleague merged to the master before me. When I wanted to merge, I found
conflicts with master. And I rebased to current master. And That method was
deleted finally without any warning or information.

Do you think Git should output something to warn the user or I just
use Git in a wrong way ?

Thanks.

2016-05-13 14:37 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> On Fri, May 13, 2016 at 11:28 AM, 李本超 <libenchao@gmail.com> wrote:
>> git version 2.6.4 (Apple Git-63)
>> system version: OS X EI Capitan 10.11.4
>>
>> below is the steps:
>> $ mkdir test_repo
>> $ cd test_repo
>> $ git init
>> $ echo "hello" > README.md
>> $ git commit -a -m 'Add README.md'
>
> It was my mistake. git-commit -a adds files which are tracked.
> Currently README.md is not tracked. So you will have to first use
> git-add to add them for tracking. Though while trying out your steps I
> used git-add. For further commits one can use -a with git-commit.
>
>> $ git checkout -b A
>> $ echo "world" > README.md
>> $ git commit -a -m 'Add one line'
>
> You are technically not adding a line. You are modifying the previous
> line to the updated line. So the contents of the file will be:
> "world"
> It seems from the further part that you actually wanted to add the
> line rather than modifying it. Better to use ">>" instead of ">". ">>"
> is used for appending.
>
>> $ git checkout master
>> $ git checkout -b B
>> $ echo "world" > README.md
>> $ git commit -a -m 'Add one line too'
>> $ [midify 'world' line to other things like 'git' using vi]
>
> I think you mean modify.
>
>> $ git commit -a -m 'Modify one line'
>>
>> $ git checkout master
>> $ git merge A
>>
>> $ git checkout B
>> $ git rebase master [problem is here, cat README.rd we will get :
>> hello and git instead of hello world git]
>
> The git behavior is quite correct.
> When you are on the B branch and you choose to rebase it on the
> master, it will apply commits as patches. So it first sees that the
> commit on the A branch which is now merged with master ie. "Add one
> line" and the commit on the B branch "Add one line too" are doing the
> same thing which is removing the line "hello" and adding the line
> "world". Then it applies the commit "modify one line" on top of this
> which removes the line "world" and adds the line "git". So finally,
> README.md will contain only "git".
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2016-05-13  5:58   ` 李本超
@ 2016-05-13  6:37     ` Pranit Bauva
  2016-05-13  6:57       ` 李本超
  0 siblings, 1 reply; 52+ messages in thread
From: Pranit Bauva @ 2016-05-13  6:37 UTC (permalink / raw)
  To: 李本超; +Cc: Git List

On Fri, May 13, 2016 at 11:28 AM, 李本超 <libenchao@gmail.com> wrote:
> git version 2.6.4 (Apple Git-63)
> system version: OS X EI Capitan 10.11.4
>
> below is the steps:
> $ mkdir test_repo
> $ cd test_repo
> $ git init
> $ echo "hello" > README.md
> $ git commit -a -m 'Add README.md'

It was my mistake. git-commit -a adds files which are tracked.
Currently README.md is not tracked. So you will have to first use
git-add to add them for tracking. Though while trying out your steps I
used git-add. For further commits one can use -a with git-commit.

> $ git checkout -b A
> $ echo "world" > README.md
> $ git commit -a -m 'Add one line'

You are technically not adding a line. You are modifying the previous
line to the updated line. So the contents of the file will be:
"world"
It seems from the further part that you actually wanted to add the
line rather than modifying it. Better to use ">>" instead of ">". ">>"
is used for appending.

> $ git checkout master
> $ git checkout -b B
> $ echo "world" > README.md
> $ git commit -a -m 'Add one line too'
> $ [midify 'world' line to other things like 'git' using vi]

I think you mean modify.

> $ git commit -a -m 'Modify one line'
>
> $ git checkout master
> $ git merge A
>
> $ git checkout B
> $ git rebase master [problem is here, cat README.rd we will get :
> hello and git instead of hello world git]

The git behavior is quite correct.
When you are on the B branch and you choose to rebase it on the
master, it will apply commits as patches. So it first sees that the
commit on the A branch which is now merged with master ie. "Add one
line" and the commit on the B branch "Add one line too" are doing the
same thing which is removing the line "hello" and adding the line
"world". Then it applies the commit "modify one line" on top of this
which removes the line "world" and adds the line "git". So finally,
README.md will contain only "git".

Regards,
Pranit Bauva

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2016-05-13  5:23 ` Pranit Bauva
@ 2016-05-13  5:58   ` 李本超
  2016-05-13  6:37     ` Pranit Bauva
  0 siblings, 1 reply; 52+ messages in thread
From: 李本超 @ 2016-05-13  5:58 UTC (permalink / raw)
  To: Pranit Bauva; +Cc: Git List

git version 2.6.4 (Apple Git-63)
system version: OS X EI Capitan 10.11.4

below is the steps:
$ mkdir test_repo
$ cd test_repo
$ git init
$ echo "hello" > README.md
$ git commit -a -m 'Add README.md'

$ git checkout -b A
$ echo "world" > README.md
$ git commit -a -m 'Add one line'

$ git checkout master
$ git checkout -b B
$ echo "world" > README.md
$ git commit -a -m 'Add one line too'
$ [midify 'world' line to other things like 'git' using vi]
$ git commit -a -m 'Modify one line'

$ git checkout master
$ git merge A

$ git checkout B
$ git rebase master [problem is here, cat README.rd we will get :
hello and git instead of hello world git]

2016-05-13 13:23 GMT+08:00 Pranit Bauva <pranit.bauva@gmail.com>:
> Please mention the version no of git you are using and your system.
> I am answering according to git 2.8.1 Lubuntu 15.04
>
> On Fri, May 13, 2016 at 10:34 AM, 李本超 <libenchao@gmail.com> wrote:
>> Hi all,
>>
>>       Yestoday when I worked using Git, I found a bug. It's about
>> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
>> problem:
>>
>>       There is a master branch, and we develop in our own branch.
>> Let's simplify this: there are two branches created at the same commit
>> point at master. Then branch A add a function X. Branch B add funciton
>> X too (yes, they are very same). Then branch B modify function X to
>> function Y.
>
> What do you mean by this? Did you amend the previous commit, or
> introduced another separate commit ?
>
>>       Branch A finishes it's job first and merged to master
>> successfully and happily without any conflicts. When branch B wants to
>> merge to master, he finds that master has updated. So branch B must
>> rebase to the current master. Then problem happends: git rebase
>> successfully without any conflicts. But branch B cannot see function X
>> from master (or branch A), only its own function Y.
>>       I think that's because Git is based on file instead of patch.
>> But I think Git can report it in this situation.
>>       How do you think ? Thank you anyway for maintaining this amazing software.
>
> Well I tried to reproduce the problem. I did the following steps:
> $ mdkir test_repo
> $ cd test_repo
> $ git init
> $ echo Hello >hi
> $ git commit -a -m "C1"
> $ git checkout -b A
> $ echo Bye >hi
> $ git commit -a -m "C2 - A"
> $ git checkout -
> $ git checkout -b B
> $ echo "Bye." >hi
> $ git commit -a -m "C3 - B"
> $ git checkout -
> $ git merge A
> $ git checkout B
> $ git rebase master
>
> This shows that some merge conflicts needs resolving. Did I follow
> your steps or I missed something? It would be better if you could
> reproduce your steps like I did so as to make things more clear to us.
>
> Regards,
> Pranit Bauva



-- 
Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2016-05-13  5:04 bug report 李本超
@ 2016-05-13  5:23 ` Pranit Bauva
  2016-05-13  5:58   ` 李本超
  0 siblings, 1 reply; 52+ messages in thread
From: Pranit Bauva @ 2016-05-13  5:23 UTC (permalink / raw)
  To: 李本超; +Cc: Git List

Please mention the version no of git you are using and your system.
I am answering according to git 2.8.1 Lubuntu 15.04

On Fri, May 13, 2016 at 10:34 AM, 李本超 <libenchao@gmail.com> wrote:
> Hi all,
>
>       Yestoday when I worked using Git, I found a bug. It's about
> rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
> problem:
>
>       There is a master branch, and we develop in our own branch.
> Let's simplify this: there are two branches created at the same commit
> point at master. Then branch A add a function X. Branch B add funciton
> X too (yes, they are very same). Then branch B modify function X to
> function Y.

What do you mean by this? Did you amend the previous commit, or
introduced another separate commit ?

>       Branch A finishes it's job first and merged to master
> successfully and happily without any conflicts. When branch B wants to
> merge to master, he finds that master has updated. So branch B must
> rebase to the current master. Then problem happends: git rebase
> successfully without any conflicts. But branch B cannot see function X
> from master (or branch A), only its own function Y.
>       I think that's because Git is based on file instead of patch.
> But I think Git can report it in this situation.
>       How do you think ? Thank you anyway for maintaining this amazing software.

Well I tried to reproduce the problem. I did the following steps:
$ mdkir test_repo
$ cd test_repo
$ git init
$ echo Hello >hi
$ git commit -a -m "C1"
$ git checkout -b A
$ echo Bye >hi
$ git commit -a -m "C2 - A"
$ git checkout -
$ git checkout -b B
$ echo "Bye." >hi
$ git commit -a -m "C3 - B"
$ git checkout -
$ git merge A
$ git checkout B
$ git rebase master

This shows that some merge conflicts needs resolving. Did I follow
your steps or I missed something? It would be better if you could
reproduce your steps like I did so as to make things more clear to us.

Regards,
Pranit Bauva

^ permalink raw reply	[flat|nested] 52+ messages in thread

* bug report
@ 2016-05-13  5:04 李本超
  2016-05-13  5:23 ` Pranit Bauva
  0 siblings, 1 reply; 52+ messages in thread
From: 李本超 @ 2016-05-13  5:04 UTC (permalink / raw)
  To: git

Hi all,

      Yestoday when I worked using Git, I found a bug. It's about
rebase. Or I don't know if it is a bug, maybe that is Git. Below is my
problem:

      There is a master branch, and we develop in our own branch.
Let's simplify this: there are two branches created at the same commit
point at master. Then branch A add a function X. Branch B add funciton
X too (yes, they are very same). Then branch B modify function X to
function Y.
      Branch A finishes it's job first and merged to master
successfully and happily without any conflicts. When branch B wants to
merge to master, he finds that master has updated. So branch B must
rebase to the current master. Then problem happends: git rebase
successfully without any conflicts. But branch B cannot see function X
from master (or branch A), only its own function Y.
      I think that's because Git is based on file instead of patch.
But I think Git can report it in this situation.
      How do you think ? Thank you anyway for maintaining this amazing software.

-- 

Benchao Li
School of Electronics Engineering and Computer Science, Peking University
Tel:+86-15650713730
Email: libenchao@gmail.com; libenchao@pku.edu.cn

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug Report
  2016-04-03  0:25 Bug Report Benjamin Sandeen
  2016-04-03  2:20 ` Eric N. Vander Weele
@ 2016-04-03  2:22 ` Jacob Keller
  1 sibling, 0 replies; 52+ messages in thread
From: Jacob Keller @ 2016-04-03  2:22 UTC (permalink / raw)
  To: Benjamin Sandeen; +Cc: Git mailing list

Hi,

On Sat, Apr 2, 2016 at 5:25 PM, Benjamin Sandeen
<benjaminsandeen2016@u.northwestern.edu> wrote:
> Today, I managed to create a duplicate branch in a git repository.  While
> this may not be a bug per se, I do think that it is confusing and some way
> of preventing such issues in the future may be helpful.
>
> I first cloned the repository:
>
> $ git clone https://github.com/CodeForChicago/superclass.git
>
> Then, I created a new branch (or so I thought):
>
> $ git checkout -b lesson_page
>
> However, this branch has already existed for about 4 weeks, without my
> knowledge.  I proceeded to do some work on the files it contained, and when
> it came time to commit and push, and when I pushed, I got the following
> message:

The branch existed in the remote repository, but it doesn't exist
locally. You never fetched a copy into refs/remotes/origin since you
didn't say you were interested, and git will fully allow you to create
local branches with the same name as remote branches.

>
> To https://github.com/CodeForChicago/superclass.git
>  ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
> error: failed to push some refs to '
> https://github.com/CodeForChicago/superclass.git'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>

When you tried to push this branch, it will push into
refs/heads/lesson_page on the remote, which already exists. Since it
cannot perform a fast-forward update, as your local work isn't based
directly on the tip of the remote branch, you either need to merge,
rebase, or start from scratch.

> Given that I had believed that I had created the branch just a few hours
> prior and was the first to attempt to push to it, this error was
> consternating.

Let me try to explain. You created your own local branch, which
happened to share the same name as an already existing branch. Had you
know this you could have fetched and checked out that branch. You can
view all branches using "git branch -a" or "git ls-remote".

>
> I may be wrong (I am aware that my understanding of git is limited), but I
> believe that the git checkout -b command is simply supposed to create a new
> branch and then switch to it (I'm not aware of any subtle behavior that goes
> on behind the scenes if the "new" branch that the user is attempting to
> create already exists).  This is why I said it "may not be a bug per se".
> However, I expect most people who use git to expect this command to create a
> new branch and then switch to it (this is what most sources online will tell
> users to do to create a new branch), and as such, it would be extremely
> beneficial if git were to, at the very least, alert the user to the conflict
> in some way or another.

git checkout -b <branch_name> will create a new branch in your local
copy of the repository. Git is distributed. You can do "git checkout
--track <branch>" to attempt to create a local branch which tracks the
upstream branch, and then git status will provide useful information
about the relationship between your local work and the remote work.

It could maybe be improved to notice that a remote has a branch with
the same name. However, git can support multiple remotes, so
determining which remote to care about is difficult.

In your case you have a couple of options to fix it. I would suggest at least

"git branch --set-upstream-to=origin/<branch_name>" so that git status
will give you useful information about the branch relationship. Then
you can merge or rebase your work into the branch.

The issue is in understanding how git distributes branches, and how it
could handle this. I suspect improvements could be made so that it
will attempt to warn you when you create a branch that already exists.
However, often you do this *intending* to make it track the specific
branch so I am not sure how much good a warning would do. Just a
message wouldn't really hurt anything, however.

Thanks,
Jake

>
> Thanks,
> Ben
>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug Report
  2016-04-03  0:25 Bug Report Benjamin Sandeen
@ 2016-04-03  2:20 ` Eric N. Vander Weele
  2016-04-03  2:22 ` Jacob Keller
  1 sibling, 0 replies; 52+ messages in thread
From: Eric N. Vander Weele @ 2016-04-03  2:20 UTC (permalink / raw)
  To: Benjamin Sandeen; +Cc: git

On Sat, Apr 2, 2016 at 8:25 PM, Benjamin Sandeen
<benjaminsandeen2016@u.northwestern.edu> wrote:
> Today, I managed to create a duplicate branch in a git repository.  While
> this may not be a bug per se, I do think that it is confusing and some way
> of preventing such issues in the future may be helpful.

This can be confusing.  I'll hopefully try to help and explain below.

> I first cloned the repository:
>
> $ git clone https://github.com/CodeForChicago/superclass.git
>
> Then, I created a new branch (or so I thought):
>
> $ git checkout -b lesson_page

At this point, you created a *local* branch called 'lesson_page' which
points to the current HEAD and then switched to that branch .  This
local branch is independent of the remote branch called
'origin/lesson_page'.

> However, this branch has already existed for about 4 weeks, without my
> knowledge.  I proceeded to do some work on the files it contained, and when
> it came time to commit and push, and when I pushed, I got the following
> message:
>
> To https://github.com/CodeForChicago/superclass.git
>  ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
> error: failed to push some refs to '
> https://github.com/CodeForChicago/superclass.git'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
> Given that I had believed that I had created the branch just a few hours
> prior and was the first to attempt to push to it, this error was
> consternating.

The non-fast-forward push is preventing history being rewritten- this
is a good thing :).

> I may be wrong (I am aware that my understanding of git is limited), but I
> believe that the git checkout -b command is simply supposed to create a new
> branch and then switch to it (I'm not aware of any subtle behavior that goes
> on behind the scenes if the "new" branch that the user is attempting to
> create already exists).  This is why I said it "may not be a bug per se".
> However, I expect most people who use git to expect this command to create a
> new branch and then switch to it (this is what most sources online will tell
> users to do to create a new branch), and as such, it would be extremely
> beneficial if git were to, at the very least, alert the user to the conflict
> in some way or another.

The `git checkout -b` command is working as expected.  `git checkout
-b <name>` is equivalent to `git branch <name> && git checkout
<name>`.  If you were to execute `git checkout lesson_page`, you would
get the desired behavior you were expecting because in the presence of
one remote, git will actually execute `git checkout -b lesson_page
--track origin/lesson_page` - more details can be found in `git help
checkout`.  Effectively, it checkouts 'origin/lesson_page' as a new
local branch named 'lesson_page'.

However, you indicated that you did not know there was a remote
branch already named 'lesson_page'.  After cloning the repository, you
can use `git branch -a` to see all remotes to determine which form of
`git checkout` to use.

> Thanks,
> Ben
>
> Lead Consultant, Northwestern University Information Technology
> Research Assistant, Center for Interdisciplinary Exploration and Research in
> Astrophysics at Northwestern University
> Phsyics, Weinberg College of Arts and Sciences
> Computer Science, Weinberg College of Arts and Sciences
> Classics, Weinberg College of Arts and Sciences
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Bug Report
@ 2016-04-03  0:25 Benjamin Sandeen
  2016-04-03  2:20 ` Eric N. Vander Weele
  2016-04-03  2:22 ` Jacob Keller
  0 siblings, 2 replies; 52+ messages in thread
From: Benjamin Sandeen @ 2016-04-03  0:25 UTC (permalink / raw)
  To: git

Today, I managed to create a duplicate branch in a git repository.  While
this may not be a bug per se, I do think that it is confusing and some way
of preventing such issues in the future may be helpful.

I first cloned the repository:

$ git clone https://github.com/CodeForChicago/superclass.git

Then, I created a new branch (or so I thought):

$ git checkout -b lesson_page

However, this branch has already existed for about 4 weeks, without my
knowledge.  I proceeded to do some work on the files it contained, and when
it came time to commit and push, and when I pushed, I got the following
message:

To https://github.com/CodeForChicago/superclass.git
 ! [rejected]        lesson_page -> lesson_page (non-fast-forward)
error: failed to push some refs to '
https://github.com/CodeForChicago/superclass.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Given that I had believed that I had created the branch just a few hours
prior and was the first to attempt to push to it, this error was
consternating.

I may be wrong (I am aware that my understanding of git is limited), but I
believe that the git checkout -b command is simply supposed to create a new
branch and then switch to it (I'm not aware of any subtle behavior that goes
on behind the scenes if the "new" branch that the user is attempting to
create already exists).  This is why I said it "may not be a bug per se".
However, I expect most people who use git to expect this command to create a
new branch and then switch to it (this is what most sources online will tell
users to do to create a new branch), and as such, it would be extremely
beneficial if git were to, at the very least, alert the user to the conflict
in some way or another.

Thanks,
Ben

Lead Consultant, Northwestern University Information Technology
Research Assistant, Center for Interdisciplinary Exploration and Research in
Astrophysics at Northwestern University
Phsyics, Weinberg College of Arts and Sciences
Computer Science, Weinberg College of Arts and Sciences
Classics, Weinberg College of Arts and Sciences

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: bug report
  2015-01-27 14:43 bug report Albert Akhriev
@ 2015-01-27 14:50 ` Jeff King
  0 siblings, 0 replies; 52+ messages in thread
From: Jeff King @ 2015-01-27 14:50 UTC (permalink / raw)
  To: Albert Akhriev; +Cc: git

On Tue, Jan 27, 2015 at 02:43:31PM +0000, Albert Akhriev wrote:

> My system:                      RedHat 6.5/64-bit (gcc 4.4.7)
> My configuration options:  ./configure --prefix=/home/albert/soft
> 
> Compilation of git 2.2.2 itself was fine, but some tests failed.
> I presume, there might be some network communication restrictions here in
> the lab
> (gitweb had failed as can be seen in the listing below):

The gitweb tests should run locally and not need to touch the network.
It looks like gitweb cannot run at all. Are you sure you have a working
perl (with CGI and other base modules)?

Try running:

  cd t
  ./t9500-gitweb-standaloneno-errors.sh -v -i

which should give more output. Also check the contents of gitweb.log in
"t/trash directory/t9500-...".

-Peff

^ permalink raw reply	[flat|nested] 52+ messages in thread

* bug report
@ 2015-01-27 14:43 Albert Akhriev
  2015-01-27 14:50 ` Jeff King
  0 siblings, 1 reply; 52+ messages in thread
From: Albert Akhriev @ 2015-01-27 14:43 UTC (permalink / raw)
  To: git


Hi All,

My system:                      RedHat 6.5/64-bit (gcc 4.4.7)
My configuration options:  ./configure --prefix=/home/albert/soft

Compilation of git 2.2.2 itself was fine, but some tests failed.
I presume, there might be some network communication restrictions here in
the lab
(gitweb had failed as can be seen in the listing below):

1..14
*** t9400-git-cvsserver-server.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9401-git-cvsserver-crlf.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9402-git-cvsserver-refs.sh ***
1..0 # SKIP skipping git-cvsserver tests, Perl SQLite interface unavailable
*** t9500-gitweb-standalone-no-errors.sh ***
not ok 1 - no commits: projects_list (implicit)
#	gitweb_run
not ok 2 - no commits: projects_index
#	gitweb_run "a=project_index"
not ok 3 - no commits: .git summary (implicit)
#	gitweb_run "p=.git"
not ok 4 - no commits: .git commit (implicit HEAD)
#	gitweb_run "p=.git;a=commit"
not ok 5 - no commits: .git commitdiff (implicit HEAD)
#	gitweb_run "p=.git;a=commitdiff"
not ok 6 - no commits: .git tree (implicit HEAD)
#	gitweb_run "p=.git;a=tree"
not ok 7 - no commits: .git heads
#	gitweb_run "p=.git;a=heads"
not ok 8 - no commits: .git tags
#	gitweb_run "p=.git;a=tags"
ok 9 - Make initial commit
not ok 10 - projects_list (implicit)
#	gitweb_run
not ok 11 - projects_index
#	gitweb_run "a=project_index"
not ok 12 - .git summary (implicit)
#	gitweb_run "p=.git"
not ok 13 - .git commit (implicit HEAD)
#	gitweb_run "p=.git;a=commit"
not ok 14 - .git commitdiff (implicit HEAD, root commit)
#	gitweb_run "p=.git;a=commitdiff"
not ok 15 - .git commitdiff_plain (implicit HEAD, root commit)
#	gitweb_run "p=.git;a=commitdiff_plain"
not ok 16 - .git commit (HEAD)
#	gitweb_run "p=.git;a=commit;h=HEAD"
not ok 17 - .git tree (implicit HEAD)
#	gitweb_run "p=.git;a=tree"
not ok 18 - .git blob (file)
#	gitweb_run "p=.git;a=blob;f=file"
not ok 19 - .git blob_plain (file)
#	gitweb_run "p=.git;a=blob_plain;f=file"
not ok 20 - .git commit (non-existent)
#	gitweb_run "p=.git;a=commit;h=non-existent"
not ok 21 - .git commitdiff (non-existent)
#	gitweb_run "p=.git;a=commitdiff;h=non-existent"
not ok 22 - .git commitdiff (non-existent vs HEAD)
#	gitweb_run "p=.git;a=commitdiff;hp=non-existent;h=HEAD"
not ok 23 - .git tree (0000000000000000000000000000000000000000)
#	gitweb_run "p=.git;a=tree;h=0000000000000000000000000000000000000000"
not ok 24 - .git tag (0000000000000000000000000000000000000000)
#	gitweb_run "p=.git;a=tag;h=0000000000000000000000000000000000000000"
not ok 25 - .git blob (non-existent)
#	gitweb_run "p=.git;a=blob;f=non-existent"
not ok 26 - .git blob_plain (non-existent)
#	gitweb_run "p=.git;a=blob_plain;f=non-existent"
not ok 27 - commitdiff(0): root
#	gitweb_run "p=.git;a=commitdiff"
not ok 28 - commitdiff(0): file added
#	echo "New file" > new_file &&
#		 git add new_file &&
#		 git commit -a -m "File added." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 29 - commitdiff(0): mode change
#	test_chmod +x new_file &&
#		 git commit -a -m "Mode changed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 30 - commitdiff(0): file renamed
#	git mv new_file renamed_file &&
#		 git commit -a -m "File renamed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 31 - commitdiff(0): file to symlink
#	rm renamed_file &&
#		 test_ln_s_add file renamed_file &&
#		 git commit -a -m "File to symlink." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 32 - commitdiff(0): file deleted
#	git rm renamed_file &&
#		 rm -f renamed_file &&
#		 git commit -a -m "File removed." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 33 - commitdiff(0): file copied / new file
#	cp file file2 &&
#		 git add file2 &&
#		 git commit -a -m "File copied." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 34 - commitdiff(0): mode change and modified
#	echo "New line" >> file2 &&
#		 test_chmod +x file2 &&
#		 git commit -a -m "Mode change and modification." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 35 - commitdiff(0): renamed and modified
#	cat >file2<<EOF &&
#	Dominus regit me,
#	et nihil mihi deerit.
#	In loco pascuae ibi me collocavit,
#	super aquam refectionis educavit me;
#	animam meam convertit,
#	deduxit me super semitas jusitiae,
#	propter nomen suum.
#	EOF
#		 git commit -a -m "File added." &&
#		 git mv file2 file3 &&
#		 echo "Propter nomen suum." >> file3 &&
#		 git commit -a -m "File rename and modification." &&
#		 gitweb_run "p=.git;a=commitdiff"
not ok 36 - commitdiff(0): renamed, mode change and modified
#	git mv file3 file2 &&
#		 echo "Propter nomen suum." >> file2 &&
#		 test_chmod +x file2 &&
#		 git commit -a -m "File rename, mode change and modification."
&&
#		 gitweb_run "p=.git;a=commitdiff"
ok 37 - setup typechange commits
not ok 38 - commitdiff(2): file renamed from foo to foo/baz
#	gitweb_run
"p=.git;a=commitdiff;hp=initial;h=foo-baz-renamed-from-foo"
not ok 39 - commitdiff(2): file renamed from foo/baz to foo
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-baz-renamed-from-foo;h=initial"
not ok 40 - commitdiff(2): directory becomes file
#	gitweb_run "p=.git;a=commitdiff;hp=foo-becomes-a-directory;h=initial"
not ok 41 - commitdiff(2): file becomes directory
#	gitweb_run "p=.git;a=commitdiff;hp=initial;h=foo-becomes-a-directory"
not ok 42 - commitdiff(2): file becomes symlink
#	gitweb_run "p=.git;a=commitdiff;hp=initial;h=foo-symlinked-to-bar"
not ok 43 - commitdiff(2): symlink becomes file
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-symlinked-to-bar;h=foo-back-to-file"
not ok 44 - commitdiff(2): symlink becomes directory
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-symlinked-to-bar;h=foo-becomes-a-directory"
not ok 45 - commitdiff(2): directory becomes symlink
#	gitweb_run
"p=.git;a=commitdiff;hp=foo-becomes-a-directory;h=foo-symlinked-to-bar"
ok 46 - setup incomplete lines
not ok 47 - commitdiff(1): addition of incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_add"
#
not ok 48 - commitdiff(1): incomplete line as context line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_ctx"
#
not ok 49 - commitdiff(1): change incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_chg"
#
not ok 50 - commitdiff(1): removal of incomplete line
#
#		gitweb_run "p=.git;a=commitdiff;h=incomplete_lines_rem"
#
ok 51 - Create a merge
not ok 52 - commit(0): merge commit
#	gitweb_run "p=.git;a=commit"
not ok 53 - commitdiff(0): merge commit
#	gitweb_run "p=.git;a=commitdiff"
ok 54 - Prepare large commit
not ok 55 - commit(1): large commit
#	gitweb_run "p=.git;a=commit;h=b"
not ok 56 - commitdiff(1): large commit
#	gitweb_run "p=.git;a=commitdiff;h=b"
not ok 57 - side-by-side: addition of incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_add;ds=sidebyside"
#
not ok 58 - side-by-side: incomplete line as context line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_ctx;ds=sidebyside"
#
not ok 59 - side-by-side: changed incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_chg;ds=sidebyside"
#
not ok 60 - side-by-side: removal of incomplete line
#
#		gitweb_run
"p=.git;a=commitdiff;h=incomplete_lines_rem;ds=sidebyside"
#
not ok 61 - side-by-side: merge commit
#
#		gitweb_run "p=.git;a=commitdiff;h=merge_commit;ds=sidebyside"
#
not ok 62 - tags: list of different types of tags
#	git checkout master &&
#		 git tag -a -m "Tag commit object" tag-commit HEAD &&
#		 git tag -a -m "" tag-commit-nomessage HEAD &&
#		 git tag -a -m "Tag tag object" tag-tag tag-commit &&
#		 git tag -a -m "Tag tree object" tag-tree HEAD^{tree} &&
#		 git tag -a -m "Tag blob object" tag-blob HEAD:file &&
#		 git tag lightweight/tag-commit HEAD &&
#		 git tag lightweight/tag-tag tag-commit &&
#		 git tag lightweight/tag-tree HEAD^{tree} &&
#		 git tag lightweight/tag-blob HEAD:file &&
#		 gitweb_run "p=.git;a=tags"
not ok 63 - tag: Tag to commit object
#	gitweb_run "p=.git;a=tag;h=tag-commit"
not ok 64 - tag: on lightweight tag (invalid)
#	gitweb_run "p=.git;a=tag;h=lightweight/tag-commit"
not ok 65 - logs: log (implicit HEAD)
#	gitweb_run "p=.git;a=log"
not ok 66 - logs: shortlog (implicit HEAD)
#	gitweb_run "p=.git;a=shortlog"
not ok 67 - logs: history (implicit HEAD, file)
#	gitweb_run "p=.git;a=history;f=file"
not ok 68 - logs: history (implicit HEAD, non-existent file)
#	gitweb_run "p=.git;a=history;f=non-existent"
not ok 69 - logs: history (implicit HEAD, deleted file)
#	git checkout master &&
#		 echo "to be deleted" > deleted_file &&
#		 git add deleted_file &&
#		 git commit -m "Add file to be deleted" &&
#		 git rm deleted_file &&
#		 git commit -m "Delete file" &&
#		 gitweb_run "p=.git;a=history;f=deleted_file"
not ok 70 - path_info: project
#	gitweb_run "" "/.git"
not ok 71 - path_info: project/branch
#	gitweb_run "" "/.git/b"
not ok 72 - path_info: project/branch:file
#	gitweb_run "" "/.git/master:file"
not ok 73 - path_info: project/branch:dir/
#	gitweb_run "" "/.git/master:foo/"
not ok 74 - path_info: project/branch (non-existent)
#	gitweb_run "" "/.git/non-existent"
not ok 75 - path_info: project/branch:filename (non-existent branch)
#	gitweb_run "" "/.git/non-existent:non-existent"
not ok 76 - path_info: project/branch:file (non-existent)
#	gitweb_run "" "/.git/master:non-existent"
not ok 77 - path_info: project/branch:dir/ (non-existent)
#	gitweb_run "" "/.git/master:non-existent/"
not ok 78 - path_info: project/branch:/file
#	gitweb_run "" "/.git/master:/file"
not ok 79 - path_info: project/:/file (implicit HEAD)
#	gitweb_run "" "/.git/:/file"
not ok 80 - path_info: project/:/ (implicit HEAD, top tree)
#	gitweb_run "" "/.git/:/"
not ok 81 - feeds: OPML
#	gitweb_run "a=opml"
not ok 82 - feed: RSS
#	gitweb_run "p=.git;a=rss"
not ok 83 - feed: Atom
#	gitweb_run "p=.git;a=atom"
not ok 84 - encode(commit): utf8
#	. "$TEST_DIRECTORY"/t3901-utf8.txt &&
#		 test_when_finished "GIT_AUTHOR_NAME=\"A U Thor\"" &&
#		 test_when_finished "GIT_COMMITTER_NAME=\"C O Mitter\"" &&
#		 echo "UTF-8" >> file &&
#		 git add file &&
#		 git commit -F "$TEST_DIRECTORY"/t3900/1-UTF-8.txt &&
#		 gitweb_run "p=.git;a=commit"
not ok 85 - encode(commit): iso-8859-1
#	. "$TEST_DIRECTORY"/t3901-8859-1.txt &&
#		 test_when_finished "GIT_AUTHOR_NAME=\"A U Thor\"" &&
#		 test_when_finished "GIT_COMMITTER_NAME=\"C O Mitter\"" &&
#		 echo "ISO-8859-1" >> file &&
#		 git add file &&
#		 test_config i18n.commitencoding ISO-8859-1 &&
#		 git commit -F "$TEST_DIRECTORY"/t3900/ISO8859-1.txt &&
#		 gitweb_run "p=.git;a=commit"
not ok 86 - encode(log): utf-8 and iso-8859-1
#	gitweb_run "p=.git;a=log"
not ok 87 - opt: log --no-merges
#	gitweb_run "p=.git;a=log;opt=--no-merges"
not ok 88 - opt: atom --no-merges
#	gitweb_run "p=.git;a=log;opt=--no-merges"
not ok 89 - opt: "file" history --no-merges
#	gitweb_run "p=.git;a=history;f=file;opt=--no-merges"
not ok 90 - opt: log --no-such-option (invalid option)
#	gitweb_run "p=.git;a=log;opt=--no-such-option"
not ok 91 - opt: tree --no-merges (invalid option for action)
#	gitweb_run "p=.git;a=tree;opt=--no-merges"
not ok 92 - URL: no project URLs, no base URL
#	gitweb_run "p=.git;a=summary"
not ok 93 - URL: project URLs via gitweb.url
#	git config --add gitweb.url git://example.com/git/trash.git &&
#	        git config --add gitweb.url http://example.com/git/trash.git
&&
#	        gitweb_run "p=.git;a=summary"
not ok 94 - URL: project URLs via cloneurl file
#	gitweb_run "p=.git;a=summary"
not ok 95 - config override: projects list (implicit)
#	gitweb_run
not ok 96 - config override: tree view, features not overridden in repo
config
#	gitweb_run "p=.git;a=tree"
not ok 97 - config override: tree view, features disabled in repo config
#	git config gitweb.blame no &&
#		 git config gitweb.snapshot none &&
#		 git config gitweb.avatar gravatar &&
#		 gitweb_run "p=.git;a=tree"
not ok 98 - config override: tree view, features enabled in repo config (1)
#	git config gitweb.blame yes &&
#		 git config gitweb.snapshot "zip,tgz, tbz2" &&
#		 gitweb_run "p=.git;a=tree"
not ok 99 - config override: tree view, features enabled in repo config (2)
#	gitweb_run "p=.git;a=tree"
ok 100 - search: preparation
not ok 101 - search: commit author
#	gitweb_run "p=.git;a=search;h=HEAD;st=author;s=A+U+Thor"
not ok 102 - search: commit message
#	gitweb_run "p=.git;a=search;h=HEAD;st=commitr;s=MATCH"
not ok 103 - search: grep
#	gitweb_run "p=.git;a=search;h=HEAD;st=grep;s=MATCH"
not ok 104 - search: pickaxe
#	gitweb_run "p=.git;a=search;h=HEAD;st=pickaxe;s=MATCH"
not ok 105 - search: projects
#	gitweb_run "a=project_list;s=.git"
not ok 106 - README.html with non-ASCII characters (utf-8)
#	echo "<b>UTF-8 example:</b><br />" > .git/README.html &&
#		 cat "$TEST_DIRECTORY"/t3900/1-UTF-8.txt >> .git/README.html &&
#		 gitweb_run "p=.git;a=summary"
Skipping syntax highlighting tests: 'highlight' not found
ok 107 # skip syntax highlighting (no highlight, unknown syntax) (missing
HIGHLIGHT)
ok 108 # skip syntax highlighting (highlighted, shell script) (missing
HIGHLIGHT)
ok 109 - forks: prepare
not ok 110 - forks: projects list
#	gitweb_run
not ok 111 - forks: forks action
#	gitweb_run "p=foo.git;a=forks"
not ok 112 - ctags: tag cloud in projects list
#	mkdir .git/ctags &&
#		 echo "2" > .git/ctags/foo &&
#		 echo "1" > .git/ctags/bar &&
#		gitweb_run
not ok 113 - ctags: search projects by existing tag
#	gitweb_run "by_tag=foo"
not ok 114 - ctags: search projects by non existent tag
#	gitweb_run "by_tag=non-existent"
not ok 115 - ctags: malformed tag weights
#	mkdir -p .git/ctags &&
#		 echo "not-a-number" > .git/ctags/nan &&
#		 echo "not-a-number-2" > .git/ctags/nan2 &&
#		 echo "0.1" >.git/ctags/floating-point &&
#		 gitweb_run
not ok 116 - categories: projects list, only default category
#	echo "\$projects_list_group_categories = 1;" >>gitweb_config.perl &&
#		 gitweb_run
not ok 117 - unborn HEAD: "summary" page (with "heads" subview)
#	git checkout orphan_branch || git checkout --orphan orphan_branch &&
#		 test_when_finished "git checkout master" &&
#		 gitweb_run "p=.git;a=summary"
# failed 108 among 117 test(s)
1..117
make[2]: *** [t9500-gitweb-standalone-no-errors.sh] Error 1
make[2]: Leaving directory
`/home/albert/work/info/install_ver2/git-2.2.2/t'
make[1]: *** [test] Error 2
make[1]: Leaving directory
`/home/albert/work/info/install_ver2/git-2.2.2/t'
make: *** [test] Error 2

Best regards,

Albert Akhriev, PhD
IBM Research - Ireland
Tech. Campus, Bldg 3,  | Mulhuddart, Dublin 15
http://researcher.ibm.com/person/ie-albert_akhriev
albert_akhriev@ie.ibm.com | +353 1 826 91 86

IBM Ireland Limited registered in Ireland under company number 16226.
Registered Office: IBM House, Shelbourne Rd., Ballsbridge, Dublin 4.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Bug Report
       [not found] <CAC34_pT9zwZDnUjo1bTUZabD02M48=_+77-mNCA5adWTgxuYgg@mail.gmail.com>
@ 2013-04-08  5:20 ` Kirk Fraser
  0 siblings, 0 replies; 52+ messages in thread
From: Kirk Fraser @ 2013-04-08  5:20 UTC (permalink / raw)
  To: git

It appears your Amazon download server is too slow.  Perhaps getting
an old used XP system and setting it up as a server will solve this
problem.

Here's the details:


PLATFORM VERSION INFO
	Windows 			: 6.1.7601.65536 (Win32NT)
	Common Language Runtime 	: 4.0.30319.296
	System.Deployment.dll 		: 4.0.30319.1 (RTMRel.030319-0100)
	clr.dll 			: 4.0.30319.296 (RTMGDR.030319-2900)
	dfdll.dll 			: 4.0.30319.1 (RTMRel.030319-0100)

SOURCES
	Deployment url			: http://github-windows.s3.amazonaws.com/GitHub.application
						Server		: AmazonS3
	Application url			:
http://github-windows.s3.amazonaws.com/Application%20Files/GitHub_1_0_41_2/GitHub.exe.manifest
						Server		: AmazonS3

IDENTITIES
	Deployment Identity		: GitHub.application, Version=1.0.41.2,
Culture=neutral, PublicKeyToken=317444273a93ac29,
processorArchitecture=x86
	Application Identity		: GitHub.exe, Version=1.0.41.2,
Culture=neutral, PublicKeyToken=317444273a93ac29,
processorArchitecture=x86, type=win32

APPLICATION SUMMARY
	* Installable application.
	* Trust url parameter is set.
ERROR SUMMARY
	Below is a summary of the errors, details of these errors are listed
later in the log.
	* Activation of
http://github-windows.s3.amazonaws.com/GitHub.application resulted in
exception. Following failure messages were detected:
		+ Downloading http://github-windows.s3.amazonaws.com/Application
Files/GitHub_1_0_41_2/7za.exe.deploy did not succeed.
		+ Unable to read data from the transport connection: An existing
connection was forcibly closed by the remote host.
		+ An existing connection was forcibly closed by the remote host

COMPONENT STORE TRANSACTION FAILURE SUMMARY
	No transaction error was detected.

WARNINGS
	There were no warnings during this operation.

OPERATION PROGRESS STATUS
	* [4/7/2013 9:17:17 PM] : Activation of
http://github-windows.s3.amazonaws.com/GitHub.application has started.
	* [4/7/2013 9:17:30 PM] : Processing of deployment manifest has
successfully completed.
	* [4/7/2013 9:17:30 PM] : Installation of the application has started.
	* [4/7/2013 9:17:34 PM] : Processing of application manifest has
successfully completed.
	* [4/7/2013 9:23:57 PM] : Found compatible runtime version 4.0.30319.
	* [4/7/2013 9:23:57 PM] : Request of trust and detection of platform
is complete.

ERROR DETAILS
	Following errors were detected during this operation.
	* [4/7/2013 9:51:39 PM]
System.Deployment.Application.DeploymentDownloadException (Unknown
subtype)
		- Downloading http://github-windows.s3.amazonaws.com/Application
Files/GitHub_1_0_41_2/7za.exe.deploy did not succeed.
		- Source: System.Deployment
		- Stack trace:
			at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem
next)
			at System.Deployment.Application.SystemNetDownloader.DownloadAllFiles()
			at System.Deployment.Application.FileDownloader.Download(SubscriptionState
subState)
			at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState
subState, AssemblyManifest deployManifest, AssemblyManifest
appManifest, Uri sourceUriBase, String targetDirectory, String group,
IDownloadNotification notification, DownloadOptions options)
			at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState
subState, ActivationDescription actDesc, Int64 transactionId,
TempDirectory& downloadTemp)
			at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState&
subState, ActivationDescription actDesc)
			at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri
activationUri, Boolean isShortcut, String textualSubId, String
deploymentProviderUrlFromExtension, BrowserSettings browserSettings,
String& errorPageUrl)
			at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object
state)
		--- Inner Exception ---
		System.IO.IOException
		- Unable to read data from the transport connection: An existing
connection was forcibly closed by the remote host.
		- Source: System
		- Stack trace:
			at System.Net.ConnectStream.Read(Byte[] buffer, Int32 offset, Int32 size)
			at System.Deployment.Application.SystemNetDownloader.DownloadSingleFile(DownloadQueueItem
next)
		--- Inner Exception ---
		System.Net.Sockets.SocketException
		- An existing connection was forcibly closed by the remote host
		- Source: System
		- Stack trace:
			at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset,
Int32 size, SocketFlags socketFlags)
			at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32
offset, Int32 size)

COMPONENT STORE TRANSACTION DETAILS
	No transaction information is available.



-- 
Kirk W. Fraser
http://freetom.info/TrueChurch - Replace the fraud churches with the
true church.
http://congressionalbiblestudy.org - Fix America by first fixing its
Christian foundation.
http://freetom.info - Example of False Justice common in America

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-05 10:47   ` Carlos Martín Nieto
@ 2012-10-05 11:03     ` Муковников Михаил
  0 siblings, 0 replies; 52+ messages in thread
From: Муковников Михаил @ 2012-10-05 11:03 UTC (permalink / raw)
  To: Carlos Martín Nieto; +Cc: git

Carlos, thank you very much, core.precomposeunicode works just like you said.
And you're right, it seems the problem is in HFS+, 'git add .' worked as well, so did even 'git add test_*'.
The problem seems solved.

05.10.2012, в 14:47, cmn@elego.de (Carlos Martín Nieto) написал(а):

> Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:
> 
>> On Fri, 5 Oct 2012 14:13:49 +0400
>> Муковников Михаил <m.mukovnikov@gmail.com> wrote:
>> 
>>> There's a problem using git with files having cyrillic 'й' in their
>>> name, git just can't track them.
>>> 
>>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>>> version: 1.7.12.1 (from macports)
>>> 
>>> Steps to reproduce:
>>> - git init
>>> - touch test_й
>>> - git status (should be "untracked files present")
>>> - git add test_й
>>> - git status
>>> 
>>> # Untracked files:
>>> #   (use "git add <file>..." to include in what will be committed)
>>> #
>>> #	"test_\320\270\314\206"
>>> nothing added to commit but untracked files present (use "git add" to
>>> track)
>>> 
>>> Could this be helped somehow?--
>> 
>> What "this"?  If you mean displaying escapes for UTF-8 bytes
>> representing that letter "й", then try setting core.quotepath to false
>> for this repository and see if that helps.
> 
> Notice the 'git add test_й'. The problem is that git reports it as untracked.
> 
> Михаил, is this the whole output or do you also see a
> differently-escaped version of the filename under tracked files? Does
> this problem not show up if you use 'git add -A' or 'git add .' instead
> of typing the name? If so, this happens because HFS+ stores and reports
> names differently than the way we told it to store it, so git sees a
> different set of bytes than what it's expecting and considers it a
> different file.
> 
> With a recent version of git, you can set the core.precomposeunicode
> config setting to true, which deals with this situation. This tells git
> to transform the data it gets from the filesystem to the format that
> everyone else uses, which helps not only this, but also the 'git add .'
> case, so git stores the filename in the format the same way that other
> OSs expect to find.
> 
>   cmn

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-05 10:32 ` Konstantin Khomoutov
  2012-10-05 10:47   ` Carlos Martín Nieto
@ 2012-10-05 10:52   ` Муковников Михаил
  1 sibling, 0 replies; 52+ messages in thread
From: Муковников Михаил @ 2012-10-05 10:52 UTC (permalink / raw)
  To: git

Hey, Konstantin!
Thanks for your reply. My bad, I described the problem not very well. I don't mind displaying escapes etc. (core.quotepath just makes "\320\270\314\206" be "й" and that's it), the problem is that git cannot track files with cyrillic "й" in their name. I created a file, added it but git writes it's still untracked, and it seems there's no way to track it.

05.10.2012, в 14:32, Konstantin Khomoutov <flatworm@users.sourceforge.net> написал(а):

> On Fri, 5 Oct 2012 14:13:49 +0400
> Муковников Михаил <m.mukovnikov@gmail.com> wrote:
> 
>> There's a problem using git with files having cyrillic 'й' in their
>> name, git just can't track them.
>> 
>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>> version: 1.7.12.1 (from macports)
>> 
>> Steps to reproduce:
>> - git init
>> - touch test_й
>> - git status (should be "untracked files present")
>> - git add test_й
>> - git status
>> 
>> # Untracked files:
>> #   (use "git add <file>..." to include in what will be committed)
>> #
>> #	"test_\320\270\314\206"
>> nothing added to commit but untracked files present (use "git add" to
>> track)
>> 
>> Could this be helped somehow?--
> 
> What "this"?  If you mean displaying escapes for UTF-8 bytes
> representing that letter "й", then try setting core.quotepath to false
> for this repository and see if that helps.
> 
> More info can be found in the git-config manual page.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-05 10:32 ` Konstantin Khomoutov
@ 2012-10-05 10:47   ` Carlos Martín Nieto
  2012-10-05 11:03     ` Муковников Михаил
  2012-10-05 10:52   ` Муковников Михаил
  1 sibling, 1 reply; 52+ messages in thread
From: Carlos Martín Nieto @ 2012-10-05 10:47 UTC (permalink / raw)
  To: Konstantin Khomoutov
  Cc: Муковников
	Михаил,
	git

Konstantin Khomoutov <flatworm@users.sourceforge.net> writes:

> On Fri, 5 Oct 2012 14:13:49 +0400
> Муковников Михаил <m.mukovnikov@gmail.com> wrote:
>
>> There's a problem using git with files having cyrillic 'й' in their
>> name, git just can't track them.
>> 
>> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
>> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
>> version: 1.7.12.1 (from macports)
>> 
>> Steps to reproduce:
>> - git init
>> - touch test_й
>> - git status (should be "untracked files present")
>> - git add test_й
>> - git status
>> 
>> # Untracked files:
>> #   (use "git add <file>..." to include in what will be committed)
>> #
>> #	"test_\320\270\314\206"
>> nothing added to commit but untracked files present (use "git add" to
>> track)
>> 
>> Could this be helped somehow?--
>
> What "this"?  If you mean displaying escapes for UTF-8 bytes
> representing that letter "й", then try setting core.quotepath to false
> for this repository and see if that helps.

Notice the 'git add test_й'. The problem is that git reports it as untracked.

Михаил, is this the whole output or do you also see a
differently-escaped version of the filename under tracked files? Does
this problem not show up if you use 'git add -A' or 'git add .' instead
of typing the name? If so, this happens because HFS+ stores and reports
names differently than the way we told it to store it, so git sees a
different set of bytes than what it's expecting and considers it a
different file.

With a recent version of git, you can set the core.precomposeunicode
config setting to true, which deals with this situation. This tells git
to transform the data it gets from the filesystem to the format that
everyone else uses, which helps not only this, but also the 'git add .'
case, so git stores the filename in the format the same way that other
OSs expect to find.

   cmn

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: Bug report
  2012-10-05 10:13 Муковников Михаил
@ 2012-10-05 10:32 ` Konstantin Khomoutov
  2012-10-05 10:47   ` Carlos Martín Nieto
  2012-10-05 10:52   ` Муковников Михаил
  0 siblings, 2 replies; 52+ messages in thread
From: Konstantin Khomoutov @ 2012-10-05 10:32 UTC (permalink / raw)
  To: Муковников
	Михаил
  Cc: git

On Fri, 5 Oct 2012 14:13:49 +0400
Муковников Михаил <m.mukovnikov@gmail.com> wrote:

> There's a problem using git with files having cyrillic 'й' in their
> name, git just can't track them.
> 
> uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25
> 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 git
> version: 1.7.12.1 (from macports)
> 
> Steps to reproduce:
> - git init
> - touch test_й
> - git status (should be "untracked files present")
> - git add test_й
> - git status
> 
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> #	"test_\320\270\314\206"
> nothing added to commit but untracked files present (use "git add" to
> track)
> 
> Could this be helped somehow?--

What "this"?  If you mean displaying escapes for UTF-8 bytes
representing that letter "й", then try setting core.quotepath to false
for this repository and see if that helps.

More info can be found in the git-config manual page.

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Bug report
@ 2012-10-05 10:13 Муковников Михаил
  2012-10-05 10:32 ` Konstantin Khomoutov
  0 siblings, 1 reply; 52+ messages in thread
From: Муковников Михаил @ 2012-10-05 10:13 UTC (permalink / raw)
  To: git

There's a problem using git with files having cyrillic 'й' in their name, git just can't track them.

uname: Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
git version: 1.7.12.1 (from macports)

Steps to reproduce:
- git init
- touch test_й
- git status (should be "untracked files present")
- git add test_й
- git status

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	"test_\320\270\314\206"
nothing added to commit but untracked files present (use "git add" to track)

Could this be helped somehow?

^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2022-04-21 17:53 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-04  4:35 Bug report John Whitney
2012-10-04 14:19 ` Phil Hord
2012-10-04 16:10   ` John Whitney
2012-10-06 13:31     ` Jeff King
2012-10-07  2:23       ` John Whitney
2012-10-07 23:52         ` Jeff King
2012-10-09 17:17           ` John Whitney
2012-10-09 19:00             ` John Whitney
2012-10-04 15:21 ` Andrew Wong
2012-10-04 16:16   ` John Whitney
2012-10-04 16:28     ` John Whitney
2012-10-04 17:01     ` Andrew Wong
2012-10-05 10:13 Муковников Михаил
2012-10-05 10:32 ` Konstantin Khomoutov
2012-10-05 10:47   ` Carlos Martín Nieto
2012-10-05 11:03     ` Муковников Михаил
2012-10-05 10:52   ` Муковников Михаил
     [not found] <CAC34_pT9zwZDnUjo1bTUZabD02M48=_+77-mNCA5adWTgxuYgg@mail.gmail.com>
2013-04-08  5:20 ` Bug Report Kirk Fraser
2015-01-27 14:43 bug report Albert Akhriev
2015-01-27 14:50 ` Jeff King
2016-04-03  0:25 Bug Report Benjamin Sandeen
2016-04-03  2:20 ` Eric N. Vander Weele
2016-04-03  2:22 ` Jacob Keller
2016-05-13  5:04 bug report 李本超
2016-05-13  5:23 ` Pranit Bauva
2016-05-13  5:58   ` 李本超
2016-05-13  6:37     ` Pranit Bauva
2016-05-13  6:57       ` 李本超
2016-05-13  7:10         ` Pranit Bauva
2016-05-13  7:41           ` 李本超
2016-05-13  8:10             ` Jeff King
2016-05-13 12:05               ` 李本超
2017-08-30 21:25 Bug report Aleksandar Pavic
2017-08-31  6:36 ` Kevin Daudt
2017-08-31 14:19   ` Dov Grobgeld
2017-08-31 14:55     ` Aleksandar Pavic
2017-08-31 16:23   ` Stephan Beyer
2017-09-02  8:49 ` Jeff King
     [not found] <CA+2sEepTyrK-iH+VBHVF1i9DuYVzDkTNxuM0-yoWbkC9N4f8HA@mail.gmail.com>
2019-04-15 15:18 ` bug report Nick Steinhauser
2020-03-27 11:53 Bug Report James Yeoman
2020-03-27 12:59 ` Pratyush Yadav
2021-11-12  4:22 bug report Theodore Li
2021-11-12  4:29 ` Junio C Hamano
2021-11-12  6:59   ` Theodore Li
2021-11-12 14:05     ` Paul Smith
2021-12-01 22:31 Bug Report Josh Rampersad
2022-04-20 19:45 Daniel Habenicht
2022-04-20 21:30 ` brian m. carlson
2022-04-20 22:34   ` rsbecker
2022-04-21 13:20     ` Daniel Habenicht
2022-04-21 14:39       ` Torsten Bögershausen
     [not found]         ` <AS1P190MB175022A7F1264807ECA464A8ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM>
2022-04-21 17:52           ` Torsten Bögershausen

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).