Bug report

Bug report

[Alastair Douglas]

I have found no solution to the issue below. Apologies if it has
already been addressed.

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

Have an existing git config with rebase = preserve

What did you expect to happen? (Expected behaviour)

Merges to be preserved when rebasing, without a warning about an option I am
not using.

What happened instead? (Actual behaviour)

I received a warning as though I had used the option on the command line:

warning: git rebase --preserve-merges is deprecated. Use
--rebase-merges instead.

I didn't do that, so I can't follow the advice. There appears to be no
alternative config setting for the new option.

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

I expected rebase=preserve to now use --rebase-merges instead of
--preserve-merges, or for a new config setting to be made available to use
--rebase-merges. Ideally the first, because the semantics are clear.

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.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC
2022 x86_64
compiler info: gnuc: 11.2
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /usr/bin/zsh


[Enabled Hooks]
not run from a git repository - no hooks to show

Re: Bug report

[Junio C Hamano]

Alastair Douglas <alastair.douglas@gmail.com> writes:

> I have found no solution to the issue below. Apologies if it has
> already been addressed.

Thanks for a report.  

The solution is to remove "[pull] rebase = preserve" and replace it
with "[pull] rebase = merges", I think.


> What did you do before the bug happened? (Steps to reproduce your issue)
>
> Have an existing git config with rebase = preserve
>
> What did you expect to happen? (Expected behaviour)
>
> Merges to be preserved when rebasing, without a warning about an option I am
> not using.
>
> What happened instead? (Actual behaviour)
>
> I received a warning as though I had used the option on the command line:
>
> warning: git rebase --preserve-merges is deprecated. Use
> --rebase-merges instead.
>
> I didn't do that, so I can't follow the advice. There appears to be no
> alternative config setting for the new option.

It sounds like splitting hairs, but I agree that the message is
misleading.  I think whoever wrote the message meant that "the
feature that is triggered by giving the --preserve-merges option to
the command" was deprecated.  IOW, they did not mean that only the
command line option was depreated, implying that it is not
deprecated to trigger the same feature by setting a configuration
variable.  Both forms of the use of the same feature was deprecated
about the same time.

I also suspect that they were hoping that the users will read the
instruction based on these command line options and understand that
it also applies to the configuration variables.

Re: Bug report

[Alastair Douglas]

On Mon, 3 Oct 2022 at 17:53, Junio C Hamano <gitster@pobox.com> wrote:
>
> Alastair Douglas <alastair.douglas@gmail.com> writes:
>
> > I have found no solution to the issue below. Apologies if it has
> > already been addressed.
>
> Thanks for a report.
>
> The solution is to remove "[pull] rebase = preserve" and replace it
> with "[pull] rebase = merges", I think.
>

Thanks for this reply. This seems to have worked, since I got no warning.

Now that I know it is a new option to the rebase setting I have found
it in the documentation:

branch.<name>.rebase
...
  When merges, pass the --rebase-merges option to git rebase so that
the local merge commits are included in the rebase (see git-rebase(1)
for details).
  When preserve (deprecated in favor of merges), also pass
--preserve-merges along to git rebase so that locally committed merge
commits will not be flattened by running git pull.

It does seem like nobody else on the internet is aware of this, since
I didn't discover this by Googling it.

> I also suspect that they were hoping that the users will read the
> instruction based on these command line options and understand that
> it also applies to the configuration variables.
>

I understood immediately that it applied to the config, but I couldn't
find a single thing about what I *should* have done until you told me
here.

Having said all this, I am fairly sure that I checked the
documentation for the rebase config and failed to spot that new part,
so I am not blameless myself! I feel like *something* could be updated
to point in the right direction, but I really don't know what.
Yesterday, I genuinely thought there was no replacement config for the
deprecated one!

Thanks for your time, but I suppose, in conclusion, there's not a lot
to be done.

Re: Bug report [die() preserve-merges messages]

[Philip Oakley]

Hi Alastair,

On 04/10/2022 11:15, Alastair Douglas wrote:
> On Mon, 3 Oct 2022 at 17:53, Junio C Hamano <gitster@pobox.com> wrote:
>> Alastair Douglas <alastair.douglas@gmail.com> writes:
>>
>>> I have found no solution to the issue below. Apologies if it has
>>> already been addressed.
>> Thanks for a report.
>>
>> The solution is to remove "[pull] rebase = preserve" and replace it
>> with "[pull] rebase = merges", I think.
>>
> Thanks for this reply. This seems to have worked, since I got no warning.
>
> Now that I know it is a new option to the rebase setting I have found
> it in the documentation:
>
> branch.<name>.rebase
> ...
>   When merges, pass the --rebase-merges option to git rebase so that
> the local merge commits are included in the rebase (see git-rebase(1)
> for details).
>   When preserve (deprecated in favor of merges), also pass
> --preserve-merges along to git rebase so that locally committed merge
> commits will not be flattened by running git pull.
>
> It does seem like nobody else on the internet is aware of this, since
> I didn't discover this by Googling it.
>
>> I also suspect that they were hoping that the users will read the
>> instruction based on these command line options and understand that
>> it also applies to the configuration variables.
>>
> I understood immediately that it applied to the config, but I couldn't
> find a single thing about what I *should* have done until you told me
> here.
>
> Having said all this, I am fairly sure that I checked the
> documentation for the rebase config and failed to spot that new part,
> so I am not blameless myself! I feel like *something* could be updated
> to point in the right direction, but I really don't know what.
> Yesterday, I genuinely thought there was no replacement config for the
> deprecated one!
>
> Thanks for your time, but I suppose, in conclusion, there's not a lot
> to be done.

Earlier this year, I tried to update the error messages to catch the
various ways that the removal of 'preserve-merges' could be confusing to
users, based on a Git for Windows user's report [1,2].

It is rare for a method to be removed, so there was little experience of
how best to handle all the different use cases.

In general, the approach was to ensure that users could not fail to
notice that something had changed, or needed to be changed. The problem
with 'preserve-merges' being that there were scenarios where the code
did the wrong thing and users were not noticing, and further it wasn't
clear to users which case that was, nor how to explain it, given the
mind-set confusions!

In general Git avoids rolling over old options to new variants, without
notification, if they do different things. It would have been nice to
cover more use cases, but often the cause was not known at the point the
problem was detected in the code, as you have seen.

It was expected that users should have been aware of their own
configuration settings, though that's not always true (see the mailing
list discussions).

Philip

[1]
https://lore.kernel.org/git/pull.1155.git.1645526016.gitgitgadget@gmail.com/
 Subject: [PATCH 0/2] Update the die() preserve-merges messages to help
some users   22 Feb 2022
[2]
https://lore.kernel.org/git/pull.1242.v2.git.1654341469.gitgitgadget@gmail.com/
Subject: [PATCH v2 0/4] Die preserve ggg   04 Jun 2022

Re: Bug report

[Junio C Hamano]

Alastair Douglas <alastair.douglas@gmail.com> writes:

> ... I feel like *something* could be updated
> to point in the right direction, but I really don't know what.

Yes, I shared the exact feeling.  Perhaps the message could have
been a bit more helpful by referring to configuration variables that
are potentially relevant.

Thanks.

Bug report

[Dexter Pontañeles]

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)
I was trying to merge another branch to my branch but then got
conflicts. After resolving the conflicts, I wanted to continue the
merge operation but a hook was failing. I wanted to bypass this hook
by adding --no-verify flag: git merge --continue --no-verify

What did you expect to happen? (Expected behavior)
I expected the merge operation to continue, bypassing the hook

What happened instead? (Actual behavior)
git command failed with error `fatal: --continue expects no arguments`

What's different between what you expected and what actually happened?
The operation failed instead of proceeding with the git merge operation

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.42.0
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:05
PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64
compiler info: clang: 14.0.3 (clang-1403.0.22.14.1)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]

Bug Report

[Tiago d'Almeida]

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

Hello!

I'm Tiago and sorry for any mistake because it is my first bug report to git.

So after git updated, I begin to get some errors and unexpected git
status output.

I made a test git repo to test this, and here are the results:

```
mkdir git_bug && cd git_bug
git init -q && git maintenance register && echo "Done!"
touch <files>
mkdir <folders>
touch <files in folders>
git status --short

## No commits yet on main
?? LICENSE
?? README.md
?? folder/
?? folder_1/

git add <files>
git status

## No commits yet on main
?? LICENSE
?? README.md
?? folder/
?? folder_1/

git commit -s -m "First commit"

On branch main

Initial commit

Untracked files:
LICENSE
README.md
folder/
folder_1/

nothing added to commit but untracked files present

```

Attached to this email follow the `git bugreport` and global `config`
files, and the git_bug repo.

I've checked my global config file and it seems all ok, but if there
is some error or contradicition, please tell me.

Thanks in advance!

[-- Attachment #2: git-bugreport-2023-06-27-1643.txt --]
[-- Type: text/plain, Size: 971 bytes --]

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)

A normal git routine.
- git add <files>
- git commit -s -m "Commit"

What did you expect to happen? (Expected behavior)

No errors and the files being added and commited.

What happened instead? (Actual behavior)

No files added. Error when tried to commit.

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

The error.

Anything else you want to add:

This just happened after updating git to version 2.41 


[System Info]
git version 2.41.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.3.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 15 02:15:40 UTC 2023 x86_64
compiler info: gnuc: 13.1
libc info: glibc: 2.37
$SHELL (typically, interactive shell): /usr/bin/fish


[Enabled Hooks]

[-- Attachment #3: global_config --]
[-- Type: application/octet-stream, Size: 7090 bytes --]

# TIAGO d'ALMEIDA GIT CONFIG


# These directives includes the user.name and user.email according to the repo location.
[include]
  path = "./config_d/personal"

[includeIf "gitdir:~/Projects/work/"]
  path = "./config_d/work"

[includeIf "gitdir:~/Work/"]
  path = "./config_d/work"

[alias]
  a   = add
  aa  = add --all .
  ai  = add -i
  aac = ! git add --all . && git commit -m
  br  = branch
  cl  = clone
  cm  = commit -s -m
  cml = commit -s
  cp  = cherry-pick
  d   = diff
  f   = fetch
  fa  = fetch --all
  i   = ! git init -q && git maintenance register && echo "Done!"
  l   = log --graph --oneline -n 10
  ls  = log --graph --oneline --all
  lch = log --pretty="format:(%h) %N %an" --show-notes=*
  m   = maintenance run
  ms  = maintenance register
  mu  = maintenance unregister
  nt  = notes
  nta = notes append
  nch = notes append --ref=changelog
  p   = push
  pa  = push --all
  rb  = rebase -i
  r   = reset
  r1  = reset HEAD~
  r2  = reset HEAD~~
  rh  = reset --hard
  rh1 = reset HEAD~ --hard
  rh2 = reset HEAD~~ --hard
  rt  = restore
  s   = status --short
  sl  = status --long
  st  = stash              # equivalent to `stash push`
  stp = stash pop
  stl = stash list
  sta = stash apply
  sts = stash show
  sw  = switch             # switch and restore is the new checkout
  w   = ! watch -n 5 -p -c git -c color.ui=always status

  amend   = commit -s --amend --no-edit
  fixup   = commit -s --fixup

  since   = log --graph --oneline --since="1 week ago"

  track   = add -N
  unstage = restore --staged
  forget  = rm -r --cached

  del     = delete
  delete  = ! git maintenance unregister && rm -rf .git && echo "Done!"
  watch   = ! watch -n 5 -p -c git -c color.ui=always status

  show    = show --show-signature

#	brd = branch -d
#	brD = branch -D
# br_desc = branch --edit-description
#	merged = branch --merged
#	dev = !git checkout dev && git pull origin dev
#	staging = !git checkout staging && git pull origin staging
#	master = !git checkout master && git pull origin 
#	po = push origin
#	pu = !git push origin `git branch --show-current`
#	pod = push origin dev
#	pos = push origin staging
#	pom = push origin main
#	poh = push origin HEAD
#	pogm = !git push origin gh-pages && git checkout master && git pull origin master && git rebase gh-pages && git push origin master && git checkout gh-pages
#	pomg = !git push origin master && git checkout gh-pages && git pull origin gh-pages && git rebase master && git push origin gh-pages && git checkout master
#	plo = pull origin
#	plod = pull origin dev
#	plos = pull origin staging
#	plom = pull origin master
#	ploh = pull origin HEAD
#	f = "!git ls-files | grep -i"
# gr = grep -Ii

[advice]
  addIgnoredFile = false
  statusHints = false

[branch]
  autoSetupMerge = always

[core]
	askPass = ""
  compression = 6
  editor = nano +1
  eol = lf
  filemode = true
  fsmonitor = true
  fsmonitorHookVersion = 2
  fsyncMethod = batch
#  hooksPath = "./hooks" --> can't be this path, correct this in the future; see man git-config
#  notes = refs/notes/commits
  pager = less --tabs=2
#  quotePath = off
  safecrlf = true
  sparseCheckout = true
  sparseCheckoutCone = true
  splitIndex = true
  symlinks = true
  whitespace = space-before-tab, tab-in-indent, trailing-space, tabwidth=2

[add]
#  ignoreErrors = true

[apply]
  ignoreWhitespace = false

[checkout]
  defaultRemote = origin
  workers = 0
  thresholdForParallelism = 100
  
[color]
  ui = auto

[color "advice"]
  hint = dim white

[color "status"]
  header       = italic white
  added        = green
  updated      = cyan
  changed      = brightyellow
  untracked    = dim white
  branch       = bold magenta
  nobranch     = red
  localBranch  = bold magenta
  remoteBranch = brightgreen
  unmerged     = cyan

[column]
  ui = auto, column, dense

[commit]
  gpgSign = true
#  template = "./commit"

[credential]
#  helper = "cache --timeout 18000 --socket ~/.config/git/socket"
  helper = "cache --timeout 18000"

[diff]
  context = 5
  mnemonicPrefix = true
  relative = true
  renames = copies
  algoritm = patience
  wsErrorHighlight = all
  colorMoved = true

[feature]
  experimental = true
  manyFiles = true

[fetch]
  prune = true
  pruneTags = true
  output = compact
  parallel = 3
  writeCommitGraph = true

[filter "lfs"]
  clean = git-lfs clean -- %f
  smudge = git-lfs smudge -- %f
  process = git-lfs filter-process
  required = true

[gc]
  bigPackThreshold    = 1g
  logExpiry           = 1.week
  cruftPacks          = true
  pruneExpire         = 1.week
  worktreePruneExpire = 1.month

[gpg]
  program = gpg2
  minTrustLevel = fully

[help]
  autoCorrect = prompt

[http]
#  cookieFile = ~/.config/git/cookie
  saveCookies = true
  version = HTTP/2
  sslVersion = tlsv1.3
  sslVerify = true

[i18n]
  commitEncoding = utf-8
  logOutputEncoding = utf-8

[index]
  sparse = true
  threads = true

[init]
  defaultBranch = main
#  templateDir = ~/.config/git/template/

[interactive]
  singleKey = true

[lfs "https://github.com/"]
  locksverify = true

[lfs "https://gitlab.com/"]
  locksverify = true

[log]
  decorate = auto
  graphColors = brightwhite, red, green, blue, magenta, yellow, cyan

[lsrefs]
  unborn = advertise

[maintenance]
  auto = false
  strategy = incremental
# commit-graph        - hourly
# prefetch            - hourly
# gc                  - off
# loose-objects       - daily
# incremental-repack  - daily
# pack-refs           - weekly

[maintenance.gc]
  enabled = true
  schedule= weekly

[merge]
  conflictStyle = merge
  ff = only
  verifySignatures = true
  branchdesc = true
  log = true
  renormalize = true
  stat = true
  autoStash = true

#[notes]
#  # https://dev.to/leehambley/effortlessly-maintain-a-high-quality-change-log-with-git-notes-4bm5
##  mergeStrategy = cat_sort_uniq
##  rewriteMode = cat_sort_uniq
##  rewriteRef = refs/notes/commits
#
#[notes "rewrite"]
#  amend = true
#  rebase = true

[pack]
  useBitmaps = true
  useSparse = true
  writeBitmapHashCache =true
  writeReverseIndex = true

# pass command-line tool 
[pass]
  signcommits = true

[protocol]
  version = 2

[pull]
  ff      = only
  rebase  = false
  twohead = ort

[push]
  autoSetupRemote = true
  default = current
  followTags = true
  gpgSign = if-asked
  negotiate = true

[rebase]
  backend = merge
  autoSquash = true
  autoStash = true
  missingCommitsCheck = warn
  abbreviateCommands = true

[remote]
  pushDefault = origin

#[remote "origin"]
#  tagOpt = "--tags"
##  fetch = +refs/heads/*:refs/remotes/origin/*
##  fetch = +refs/notes/*:refs/notes/*
##  push = +refs/heads/*
##  push = +refs/notes/*:refs/notes/*
#
[repack]
  writeBitmaps = true

[rerere]
  autoUpdate = true
  enabled = true

[safe]
  bareRepository = explicit

[splitIndex]
  maxPercentChange = 20

[ssh]
  variant = ssh

[status]
  branch    = true
  showStash = true

[transfer]
  credentialsInUrl = die
  fsckObjects = true

[tag]
  forceSignAnnotated = true
  gpgSign = true

[user]
  useConfigOnly = true
  signingkey = ***********

[versionsort]
  suffix = "-pre"
  suffix = "-rc"
  suffix = ""

[-- Attachment #4: git_bug.tar.gz --]
[-- Type: application/gzip, Size: 11601 bytes --]

Bug report

[Jensen Bean]

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)
download git
What did you expect to happen? (Expected behavior)
CTRL button to work
What happened instead? (Actual behavior)
CTRL button stops working
What's different between what you expected and what actually happened?
the CTRL button doesn't work when I have git installed
Anything else you want to add:
Deleting git and all its files has been the only thing that works so far
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
Confusing experience, wasn't sure what to actually do

[System Info]
git version:
git version 2.38.1.windows.1
cpu: x86_64
built from commit: b85c8f604d375d4d773a36842964e8a7ec056aae
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 22621
compiler info: gnuc: 12.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


[Enabled Hooks]
not run from a
git repository - no hooks to show
git-bugreport-2022-12-25-0152.txt[+] [unix] (01:52 25/12/2022)

Re: Bug report

[Eric Sunshine]

On Tue, Dec 27, 2022 at 10:09 PM Jensen Bean <jensen.bean@gmail.com> wrote:
> What did you expect to happen? (Expected behavior)
> CTRL button to work
> What happened instead? (Actual behavior)
> CTRL button stops working
> What's different between what you expected and what actually happened?
> the CTRL button doesn't work when I have git installed
>
> [System Info]
> git version:
> git version 2.38.1.windows.1

This sounds like a problem specific to Git for Windows, which is a
separate project. You may want to open a bug report with that
project's issue tracker[1].

[1]: https://github.com/git-for-windows/git/issues

bug report

[Eyal Post]

What did you do before the bug happened? (Steps to reproduce your issue)
1. I have a script which creates a git worktree and checks out a few
files from the master branch
2. When this script runs "stand alone" - everything works fine
3. When this script runs from a "pre-commit" hook it fails with an
error: "fatal: Unable to create '/tmp/wt-1/.git/index.lock': Not a
directory"

The content of the script is (simplified example):
git worktree add /tmp/wt-1 master --no-checkout --detach
cd /tmp/wt-1
git checkout master .


What did you expect to happen? (Expected behavior)
I would expect the script to run just fine as part of the pre-commit hook

What happened instead? (Actual behavior)
An error about .git not being a directory is shown

What's different between what you expected and what actually happened?
An error instead of completing successfully

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.39.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:25:27
PDT 2022; root:xnu-8020.141.5~2/RELEASE_X86_64 x86_64
compiler info: clang: 14.0.0 (clang-1400.0.29.202)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]
pre-commit

Re: bug report

[Eric Sunshine]

On Sun, Dec 25, 2022 at 12:48 PM Eyal Post <eyalpost@gmail.com> wrote:
> 1. I have a script which creates a git worktree and checks out a few
> files from the master branch
> 2. When this script runs "stand alone" - everything works fine
> 3. When this script runs from a "pre-commit" hook it fails with an
> error: "fatal: Unable to create '/tmp/wt-1/.git/index.lock': Not a
> directory"
>
> The content of the script is (simplified example):
> git worktree add /tmp/wt-1 master --no-checkout --detach

This was previously reported[1]. Based upon a quick scan of that old
email thread, I'm not sure we ever came to a final conclusion about
whether Git could address this case itself[2] without breaking
existing workflows or if it should be the hook's responsibility[3].
Perhaps try having your hook script unset environment variables as
explained in [3], or at minimum unset GIT_INDEX_FILE. Also, perhaps
this advice[4] applies and you can take a simpler, less heavyweight
approach to whatever your hook is doing.

[1]: https://lore.kernel.org/git/CAJFQqN+Z9eX6onaj8vVSqpvf-nOC7-Y0Un4NLUie6x6bGfmvZA@mail.gmail.com/
[2]: https://lore.kernel.org/git/20190517011941.GA30372@sigill.intra.peff.net/
[3]: https://lore.kernel.org/git/20190516221702.GA11784@sigill.intra.peff.net/
[4]: https://lore.kernel.org/git/CAGyf7-GtnCqfqPWVpBAELB4xAE6syn7+DfKXgfhL0UoMfvbn4A@mail.gmail.com/

Bug Report

[Jensen Bean]

 H e l l o ,   I   d o w n l o a d e d   g i t   b a s h   2   m o n t
h s   a g o .   E v e r   s i n c e   t h e n   m y   C T R L   b u t
t o n   h a s   n o t   w o r k e d   c o r r e c t l y .   I   k n o
w   t h i s   i s   n o t   a   h a r d w a r e   g l i t c h   b e c
a u s e   t h e   o n l y   t h i n g   t h a t   f i x e s   i t   i
s   u n i n s t a l l i n g   G i t   a n d   a l l   o f   i t   s
a s s o c i a t e d   f i l e s .   A n y   h e l p   o n   t h i s
w o u l d   b e   g r e a t l y   a p p r e c i a t e d .
 J e n s e n

Re: Bug Report

[Bagas Sanjaya]

On 12/8/22 12:29, Jensen Bean wrote:
>  H e l l o ,   I   d o w n l o a d e d   g i t   b a s h   2   m o n t
> h s   a g o .   E v e r   s i n c e   t h e n   m y   C T R L   b u t
> t o n   h a s   n o t   w o r k e d   c o r r e c t l y .   I   k n o
> w   t h i s   i s   n o t   a   h a r d w a r e   g l i t c h   b e c
> a u s e   t h e   o n l y   t h i n g   t h a t   f i x e s   i t   i
> s   u n i n s t a l l i n g   G i t   a n d   a l l   o f   i t   s
> a s s o c i a t e d   f i l e s .   A n y   h e l p   o n   t h i s
> w o u l d   b e   g r e a t l y   a p p r e c i a t e d .
>  J e n s e n

What are your setup? Please try git-bugreport(1) and fill the details.

-- 
An old man doll... just what I always wanted! - Clara

Re: Bug Report

[Bagas Sanjaya]

On 12/25/22 16:02, Jensen Bean wrote:
> 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)
> download git
> What did you expect to happen? (Expected behavior)
> CTRL button to work
> What happened instead? (Actual behavior)
> CTRL button stops working
> What's different between what you expected and what actually happened?
> the CTRL button doesn't work when I have git installed
> Anything else you want to add:
> Deleting git and all its files has been the only thing that works so far
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
> Confusing experience, wasn't sure what to actually do
> 
> [System Info]
> git version:
> git version 2.38.1.windows.1
> cpu: x86_64
> built from commit: b85c8f604d375d4d773a36842964e8a7ec056aae
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Windows 10.0 22621
> compiler info: gnuc: 12.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe
> 
> 
> [Enabled Hooks]
> not run from a
> git repository - no hooks to show
> git-bugreport-2022-12-25-0152.txt[+] [unix] (01:52 25/12/2022)
> 

Thanks for the bug report but you need to send it to Git mailing list, in
order for developers there to see the report and act on it.

Also, when replying, don't top-post; reply inline with appropriate context
instead. If you top-post, I'm going to cut the whole context below.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Bug Report

[Jensen Bean]

Hello,



I downloaded Git and Git Bash onto my windows laptop. A few hours
after, I noticed that my CTRL button was not working. I looked online
to see how to fix it. I reinstalled drivers, tried to enable and
disable CTRL shortcuts, turned on the on screen keyboard to see if it
was registering, but nothing has fixed it. The only thing that works
is uninstalling Git, and deleting all files related to it. Once I do
that my CTRL button works again. I can plug in an external keyboard,
but that limits the portability of having a laptop. I tried asking
software developers/engineers, but no one knows. I hope this isn’t a
completely unique case, any help would be greatly appreciated!!



Jensen

Bug Report

[Daniel Habenicht]

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

Re: Bug Report

[brian m. carlson]

[-- 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 --]

RE: Bug Report

[rsbecker]

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.

Re: Bug Report

[Daniel Habenicht]

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.

Re: Bug Report

[Torsten Bögershausen]

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.

Re: Bug Report

[Torsten Bögershausen]

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

Bug Report

[Josh Rampersad]

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]

bug report

[Theodore Li]

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]

Re: bug report

[Junio C Hamano]

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 "/*"

?

Re: bug report

[Theodore Li]

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 "/*"
>
> ?

Re: bug report

[Paul Smith]

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.

Bug Report

[James Yeoman]

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.

-- 

Re: Bug Report

[Pratyush Yadav]

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

Re: bug report

[Nick Steinhauser]

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

Bug report

[Aleksandar Pavic]

  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...

Re: Bug report

[Kevin Daudt]

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?

Re: Bug report

[Dov Grobgeld]

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?

Re: Bug report

[Aleksandar Pavic]

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?

Re: Bug report

[Stephan Beyer]

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

Re: Bug report

[Jeff King]

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

bug report

[李本超]

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

Re: bug report

[Pranit Bauva]

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

Re: bug report

[李本超]

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

Re: bug report

[Pranit Bauva]

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

Re: bug report

[李本超]

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

Re: bug report

[Pranit Bauva]

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

Re: bug report

[李本超]

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

Re: bug report

[Jeff King]

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.

Re: bug report

[李本超]

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

Bug Report

[Benjamin Sandeen]

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

Re: Bug Report

[Eric N. Vander Weele]

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

Re: Bug Report

[Jacob Keller]

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
>

bug report

[Albert Akhriev]

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.

Re: bug report

[Jeff King]

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

Bug Report

[Kirk Fraser]

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

Bug report

[Муковников Михаил]

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?

Re: Bug report

[Konstantin Khomoutov]

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.

Re: Bug report

[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

Re: Bug report

[Муковников Михаил]

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

Re: Bug report

[Муковников Михаил]

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.

Bug report

[John Whitney]

[-- 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 --]

Re: Bug report

[Phil Hord]

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

Re: Bug report

[John Whitney]

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.

Re: Bug report

[Jeff King]

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

Re: Bug report

[John Whitney]

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 {} \;".

Re: Bug report

[Jeff King]

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

Re: Bug report

[John Whitney]

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

Re: Bug report

[John Whitney]

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

Re: Bug report

[Andrew Wong]

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.

Re: Bug report

[John Whitney]

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.

Re: Bug report

[John Whitney]

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.

Re: Bug report

[Andrew Wong]

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.