Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

html pages are not 'hyperlinked' #404

Closed
snaewe opened this issue Sep 18, 2015 · 8 comments · Fixed by git-for-windows/MINGW-packages#16
Closed

html pages are not 'hyperlinked' #404

snaewe opened this issue Sep 18, 2015 · 8 comments · Fixed by git-for-windows/MINGW-packages#16
Assignees
@nalla
Labels
bug git

Comments

@snaewe
Copy link

snaewe commented Sep 18, 2015

I'm on Win7, git-for-windows 2.5.2.windows.2

The html pages that come with Git for Windows are note hyperlinked.
Take a look at the man page (html page that is) of 'git' itself.
In the second paragraph of the 'Description' section, I see

See linkgit:gittutorial[7] to get started, then see linkgit:giteveryday[7] for a useful minimum set of commands.

Which is not quite correct I presume.
@snaewe
Copy link
Author

snaewe commented Sep 18, 2015

Oh. I just noticed that in the next sentence of the above mentioned paragraph the link to "Git Users' Manual" is correct.

@dscho
Copy link
Member

dscho commented Sep 18, 2015

Let's put some precision into this description. Do I understand correctly that you meant to instruct me to

  1. run git help git in a Git Bash,
  2. observe the following paragraph below the synopsis:
    incorrect-linkgit

If so, then good: I can reproduce.

Now, this is what you can do about it:

  1. install the Git for Windows SDK
  2. build the Git package
  3. debug why the linkgit is not interpreted while the link is

You could also debug that in /usr/src/git/Documentation, but you need to make sure to copy the ASCIIDOC settings from /usr/src/MINGW-packages/mingw-git/PKGBUILD.

@dscho
Copy link
Member

dscho commented Sep 18, 2015

I just added the label unclear because it is not clear whether the bug is in the PKGBUILD settings or in the ASCIIDOC invocation in Git's repository. As soon as you find out and let us know, I will replace that label with the correct one.

@nalla
Copy link

nalla commented Sep 18, 2015

it seems to be the invocation. cd /usr/src/git/Documentation && asciidoctor --verbose --trace -I/mingw64/lib/asciidoctor-extensions -rman-inline-macro git.txt seems to work.

@nalla
Copy link

nalla commented Sep 18, 2015

Found it. If you run make clean && make -j8 html SHELL='sh -x' you can see the output. There you can see asciidoctor '-alitdd=--' -a git-asciidoc-no-roff '-I/mingw64/lib/asciidoctor-extensions -rman-inline-macro' -agit_version=2.5.2.windows.2 -b html5 -d manpage -o git.html.new git.txt

If you remove the two 's in the include and library invocation it works again.

@nalla nalla self-assigned this Sep 18, 2015
@nalla nalla added git and removed unclear labels Sep 18, 2015
@dscho
Copy link
Member

dscho commented Sep 18, 2015

@nalla you are truly awesome!

@nalla nalla mentioned this issue Sep 18, 2015
Merged
@nalla
Copy link

nalla commented Sep 18, 2015

OT: @dscho is it fate that issue #404 is html-hyperlink related?

@dscho
Copy link
Member

dscho commented Sep 18, 2015

@nalla it is part of the Greater Scheme of the Universe, for sure!

jeffhostetler pushed a commit to jeffhostetler/git that referenced this issue Aug 18, 2021
@derrickstolee
Merge pull request git-for-windows#404: Make 'ort' the default merge …
8c587d7 
…strategy

The 'ort' strategy is a new algorithm to replace the 'recursive' merge strategy. I've been reviewing some of the performance patches upstream, many of which are already in Git 2.32.0 (more coming in 2.33.0) and even with the ones already included, it is a clear performance win for our large repos.

I tested on the Office monorepo and consistently saw merge times in the 5-6 second range. With the 'recursive' strategy, these would range from 7-20 seconds. My tests reproduced merges found within the commit history, and the ones that succeeded without conflicts matched the committed changes. There were even a few where the 'recursive' strategy did not resolve to the committed change, but the 'ort' version did (probably because of better rename detection).

Not only is this a beneficial performance change for our users across `microsoft/git`, it will be a critical step to allowing `git merge` to work quickly with sparse index. In my testing of a prototype, I was able to get `git merge` commands with sparse index and the 'ort' strategy down to 0.5-1.5 seconds in most cases. (Cases with a merge conflict outside of the sparse-checkout definition jumped back up to the 6-7 second range, which is expected, and should be rare.)

cc: @newren for awareness. Thanks for the patches! These were applied from those sent to the list via git#1055.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nalla nalla

Labels
bug git
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

git: fix asciidoctor invocation
3 participants
@snaewe @dscho @nalla