git/Documentation/git-bundle.txt, branch v2.48.2

Merge branch 'kh/doc-bundle-typofix'

2024-12-13T15:33:38Z

Typofix. * kh/doc-bundle-typofix: Documentation/git-bundle.txt: fix word join typo

Documentation/git-bundle.txt: fix word join typo

2024-12-02T01:29:59Z

Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

Documentation/git-bundle.txt: discuss naïve backups

2024-11-18T00:56:26Z

It might be naïve to think that those who need this education would end up here in the first place. But I think it’s good to mention this high-level concept here on a command which provides a backup strategy. Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

Documentation/git-bundle.txt: mention --all in spec. refs

2024-11-18T00:56:25Z

Mention `--all` as an alternative in “Specifying References”. Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

Documentation/git-bundle.txt: remove old `--all` example

2024-11-18T00:56:25Z

We don’t need this part now that we have a fleshed-out `--all` example. Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

Documentation/git-bundle.txt: mention full backup example

2024-11-18T00:56:25Z

Provide an example about how to make a “full backup” with caveats about what that means in this case. This is a requested use-case.[1] But the doc is a bit unassuming about it: If you want to match `git clone --mirror`, which would include your refs such as `refs/remotes/*`, use `--all`. The user cannot be expected to formulate “I want a full backup” as “I want to match `git clone --mirror`” for a bundle file or something. Let’s drop this mention of `--all` later in the doc and frontload it. † 1: E.g.: • https://stackoverflow.com/questions/5578270/fully-backup-a-git-repo • https://stackoverflow.com/questions/11792671/how-to-git-bundle-a-complete-repo Helped-by: Junio C Hamano Signed-off-by: Kristoffer Haugsbakk Signed-off-by: Junio C Hamano

Merge branch 'jk/bundle-use-dash-for-stdfiles'

2023-03-19T22:03:12Z

"git bundle" learned that "-" is a common way to say that the input comes from the standard input and/or the output goes to the standard output. It used to work only for output and only from the root level of the working tree. * jk/bundle-use-dash-for-stdfiles: parse-options: use prefix_filename_except_for_dash() helper parse-options: consistently allocate memory in fix_filename() bundle: don't blindly apply prefix_filename() to "-" bundle: document handling of "-" as stdin bundle: let "-" mean stdin for reading operations

bundle: document handling of "-" as stdin

2023-03-06T21:12:56Z

We have always allowed "bundle create -" to write to stdout, but it was never documented. And a recent patch let reading operations like "bundle list-heads -" read from stdin. Let's document all of these cases. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

bundle: turn on --all-progress-implied by default

2023-03-06T17:51:06Z

In 79862b6b77c (bundle-create: progress output control, 2019-11-10), "bundle create" learned about the --all-progress and --all-progress-implied options, which were copied from pack-objects. I think these were a mistake. In pack-objects, "all-progress-implied" is about switching the behavior between a regular on-disk "git repack" and the use of pack-objects for push/fetch (where a fetch does not want progress from the server during the write stage; the client will print progress as it receives the data). But there's no such distinction for bundles. Prior to 79862b6b77c, we always printed the write stage. Afterwards, a vanilla: git bundle create foo.bundle omits the write progress, appearing to hang (especially if your repository is large or your disk is slow). That seems like a regression. It's possible that the flexibility to disable the write-phase progress _could_ be useful for bundle. E.g., if you did something like: ssh some-host git bundle create foo.bundle | git bundle unbundle But if you are running both in real-time, why are you using bundles in the first place? You're better off doing a real fetch. But even if we did want to support that, it should be the exception, and vanilla "bundle create" should display the full progress. So we'd want to name the option "--no-write-progress" or something. The "--all-progress" option itself is even worse. It exists in pack-objects only for historical reasons. It's a mistake because it implies "--progress", and we added "--all-progress-implied" to fix that. There is no reason to propagate that mistake to new commands. Likewise, the documentation for these options was pulled from pack-objects. But it doesn't make any sense in this context. It talks about "--stdout", but that is not even an option that git-bundle supports. This patch flips the default for "--all-progress-implied" back to "true", fixing the regression in 79862b6b77c. This turns that option into a noop, and means that "--all-progress" is really the same as "--progress". We _could_ drop them completely, but since they've been shipped with Git since v2.25.0, it's polite to continue accepting them. I didn't implement any sort of "--no-write-progress" here. I'm not at all convinced it's necessary, and the discussion from the original thread: https://lore.kernel.org/git/20191110204126.30553-2-robbat2@gentoo.org/ shows that that the main focus was on getting --progress and --quiet support, and not any kind of clever "real-time bundle over the network" feature. But technically this patch is making it impossible to do something that you _could_ do post-79862b6b77c. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Documentation: fix various repeat word typos

2022-09-12T18:04:55Z

Inspired by 24966cd982 ("doc: fix repeated words", 08-09-2019), I ran "egrep -R "\<([a-zA-Z]+)\> \<\1\>" ./Documentation/*" to find current cases of repeated words such as "the the" that were quite clearly typos. There were many false positives reported, such as "really really" or valid uses of "that that" which I left alone. Signed-off-by: Jacob Stopak Signed-off-by: Junio C Hamano