Re: [PATCH v3 4/4] wt-status.c: Set the committable flag in the collect phase.
On Friday, September 7, 2018 3:31:55 PM MST Junio C Hamano wrote: > For example, I noticed that both of the old > callsites of wt_status_get_state() have free() of a few fiedls in > the structure, and I kept the code as close to the original, but I > suspect they should not be freed there in the functions in the > "print" phase, but rather the caller of the "collect" and "print" > should be made responsible for deciding when to dispose the entire > wt_status (and wt_status_state as part of it). This illustration > patch does not address that kind of details (yet). I followed the call tree back to original callers run_status() and cmd_status() in commit.c This leads to a philosophical question. We want to move the state information out of the print functions because it doesn't seem correct. For the case in question this includes the calls to free() . By doing this we seem go have traded one location that shouldn't be touching the state variables for another. I can see three solutions and could support any of the three: 1) Move the free calls to run_status() and cmd_status(). 2) Move the calls calls to wt_status_print since that is the last function from wt_status.c that is called befor the structure goes out of scope in run_status() and cmd_status(). 3) Add a new wt_collect*() function to free the variables. This would have an advantage that the free calls could be grouped in on place and not done in to functions. A second advantage is that the free calls would be located where the pointers are initialized. Personally I like solutions 1 and 3 over 2. What do others think? sps
Re: git diff-tree ignores --textconv
On 2018-09-23 06:23 PM, Jeff King wrote: > On Sun, Sep 23, 2018 at 05:56:03PM -0700, Stas Bekman wrote: > >>> You probably want "--ext-diff", not "--textconv". >> [...] >> Would it be safe to ask the maintainer of the application to include >> both --textconv and --ext-diff in that 'git diff-tree' call? I only need >> the latter, but someone needed --textconv there as it's in the code. > > I think so. The main reason that they are not the default for plumbing > commands such as diff-tree is that the output may be quite surprising to > anything trying to parse the output. Using --textconv will always > produce a diff, but one that may not be applied to the original content. > Using --ext-diff may produce output that doesn't even look like a diff, > though in practice they often do. > >> This is for this package: >> https://github.com/rsmmr/git-notifier > > It looks like the output is meant to be read by humans, so yeah, I think > it would be fine (and preferred) to enable both. Fantastic. Thank you so much, Jeff. -- Stas Bekman <'>< <'>< https://stasosphere.com https://chestofbooks.com https://experientialsexlab.com https://stason.org https://stasosphere.com/experience-life/my-books
Re: git diff-tree ignores --textconv
On Sun, Sep 23, 2018 at 05:56:03PM -0700, Stas Bekman wrote: > > You probably want "--ext-diff", not "--textconv". > [...] > Would it be safe to ask the maintainer of the application to include > both --textconv and --ext-diff in that 'git diff-tree' call? I only need > the latter, but someone needed --textconv there as it's in the code. I think so. The main reason that they are not the default for plumbing commands such as diff-tree is that the output may be quite surprising to anything trying to parse the output. Using --textconv will always produce a diff, but one that may not be applied to the original content. Using --ext-diff may produce output that doesn't even look like a diff, though in practice they often do. > This is for this package: > https://github.com/rsmmr/git-notifier It looks like the output is meant to be read by humans, so yeah, I think it would be fine (and preferred) to enable both. -Peff
Re: git diff-tree ignores --textconv
On 2018-09-23 05:43 PM, Jeff King wrote: > On Sun, Sep 23, 2018 at 03:41:45PM -0700, Stas Bekman wrote: > >> $ git config --get diff.jupyternotebook.command >> git-nbdiffdriver diff > > That's an "external diff driver", not a textconv driver. > > So here: > >> $ GIT_TRACE=1 git diff-tree -p HEAD --textconv test/test.ipynb >> > > You probably want "--ext-diff", not "--textconv". > > There's some discussion in the gitattributes manpage, but the short of > it is that textconv converts binary input to text, which is then fed > through the normal diff mechanism. Whereas an external diff driver is > given both sides and can produce whatever output it wants. Textconv is > less flexible, but generally way easier to write. Thank you, Jeff, for explaining my misunderstanding and how to fix it. Would it be safe to ask the maintainer of the application to include both --textconv and --ext-diff in that 'git diff-tree' call? I only need the latter, but someone needed --textconv there as it's in the code. This is for this package: https://github.com/rsmmr/git-notifier It was added here: https://github.com/rsmmr/git-notifier/search?q=textconv_q=textconv -- Stas Bekman <'>< <'>< https://stasosphere.com https://chestofbooks.com https://experientialsexlab.com https://stason.org https://stasosphere.com/experience-life/my-books
Re: git diff-tree ignores --textconv
On Sun, Sep 23, 2018 at 03:41:45PM -0700, Stas Bekman wrote: > $ git config --get diff.jupyternotebook.command > git-nbdiffdriver diff That's an "external diff driver", not a textconv driver. So here: > $ GIT_TRACE=1 git diff-tree -p HEAD --textconv test/test.ipynb > You probably want "--ext-diff", not "--textconv". There's some discussion in the gitattributes manpage, but the short of it is that textconv converts binary input to text, which is then fed through the normal diff mechanism. Whereas an external diff driver is given both sides and can produce whatever output it wants. Textconv is less flexible, but generally way easier to write. -Peff
Re: git silently ignores include directive with single quotes
Apologies for I don't know how this project manages issues, so I'm not sure whether it is my responsibility to make sure this issue gets resolved, or do you have some tracking mechanism where you have it registered? There is no rush, I'm asking because the discussion about this issue has suddenly dropped about 2 weeks ago, hence my ping. Thank you. -- Stas Bekman <'>< <'>< https://stasosphere.com https://chestofbooks.com https://experientialsexlab.com https://stason.org https://stasosphere.com/experience-life/my-books
git diff-tree ignores --textconv
Hi, I'm using a 3rd party application that internally uses 'git diff-tree' instead of 'git diff'. I'm trying to add filter and it works with 'git diff' but it gets ignored with 'git diff-tree' despite having --textconv. I was able to reproduce the problem with the following much more simplified setup: $ git check-attr diff test/test.ipynb test/test.ipynb: diff: jupyternotebook $ git config --get diff.jupyternotebook.command git-nbdiffdriver diff $ GIT_TRACE=1 git diff test/test.ipynb [...] run_command: GIT_DIFF_PATH_COUNTER=1 GIT_DIFF_PATH_TOTAL=1 'git-nbdiffdriver diff' [...] $ GIT_TRACE=1 git diff-tree -p HEAD --textconv test/test.ipynb Git tracing shows nothing relevant as in the command above. According to https://git-scm.com/docs/git-diff-tree adding --textconv should have respected the configured diff filter, but it does nothing. Is this a bug or do I have something misconfigured? Thank you. git version 2.17.1 -- Stas Bekman <'>< <'>< https://stasosphere.com https://chestofbooks.com https://experientialsexlab.com https://stason.org https://stasosphere.com/experience-life/my-books
Re: What's cooking in git.git (Sep 2018, #04; Thu, 20)
Hello, On 21.09.2018 08:22, Junio C Hamano wrote: The tip of 'next' hasn't been rewound yet. The three GSoC "rewrite in C" topics are still unclassified in this "What's cooking" report, but I am hoping that we can have them in 'next' sooner rather than later. I got an impression that Dscho wanted a chance for the final clean-up on some of them, so I am not doing anything hasty yet at this moment, though. Sorry for this late response. I was unexpectedly busy for this period of time. I will send a new iteration of `stash` tomorrow or Tuesday at the latest. Best regards, Paul
Re: [PATCH] worktree: add per-worktree config files
On Sun, Sep 23, 2018 at 1:04 PM Nguyễn Thái Ngọc Duy wrote:
> A new repo extension is added, worktreeConfig. When it is present:
>
> - Repository config reading by default includes $GIT_DIR/config _and_
>$GIT_DIR/config.worktree. "config" file remains shared in multiple
>worktree setup.
>
> - The special treatment for core.bare and core.worktree, to stay
>effective only in main worktree, is gone. These config files are
>supposed to be in config.worktree.
"These config _settings_ are supposed to be..."
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -2,8 +2,9 @@ CONFIGURATION FILE
> The Git configuration file contains a number of variables that affect
> -the Git commands' behavior. The `.git/config` file in each repository
> -is used to store the configuration for that repository, and
> +the Git commands' behavior. The files `.git/config` and optionally
> +`config.worktree` (see `extensions.worktreeConfig` below) are each
s/are/in/
> +repository is used to store the configuration for that repository, and
> `$HOME/.gitconfig` is used to store a per-user configuration as
> diff --git a/t/t2029-worktree-config.sh b/t/t2029-worktree-config.sh
> @@ -0,0 +1,82 @@
> +cmp_config() {
> + if [ "$1" = "-C" ]; then
Style:
if test "$1" = "-C"
then
...
> +}
> +
> +test_expect_success 'setup' '
> + test_commit start &&
> + git config --worktree per.worktree is-ok &&
Did you want:
cmp_config false extensions.worktreeConfig
at this point in the test or something? It's not clear what the
intention is here.
> + git worktree add wt1 &&
> + git worktree add wt2 &&
> + git config --worktree per.worktree is-ok &&
> + cmp_config true extensions.worktreeConfig
> +'
> +test_expect_success 'core.bare no longer for main only' '
> + git config core.bare true &&
> + cmp_config true core.bare &&
> + cmp_config -C wt1 true core.bare &&
> + cmp_config -C wt2 true core.bare &&
> + git config --unset core.bare
Should this be?
test_when_finished "git config --unset core.bare" &&
or perhaps test_config()?
> +'
RE: Git for games working group
On September 23, 2018 3:54 PM, John Austin wrote: > On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker > wrote: > > I would even like to help with your effort and have non-unixy platforms I'd > like to do this on. > > Having this separate from git LFS is an even better idea IMO, and I would > suggest implementing this using the same set of build tools that git uses so > that it is broadly portable, unlike git LFS. Glad to help there too. > > Great to hear -- once the code is in a bit better shape I can open it up on > github. Cross platform is definitely one of my focuses. I'm currently > implementing in Rust because it targets the same space as C and has great, > near trivial, cross-platform support. What sorts of platforms are you > interested in? Windows is my first target because that's where many game > developers live. I have looked at porting Rust to my two mid-to-large platforms which do not have a Rust port. I would prefer keeping within what git currently requires without adding dependencies, but I'd be happy to take a Rust prototype and translate it. My need is actually not for gamers, but in similar processes that gamers use. The following dependences are not available on the two platforms I have in mind: g++ or clang; And cmake (despite efforts by people on the platform to do ports). This puts me in a difficult spot with Rust. I understand you might want to use Rust's implied threating, so I would be willing to do the pthread work to make it happen in C. > > I would suggest that a higher-level grouping mechanism of resource groups > might be helpful - as in "In need this directory" rather than "I need this > file". > Better still, I could see "I need all objects in this commit-ish", which would > allow a revert operation to succeed or fail atomically while adhering to a > lock > requirement. > > One bit that traditional lock-brokering systems implement involve forcing > security attribute changes - so an unlocked file is stored as chmod a-w to > prevent accidental modification of lockables, when changing that to chmod > ?+w when a lock is acquired. It's not perfect, but does catch a lot of errors. > > Agreed -- I think this is all up to how the query endpoint and client is > designed. A couple of different types of clients could be implemented, > depending on the policies you want in place. One could have strict security > that stored unlocked files with a-w, as mentioned. Another could be a > weaker client, and simply warn developers when their current branch is in > conflict. Regards, Randall
git fetch behaves weirdely when run in a worktree
Hi, I was actually trying to automae the building and installation of Git source code to reduce my burden. I tried to automate it with the help of a script that runs daily via cron and a separate worktree used only by the build script.y run The script typically fetches new changes for the next branch by running the following in the build worktree (which is not the main worktree): $ git fetch origin next I thought that would result in FETCH_HEAD pointing to the latest changes for origin/next if the command succeeded. Unfortunately, it seems to be behaving weirdely when run in a worktree. It sems to be behaving as if I ran 'git fetch origin'. To add to that confusion when I run $ cat $MAIN_WORKTREE/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD it seems to be printing the info about the remote refs once and then if I run it again immediately nothing is printed. If I repeat it again, info about remote refs is printed but this time the info about the remote refs is printed thrice. This happens randomly. Sample output: 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eacnot-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139danot-for-merge branch 'todo' of https://github.com/git/git 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eacnot-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139danot-for-merge branch 'todo' of https://github.com/git/git 53f9a3e157dbbc901a02ac2c73346d375e24978cnot-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eacnot-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139danot-for-merge branch 'todo' of https://github.com/git/git 53f9a3e157dbbc901a02ac2c73346d375e24978cnot-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eacnot-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139danot-for-merge branch 'todo' of https://github.com/git/git 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eacnot-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139danot-for-merge branch 'todo' of https://github.com/git/git 'git fetch ' behaves correctly in the main worktree. Why is this weirdness happening when run in other worktrees? Why isn't 'git fetch not fetching the changes for just the specified branch? Am I missing something? -- Sivaraam
Re: Git for games working group
Regarding integration into LFS, I'd like to build the library in such a way that it would easy to bundle with LFS (so they could share the same git hooks), but also make it flexible enough to work for other workflows. On Sun, Sep 23, 2018 at 12:53 PM John Austin wrote: > > On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker > wrote: > > I would even like to help with your effort and have non-unixy platforms > > I'd like to do this on. > > Having this separate from git LFS is an even better idea IMO, and I would > > suggest implementing this using the same set of build tools that git uses > > so that it is broadly portable, unlike git LFS. Glad to help there too. > > Great to hear -- once the code is in a bit better shape I can open it > up on github. Cross platform is definitely one of my focuses. I'm > currently implementing in Rust because it targets the same space as C > and has great, near trivial, cross-platform support. What sorts of > platforms are you interested in? Windows is my first target because > that's where many game developers live. > > > I would suggest that a higher-level grouping mechanism of resource groups > > might be helpful - as in "In need this directory" rather than "I need this > > file". Better still, I could see "I need all objects in this commit-ish", > > which would allow a revert operation to succeed or fail atomically while > > adhering to a lock requirement. > > One bit that traditional lock-brokering systems implement involve forcing > > security attribute changes - so an unlocked file is stored as chmod a-w to > > prevent accidental modification of lockables, when changing that to chmod > > ?+w when a lock is acquired. It's not perfect, but does catch a lot of > > errors. > > Agreed -- I think this is all up to how the query endpoint and client > is designed. A couple of different types of clients could be > implemented, depending on the policies you want in place. One could > have strict security that stored unlocked files with a-w, as > mentioned. Another could be a weaker client, and simply warn > developers when their current branch is in conflict.
Re: Git for games working group
On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker wrote: > I would even like to help with your effort and have non-unixy platforms I'd > like to do this on. > Having this separate from git LFS is an even better idea IMO, and I would > suggest implementing this using the same set of build tools that git uses so > that it is broadly portable, unlike git LFS. Glad to help there too. Great to hear -- once the code is in a bit better shape I can open it up on github. Cross platform is definitely one of my focuses. I'm currently implementing in Rust because it targets the same space as C and has great, near trivial, cross-platform support. What sorts of platforms are you interested in? Windows is my first target because that's where many game developers live. > I would suggest that a higher-level grouping mechanism of resource groups > might be helpful - as in "In need this directory" rather than "I need this > file". Better still, I could see "I need all objects in this commit-ish", > which would allow a revert operation to succeed or fail atomically while > adhering to a lock requirement. > One bit that traditional lock-brokering systems implement involve forcing > security attribute changes - so an unlocked file is stored as chmod a-w to > prevent accidental modification of lockables, when changing that to chmod ?+w > when a lock is acquired. It's not perfect, but does catch a lot of errors. Agreed -- I think this is all up to how the query endpoint and client is designed. A couple of different types of clients could be implemented, depending on the policies you want in place. One could have strict security that stored unlocked files with a-w, as mentioned. Another could be a weaker client, and simply warn developers when their current branch is in conflict.
RE: Git for games working group
On September 23, 2018 1:29 PM, John Austin wrote: > I've been putting together a prototype file-locking implementation for a > system that plays better with git. What are everyone's thoughts on > something like the following? I'm tentatively labeling this system git-sync or > sync-server. There are two pieces: > > 1. A centralized repository called the Global Graph that contains the union > git > commit graph for local developer repos. When Developer A makes a local > commit on branch 'feature', git-sync will automatically push that new commit > up to the global server, under a name-spaced > branch: 'developera_repoabcdef/feature'. This can be done silently as a > force push, and shouldn't ever interrupt the developer's workflow. > Simple http queries can be made to the Global Graph, such as "Which > commits descend from commit abcdefgh?" > > 2. A client-side tool that queries the Global Graph to determine when your > current changes are in conflict with another developer. It might ask "Are > there any commits I don't have locally that modify lockable_file.bin?". This > could either be on pre-commit, or for more security, be part of a read-only > marking system ala Git LFS. There wouldn't be any "lock" per say, rather, the > client could refuse to modify a file if it found other commits for that file > in the > global graph. > > The key here is the separation of concerns. The Global Graph is fairly > dimwitted -- it doesn't know anything about file locking. But it provides a > layer of information from which we can implement file locking on the client > side (or perhaps other interesting systems). > > Thoughts? I'm encouraged of where this is going. I might suggest "sync" is the wrong name here, with "mutex" being slightly better - I would even like to help with your effort and have non-unixy platforms I'd like to do this on. Having this separate from git LFS is an even better idea IMO, and I would suggest implementing this using the same set of build tools that git uses so that it is broadly portable, unlike git LFS. Glad to help there too. I would suggest that a higher-level grouping mechanism of resource groups might be helpful - as in "In need this directory" rather than "I need this file". Better still, I could see "I need all objects in this commit-ish", which would allow a revert operation to succeed or fail atomically while adhering to a lock requirement. One bit that traditional lock-brokering systems implement involve forcing security attribute changes - so an unlocked file is stored as chmod a-w to prevent accidental modification of lockables, when changing that to chmod ?+w when a lock is acquired. It's not perfect, but does catch a lot of errors. Cheers, Randall
Re: Git for games working group
I've been putting together a prototype file-locking implementation for a system that plays better with git. What are everyone's thoughts on something like the following? I'm tentatively labeling this system git-sync or sync-server. There are two pieces: 1. A centralized repository called the Global Graph that contains the union git commit graph for local developer repos. When Developer A makes a local commit on branch 'feature', git-sync will automatically push that new commit up to the global server, under a name-spaced branch: 'developera_repoabcdef/feature'. This can be done silently as a force push, and shouldn't ever interrupt the developer's workflow. Simple http queries can be made to the Global Graph, such as "Which commits descend from commit abcdefgh?" 2. A client-side tool that queries the Global Graph to determine when your current changes are in conflict with another developer. It might ask "Are there any commits I don't have locally that modify lockable_file.bin?". This could either be on pre-commit, or for more security, be part of a read-only marking system ala Git LFS. There wouldn't be any "lock" per say, rather, the client could refuse to modify a file if it found other commits for that file in the global graph. The key here is the separation of concerns. The Global Graph is fairly dimwitted -- it doesn't know anything about file locking. But it provides a layer of information from which we can implement file locking on the client side (or perhaps other interesting systems). Thoughts? On Mon, Sep 17, 2018 at 10:23 AM Ævar Arnfjörð Bjarmason wrote: > > > On Mon, Sep 17 2018, Joey Hess wrote: > > > Ævar Arnfjörð Bjarmason wrote: > >> There's surely other aspects of that square peg of large file tracking > >> not fitting the round hole of file locking, the point of my write-up was > >> not that *that* solution is perfect, but there's prior art here that's > >> very easily adopted to distributed locking if someone wanted to scratch > >> that itch, since the notion of keeping a log of who has/hasn't gotten a > >> file is very similar to a log of who has/hasn't locked some file(s) in > >> the tree. > > > > Actually they are fundamentally very different. git-annex's tracking of > > locations of files is eventually consistent, which of course means that > > at any given point in time it may be currently inconsistent. That is > > fine for tracking locations of files, but not for locking. > > > > When git-annex needs to do an operation that relies on someone else's > > copy of a file actually being present, it uses real locking. That > > locking is not centralized, instead it relies on the connections between > > git repositories. That turns out to be sufficient for git-annex's own > > locking needs, but it would not be sufficient to avoid file edit > > conflict problems in eg a split brain situation. > > Right, all of that's true. I forgot to explicitly say what I meant by > "locking" in this context. Clearly it's not suitable for something like > actual file locking (in the sense of flock() et al), but rather just > advisory locking in the loosest sense of the word, i.e. some git-ish way > of someone writing on the office whiteboard "unless you're Bob, don't > touch main.c today Tuesday Sep 17th, he's hacking on it". > > So just a way to have some eventually consistent side channel to pass > such a message through git. Something similar to what git-annex does > with its "git-annex" branch would work for that, as long as everyone who > wanted get such messages ran some equivalent of "git annex sync" in a > timely manner (or checked the office whiteboard every day...). > > Such a schema is never going to be 100% reliable even in centralized > source control systems, e.g. even with cvs/perforce you might pull the > latest changes, then go on a plane and edit the locked main.c. Then the > lock has "failed" in the sense of "the message didn't get there in time, > and two people who could have just picked different areas to work on > made conflicting edits". > > As noted upthread this isn't my use-case, I just wanted to point the > git-annex method of distributing metadata as a bolt-on to git as > interesting prior art. If someone wants "truly distributed, but with > file locking like cvs/perforce" something like what git-annex is doing > would probably work for them. >
Re: [PATCH] add -p: coalesce hunks before testing applicability
* Phillip Wood [2018-09-13 11:20]: Yes in the long term we want to be able to coalesce edited hunks, but I think it is confusing to call coalesce_overlapping_hunks() at the moment as it will not coalesce the edited hunks. I would see it as a first step into that direction. I think that if you split a hunk, edit the first subhunk, transforming a trailing context line to a deletion then try if you try to stage the second subhunk it will fail. With your patch the edit will succeed as the second subhunk is skipped when testing the edited patch. Then when you try to stage the second subhunk it will fail as it's leading context will contradict the trailing lines of the edited subhunk. With the old method the edit failed but didn't store up trouble for the future. Agreed. I guess the question is if you assume a hunk to be applied or skipped as the default. You can still find enough cases where neither the current nor the patched version works. I stumbled upon the one case where I wanted to stage only one part of a split hunk and that one worked after my patch. I leave it up to you if the added benefit overweights the stored up trouble. Cheers Jochen signature.asc Description: PGP signature
[PATCH] worktree: add per-worktree config files
A new repo extension is added, worktreeConfig. When it is present: - Repository config reading by default includes $GIT_DIR/config _and_ $GIT_DIR/config.worktree. "config" file remains shared in multiple worktree setup. - The special treatment for core.bare and core.worktree, to stay effective only in main worktree, is gone. These config files are supposed to be in config.worktree. This extension is most useful in multiple worktree setup because you now have an option to store per-worktree config (which is either .git/config.worktree for main worktree, or .git/worktrees/xx/config.worktree for linked ones). This extension can be used in single worktree mode, even though it's pretty much useless (but this can happen after you remove all linked worktrees and move back to single worktree). "git config" reads from both "config" and "config.worktree" by default (i.e. without either --user, --file...) when this extension is present. Default writes still go to "config", not "config.worktree". A new option --worktree is added for that (*). Since a new repo extension is introduced, existing git binaries should refuse to access to the repo (both from main and linked worktrees). So they will not misread the config file (i.e. skip the config.worktree part). They may still accidentally write to the config file anyway if they use with "git config --file ". This design places a bet on the assumption that the majority of config variables are shared so it is the default mode. A safer move would be default writes go to per-worktree file, so that accidental changes are isolated. (*) "git config --worktree" points back to "config" file when this extension is not present so that it works in any setup. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 11 +++- Documentation/git-config.txt | 26 +--- Documentation/git-worktree.txt | 37 Documentation/gitrepository-layout.txt | 8 +++ builtin/config.c | 16 - cache.h| 2 + config.c | 7 +++ environment.c | 1 + setup.c| 5 +- t/t2029-worktree-config.sh | 82 ++ worktree.c | 41 + worktree.h | 6 ++ 12 files changed, 231 insertions(+), 11 deletions(-) create mode 100755 t/t2029-worktree-config.sh diff --git a/Documentation/config.txt b/Documentation/config.txt index 8d85d1a324..c24abf5871 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2,8 +2,9 @@ CONFIGURATION FILE -- The Git configuration file contains a number of variables that affect -the Git commands' behavior. The `.git/config` file in each repository -is used to store the configuration for that repository, and +the Git commands' behavior. The files `.git/config` and optionally +`config.worktree` (see `extensions.worktreeConfig` below) are each +repository is used to store the configuration for that repository, and `$HOME/.gitconfig` is used to store a per-user configuration as fallback values for the `.git/config` file. The file `/etc/gitconfig` can be used to store a system-wide default configuration. @@ -371,6 +372,12 @@ advice.*:: editor input from the user. -- +extensions.worktreeConfig:: + If set, by default "git config" reads from both "config" and + "config.worktree" file in that order. In multiple working + directory mode, "config" file is shared while + "config.worktree" is per-working directory. + core.fileMode:: Tells Git if the executable bit of files in the working tree is to be honored. diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 8e240435be..4870e00b89 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -45,13 +45,15 @@ unset an existing `--type` specifier with `--no-type`. When reading, the values are read from the system, global and repository local configuration files by default, and options -`--system`, `--global`, `--local` and `--file ` can be -used to tell the command to read from only that location (see <>). +`--system`, `--global`, `--local`, `--worktree` and +`--file ` can be used to tell the command to read from only +that location (see <>). When writing, the new value is written to the repository local configuration file by default, and options `--system`, `--global`, -`--file ` can be used to tell the command to write to -that location (you can say `--local` but that is the default). +`--worktree`, `--file ` can be used to tell the command to +write to that location (you can say `--local` but that is the +default). This command will fail with non-zero status upon error. Some exit codes are: @@ -131,6 +133,11 @@ from all available files. + See also <>. +--worktree:: +
Re: Import/Export as a fast way to purge files from Git?
On Sun, Sep 23, 2018 at 03:53:38PM +, brian m. carlson wrote: > I suspect you're gaining speed mostly because you're running three > processes total instead of at least one process (sh) per commit. So I > don't think there's anything that Git can do to make this faster on our > end without a redesign. It's not just the process startup overhead that makes it faster. Using multiple processes means they have to communicate somehow. In this case, git-read-tree is writing out the whole index for each commit, which git-rm reads in and modifies, and then git-commit-tree finally converts back to a tree. In addition to the raw CPU of that work, there's a bunch of latency as each step is performed serially. Whereas in the proposed pipeline, fast-export is writing out a diff and fast-import is turning that directly back into tree objects. And both processes are proceeding independently, so you benefit from multiple cores. Which isn't to say I really disagree with "Git can't really make this faster". filter-branch has a ton of power to let you replay arbitrary commands (including non-Git commands!), so the speed tradeoff in its approach is very intentional. If we could modify the index in-place that would probably make it a little faster, but that probably counts as "redesign" in your statement. ;) -Peff
Re: Import/Export as a fast way to purge files from Git?
> On Sep 23, 2018, at 4:55 PM, Eric Sunshine wrote: > > On Sun, Sep 23, 2018 at 9:05 AM Lars Schneider > wrote: >> I recently had to purge files from large Git repos (many files, many >> commits). >> The usual recommendation is to use `git filter-branch --index-filter` to >> purge >> files. However, this is *very* slow for large repos (e.g. it takes 45min to >> remove the `builtin` directory from git core). I realized that I can remove >> files *way* faster by exporting the repo, removing the file references, >> and then importing the repo (see Perl script below, it takes ~30sec to remove >> the `builtin` directory from git core). Do you see any problem with this >> approach? > > A couple comments: > > For purging files from a history, take a look at BFG[1] which bills > itself as "a simpler, faster alternative to git-filter-branch for > cleansing bad data out of your Git repository history". Yes, BFG is great. Unfortunately, it requires Java which is not available on every system I have to work with. I required a solution that would work in every Git environment. Hence the Perl script :-) > The approach of exporting to a fast-import stream, modifying the > stream, and re-importing is quite reasonable. Thanks for the confirmation! > However, rather than > re-inventing, take a look at reposurgeon[2], which allows you to do > major surgery on fast-import streams. Not only can it purge files from > a repository, but it can slice, dice, puree, and saute pretty much any > attribute of a repository. Wow. Reposurgeon looks very interesting. Thanks a lot for the pointer! Cheers, Lars > [1]: https://rtyley.github.io/bfg-repo-cleaner/ > [2]: http://www.catb.org/esr/reposurgeon/
Re: Import/Export as a fast way to purge files from Git?
On Sun, Sep 23, 2018 at 03:04:58PM +0200, Lars Schneider wrote: > Hi, > > I recently had to purge files from large Git repos (many files, many commits). > The usual recommendation is to use `git filter-branch --index-filter` to purge > files. However, this is *very* slow for large repos (e.g. it takes 45min to > remove the `builtin` directory from git core). I realized that I can remove > files *way* faster by exporting the repo, removing the file references, > and then importing the repo (see Perl script below, it takes ~30sec to remove > the `builtin` directory from git core). Do you see any problem with this > approach? I don't know of any problems with this approach. I didn't audit your specific Perl script for any issues, though. I suspect you're gaining speed mostly because you're running three processes total instead of at least one process (sh) per commit. So I don't think there's anything that Git can do to make this faster on our end without a redesign. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Re: Import/Export as a fast way to purge files from Git?
On Sun, Sep 23, 2018 at 9:05 AM Lars Schneider wrote: > I recently had to purge files from large Git repos (many files, many commits). > The usual recommendation is to use `git filter-branch --index-filter` to purge > files. However, this is *very* slow for large repos (e.g. it takes 45min to > remove the `builtin` directory from git core). I realized that I can remove > files *way* faster by exporting the repo, removing the file references, > and then importing the repo (see Perl script below, it takes ~30sec to remove > the `builtin` directory from git core). Do you see any problem with this > approach? A couple comments: For purging files from a history, take a look at BFG[1] which bills itself as "a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history". The approach of exporting to a fast-import stream, modifying the stream, and re-importing is quite reasonable. However, rather than re-inventing, take a look at reposurgeon[2], which allows you to do major surgery on fast-import streams. Not only can it purge files from a repository, but it can slice, dice, puree, and saute pretty much any attribute of a repository. [1]: https://rtyley.github.io/bfg-repo-cleaner/ [2]: http://www.catb.org/esr/reposurgeon/
Re: [PATCH v2 2/3] transport.c: introduce core.alternateRefsCommand
On Sat, Sep 22, 2018 at 03:52:58PM -0400, Jeff King wrote:
> On Sat, Sep 22, 2018 at 06:02:31PM +, brian m. carlson wrote:
>
> > On Fri, Sep 21, 2018 at 02:47:43PM -0400, Taylor Blau wrote:
> > > +expect_haves () {
> > > + printf "%s .have\n" $(git rev-parse $@) >expect
> > > +}
> > > +
> > > +extract_haves () {
> > > + depacketize - | grep '\.have' | sed -e 's/\\0.*$//g'
> >
> > It looks like you're trying to match a NUL here in the sed expression,
> > but from my reading of it, POSIX doesn't permit BREs to match NUL.
>
> No, it's trying to literally match backslash followed by 0. The
> depacketize() script will have undone the NUL already. In perl, no less,
> making it more or less equivalent to your suggestion. ;)
Ah, okay. That makes more sense.
> So I think this is fine (modulo that the grep and sed can be combined).
> Yet another option would be to simply strip away everything except the
> object id (which is all we care about), like:
>
> depacketize | perl -lne '/^(\S+) \.have/ and print $1'
>
> Or the equivalent in sed. I am happy with any solution that does the
> correct thing.
Yeah, I agree that with that context, no change is needed.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
Re: [PATCH 5/8] revision.c: better error reporting on ref from different worktrees
On Sun, Sep 23, 2018 at 10:25 AM Eric Sunshine wrote:
> > @@ -487,6 +487,28 @@ int submodule_uses_worktrees(const char *path)
> > +void strbuf_worktree_ref(const struct worktree *wt,
> > +struct strbuf *sb,
> > +const char *refname)
> > +{
> > + if (wt && !wt->is_current) {
> > + if (is_main_worktree(wt))
> > + strbuf_addstr(sb, "main/");
> > + else
> > + strbuf_addf(sb, "worktrees/%s/", wt->id);
> > + }
> > + strbuf_addstr(sb, refname);
> > +}
>
> Seeing this use worktree->id to construct "worktrees//"
> makes me wonder how the user is going to know the ID of a worktree in
> order to specify such refs in the first place. For example, how is the
> user going to know the in "git rev-parse worktrees//HEAD"? I
> don't think we print the worktree ID anywhere, do we? Certainly, "git
> worktree list" doesn't show it, and "git worktree add" stopped showing
> it as of 2c27002a0a (worktree: improve message when creating a new
> worktree, 2018-04-24).
Oh yes I forgot to point this out. With this approach we have to have
an id, and the directory name inside $GIT_DIR/worktrees seems a
natural choice. I was hoping to go with extended ref syntax instead
[1] which gives us more flexibility in identifying a worktree. But I
don't think that's going to happen. "git worktree" would need some
improvements to show this id, specify it at "git worktree add" and
potentially rename it even.
[1]
https://public-inbox.org/git/cacsjy8bovu_z-ulrfmzfyrymxhndfc_fun_4i4nnvxwosha...@mail.gmail.com/
--
Duy
Re: [PATCH 3/8] refs: new ref types to make per-worktree refs visible to all worktrees
On Sun, Sep 23, 2018 at 10:06 AM Eric Sunshine wrote: > > On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy > wrote: > > [...] > > The main worktree has to be treated specially because well.. it's > > special from the beginning. So HEAD from the main worktree is > > acccessible via the name "main/HEAD" (we can't use > > "worktrees/main/HEAD" because "main" under "worktrees" is not > > reserved). > > Bikeshedding: I wonder if this would be more intuitive if called > simply "/HEAD" rather than "main/HEAD". A ref name cannot start with '/'. I'm open to a different name than "main" though, it just felt a better name than "main-worktree". -- Duy
Re: Very simple popen() code request, ground-shaking functionality openned by it
On Sat, Sep 22, 2018 at 1:30 AM Ævar Arnfjörð Bjarmason wrote: > Duy's > https://public-inbox.org/git/20180920161928.ga13...@duynguyen.home/ is > another recent thing that reminded me of this, i.e. that suggested > "\\|/-" spinner could be made much neater with non-ASCII. > > > 1. Add a trace_key for sending machine-readable progress output to a > > descriptor or file. E.g., via setting GIT_TRACE_PROGRESS=2 in the > > environment. > > > > 2. Teach the trace code to open a command for piping, so that you > > could do something like GIT_TRACE_PROGRESS='|mygauge'. > > > > That would make your use case work, and I think many other use cases > > would benefit from both of those features independently. > > Yup, that's all sensible, and would be great both for this and other > stuff if we wanted true extensibility for this sort of thing. > > I'll just add that a 3rd thing that would also make sense would be to > add a feature to configure the value of these GIT_TRACE_*=* variables > via the .gitconfig, that's been suggested before (too lazy to dig up a > ML archive reference), and would make this as easy to configure as > Sebastian's suggestion. I'm less concern about prettiness than showing numbers that are hard to interpret. My other option was just showing ".", "..", "..." sequence, which achieves the same thing. I'm not opposed to having core.progressor or something like that. We already have core.pager and this new config serves more or less the same purpose. But I don't think I'll put time into implementing it. -- Duy
Import/Export as a fast way to purge files from Git?
Hi,
I recently had to purge files from large Git repos (many files, many commits).
The usual recommendation is to use `git filter-branch --index-filter` to purge
files. However, this is *very* slow for large repos (e.g. it takes 45min to
remove the `builtin` directory from git core). I realized that I can remove
files *way* faster by exporting the repo, removing the file references,
and then importing the repo (see Perl script below, it takes ~30sec to remove
the `builtin` directory from git core). Do you see any problem with this
approach?
Thank you,
Lars
#!/usr/bin/perl
#
# Purge paths from Git repositories.
#
# Usage:
# git-purge-path [path-regex1] [path-regex2] ...
#
# Examples:
#Remove the file "test.bin" from all directories:
#git-purge-path "/test.bin$"
#
#Remove all "*.bin" files from all directories:
#git-purge-path "\.bin$"
#
#Remove all files in the "/foo" directory:
#git-purge-path "^/foo/$"
#
# Attention:
# You want to run this script on a case sensitive file-system (e.g.
# ext4 on Linux). Otherwise the resulting Git repository will not
# contain changes that modify the casing of file paths.
#
use strict;
use warnings;
open( my $pipe_in, "git fast-export --progress=100 --no-data HEAD |" ) or die
$!;
open( my $pipe_out, "| git fast-import --force --quiet" ) or die $!;
LOOP: while ( my $cmd = <$pipe_in> ) {
my $data = "";
if ( $cmd =~ /^data ([0-9]+)$/ ) {
# skip data blocks
my $skip_bytes = $1;
read($pipe_in, $data, $skip_bytes);
}
elsif ( $cmd =~ /^M [0-9]{6} [0-9a-f]{40} (.+)$/ ) {
my $pathname = $1;
foreach (@ARGV) {
next LOOP if ("/" . $pathname) =~ /$_/
}
}
print {$pipe_out} $cmd . $data;
}
Re: [PATCH 7/8] fsck: check HEAD and reflog from other worktrees
On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy wrote: > fsck is a repo-wide operation and should check all references no > matter which worktree they are associated to. > > Reported-by: Jeff King > Helped-by: Elijah Newren > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh > @@ -101,6 +101,45 @@ test_expect_success 'HEAD link pointing at a funny > place' ' > +test_expect_success 'HEAD link pointing at a funny object (from different > wt)' ' > + test_when_finished "mv .git/SAVED_HEAD .git/HEAD" && > + test_when_finished "rm -rf .git/worktrees wt" && > + git worktree add wt && > + mv .git/HEAD .git/SAVED_HEAD && > + echo >.git/HEAD && Perhaps use $ZERO_OID here instead of hardcoded "0..." string to play friendly with brian's bc/hash-independent-tests (in 'next'). Same for following test. > + # avoid corrupt/broken HEAD from interfering with repo discovery > + test_must_fail git -C wt fsck 2>out && > + cat out && Unneeded 'cat'. Debugging cruft? Same for other tests. > + grep "main/HEAD: detached HEAD points" out This message doesn't get localized, so no need for test_i18ngrep(). Okay. > +'
Re: [PATCH 5/8] revision.c: better error reporting on ref from different worktrees
On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy wrote:
> Make use of the new ref aliases to pass refs from another worktree
> around and access them from the current ref store instead. This does
> not change any functionality, but when a problem shows up, we would
> report something like
>From this description, I had a hard time grasping that the first
example output is the desired one. Not necessarily worth a re-roll,
but had it said instead something like this:
...but when a problem arises, we would like the reported
messages to mention full ref aliases, like this:
it would have been more obvious.
More below...
> fatal: bad object worktrees/ztemp/HEAD
> warning: reflog of 'main/HEAD' references pruned commits
>
> instead of
>
> fatal: bad object HEAD
> warning: reflog of 'HEAD' references pruned commits
>
> which does not really tell where the refs are from.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/worktree.c b/worktree.c
> @@ -487,6 +487,28 @@ int submodule_uses_worktrees(const char *path)
> +void strbuf_worktree_ref(const struct worktree *wt,
> +struct strbuf *sb,
> +const char *refname)
> +{
> + if (wt && !wt->is_current) {
> + if (is_main_worktree(wt))
> + strbuf_addstr(sb, "main/");
> + else
> + strbuf_addf(sb, "worktrees/%s/", wt->id);
> + }
> + strbuf_addstr(sb, refname);
> +}
Seeing this use worktree->id to construct "worktrees//"
makes me wonder how the user is going to know the ID of a worktree in
order to specify such refs in the first place. For example, how is the
user going to know the in "git rev-parse worktrees//HEAD"? I
don't think we print the worktree ID anywhere, do we? Certainly, "git
worktree list" doesn't show it, and "git worktree add" stopped showing
it as of 2c27002a0a (worktree: improve message when creating a new
worktree, 2018-04-24).
> diff --git a/worktree.h b/worktree.h
> @@ -108,4 +108,18 @@ extern const char *worktree_git_path(const struct
> worktree *wt,
> +/*
> + * Return a refname suitable for access from the current ref
> + * store. The result may be destroyed at the next call.
> + */
If you re-roll, perhaps: s/may/will/
Re: [PATCH 3/8] refs: new ref types to make per-worktree refs visible to all worktrees
On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy wrote:
> [...]
> The main worktree has to be treated specially because well.. it's
> special from the beginning. So HEAD from the main worktree is
> acccessible via the name "main/HEAD" (we can't use
> "worktrees/main/HEAD" because "main" under "worktrees" is not
> reserved).
Bikeshedding: I wonder if this would be more intuitive if called
simply "/HEAD" rather than "main/HEAD".
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/refs.c b/refs.c
> @@ -641,12 +641,32 @@ static int is_pseudoref_syntax(const char *refname)
> +static int is_main_pseudoref_syntax(const char *refname)
> +{
> + return skip_prefix(refname, "main/", ) &&
> + is_pseudoref_syntax(refname);
> +}
> +
> +static int is_other_pseudoref_syntax(const char *refname)
> +{
> + if (!skip_prefix(refname, "worktrees/", ))
> + return 0;
> + refname = strchr(refname, '/');
> + if (!refname)
> + return 0;
> + return is_pseudoref_syntax(refname + 1);
> +}
If the input is "worktrees/refs/" (nothing following the trailing
'/'), then an empty string will be passed to is_pseudoref_syntax(),
which will return true. Does that result in correct behavior? (Same
question about "main/" being passed to is_main_pseudoref_syntax().)
Re: [PATCH 2/8] Add a place for (not) sharing stuff between worktrees
On Sat, Sep 22, 2018 at 2:05 PM Nguyễn Thái Ngọc Duy wrote: > When multiple worktrees are used, we need rules to determine if > something belongs to one worktree or all of them. Instead of keeping > adding rules when new stuff comes, have a generic rule: > [...] > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/t/t1415-worktree-refs.sh b/t/t1415-worktree-refs.sh > @@ -0,0 +1,36 @@ > +test_expect_success 'setup' ' > + test_commit initial && > + test_commit wt1 && > + test_commit wt2 && > + git worktree add wt1 wt1 && > + git worktree add wt2 wt2 && > + git checkout initial > +' > + > +test_expect_success 'add refs/local' ' > + git update-ref refs/local/foo HEAD && > + git -C wt1 update-ref refs/local/foo HEAD && > + git -C wt2 update-ref refs/local/foo HEAD > +' Not at all worth a re-roll, but the "add refs/local" test seems like just more setup, thus could be rolled into the "setup" test (unless it will be growing in some non-setup way in later patches).
Re: [PATCH] git help: promote 'git help -av'
On Sat, Sep 22, 2018 at 9:29 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sat, Sep 22 2018, Nguyễn Thái Ngọc Duy wrote:
>
> > When you type "git help" (or just "git") you are greeted with a list
> > with commonly used commands and their short description and are
> > suggested to use "git help -a" or "git help -g" for more details.
> >
> > "git help -av" would be more friendly and inline with what is shown
> > with "git help" since it shows list of commands with description as
> > well, and commands are properly grouped.
> >
> > Signed-off-by: Nguyễn Thái Ngọc Duy
> > ---
> > git.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/git.c b/git.c
> > index a6f4b44af5..69c21f378b 100644
> > --- a/git.c
> > +++ b/git.c
> > @@ -31,7 +31,7 @@ const char git_usage_string[] =
> > "[]");
> >
> > const char git_more_info_string[] =
> > - N_("'git help -a' and 'git help -g' list available subcommands and
> > some\n"
> > + N_("'git help -av' and 'git help -g' list available subcommands and
> > some\n"
> > "concept guides. See 'git help ' or 'git help
> > '\n"
> > "to read about a specific subcommand or concept.");
>
> A side-effect of this not noted in your commit message is that we'll now
> invoke the pager, perhaps we should just do:
>
> diff --git a/builtin/help.c b/builtin/help.c
> index 8d4f6dd301..1a3b174aaf 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -436,9 +436,9 @@ int cmd_help(int argc, const char **argv, const char
> *prefix)
> parsed_help_format = help_format;
>
> if (show_all) {
> + setup_pager();
> git_config(git_help_config, NULL);
> if (verbose) {
> - setup_pager();
> list_all_cmds_help();
> return 0;
> }
> @@ -460,8 +460,10 @@ int cmd_help(int argc, const char **argv, const char
> *prefix)
> return 0;
> }
>
> - if (show_guides)
> + if (show_guides) {
> + setup_pager();
> list_common_guides_help();
> + }
>
> if (show_all || show_guides) {
> printf("%s\n", _(git_more_info_string));
>
> Or is there a good reason we shouldn't invoke the pager for e.g. -g when
> the terminal is too small (per our default less config)?
Different pagers may behave differently (and so far "help -a" still
fits in my screen). So I don't think we should invoke pager more than
necessary.
--
Duy
