doc: git-push: clarify DESCRIPTION section #1964
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,31 +19,34 @@ SYNOPSIS | |
| DESCRIPTION | ||
|
There was a problem hiding this comment. On the Git mailing list, Junio C Hamano wrote (reply to this): "Julia Evans via GitGitGadget" <[email protected]> writes:
> From: Julia Evans <[email protected]>
>
> From user feedback, 5 users are unsure what "ref" and/or "objects" means
> in this context. 3 users said they don't know what "complete the refs"
> means.
Well, "this concept I do not understand" from many users is not
necessarily mean that the concept does not have to be taught.
> -Updates remote refs using local refs, while sending objects
> -necessary to complete the given refs.
>
> +Updates one or more branches, tags, or other references in a remote
> +repository from your local repository.
This is a very good rewrite of the first half of the sentence.
Complete loss of the latter is a bit disturbing.
Send data that records commits, directories, and files
(collectively called "objects"), and update branches, tags and
other references at the remote repository, to make newer part of
the history available there.
or something?
> @@ -44,6 +40,9 @@ corresponding upstream branch, but as a safety measure, the push is
> aborted if the upstream branch does not have the same name as the
> local one.
>
> +You can make interesting things happen to a repository
> +every time you push into it, by setting up 'hooks' there. See
> +documentation for linkgit:git-receive-pack[1].
>
> OPTIONS[[OPTIONS]]
> ------------------
Moving the description of the secondary effect down like this is a
welcome change.
The original had two blank lines to separate the previous section
and the subsequent OPTIONS section, but now we have only one. It
would not make a difference in the rendered output, but having a
blank lines between paragraphs and two blank lines between sections,
if done consistently, would help reading the documentation in the
source form.
Thanks.There was a problem hiding this comment. On the Git mailing list, "Julia Evans" wrote (reply to this): > Well, "this concept I do not understand" from many users is not
> necessarily mean that the concept does not have to be taught.
That's true. I'll try to explain in more detail why I think terms can be
omitted (or why they can't!) in the future.
Here we're talking about two terms: refs and objects.
Re "refs": I think "refs" is pretty relevant to `git push`, which is why I left it in
(as "or other references", to give readers a hint that a branch is a type
of ref/reference).
Re "objects": I can't think right now of a common reason why it would be useful
to understand the details of how Git's object database works in the context of
"git push", do you have an example? I think `git show` is a much better example
of a command where the term "object" is relevant, because you can use `git show`
to show blob objects.
>> -Updates remote refs using local refs, while sending objects
>> -necessary to complete the given refs.
>>
>> +Updates one or more branches, tags, or other references in a remote
>> +repository from your local repository.
>
> This is a very good rewrite of the first half of the sentence.
> Complete loss of the latter is a bit disturbing.
>
> Send data that records commits, directories, and files
> (collectively called "objects"), and update branches, tags and
> other references at the remote repository, to make newer part of
> the history available there.
>
> or something?
Will try this:
Updates one or more branches, tags, or other references in a remote
repository from your local repository, and sends all necessary data in
those branches or tags that isn't already on the remote.
The goal there is to make sure the reader knows that git push may need to
send a significant amount of data, depending on what's in the new commits
you're pushing.
>> OPTIONS[[OPTIONS]]
>> ------------------
>
> Moving the description of the secondary effect down like this is a
> welcome change.
>
> The original had two blank lines to separate the previous section
> and the subsequent OPTIONS section, but now we have only one.
Will fix.There was a problem hiding this comment. On the Git mailing list, Junio C Hamano wrote (reply to this): "Julia Evans" <[email protected]> writes:
> Re "refs": I think "refs" is pretty relevant to `git push`, which is why I left it in
> (as "or other references", to give readers a hint that a branch is a type
> of ref/reference).
I have (and I didn't have) no issues with "refs" -> "references".
> Will try this:
>
> Updates one or more branches, tags, or other references in a remote
> repository from your local repository, and sends all necessary data in
> those branches or tags that isn't already on the remote.
>
> The goal there is to make sure the reader knows that git push may need to
> send a significant amount of data, depending on what's in the new commits
> you're pushing.
Yes. I do not partculary see the point of deliberately trying to be
vague by saying "data" (in "all necessary data") instead of "tags,
commits, trees, and blobs (collectively known as objects), but I
agree with the stated goal here.There was a problem hiding this comment. On the Git mailing list, "Julia Evans" wrote (reply to this): >> Will try this:
>>
>> Updates one or more branches, tags, or other references in a remote
>> repository from your local repository, and sends all necessary data in
>> those branches or tags that isn't already on the remote.
>>
>> The goal there is to make sure the reader knows that git push may need to
>> send a significant amount of data, depending on what's in the new commits
>> you're pushing.
>
> Yes. I do not partculary see the point of deliberately trying to be
> vague by saying "data" (in "all necessary data") instead of "tags,
> commits, trees, and blobs (collectively known as objects), but I
> agree with the stated goal here.
What we're trying to prevent here is readers getting distracted by trying to
learn concepts which are not necessary to understand how `git push` works.
For example, one user commented:
> I had to look up what the term "object" meant...
It's not necessary to know what an "object" is to understand how to use `git
push` (though if you have an example of why it is necessary, I would love
to hear it!) If it's not necessary to understand the command, readers should
not feel like they have to look it up to understand its documentation.
I think "..., and sends all necessary commits or other objects that aren't
already on the remote." might work if we want to add more detail, since it
gives users a hint that maybe they can ignore the "or other objects" part if
they're not sure what an "object" is.There was a problem hiding this comment. On the Git mailing list, Ben Knoble wrote (reply to this): > Le 16 sept. 2025 à 14:46, Julia Evans <[email protected]> a écrit :
>
> I think "..., and sends all necessary commits or other objects that aren't
> already on the remote." might work if we want to add more detail, since it
> gives users a hint that maybe they can ignore the "or other objects" part if
> they're not sure what an "object" is.
Nit, without wading into the above discussion: shouldn’t that be « and other objects »?There was a problem hiding this comment. On the Git mailing list, Junio C Hamano wrote (reply to this): Ben Knoble <[email protected]> writes:
>> Le 16 sept. 2025 à 14:46, Julia Evans <[email protected]> a écrit :
>>
>> I think "..., and sends all necessary commits or other objects that aren't
>> already on the remote." might work if we want to add more detail, since it
>> gives users a hint that maybe they can ignore the "or other objects" part if
>> they're not sure what an "object" is.
>
> Nit, without wading into the above discussion: shouldn’t that be « and other objects »?
You could push a tag that points at a blob, so it is possible that
the push transfers only "other objects", but "necessary commits and
other objects" would naturally cover the case where the number of
necessary commits is zero ;-), so I tend to agree that *and* would
read better in that sentence.
But if we really want to do the progressive disclosure, I am OK with
the idea that hiding the details behind a vague words like "transfer
data necessary for updated branches" without saying what these data
are would work OK.
Thanks.There was a problem hiding this comment. On the Git mailing list, Junio C Hamano wrote (reply to this): Junio C Hamano <[email protected]> writes:
> "Julia Evans" <[email protected]> writes:
>
>> Re "refs": I think "refs" is pretty relevant to `git push`, which is why I left it in
>> (as "or other references", to give readers a hint that a branch is a type
>> of ref/reference).
>
> I have (and I didn't have) no issues with "refs" -> "references".
>
>> Will try this:
>>
>> Updates one or more branches, tags, or other references in a remote
>> repository from your local repository, and sends all necessary data in
>> those branches or tags that isn't already on the remote.
>>
>> The goal there is to make sure the reader knows that git push may need to
>> send a significant amount of data, depending on what's in the new commits
>> you're pushing.
>
> Yes. I do not partculary see the point of deliberately trying to be
> vague by saying "data" (in "all necessary data") instead of "tags,
> commits, trees, and blobs (collectively known as objects), but I
> agree with the stated goal here.
Let me change my mind here.
If you are trying to avoid overwhelming the readers by carefully
trying not to write things that do not have to be said at each point
in the teaching, I do agree that the deliberate vagueness I
mentioned above is a good idea. You seem to have better "taste" of
knowing what the right amount of detail to give, a lot better than I
do.
Please keep these goodness coming.
Thanks.There was a problem hiding this comment. On the Git mailing list, "Julia Evans" wrote (reply to this): > Let me change my mind here.
>
> If you are trying to avoid overwhelming the readers by carefully
> trying not to write things that do not have to be said at each point
> in the teaching, I do agree that the deliberate vagueness I
> mentioned above is a good idea. You seem to have better "taste" of
> knowing what the right amount of detail to give, a lot better than I
> do.
>
> Please keep these goodness coming.
Thanks so much for the encouragement, it really helps a lot. I've
appreciated your detailed reviews.
let's keep going!
- Julia |
||
| ----------- | ||
|
|
||
| Updates one or more branches, tags, or other references in a remote | ||
|
There was a problem hiding this comment. On the Git mailing list, Junio C Hamano wrote (reply to this): "Julia Evans via GitGitGadget" <[email protected]> writes:
> From: Julia Evans <[email protected]>
>
> Signed-off-by: Julia Evans <[email protected]>
>
> Be clearer about what we're describing ("which repository" instead of
> "what to push"), and start with a positive "try X, then Y, then Z"
> instead of a negative ("if X is not specified..").
Since I like this simple rule so much, if it is generally applicable
everywhere, I'd like to have it or a variant of it in one of our
developer facing documentation as a tip to write better
documentation.
> Signed-off-by: Julia Evans <[email protected]>
There is some funny ordering problem with the commit log body and
sign-off.
> ---
> Documentation/git-push.adoc | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-push.adoc b/Documentation/git-push.adoc
> index e73b64f61fd0..5c934486c33d 100644
> --- a/Documentation/git-push.adoc
> +++ b/Documentation/git-push.adoc
> @@ -22,10 +22,10 @@ DESCRIPTION
> Updates one or more branches, tags, or other references in a remote
> repository from your local repository.
>
> -When the command line does not specify where to push with the
> -`<repository>` argument, `branch.*.remote` configuration for the
> -current branch is consulted to determine where to push. If the
> -configuration is missing, it defaults to 'origin'.
> +To decide which repository to push to, Git uses the `<repository>`
> +argument (for example `git push dev`), then if that's not specified the
> +`branch.*.remote` configuration for the current branch, and then defaults
> +to `origin`.
Very nicely done.
> When the command line does not specify what to push with `<refspec>...`
> arguments or `--all`, `--mirror`, `--tags` options, the command findsThere was a problem hiding this comment. On the Git mailing list, Junio C Hamano wrote (reply to this): "Julia Evans via GitGitGadget" <[email protected]> writes:
> -When the command line does not specify where to push with the
> -`<repository>` argument, `branch.*.remote` configuration for the
> -current branch is consulted to determine where to push. If the
> -configuration is missing, it defaults to 'origin'.
> +To decide which repository to push to, Git uses the `<repository>`
> +argument (for example `git push dev`), then if that's not specified the
> +upstream configuration for the current branch, and then defaults
> +to `origin`.
OK. Much less awkward and much clearer. Nice.There was a problem hiding this comment. On the Git mailing list, Junio C Hamano wrote (reply to this): "Julia Evans via GitGitGadget" <[email protected]> writes:
> From: Julia Evans <[email protected]>
>
> Be clearer about what we're describing ("which repository" instead of
> "what to push"), and start with a positive "try X, then Y, then Z"
I forgot to say, even though I did spot:
"what to push" -> "where to push"
"what to push" is the topic of the next patch.There was a problem hiding this comment. On the Git mailing list, "Julia Evans" wrote (reply to this): >> Be clearer about what we're describing ("which repository" instead of
>> "what to push"), and start with a positive "try X, then Y, then Z"
>
> I forgot to say, even though I did spot:
>
> "what to push" -> "where to push"
>
> "what to push" is the topic of the next patch.
Thanks for spotting that. Will fix. |
||
| repository from your local repository, and sends all necessary data | ||
| that isn't already on the remote. | ||
|
|
||
| To decide which repository to push to, Git uses the `<repository>` | ||
| argument (for example `git push dev`), then if that's not specified the | ||
| upstream configuration for the current branch, and then defaults | ||
| to `origin`. | ||
|
|
||
| To decide which branches, tags, or other refs to push, Git uses | ||
| (in order of precedence): | ||
|
|
||
| 1. The `<refspec>` argument(s) (for example `main` in `git push origin main`) | ||
| or the `--all`, `--mirror`, or `--tags` options | ||
| 2. The `remote.*.push` configuration for the repository being pushed to | ||
| 3. The `push.default` configuration. The default is `push.default=simple`, | ||
| which will push to a branch with the same name as the current branch. | ||
| See the CONFIGURATION section below for more on `push.default`. | ||
|
|
||
| As a safety measure, `git push` may fail if you haven't set an upstream | ||
| for the current branch, depending on what `push.default` is set to. | ||
| See the UPSTREAM BRANCHES section below for more on how to set and | ||
| use upstreams. | ||
|
|
||
| You can make interesting things happen to a repository | ||
| every time you push into it, by setting up 'hooks' there. See | ||
| documentation for linkgit:git-receive-pack[1]. | ||
|
|
||
|
|
||
| OPTIONS[[OPTIONS]] | ||
| ------------------ | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, "D. Ben Knoble" wrote (reply to this):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, Junio C Hamano wrote (reply to this):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, "Julia Evans" wrote (reply to this):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, "D. Ben Knoble" wrote (reply to this):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, "Kristoffer Haugsbakk" wrote (reply to this):