* [PATCH 3/4] rev-list-options.txt: do not nest open blocks
From: Martin Ågren @ 2018-12-15 11:27 UTC (permalink / raw)
To: git
In-Reply-To: <20181215112742.1475882-1-martin.agren@gmail.com>
Similar to the previous commit, it appears we try to nest open blocks,
which does not work well with Asciidoctor. Drop the outer one. That
fixes the indentation similar to the previous patch, and makes us stop
rendering a literal '+' before "Under --pretty=oneline ...". Asciidoc
renders identically before and after this patch, both man-page and html.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
See https://git-scm.com/docs/git-log#git-log--g and
https://git-scm.com/docs/git-rev-list#git-rev-list--g . The indentation
doesn't look too bad, but the "+ Under" is clearly wrong.
Documentation/rev-list-options.txt | 4 ----
1 file changed, 4 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index bab5f50b17..98b538bc77 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -13,8 +13,6 @@ has a line that matches `<pattern>`), unless otherwise noted.
Note that these are applied before commit
ordering and formatting options, such as `--reverse`.
---
-
-<number>::
-n <number>::
--max-count=<number>::
@@ -308,8 +306,6 @@ ifdef::git-rev-list[]
`<header>` text will be printed with each progress update.
endif::git-rev-list[]
---
-
History Simplification
~~~~~~~~~~~~~~~~~~~~~~
--
2.20.1
^ permalink raw reply related
* [PATCH 4/4] git-status.txt: render tables correctly under Asciidoctor
From: Martin Ågren @ 2018-12-15 11:27 UTC (permalink / raw)
To: git
In-Reply-To: <20181215112742.1475882-1-martin.agren@gmail.com>
Asciidoctor removes the indentation of each line in these tables, so the
last lines of each table have a completely broken alignment.
Similar to 379805051d ("Documentation: render revisions correctly under
Asciidoctor", 2018-05-06), use an explicit literal block to indicate
that we want to keep the leading whitespace in the tables.
Because this gives us some extra indentation, we can remove the one that
we have been carrying explicitly. That is, drop the first four spaces of
indentation on each line. With Asciidoc (8.6.10), this results in
identical rendering before and after this commit, both for git-status.1
and git-status.html.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
See https://git-scm.com/docs/git-status#_short_format ,
https://git-scm.com/docs/git-status#_branch_headers and
https://git-scm.com/docs/git-status#_changed_tracked_entries .
Documentation/git-status.txt | 162 ++++++++++++++++++-----------------
1 file changed, 85 insertions(+), 77 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index d9f422d560..861d821d7f 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -197,31 +197,33 @@ codes can be interpreted as follows:
Ignored files are not listed, unless `--ignored` option is in effect,
in which case `XY` are `!!`.
- X Y Meaning
- -------------------------------------------------
- [AMD] not updated
- M [ MD] updated in index
- A [ MD] added to index
- D deleted from index
- R [ MD] renamed in index
- C [ MD] copied in index
- [MARC] index and work tree matches
- [ MARC] M work tree changed since index
- [ MARC] D deleted in work tree
- [ D] R renamed in work tree
- [ D] C copied in work tree
- -------------------------------------------------
- D D unmerged, both deleted
- A U unmerged, added by us
- U D unmerged, deleted by them
- U A unmerged, added by them
- D U unmerged, deleted by us
- A A unmerged, both added
- U U unmerged, both modified
- -------------------------------------------------
- ? ? untracked
- ! ! ignored
- -------------------------------------------------
+....
+X Y Meaning
+-------------------------------------------------
+ [AMD] not updated
+M [ MD] updated in index
+A [ MD] added to index
+D deleted from index
+R [ MD] renamed in index
+C [ MD] copied in index
+[MARC] index and work tree matches
+[ MARC] M work tree changed since index
+[ MARC] D deleted in work tree
+[ D] R renamed in work tree
+[ D] C copied in work tree
+-------------------------------------------------
+D D unmerged, both deleted
+A U unmerged, added by us
+U D unmerged, deleted by them
+U A unmerged, added by them
+D U unmerged, deleted by us
+A A unmerged, both added
+U U unmerged, both modified
+-------------------------------------------------
+? ? untracked
+! ! ignored
+-------------------------------------------------
+....
Submodules have more state and instead report
M the submodule has a different HEAD than
@@ -281,14 +283,16 @@ don't recognize.
If `--branch` is given, a series of header lines are printed with
information about the current branch.
- Line Notes
- ------------------------------------------------------------
- # branch.oid <commit> | (initial) Current commit.
- # branch.head <branch> | (detached) Current branch.
- # branch.upstream <upstream_branch> If upstream is set.
- # branch.ab +<ahead> -<behind> If upstream is set and
- the commit is present.
- ------------------------------------------------------------
+....
+Line Notes
+------------------------------------------------------------
+# branch.oid <commit> | (initial) Current commit.
+# branch.head <branch> | (detached) Current branch.
+# branch.upstream <upstream_branch> If upstream is set.
+# branch.ab +<ahead> -<behind> If upstream is set and
+ the commit is present.
+------------------------------------------------------------
+....
### Changed Tracked Entries
@@ -306,56 +310,60 @@ Renamed or copied entries have the following format:
2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
- Field Meaning
- --------------------------------------------------------
- <XY> A 2 character field containing the staged and
- unstaged XY values described in the short format,
- with unchanged indicated by a "." rather than
- a space.
- <sub> A 4 character field describing the submodule state.
- "N..." when the entry is not a submodule.
- "S<c><m><u>" when the entry is a submodule.
- <c> is "C" if the commit changed; otherwise ".".
- <m> is "M" if it has tracked changes; otherwise ".".
- <u> is "U" if there are untracked changes; otherwise ".".
- <mH> The octal file mode in HEAD.
- <mI> The octal file mode in the index.
- <mW> The octal file mode in the worktree.
- <hH> The object name in HEAD.
- <hI> The object name in the index.
- <X><score> The rename or copy score (denoting the percentage
- of similarity between the source and target of the
- move or copy). For example "R100" or "C75".
- <path> The pathname. In a renamed/copied entry, this
- is the target path.
- <sep> When the `-z` option is used, the 2 pathnames are separated
- with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
- byte separates them.
- <origPath> The pathname in the commit at HEAD or in the index.
- This is only present in a renamed/copied entry, and
- tells where the renamed/copied contents came from.
- --------------------------------------------------------
+....
+Field Meaning
+--------------------------------------------------------
+<XY> A 2 character field containing the staged and
+ unstaged XY values described in the short format,
+ with unchanged indicated by a "." rather than
+ a space.
+<sub> A 4 character field describing the submodule state.
+ "N..." when the entry is not a submodule.
+ "S<c><m><u>" when the entry is a submodule.
+ <c> is "C" if the commit changed; otherwise ".".
+ <m> is "M" if it has tracked changes; otherwise ".".
+ <u> is "U" if there are untracked changes; otherwise ".".
+<mH> The octal file mode in HEAD.
+<mI> The octal file mode in the index.
+<mW> The octal file mode in the worktree.
+<hH> The object name in HEAD.
+<hI> The object name in the index.
+<X><score> The rename or copy score (denoting the percentage
+ of similarity between the source and target of the
+ move or copy). For example "R100" or "C75".
+<path> The pathname. In a renamed/copied entry, this
+ is the target path.
+<sep> When the `-z` option is used, the 2 pathnames are separated
+ with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
+ byte separates them.
+<origPath> The pathname in the commit at HEAD or in the index.
+ This is only present in a renamed/copied entry, and
+ tells where the renamed/copied contents came from.
+--------------------------------------------------------
+....
Unmerged entries have the following format; the first character is
a "u" to distinguish from ordinary changed entries.
u <xy> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
- Field Meaning
- --------------------------------------------------------
- <XY> A 2 character field describing the conflict type
- as described in the short format.
- <sub> A 4 character field describing the submodule state
- as described above.
- <m1> The octal file mode in stage 1.
- <m2> The octal file mode in stage 2.
- <m3> The octal file mode in stage 3.
- <mW> The octal file mode in the worktree.
- <h1> The object name in stage 1.
- <h2> The object name in stage 2.
- <h3> The object name in stage 3.
- <path> The pathname.
- --------------------------------------------------------
+....
+Field Meaning
+--------------------------------------------------------
+<XY> A 2 character field describing the conflict type
+ as described in the short format.
+<sub> A 4 character field describing the submodule state
+ as described above.
+<m1> The octal file mode in stage 1.
+<m2> The octal file mode in stage 2.
+<m3> The octal file mode in stage 3.
+<mW> The octal file mode in the worktree.
+<h1> The object name in stage 1.
+<h2> The object name in stage 2.
+<h3> The object name in stage 3.
+<path> The pathname.
+--------------------------------------------------------
+....
### Other Items
--
2.20.1
^ permalink raw reply related
* Re: Bug in git-remote
From: SZEDER Gábor @ 2018-12-15 13:02 UTC (permalink / raw)
To: Gennady Uraltsev; +Cc: git
In-Reply-To: <650b15f4-5e13-7a83-9f2e-072efc4815e4@gmail.com>
On Sat, Dec 15, 2018 at 02:14:56AM -0500, Gennady Uraltsev wrote:
> I am on git version 2.20.0
>
> $ git remote
>
> does not show remotes configured in named files in $GIT_DIR/remotes/
>
> I do not think that this is the intended behavior.
It's a known bug. When 'git remote' was rewritten as a builtin
command in C in commit 211c89682e (Make git-remote a builtin,
2008-02-29) the parts dealing with remotes under 'GIT_DIR/remotes/'
were not rewritten. I don't know whether that was intended or not,
but storing remote information as configuration was about two years
old back then. Given that since then '$GIT_DIR/remotes/' got marked
as "This mechanism is legacy and not likely to be found in modern
repositories", I'm not sure it's worth fixing. Perhaps it's time for
calling it deprecated.
> In particular:
>
> $ git init --bare test.git
> Initialized empty Git repository in /home/guraltsev/admin/test/git/test.git/
>
> $ cd test.git
>
> $ mkdir -p remotes
> mkdir: created directory 'remotes'
>
> $ echo -e "URL: /testremote.git \n Push: *:* \n Pull:
> refs/heads/*:refs/remotes/testremote/* " > remotes/testremote
>
> $ git remote
>
> $ git remote show testremote
> fatal: '/testremote.git' does not appear to be a git repository
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
>
>
> The second to last command should show testremote as a remote.
>
>
> Best,
>
> Gennady
>
^ permalink raw reply
* [ANNOUNCE] Git for Windows 2.20.1
From: Johannes Schindelin @ 2018-12-15 16:59 UTC (permalink / raw)
To: git-for-windows, git, git-packagers
Dear Git users,
It is my pleasure to announce that Git for Windows 2.20.1 is available from:
https://gitforwindows.org/
Changes since Git for Windows v2.20.0 (December 10th 2018)
New Features
* Comes with Git v2.20.1.
* Comes with cURL v7.63.0.
Bug Fixes
* Fixes a speed regression in the built-in rebase.
Filename | SHA-256
-------- | -------
Git-2.20.1-64-bit.exe | 0dce453188d4aed938e3fd1919393a3600dd3dfe100f3fc92f54f80e372e031f
Git-2.20.1-32-bit.exe | f9ee8d72bed562e01e41ca335f4d1db6ec1b3ac5ffe4494bf8bce0a38bb527bd
PortableGit-2.20.1-64-bit.7z.exe | 4c0fc0c77d577f8dbb3d7711283458ba1d0ce1781cfe0d49c940abbcdf18faa0
PortableGit-2.20.1-32-bit.7z.exe | 64e9b5cfb9b6381f9791225287d80a3705341ca93e7483af9ded54bfff731dbe
MinGit-2.20.1-64-bit.zip | 02328f37eeefe8d8f5396553ac8f91c98d09e533d49d93c617a4643915a76552
MinGit-2.20.1-32-bit.zip | a51b66795c45e3cd1a6041fa6bcc606175870bb2c777f4cfc3dc12c7973ae634
MinGit-2.20.1-busybox-64-bit.zip | 9817ab455d9cbd0b09d8664b4afbe4bbf78d18b556b3541d09238501a749486c
MinGit-2.20.1-busybox-32-bit.zip | da0c03e3b6e77004efafd7c244dc62e92b4f78642d83234b0c62367c6ab2ad95
Git-2.20.1-64-bit.tar.bz2 | 8a35be30f2a5de01b173d81de6355bff9090cc069e265f7e996116acbf21fd78
Git-2.20.1-32-bit.tar.bz2 | 3bace612f3e0c8fd0a470bc4f0a7af88b3fcf051550102b399997e75eb1d887e
pdbs-for-git-64-bit-2.20.1.1.7c9fbc07db-1.zip | 6f0178fcf26a6eaaf9a0d2aea3504e828d3b92735967bacefe9bc743608a9471
pdbs-for-git-32-bit-2.20.1.1.7c9fbc07db-1.zip | e1f601c22e3e7142b96d468ff949db741d38200ca77d0d27e4e0b839261f0cd6
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH] doc: improve grammar in git-update-index
From: Philip Oakley @ 2018-12-15 17:06 UTC (permalink / raw)
To: Anthony Sottile, git, Philip Oakley
In-Reply-To: <20181214212504.3164-1-asottile@umich.edu>
On 14/12/2018 21:25, Anthony Sottile wrote:
> Signed-off-by: Anthony Sottile <asottile@umich.edu>
> ---
> Documentation/git-update-index.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
> index 1c4d146a4..9c03ca167 100644
> --- a/Documentation/git-update-index.txt
> +++ b/Documentation/git-update-index.txt
> @@ -326,7 +326,7 @@ inefficient `lstat(2)`. If your filesystem is one of them, you
> can set "assume unchanged" bit to paths you have not changed to
> cause Git not to do this check. Note that setting this bit on a
> path does not mean Git will check the contents of the file to
> -see if it has changed -- it makes Git to omit any checking and
> +see if it has changed -- it means Git will skip any checking and
> assume it has *not* changed. When you make changes to working
> tree files, you have to explicitly tell Git about it by dropping
> "assume unchanged" bit, either before or after you modify them.
Doesn't this also need the caveat that it is _a promise by the user_
that they will not change the file, such that Git doesn't need to keep
checking, and that occasionally Git will check, or may perform
unexpected actions if the user has the wrong mental model.
--
Philip
^ permalink raw reply
* Re: [PATCH 0/3] protocol v2 and hidden refs
From: Ævar Arnfjörð Bjarmason @ 2018-12-15 19:53 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Tan, git, bwilliamseng
In-Reply-To: <20181214083507.GB11777@sigill.intra.peff.net>
On Fri, Dec 14 2018, Jeff King wrote:
> On Thu, Dec 13, 2018 at 11:53:05AM -0800, Jonathan Tan wrote:
>
>> > I don't know if there's a good solution. I tried running the whole
>> > test suite with v2 as the default. It does find this bug, but it has
>> > a bunch of other problems (notably fetch-pack won't run as v2, but
>> > some other tests I think also depend on v0's reachability rules,
>> > which v2 is documented not to enforce).
>>
>> I think Aevar's patches (sent after you wrote this) is a good start, and
>> I have started looking at it too.
>
> Yeah, I'm excited to see it working with fetch-pack, as the current
> behavior is to complain if you've tried to enable v2 config:
>
> $ git config protocol.version 2
> $ git fetch-pack git://github.com/git/git
> fatal: support for protocol v2 not implemented yet
>
> I haven't actually run into it in the real world, but somebody might if
> they have scripted around fetch-pack and are experimenting with v2. A
> much friendlier behavior would be falling back to v1, but actually
> supporting v2 is better still. :)
>
>> > - The "serve" command is funky, because it has no concept of whether
>> > the "ls-refs" is for fetching or pushing. Is git-serve even a thing
>> > that we want to support going forward? I know part of the original
>> > v2 conception was that one would be able to just connect to
>> > "git-serve" and do a number of operations. But in practice the v2
>> > probing requires saying "I'd like to git-upload-pack, and v2 if you
>> > please". So no client ever calls git-serve.
>> >
>> > Is this something we plan to eventually move to? Or can it be
>> > considered a funny vestige of the development? In the latter case, I
>> > think we should consider removing it.
>>
>> Personally, I lean towards removing it, but there are arguments on both
>> sides. In particular, removing "serve" means that both developers and
>> users of Git need not be concerned with a 3rd endpoint, but preserving
>> "serve" (and planning to migrate away from "upload-pack" and
>> "receive-pack") means that we will only have one endpoint, eliminating
>> confusion about which endpoint to use when making certain requests (when
>> we add requests other than "fetch" and "push").
>
> Yeah, at first glance I like the simplicity of a unified model. But the
> separate fetch/push endpoints have been useful in the past. Separate
> uploadpack/receive.hiderefs that I dealt with here are one form. Another
> is that many people do HTTP access control using the endpoints. For
> example, if I have a repo which is public-read and private-write, the
> config we recommend in git-http-backend(1) is to lock down the
> receive-pack access using webserver config.
>
> If all the webserver sees is "somebody wants to connect to git-serve",
> it doesn't know if it should be challenging them for authentication or
> not. It would have to start peeking into the git-serve conversation to
> see what the client actually wants to do. That's _possible_ to do, but
> it gets pretty awkward with existing webserver tools (whereas matching
> the URI endpoint is pretty easy).
>
> Ditto for locked down ssh sessions like git-shell (or custom solutions
> like gitolite). Right now we can "git-upload-pack is OK on this repo,
> git-receive-pack is not". But blindly running "git serve" would be
> dangerous. In this case I think we have a few more options, because the
> user has always already authenticated. So we can just tell "git serve"
> via the environment whether the user is authorized for push. It's harder
> with HTTP because most setups avoid even challenging for auth unless
> it's necessary.
>
> So I'm a bit worried that the unified endpoint model is going to be a
> dead end, at which point carrying around git-serve just makes things
> more complicated.
This is from wetware memory of something discussed at a previous Git
Merge, so I may have (inadvertently) made it up, but wasn't part of the
idea of "git-serve" to have an extensible next-gen protocol where we
could add new actions & verbs unrelated to sending or receiving packs?
E.g. client<->server optimistic cooperation like offloading a
long-running "git-grep", "git log -G" etc. to a more powerful workhorse
server, which would use "git-serve" as a routing layer.
Of course that's not in itself an argument for having a general "serve"
command, actually the opposite for the reasons you mention with locking
down things. E.g. maybe I want to support server-side git-grep on my
server, but not git-log, and if it's one command it becomes a hassle to
do that via SSH config or HTTPD config for the reasons you mention.
The upside would be that once a host understands "git serve" I'm more
likely to be able to get past whatever middle layer there is between my
client and the "git" binary on the other side. E.g. if I have a newly
compiled "git" client/server binary, but something like GitLab's
"gitaly" sitting between the two of us.
^ permalink raw reply
* Re: Bug in lineendings handling that prevents resetting checking out, rebasing etc
From: Mr&Mrs D @ 2018-12-15 20:58 UTC (permalink / raw)
To: tboegi; +Cc: git
In-Reply-To: <20181215044345.GA19192@tor.lan>
Thanks again!
Whichever path I take all the intermediate commits between the fix
commit and the one that added the gitattributes file (so marked that
file as text) will be plagued by this - checking them out on linux or
macos will show that particular file as modified. Is my understanding
correct?
It still seems to me that at least the operating system should not
matter here - I did not encounter this on windows and when I did (as
described in the SO post) `git rm -r . --cached -q && git reset
--hard` would reset the branch.
Is there a way I can add this file to local .git/info/attributes so
that I overwrite the .gitattributes (see
https://stackoverflow.com/a/33715791/281545 ) ?
I tried adding the line:
$ cat .git/info/attributes
Mopy/Docs/Bash Readme Template.html -text
but does nothing. The idea would be to add the commit fixing the line
endings on the stable branch and also instruct collaborators to edit
their .git/info/attributes files so when checking out older commits
the file does not show as changed.
Speaking of line endings fix issuing:
(dev) $ git add --renormalize .
(dev) $ git status
On branch dev
Your branch is up to date with 'origin/dev'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: Mopy/Docs/Bash Readme Template.html
modified: Mopy/Docs/Bash Readme Template.txt
modified: Mopy/bash/db/Oblivion_ids.pkl
modified: Mopy/bash/db/Skyrim_ids.pkl
Untracked files:
...
adds 4 files as seen (?)
Thanks again and sorry for the late reply
On Fri, Dec 14, 2018 at 11:43 PM Torsten Bögershausen <tboegi@web.de> wrote:
>
> On Fri, Dec 14, 2018 at 04:51:54PM -0500, Mr&Mrs D wrote:
> > Thanks for looking to it - git attributes was added in
> > 4b0863a8b834c5804fd3a568ed56ff85b27acdeb
> >
> > The file in question was added in 17ca75f0a8c25f321f2b63bc3b9c065ff91adc23
> >
> > So you mean to say that because a gitattributes was added after the
> > fact this resulted in an illegal state?
> >
> > But _shouldn't git reset --hard work anyway?_ That's the buggy part.
>
> Yes and no.
> If I look at the dev branch:
> commit 02ae6f264f340137b8b41ba6953e2a4f962c222e (HEAD, origin/dev, origin/HEAD, dev)
>
> Now we can ask Git, why a file is modified:
>
> git ls-files --eol | grep "Mopy/Docs/Bash eadme Template.html"
> i/crlf w/crlf attr/text Mopy/Docs/Bash Readme Template.html
>
> Now we have 2 conflicting "messages" to Git:
> a) "Mopy/Docs/Bash Readme Template.html" has the attribute "text"
> b) "Mopy/Docs/Bash Readme Template.html" has been commited with CRLF.
>
> Git itself can not resolve this conflict.
> Either you normalize the repo (in this case only 1 file), other commits have 4 files
> that needs to be normalized.
> Or you change the attribute into "text=auto".
>
> That decision is up to the user.
>
> >
> > As for fixing it - not sure what is the best course of action here.
> > probably issuing `git add --renormalize .` and committing that to the
> > stable (dev) branch will fix this for future checkouts/rebases but
> > IIUC won't do nothing for older commits - so checking out a commit
> > before the fix one, ghit will see this file as changed and then
> > completely refuse to go back to another branch
> >
> > This seems a bug - as illegal as the state of the file is, shouldn't
> > git reset always work?
> >
> > Thanks! (will be out for a bit but really looking forward to your replies)
> > On Fri, Dec 14, 2018 at 4:32 PM Torsten Bögershausen <tboegi@web.de> wrote:
> > >
> > > On Fri, Dec 14, 2018 at 04:04:15PM -0500, Mr&Mrs D wrote:
> > > > Hi all,
> > > >
> > > > I maintain a python project you can clone from:
> > > >
> > > > git@github.com:wrye-bash/wrye-bash.git
> > > >
> > > > For reasons unknown git sees a particular file as changed
> > > > (Mopy/Docs/Bash Readme Template.html, sometimes others too). This file
> > > > was probably committed to the svn repository this git repo was created
> > > > from with CRLF line endings. When we moved to git we added a
> > > > gitattributes file (
> > > > https://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and
> > > > this file was edited to explicitly state htms are text - all to no
> > > > avail. From time to time - on windows - as in when checking out an old
> > > > commit - git would see that file as changed. The only workaround that
> > > > worked for me was
> > > >
> > > > git rm -r . --cached -q && git reset --hard
> > > >
> > > > For more details and discussion see this SO question I posted almost
> > > > five years ago:
> > > >
> > > > https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en
> > > >
> > > > I used to work in windows and the bug was tolerable as there was that
> > > > workaround. Now I moved to mac and no workaround works anymore - we
> > > > have a special page on our wiki with workarounds for this one btw:
> > > >
> > > > https://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc
> > > >
> > > > Well after 5 years and countless hours trying to solve this I reach
> > > > out to you guys and girls - _this is a full-time bug in git line
> > > > endings handling_. When someone issues a git reset --hard this should
> > > > work no matter what - well it does not. So this bug may be really a
> > > > can of worms.
> > > >
> > > > Please someone clone this repo on linux or mac - probably just cloning
> > > > will have the files appear as changed (by the way hitting refresh on
> > > > git gui I have different sets of files appear as changed). If not then
> > > >
> > > > git checkout utumno-wip
> > > Thet commit is -excuse me if that sounds too harsh- is messed up.
> > > git status says
> > > modified: Mopy/Docs/Bash Readme Template.html
> > >
> > > And if I dig into the EOL stuff, I run
> > > git ls-files --eol | grep Readme | less
> > >
> > > And find a contradiction here:
> > > i/crlf w/crlf attr/text Mopy/Docs/Bash Readme Template.html
> > >
> > > The attributes say "text" and the file has CRLF "in the repo",
> > > (techically speaking in the index) and that is an "illegal" condition
> > > in the repo, and not a bug in Git.
> > > I didn't try the rebase as such, sice the first problem needs
> > > to be fixed, before we try to move on.
> > >
> > > So, the old commits are problematic/illegal and they are as they are.
> > > Such a commit can not be fixed, whenever somebody checks it out,
> > > there will be a problem (or two, or none, depending on the timing,
> > > the file system...)
> > >
> > > We can not fix commits like b1acc012878c9fdd8b4ad610ce7eae0dcbcbcab0.
> > > We can make new commits, and fix them.
> > >
> > > We can fix one branch, and other branches, and merge them together.
> > > But rebase seems to be problamatic, at least to me.
> > > What exactly do you want to do?
> > >
> > > Can we agree to do a merge of 2 branches?
> > > Then I can possibly help you out.
> > >
> > >
> > >
> > >
> > >
> > > > git rebase -i dev
> > > >
> > > > and then select a commit to edit should be enough to trigger this bug
> > > >
> > > > Needless to say I am well aware of things like `git add --renormalize
> > > > .` - but renormalizing is not the issue. The issue is that _files show
> > > > as changed and even a git reset --hard won't convince git that
> > > > nothing's changed_.
> > > >
> > > > $ git reset --hard
> > > > HEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:
> > > > $ git status
> > > > interactive rebase in progress; onto 02ae6f26
> > > > Last commands done (4 commands done):
> > > > pick 3a39a0c0 Monkey patch for undecodable inis:
> > > > pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:
> > > > (see more in file .git/rebase-merge/done)
> > > > Next commands to do (19 remaining commands):
> > > > edit a3a7b237 Amend last commit and linefixes: ΕΕΕΕ
> > > > edit 432fd314 fFF handle empty or malformed inis
> > > > (use "git rebase --edit-todo" to view and edit)
> > > > You are currently editing a commit while rebasing branch 'utumno-wip'
> > > > on '02ae6f26'.
> > > > (use "git commit --amend" to amend the current commit)
> > > > (use "git rebase --continue" once you are satisfied with your changes)
> > > >
> > > > Changes not staged for commit:
> > > > (use "git add <file>..." to update what will be committed)
> > > > (use "git checkout -- <file>..." to discard changes in working directory)
> > > >
> > > > modified: Mopy/Docs/Bash Readme Template.html
> > > >
> > > > Untracked files:
> > > > (use "git add <file>..." to include in what will be committed)
> > > >
> > > > .DS_Store
> > > > .idea.7z
> > > >
> > > > no changes added to commit (use "git add" and/or "git commit -a")
> > > > $
> > > >
> > > > I really hope someone here can debug this
> > > > Thanks!
^ permalink raw reply
* [PATCH 0/1] gc/repack: release packs when needed
From: Johannes Schindelin via GitGitGadget @ 2018-12-15 22:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This fixes more "can't delete files while they are still open" issues on
Windows.
Johannes Schindelin (1):
gc/repack: release packs when needed
builtin/gc.c | 4 +++-
builtin/repack.c | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
base-commit: 5d826e972970a784bd7a7bdf587512510097b8c7
Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-95%2Fdscho%2Frelease-gc-repack-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-95/dscho/release-gc-repack-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/95
--
gitgitgadget
^ permalink raw reply
* [PATCH 1/1] gc/repack: release packs when needed
From: Johannes Schindelin via GitGitGadget @ 2018-12-15 22:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <pull.95.git.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still
handles held by a process. To remedy that, we introduced the
close_all_packs() function.
Earlier, we made sure that the packs are released just before `git gc`
is spawned, in case that gc wants to remove no-longer needed packs.
But this developer forgot that gc itself also needs to let go of packs,
e.g. when consolidating all packs via the --aggressive option.
Likewise, `git repack -d` wants to delete obsolete packs and therefore
needs to close all pack handles, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin/gc.c | 4 +++-
builtin/repack.c | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 871a56f1c5..df90fd7f51 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -659,8 +659,10 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
report_garbage = report_pack_garbage;
reprepare_packed_git(the_repository);
- if (pack_garbage.nr > 0)
+ if (pack_garbage.nr > 0) {
+ close_all_packs(the_repository->objects);
clean_pack_garbage();
+ }
if (gc_write_commit_graph)
write_commit_graph_reachable(get_object_directory(), 0,
diff --git a/builtin/repack.c b/builtin/repack.c
index 45583683ee..f9319defe4 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -419,6 +419,8 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
if (!names.nr && !po_args.quiet)
printf("Nothing new to pack.\n");
+ close_all_packs(the_repository->objects);
+
/*
* Ok we have prepared all new packfiles.
* First see if there are packs of the same name and if so
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] doc: improve grammar in git-update-index
From: Anthony Sottile @ 2018-12-16 0:21 UTC (permalink / raw)
To: philipoakley; +Cc: Git Mailing List
In-Reply-To: <bfe22381-864a-4a6b-8dd9-78e268e52c36@iee.org>
On Sat, Dec 15, 2018 at 9:18 AM Philip Oakley <philipoakley@iee.org> wrote:
>
> On 14/12/2018 21:25, Anthony Sottile wrote:
> > Signed-off-by: Anthony Sottile <asottile@umich.edu>
> > ---
> > Documentation/git-update-index.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
> > index 1c4d146a4..9c03ca167 100644
> > --- a/Documentation/git-update-index.txt
> > +++ b/Documentation/git-update-index.txt
> > @@ -326,7 +326,7 @@ inefficient `lstat(2)`. If your filesystem is one of them, you
> > can set "assume unchanged" bit to paths you have not changed to
> > cause Git not to do this check. Note that setting this bit on a
> > path does not mean Git will check the contents of the file to
> > -see if it has changed -- it makes Git to omit any checking and
> > +see if it has changed -- it means Git will skip any checking and
> > assume it has *not* changed. When you make changes to working
> > tree files, you have to explicitly tell Git about it by dropping
> > "assume unchanged" bit, either before or after you modify them.
>
> Doesn't this also need the caveat that it is _a promise by the user_
> that they will not change the file, such that Git doesn't need to keep
> checking, and that occasionally Git will check, or may perform
> unexpected actions if the user has the wrong mental model.
>
> --
>
> Philip
>
>
yep, the rest of the documentation in this file explains that in
detail -- I'm just fixing up a sentence that doesn't read well :)
^ permalink raw reply
* Re: [PATCH] Simplify handling of setup_git_directory_gently() failure cases.
From: Erin Dahlgren @ 2018-12-16 1:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <nycvar.QRO.7.76.6.1812141130180.43@tvgsbejvaqbjf.bet>
On Fri, Dec 14, 2018 at 2:32 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Erin,
>
> On Thu, 13 Dec 2018, Erin Dahlgren wrote:
>
> > setup_git_directory_gently() expects two types of failures to
> > discover a git directory (e.g. .git/):
> >
> > - GIT_DIR_HIT_CEILING: could not find a git directory in any
> > parent directories of the cwd.
> > - GIT_DIR_HIT_MOUNT_POINT: could not find a git directory in
> > any parent directories up to the mount point of the cwd.
> >
> > Both cases are handled in a similar way, but there are misleading
> > and unimportant differences. In both cases, setup_git_directory_gently()
> > should:
> >
> > - Die if we are not in a git repository. Otherwise:
> > - Set nongit_ok = 1, indicating that we are not in a git repository
> > but this is ok.
> > - Call strbuf_release() on any non-static struct strbufs that we
> > allocated.
> >
> > Before this change are two misleading additional behaviors:
> >
> > - GIT_DIR_HIT_CEILING: setup_nongit() changes to the cwd for no
> > apparent reason. We never had the chance to change directories
> > up to this point so chdir(current cwd) is pointless.
> > - GIT_DIR_HIT_MOUNT_POINT: strbuf_release() frees the buffer
> > of a static struct strbuf (cwd). This is unnecessary because the
> > struct is static so its buffer is always reachable. This is also
> > misleading because nowhere else in the function is this buffer
> > released.
> >
> > This change eliminates these two misleading additional behaviors and
> > deletes setup_nogit() because the code is clearer without it. The
> > result is that we can see clearly that GIT_DIR_HIT_CEILING and
> > GIT_DIR_HIT_MOUNT_POINT lead to the same behavior (ignoring the
> > different help messages).
> >
> > Thanks-to: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Signed-off-by: Erin Dahlgren <eedahlgren@gmail.com>
>
> Thank you for working on this!
>
> > ---
> > setup.c | 34 +++++++++++++---------------------
> > 1 file changed, 13 insertions(+), 21 deletions(-)
>
> Nice! It's always good to see a code reduction with such a cleanup.
>
> Just one thing:
>
> > diff --git a/setup.c b/setup.c
> > index 1be5037..b441e39 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -831,16 +831,6 @@ static const char *setup_bare_git_dir(struct strbuf *cwd, int offset,
> > return NULL;
> > }
> >
> > -static const char *setup_nongit(const char *cwd, int *nongit_ok)
> > -{
> > - if (!nongit_ok)
> > - die(_("not a git repository (or any of the parent directories): %s"), DEFAULT_GIT_DIR_ENVIRONMENT);
> > - if (chdir(cwd))
> > - die_errno(_("cannot come back to cwd"));
> > - *nongit_ok = 1;
> > - return NULL;
> > -}
> > -
> > static dev_t get_device_or_die(const char *path, const char *prefix, int prefix_len)
> > {
> > struct stat buf;
> > @@ -1097,18 +1087,20 @@ const char *setup_git_directory_gently(int *nongit_ok)
> > prefix = setup_bare_git_dir(&cwd, dir.len, &repo_fmt, nongit_ok);
> > break;
> > case GIT_DIR_HIT_CEILING:
> > - prefix = setup_nongit(cwd.buf, nongit_ok);
> > - break;
> > + if (!nongit_ok)
> > + die(_("not a git repository (or any of the parent directories): %s"),
> > + DEFAULT_GIT_DIR_ENVIRONMENT);
> > + *nongit_ok = 1;
> > + strbuf_release(&dir);
> > + return NULL;
> > case GIT_DIR_HIT_MOUNT_POINT:
> > - if (nongit_ok) {
> > - *nongit_ok = 1;
> > - strbuf_release(&cwd);
> > - strbuf_release(&dir);
> > - return NULL;
> > - }
> > - die(_("not a git repository (or any parent up to mount point %s)\n"
> > - "Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)."),
> > - dir.buf);
> > + if (!nongit_ok)
> > + die(_("not a git repository (or any parent up to mount point %s)\n"
> > + "Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)."),
> > + dir.buf);
>
> This indentation would probably be better aligned with the first
> double-quote on the `die` line.
Hi Johannes,
No problem. Thanks for your time discussing and reviewing!
- Erin
>
> Otherwise: ACK!
>
> Thank you,
> Johannes
>
> > + *nongit_ok = 1;
> > + strbuf_release(&dir);
> > + return NULL;
> > default:
> > BUG("unhandled setup_git_directory_1() result");
> > }
> > --
> > 2.7.4
> >
> >
^ permalink raw reply
* [PATCH v2] Simplify handling of setup_git_directory_gently() failure cases.
From: Erin Dahlgren @ 2018-12-16 1:05 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano, Erin Dahlgren
In-Reply-To: <1544722211-13370-1-git-send-email-eedahlgren@gmail.com>
setup_git_directory_gently() expects two types of failures to
discover a git directory (e.g. .git/):
- GIT_DIR_HIT_CEILING: could not find a git directory in any
parent directories of the cwd.
- GIT_DIR_HIT_MOUNT_POINT: could not find a git directory in
any parent directories up to the mount point of the cwd.
Both cases are handled in a similar way, but there are misleading
and unimportant differences. In both cases, setup_git_directory_gently()
should:
- Die if we are not in a git repository. Otherwise:
- Set nongit_ok = 1, indicating that we are not in a git repository
but this is ok.
- Call strbuf_release() on any non-static struct strbufs that we
allocated.
Before this change are two misleading additional behaviors:
- GIT_DIR_HIT_CEILING: setup_nongit() changes to the cwd for no
apparent reason. We never had the chance to change directories
up to this point so chdir(current cwd) is pointless.
- GIT_DIR_HIT_MOUNT_POINT: strbuf_release() frees the buffer
of a static struct strbuf (cwd). This is unnecessary because the
struct is static so its buffer is always reachable. This is also
misleading because nowhere else in the function is this buffer
released.
This change eliminates these two misleading additional behaviors and
deletes setup_nogit() because the code is clearer without it. The
result is that we can see clearly that GIT_DIR_HIT_CEILING and
GIT_DIR_HIT_MOUNT_POINT lead to the same behavior (ignoring the
different help messages).
---
Changes in v2:
- Aligned indentation of second line of die message for case
GIT_DIR_HIT_MOUNT_POINT.
setup.c | 34 +++++++++++++---------------------
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/setup.c b/setup.c
index 1be5037..e1a9e17 100644
--- a/setup.c
+++ b/setup.c
@@ -831,16 +831,6 @@ static const char *setup_bare_git_dir(struct strbuf *cwd, int offset,
return NULL;
}
-static const char *setup_nongit(const char *cwd, int *nongit_ok)
-{
- if (!nongit_ok)
- die(_("not a git repository (or any of the parent directories): %s"), DEFAULT_GIT_DIR_ENVIRONMENT);
- if (chdir(cwd))
- die_errno(_("cannot come back to cwd"));
- *nongit_ok = 1;
- return NULL;
-}
-
static dev_t get_device_or_die(const char *path, const char *prefix, int prefix_len)
{
struct stat buf;
@@ -1097,18 +1087,20 @@ const char *setup_git_directory_gently(int *nongit_ok)
prefix = setup_bare_git_dir(&cwd, dir.len, &repo_fmt, nongit_ok);
break;
case GIT_DIR_HIT_CEILING:
- prefix = setup_nongit(cwd.buf, nongit_ok);
- break;
+ if (!nongit_ok)
+ die(_("not a git repository (or any of the parent directories): %s"),
+ DEFAULT_GIT_DIR_ENVIRONMENT);
+ *nongit_ok = 1;
+ strbuf_release(&dir);
+ return NULL;
case GIT_DIR_HIT_MOUNT_POINT:
- if (nongit_ok) {
- *nongit_ok = 1;
- strbuf_release(&cwd);
- strbuf_release(&dir);
- return NULL;
- }
- die(_("not a git repository (or any parent up to mount point %s)\n"
- "Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)."),
- dir.buf);
+ if (!nongit_ok)
+ die(_("not a git repository (or any parent up to mount point %s)\n"
+ "Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)."),
+ dir.buf);
+ *nongit_ok = 1;
+ strbuf_release(&dir);
+ return NULL;
default:
BUG("unhandled setup_git_directory_1() result");
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/3] serve: pass "config context" through to individual commands
From: Jeff King @ 2018-12-16 10:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Williams, Jonathan Tan
In-Reply-To: <xmqq5zvvd418.fsf@gitster-ct.c.googlers.com>
On Sat, Dec 15, 2018 at 09:31:15AM +0900, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I actually started by doing that, but "struct serve_options" is not
> > currently known by ls-refs.c, upload-pack.c, etc. So they'd have to
> > start including "serve.h". I don't think that's the end of the world,
> > but it felt like a funny mutual circular to me (my mental model now is
> > that ls-refs, upload-pack, etc are low-level commands, tied together by
> > the "serve" stuff).
>
> That matches my mental model, too. I think the difference between
> us is what *_opt struct is. I viewed that it was like diff_options
> struct where the driving machinery keeps state of the ongoing
> operation performed by lower level routines to fulfill the request
> by the API caller, i.e. holding both wish from the caller, and
> scratchpad data for the mchinery and the lower level routine to
> communicate with each other.
>
> And the new field feels like the last "scratchpad used by the
> machinery to tell lower-level ls-refs helper what context it is
> operting in".
Yeah, I agree that such a "pass this through" struct full of options and
context would make sense. I just wouldn't tie it to the "serve"
machinery.
Did you read the side-thread between me and Jonathan? Another option
here is to just have ls-refs assume that the client will tell it the
context (and assume uploadpack for now, since that's all that v2
currently does).
That would make this patch go away entirely. :)
-Peff
^ permalink raw reply
* Re: [PATCH 0/3] protocol v2 and hidden refs
From: Jeff King @ 2018-12-16 10:40 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Jonathan Tan, git, bwilliamseng
In-Reply-To: <87d0q21s8w.fsf@evledraar.gmail.com>
On Sat, Dec 15, 2018 at 08:53:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > So I'm a bit worried that the unified endpoint model is going to be a
> > dead end, at which point carrying around git-serve just makes things
> > more complicated.
>
> This is from wetware memory of something discussed at a previous Git
> Merge, so I may have (inadvertently) made it up, but wasn't part of the
> idea of "git-serve" to have an extensible next-gen protocol where we
> could add new actions & verbs unrelated to sending or receiving packs?
Yes, I think that's a goal (and we already have upload-archive, which is
a similar thing).
> Of course that's not in itself an argument for having a general "serve"
> command, actually the opposite for the reasons you mention with locking
> down things. E.g. maybe I want to support server-side git-grep on my
> server, but not git-log, and if it's one command it becomes a hassle to
> do that via SSH config or HTTPD config for the reasons you mention.
Right, exactly. It pushes more of the information down into Git's own
protocol. Of course we _can_ build mechanisms at that level for
configuring which verbs are allowed. But if some context is available at
the higher protocol level, then we can use the mechanisms at that higher
level.
I think of it as a tradeoff. By including the endpoint in the transport
protocol (e.g., in ssh the command name, in HTTP the URL), we get to use
the mechanisms in those transports to make policy decisions on the
server. But it also means we _have_ to implement those policies twice,
once per transport.
IMHO having to deal with both transports is not that big a loss,
considering that there are only two, and really not likely to be more.
git:// is already unauthenticated, and IMHO is mostly a dead-end for
future protocol work since it provides no advantage over HTTP, and the
future is mostly HTTP, with ssh for people who really prefer its
authentication mode.
> The upside would be that once a host understands "git serve" I'm more
> likely to be able to get past whatever middle layer there is between my
> client and the "git" binary on the other side. E.g. if I have a newly
> compiled "git" client/server binary, but something like GitLab's
> "gitaly" sitting between the two of us.
But I think that's what makes it dangerous, too. :)
Gitaly (and we have our own equivalent at GitHub) is responsible for
making those policy decisions about who can run what. Opening a pipe
between the client and the backend that can issue arbitrary verbs is
exactly what they _don't_ want to do.
So they have to intercept the conversation at least at the verb level.
It _is_ nice if conversation for each verb is standardized (so once a
verb is issued, they can just step out of the way and proxy bytes[1]),
and v2 helps with that.
That's not too hard for a Git-aware endpoint to implement. But when
that verb interception can be done at the HTTP/ssh level, then it's easy
for tools that _aren't_ Git-aware to do handle it (again, like the
Apache config we recommend in git-http-backend(1)).
-Peff
[1] Actually, we do much more intimate interception than that at GitHub
already. The upload-pack conversation is mostly vanilla, but for
receive-pack we handle replication at that layer. So your pack is
streamed to 3-6 backend receive-packs simultaneously, and that
endpoint layer handles quorum for updating refs, etc.
^ permalink raw reply
* Re: [PATCH 0/4] A few Asciidoctor-fixes
From: Jeff King @ 2018-12-16 10:44 UTC (permalink / raw)
To: Martin Ågren; +Cc: git
In-Reply-To: <20181215112742.1475882-1-martin.agren@gmail.com>
On Sat, Dec 15, 2018 at 12:27:38PM +0100, Martin Ågren wrote:
> I have (ab)used doc-diff to try to find instances where Asciidoctor and
> Asciidoc render our documentation differently. (See [1] for details on
> the hack.) This series fixes the differences that somehow stood out in
> the diff. Many smaller differences remain.
I think the relevant bits from [1] are:
* Use `make --always-make ... install-man` in doc-diff.
* ./doc-diff -f HEAD HEAD # note -f
* Add empty commit and tweak config.mak
* ./doc-diff HEAD^ HEAD # note no -f
To make this easier, it would make sense to me to:
- teach doc-diff a flag for marking one or both of the endpoints to be
built with asciidoctor versus asciidoc
- mark the asciidoc/asciidoctor in the directory name. That name
serves as a cache key for avoiding re-doing the work, you should be
able to just:
./doc-diff --asciidoctor HEAD HEAD
and actually build and compare what you want.
- it sounds from "make --always-make" that our Makefile does not
properly rebuild when we switch from asciidoc to asciidoctor. That
might be nice to fix with a mechanism similar to the GIT-BUILD-FLAGS
we use in the top-level Makefile.
-Peff
^ permalink raw reply
* Re: [PATCH 1/4] git-column.txt: fix section header
From: Jeff King @ 2018-12-16 10:51 UTC (permalink / raw)
To: Martin Ågren; +Cc: git
In-Reply-To: <20181215112742.1475882-2-martin.agren@gmail.com>
On Sat, Dec 15, 2018 at 12:27:39PM +0100, Martin Ågren wrote:
> We have too few dashes under "Examples", which causes Asciidoctor to not
> pick it up as a section header, but to instead just render the dashes
> literally. This also seems to confuse Asciidoctor about dashes in
> general around here. It misinterprets the listing blocks in this
> section, again rendering the dashes literally.
>
> Make sure we have as many dashes as we have characters in "Examples".
> This fixes the section-issue and, somehow, makes the listing blocks
> render correctly.
Yeah, the mis-matched title-and-dashes thing has bitten us several
times. I think this one just post-dates the last round of fixing.
The "somehow" here is that the mismatched dashes appear to be the start
of a code listing block, making the whole example section into one big
listing (which isn't properly closed, generating a warning).
And that's why in the context:
> EXAMPLES
> -------
> +--------
>
> Format data by columns:
> ------------
We _don't_ need to match up the dashes for "Format data...". That is
meant to be a listing block (and arguably should use a shorter string of
dashes to make that intent more obvious).
-Peff
^ permalink raw reply
* Re: [PATCH 2/4] git-init.txt: do not nest open blocks
From: Jeff King @ 2018-12-16 10:55 UTC (permalink / raw)
To: Martin Ågren; +Cc: git
In-Reply-To: <20181215112742.1475882-3-martin.agren@gmail.com>
On Sat, Dec 15, 2018 at 12:27:40PM +0100, Martin Ågren wrote:
> It appears we try to nest open blocks, but that does not work well with
> Asciidoctor, which fails to indent the inner block. This causes the
> inner block to be set as if it had nothing to do with `--shared`. Drop
> the outer one. Asciidoc renders identically before and after this patch,
> both man-page and html.
Hrm. I'm not sure how we're supposed to have a block-within-a-block in
asciidoctor, and that may be something we want to fix in the long run.
But I agree this block around all of the options is not doing anything
useful, and the simplest solution here is just to get rid of it.
It dates all the way back to d145144c3b (Document git-init, 2007-01-11),
so perhaps it did something useful in an ancient version of asciidoc.
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] rev-list-options.txt: do not nest open blocks
From: Jeff King @ 2018-12-16 10:56 UTC (permalink / raw)
To: Martin Ågren; +Cc: git
In-Reply-To: <20181215112742.1475882-4-martin.agren@gmail.com>
On Sat, Dec 15, 2018 at 12:27:41PM +0100, Martin Ågren wrote:
> Similar to the previous commit, it appears we try to nest open blocks,
> which does not work well with Asciidoctor. Drop the outer one. That
> fixes the indentation similar to the previous patch, and makes us stop
> rendering a literal '+' before "Under --pretty=oneline ...". Asciidoc
> renders identically before and after this patch, both man-page and html.
Makes sense. Arguably this could be squashed into the previous one,
since the rationale is completely the same (but I'm OK with it either
way).
-Peff
^ permalink raw reply
* Re: [PATCH 4/4] git-status.txt: render tables correctly under Asciidoctor
From: Jeff King @ 2018-12-16 10:59 UTC (permalink / raw)
To: Martin Ågren; +Cc: git
In-Reply-To: <20181215112742.1475882-5-martin.agren@gmail.com>
On Sat, Dec 15, 2018 at 12:27:42PM +0100, Martin Ågren wrote:
> Asciidoctor removes the indentation of each line in these tables, so the
> last lines of each table have a completely broken alignment.
>
> Similar to 379805051d ("Documentation: render revisions correctly under
> Asciidoctor", 2018-05-06), use an explicit literal block to indicate
> that we want to keep the leading whitespace in the tables.
>
> Because this gives us some extra indentation, we can remove the one that
> we have been carrying explicitly. That is, drop the first four spaces of
> indentation on each line. With Asciidoc (8.6.10), this results in
> identical rendering before and after this commit, both for git-status.1
> and git-status.html.
Yep, this makes sense based on the prior art you cited.
The whole series looks good to me. Thanks for working on it!
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] serve: pass "config context" through to individual commands
From: Junio C Hamano @ 2018-12-16 11:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, Brandon Williams, Jonathan Tan
In-Reply-To: <20181216102544.GA13704@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yeah, I agree that such a "pass this through" struct full of options and
> context would make sense. I just wouldn't tie it to the "serve"
> machinery.
>
> Did you read the side-thread between me and Jonathan? Another option
> here is to just have ls-refs assume that the client will tell it the
> context (and assume uploadpack for now, since that's all that v2
> currently does).
Yes, I'd be 100% happy with that, too. And it certainly is simpler.
Thanks.
P.S. I expect to be mostly offline for the coming 72 hours, as I and
my wife are both down with a cold. I am guessing that we will enter
slower weeks in many parts of the world, and hoping this won't be
too disruptive.
^ permalink raw reply
* Re: [PATCH 0/3] protocol v2 and hidden refs
From: Ævar Arnfjörð Bjarmason @ 2018-12-16 11:47 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Tan, git, bwilliamseng
In-Reply-To: <20181216104017.GB13704@sigill.intra.peff.net>
On Sun, Dec 16 2018, Jeff King wrote:
> On Sat, Dec 15, 2018 at 08:53:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > So I'm a bit worried that the unified endpoint model is going to be a
>> > dead end, at which point carrying around git-serve just makes things
>> > more complicated.
>>
>> This is from wetware memory of something discussed at a previous Git
>> Merge, so I may have (inadvertently) made it up, but wasn't part of the
>> idea of "git-serve" to have an extensible next-gen protocol where we
>> could add new actions & verbs unrelated to sending or receiving packs?
>
> Yes, I think that's a goal (and we already have upload-archive, which is
> a similar thing).
>
>> Of course that's not in itself an argument for having a general "serve"
>> command, actually the opposite for the reasons you mention with locking
>> down things. E.g. maybe I want to support server-side git-grep on my
>> server, but not git-log, and if it's one command it becomes a hassle to
>> do that via SSH config or HTTPD config for the reasons you mention.
>
> Right, exactly. It pushes more of the information down into Git's own
> protocol. Of course we _can_ build mechanisms at that level for
> configuring which verbs are allowed. But if some context is available at
> the higher protocol level, then we can use the mechanisms at that higher
> level.
>
> I think of it as a tradeoff. By including the endpoint in the transport
> protocol (e.g., in ssh the command name, in HTTP the URL), we get to use
> the mechanisms in those transports to make policy decisions on the
> server. But it also means we _have_ to implement those policies twice,
> once per transport.
>
> IMHO having to deal with both transports is not that big a loss,
> considering that there are only two, and really not likely to be more.
> git:// is already unauthenticated, and IMHO is mostly a dead-end for
> future protocol work since it provides no advantage over HTTP, and the
> future is mostly HTTP, with ssh for people who really prefer its
> authentication mode.
>
>> The upside would be that once a host understands "git serve" I'm more
>> likely to be able to get past whatever middle layer there is between my
>> client and the "git" binary on the other side. E.g. if I have a newly
>> compiled "git" client/server binary, but something like GitLab's
>> "gitaly" sitting between the two of us.
>
> But I think that's what makes it dangerous, too. :)
>
> Gitaly (and we have our own equivalent at GitHub) is responsible for
> making those policy decisions about who can run what. Opening a pipe
> between the client and the backend that can issue arbitrary verbs is
> exactly what they _don't_ want to do.
>
> So they have to intercept the conversation at least at the verb level.
> It _is_ nice if conversation for each verb is standardized (so once a
> verb is issued, they can just step out of the way and proxy bytes[1]),
> and v2 helps with that.
>
> That's not too hard for a Git-aware endpoint to implement. But when
> that verb interception can be done at the HTTP/ssh level, then it's easy
> for tools that _aren't_ Git-aware to do handle it (again, like the
> Apache config we recommend in git-http-backend(1)).
>
> -Peff
>
> [1] Actually, we do much more intimate interception than that at GitHub
> already. The upload-pack conversation is mostly vanilla, but for
> receive-pack we handle replication at that layer. So your pack is
> streamed to 3-6 backend receive-packs simultaneously, and that
> endpoint layer handles quorum for updating refs, etc.
Yeah I think overall this makes sense. I was just thinking we'd have
stuff like this needing to be maintained in all middleware:
https://gitlab.com/gitlab-org/gitlab-shell/blob/v8.4.4/lib/gitlab_shell.rb#L15-28
Which, if and when we have a lot of verbs would be a pain, but of course
server operators might want to explicitly whitelist them.
Also for things like "git-grep" I can see e.g. "no POSIX regex" (due to
well known DoS issues0 being a configuration we ourselves would want to
carry, at that point server operators would need to maintain two
whitelists anyway, one in their custom code & another in /etc/gitconfig.
But I think that trade-off is worth it as you note because when you want
to filter these it's handy to be able to do it in a dumb ssh/web server.
Another thing to consider is not having a proliferation of things in
git-<TAB> completion again. AFAIK these things can't have spaces in them
for /etc/passwd & inetd tab completion. So perhaps call them all
git-serve-*, or not put them in our bin/ install path as a special case?
^ permalink raw reply
* [PATCH] worktree: allow to (re)move worktrees with uninitialized submodules
From: Nguyễn Thái Ngọc Duy @ 2018-12-16 12:12 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Uninitialized submodules have nothing valueable for us to be worried
about. They are just SHA-1. Let "worktree remove" and "worktree move"
continue in this case so that people can still use multiple worktrees
on repos with optional submodules that are never populated, like
sha1collisiondetection in git.git when checked out by doc-diff script.
Note that for "worktree remove", it is possible that a user
initializes a submodule (*), makes some commits (but not push), then
deinitializes it. At that point, the submodule is unpopulated, but the
precious new commits are still in
$GIT_COMMON_DIR/worktrees/<worktree>/modules/<submodule>
directory and we should not allow removing the worktree or we lose
those commits forever. The new directory check is added to prevent
this.
(*) yes they are screwed anyway by doing this since "git submodule"
would add submodule.* in $GIT_COMMON_DIR/config, which is shared
across multiple worktrees. But it does not mean we let them be
screwed even more.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/worktree.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 5e84026177..af03b83a26 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -9,6 +9,7 @@
#include "refs.h"
#include "run-command.h"
#include "sigchain.h"
+#include "submodule.h"
#include "refs.h"
#include "utf8.h"
#include "worktree.h"
@@ -724,20 +725,32 @@ static int unlock_worktree(int ac, const char **av, const char *prefix)
static void validate_no_submodules(const struct worktree *wt)
{
struct index_state istate = { NULL };
+ struct strbuf path = STRBUF_INIT;
int i, found_submodules = 0;
+ if (is_directory(worktree_git_path(wt, "modules")))
+ die(_("working trees containing submodules cannot be moved or removed"));
+
if (read_index_from(&istate, worktree_git_path(wt, "index"),
get_worktree_git_dir(wt)) > 0) {
for (i = 0; i < istate.cache_nr; i++) {
struct cache_entry *ce = istate.cache[i];
+ int err;
- if (S_ISGITLINK(ce->ce_mode)) {
- found_submodules = 1;
- break;
- }
+ if (!S_ISGITLINK(ce->ce_mode))
+ continue;
+
+ strbuf_reset(&path);
+ strbuf_addf(&path, "%s/%s", wt->path, ce->name);
+ if (!is_submodule_populated_gently(path.buf, &err))
+ continue;
+
+ found_submodules = 1;
+ break;
}
}
discard_index(&istate);
+ strbuf_release(&path);
if (found_submodules)
die(_("working trees containing submodules cannot be moved or removed"));
--
2.20.0.482.g66447595a7
^ permalink raw reply related
* Re: [PATCH] worktree: allow to (re)move worktrees with uninitialized submodules
From: Eric Sunshine @ 2018-12-16 13:18 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Git List
In-Reply-To: <20181216121239.10017-1-pclouds@gmail.com>
On Sun, Dec 16, 2018 at 7:12 AM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> Uninitialized submodules have nothing valueable for us to be worried
> about. They are just SHA-1. Let "worktree remove" and "worktree move"
> continue in this case so that people can still use multiple worktrees
> on repos with optional submodules that are never populated, like
> sha1collisiondetection in git.git when checked out by doc-diff script.
> [...]
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -724,20 +725,32 @@ static int unlock_worktree(int ac, const char **av, const char *prefix)
> static void validate_no_submodules(const struct worktree *wt)
> {
> + if (is_directory(worktree_git_path(wt, "modules")))
> + die(_("working trees containing submodules cannot be moved or removed"));
> +
> if (read_index_from(&istate, worktree_git_path(wt, "index"),
> get_worktree_git_dir(wt)) > 0) {
> [...]
> + found_submodules = 1;
> + break;
> }
> if (found_submodules)
> die(_("working trees containing submodules cannot be moved or removed"));
Not worth a re-roll, but an alternate way to structure this to avoid
duplicating the die() message would be:
if (is_directory(...))
found_submodules = 1;
else if (read_index_from(...)) {
...
found_submodules = 1;
break;
}
if (found_submodules)
die(...);
^ permalink raw reply
* Re: [PATCH 1/4] git-column.txt: fix section header
From: Martin Ågren @ 2018-12-16 14:27 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20181216105123.GD13704@sigill.intra.peff.net>
On Sun, 16 Dec 2018 at 11:51, Jeff King <peff@peff.net> wrote:
>
> On Sat, Dec 15, 2018 at 12:27:39PM +0100, Martin Ågren wrote:
>
> > We have too few dashes under "Examples", which causes Asciidoctor to not
> > pick it up as a section header, but to instead just render the dashes
> > literally. This also seems to confuse Asciidoctor about dashes in
> > general around here. It misinterprets the listing blocks in this
> > section, again rendering the dashes literally.
> >
> > Make sure we have as many dashes as we have characters in "Examples".
> > This fixes the section-issue and, somehow, makes the listing blocks
> > render correctly.
>
> The "somehow" here is that the mismatched dashes appear to be the start
> of a code listing block, making the whole example section into one big
> listing (which isn't properly closed, generating a warning).
Of course. Thanks for pointing it out. I now realize that when I wrote
"render the dashes literally", I was wrong.
This should be improved in v2.
Martin
^ permalink raw reply
* [PATCH v2 0/3] A few Asciidoctor-fixes
From: Martin Ågren @ 2018-12-16 14:28 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20181216105944.GG13704@sigill.intra.peff.net>
This series addresses a few instances where our documentation renders
badly in Asciidoctor, compared to Asciidoc. The changes made are exactly
the same as in v1 [1], but the first commit message is corrected, and
the two patches 2/4 and 3/4 are now just a single patch 2/3.
Thanks Peff for your comments on v1.
[1] https://public-inbox.org/git/20181215112742.1475882-1-martin.agren@gmail.com/
Martin Ågren (3):
git-column.txt: fix section header
Documentation: do not nest open blocks
git-status.txt: render tables correctly under Asciidoctor
Documentation/git-column.txt | 2 +-
Documentation/git-init.txt | 4 -
Documentation/git-status.txt | 162 +++++++++++++++--------------
Documentation/rev-list-options.txt | 4 -
4 files changed, 86 insertions(+), 86 deletions(-)
--
2.20.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox