* Re: [PATCH v2 09/15] user-manual: Use 'git config --global user.*' for setup
From: Junio C Hamano @ 2013-02-10 22:48 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <20130210222508.GC8377@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Sun, Feb 10, 2013 at 02:12:05PM -0800, Junio C Hamano wrote:
>> > +Which will add the following stanza to a file named `.gitconfig` in
>> > +your home directory:
>>
>> Looks good, even though I do not think we would want/need to confuse
>> the readers with an unfamiliar word "stanza".
>
> Aw. I suppose "section" is better? (It's what Python's ConfigParser
> uses anyway). I saw "stanza" in another part of the manual and
> thought it was quite poetic ;).
How about not saying anything and say "adds the following"?
^ permalink raw reply
* Re: [PATCH v2 03/15] user-manual: Use 'remote add' to setup push URLs
From: Junio C Hamano @ 2013-02-10 22:45 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <20130210215442.GB8000@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Sun, Feb 10, 2013 at 01:33:31PM -0800, Junio C Hamano wrote:
>> Look at how "Fetching branches from other repositories" is done. It
>> shows the use of "remote add" and then shows the result by running
>> "cat" to show the contents.
>>
>> I think that organization is much nicer than completely hiding how
>> the result looks like behind another "git config --set" call, like
>> the latter half of this patch does.
>
> I think for new users, `git config …`'s opacity may a good thing
No. Reducing the fear factor from new users by not hiding simple
things is one of the design of these tutorials, and showing that the
contents of .git/config is a simple, human-readable plain text file
is a part of it.
> I'm fine with this too, but if this is the suggested route, why bother
> with `git config` at all? Is it just for ease of scripting?
I would actually say why bother with `git remote` at all, when you
can do that with `git config`, but arguably when a Porcelain that is
type-specific exists, use of it would make the life of end users
easier, and that is why we ended up having `git remote add`. So if
you know how the remote configuration is implemented, you can still
use `config` to do the same, but `remote add` that futzes with many
variables at once would be easier to use for most people.
^ permalink raw reply
* Re: Git prompt
From: Jeff King @ 2013-02-10 22:43 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ethan Reesor, git, Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130210212538.GA11720@elie.Belkin>
On Sun, Feb 10, 2013 at 01:25:38PM -0800, Jonathan Nieder wrote:
> Ethan Reesor wrote:
>
> > I have a git user set up on my server. It's prompt is set to
> > git-prompt and it's git-shell-commands is empty.
> [...]
> > How do I make the git user work like github where, upon attempting to
> > get a prompt, the connection is closed?
>
> I assume you mean that the user's login shell is git-shell.
>
> You can disable interactive logins by removing the
> ~/git-shell-commands/ directory. Unfortunately that doesn't let you
> customize the message. Perhaps it would make sense to teach shell.c
> to look for a
>
> [shell]
> greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'
>
> setting in git's config file. What do you think?
I think something like that makes sense. To my knowledge there is no way
with stock git to customize git-shell's output (at GitHub, that message
comes from our front-end routing process before you even hit git-shell
on our backend machines).
The "username" in our version of the message comes from a database
mapping public keys to GitHub users, not the Unix username. But I
suspect sites running stock Git would be happy enough to have
%(username) map to the actual Unix username.
-Peff
^ permalink raw reply
* Re: [PATCH] fixup! graph: output padding for merge subsequent parents
From: Junio C Hamano @ 2013-02-10 22:38 UTC (permalink / raw)
To: John Keeping; +Cc: git, Matthieu Moy, Michał Kiedrowicz
In-Reply-To: <20130210210229.GB2270@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Sun, Feb 10, 2013 at 11:30:39AM -0800, Junio C Hamano wrote:
> ...
>> Is it correct to say that this essentially re-does 656197ad3805
>> (graph.c: infinite loop in git whatchanged --graph -m, 2009-07-25)
>> in a slightly different way, in that Michał's original fix also
>> protected against the case where graph->state is flipped to
>> GRAPH_PADDING by graph_next_line() that returns false, but with your
>> fixup, the code knows it never happens (i.e. when graph_next_line()
>> returns false, graph->state is always in the GRAPH_PADDING state),
>> and the only thing we need to be careful about is when graph->state
>> is already in the PADDING state upon entry to this function?
>
> Yes, although I wonder if we can end up in POST_MERGE or COLLAPSING
> state here as well. The check in the loop guards against that because
> those will eventually end up as PADDING.
>
> As far as I can see, this is okay because we have called
> graph_show_remainder() at the end of outputting a commit, even when we
> end up outputting the same (merge) commit more than once. But someone
> more familiar with the graph code might want to comment here.
More importantly, that kind of thought process needs to be
documented in the log message; that will help people to diagnose the
cause of the problem if they later find that this patch made an
incorrect assumption while simplifying the code.
^ permalink raw reply
* Re: [PATCH v2 00/15] User manual updates
From: W. Trevor King @ 2013-02-10 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7v621zsswg.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 614 bytes --]
On Sun, Feb 10, 2013 at 02:31:11PM -0800, Junio C Hamano wrote:
> Thanks. I queued 01, 10, 11, 13 directly on 'maint'; they looked
> not just good to me but I wouldn't expect any objection to them.
Ok, I'll drop them from v3. I based my changes on `master` to avoid
colliding with 2de9b711 (Documentation: the name of the system is
'Git', not 'git', 2013-01-21), but if you shifted them already I
suppose you've fixed any conflicts ;).
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: Junio C Hamano @ 2013-02-10 22:36 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <20130210214621.GA8000@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> On Sun, Feb 10, 2013 at 01:24:47PM -0800, Junio C Hamano wrote:
>> I would not be surprised if some readers felt as if "then why not
>> update it instead of rejecting?" were a valid question, without a
>> bit more explanation.
>>
>> You can also push to a repository that has a working tree,
>> …
>
> Looks good to me :). Shall I just drop this patch from v3 and leave
> it to you?
No.
Others need to object to, comment on and polish what you saw from
me, before it turns into a commit. And you need to be credited for
identifying the problem, initiating the discussion, and collecting
responses to result in the final patch.
^ permalink raw reply
* Re: [PATCH v2 15/15] user-manual: Use --format=tar.gz to create a gzipped tarball
From: W. Trevor King @ 2013-02-10 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7va9rbst37.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
On Sun, Feb 10, 2013 at 02:27:08PM -0800, Junio C Hamano wrote:
> This is a "meh" at least to me. Unless it uses something like
>
> git archive -o latest.tar.gz --prefix=project/ HEAD
>
> it is not all that interesting.
Great suggestion. My original goal was to remove the pipe, but if we
can remove the redirection too, that's one less POSIX-ism for newbies
to wonder about ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/15] User manual updates
From: Junio C Hamano @ 2013-02-10 22:31 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> This combines my ealier patches:
>
> * user-manual: Rewrite git-gc section for automatic packing
> * user-manual: Update for receive.denyCurrentBranch=refuse
>
> With a number of additional fixups. Changes since v1:
>
> * user-manual: Rewrite git-gc section for automatic packing:
> - Reworded following suggestions from Junio. This removed the
> phrase containing the 'comression' typo pointed out by Javier.
> * user-manual: Update for receive.denyCurrentBranch=refuse
> - No changes.
>
> Most of the patches are well-focused, with the exception of
> "Standardize backtick quoting". I can break this up into smaller
> chunks (e.g. "Standardize backtick quoting in Chapter 1", "Standardize
> backtick quoting in Chapter 2", …) if this is too much to bite off in
> one patch.
>
> I may add additional patches onto the end of this series as I make new
> fixes and the series cooks on the list.
Thanks. I queued 01, 10, 11, 13 directly on 'maint'; they looked
not just good to me but I wouldn't expect any objection to them.
Others patches may see comments from reviewers, so I didn't pick
them up even for 'pu'.
^ permalink raw reply
* Re: [PATCH v2 12/15] user-manual: Use request-pull to generate "please pull" text
From: W. Trevor King @ 2013-02-10 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7vehgnst8r.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
On Sun, Feb 10, 2013 at 02:23:48PM -0800, Junio C Hamano wrote:
> The request-pull checks a lot more than "does a merge base exist?",
> no?
It does, but the man page doesn't list the checks, and I didn't want
to read through the source to find them all ;). Maybe I should, and
then update the man page :p.
> Does the examples in this flow push out what you want to be
> pulled _before_ running this step?
Err, yes. And I should have used `mytree` unstead of the explicit
URL. Maybe I should have an explicit push just before the
`request-pull` for extra clarity.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 15/15] user-manual: Use --format=tar.gz to create a gzipped tarball
From: Junio C Hamano @ 2013-02-10 22:27 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <92a02e35df3dab70928e56e6790417243beea2af.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> This functionality was introduced by 0e804e09 (archive: provide
> builtin .tar.gz filter, 2011-07-21) for v1.7.7.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
This is a "meh" at least to me. Unless it uses something like
git archive -o latest.tar.gz --prefix=project/ HEAD
it is not all that interesting.
> Documentation/user-manual.txt | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 8024758..c04ea51 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -931,12 +931,19 @@ The linkgit:git-archive[1] command can create a tar or zip archive from
> any version of a project; for example:
>
> -------------------------------------------------
> -$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
> +$ git archive --format=tar.gz --prefix=project/ HEAD >latest.tar.gz
> -------------------------------------------------
>
> will use HEAD to produce a tar archive in which each filename is
> preceded by `project/`.
>
> +Versions of Git older than 1.7.7 don't know about the 'tar.gz' format,
> +you'll need to use gzip explicitly:
> +
> +-------------------------------------------------
> +$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
> +-------------------------------------------------
> +
> If you're releasing a new version of a software project, you may want
> to simultaneously make a changelog to include in the release
> announcement.
^ permalink raw reply
* Re: [PATCH v2 09/15] user-manual: Use 'git config --global user.*' for setup
From: W. Trevor King @ 2013-02-10 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7vip5zstsa.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Sun, Feb 10, 2013 at 02:12:05PM -0800, Junio C Hamano wrote:
> > +Which will add the following stanza to a file named `.gitconfig` in
> > +your home directory:
>
> Looks good, even though I do not think we would want/need to confuse
> the readers with an unfamiliar word "stanza".
Aw. I suppose "section" is better? (It's what Python's ConfigParser
uses anyway). I saw "stanza" in another part of the manual and
thought it was quite poetic ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 12/15] user-manual: Use request-pull to generate "please pull" text
From: Junio C Hamano @ 2013-02-10 22:23 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <3d860e7c19b33ebc2725eb86ec481f966e3007de.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> Less work and more error checking (e.g. does a merge base exist?).
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 31054a2..6446791 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2298,17 +2298,14 @@ these changes, just apply directly to the `release` branch, and then
> merge that into the `test` branch.
>
> To create diffstat and shortlog summaries of changes to include in a "please
> -pull" request to Linus you can use:
> +pull" request to Linus you can use linkgit:git-request-pull[1]:
>
> -------------------------------------------------
> -$ git diff --stat origin..release
> +$ git request-pull origin git://example.com/proj.git release
> -------------------------------------------------
>
> -and
> -
> --------------------------------------------------
> -$ git log -p origin..release | git shortlog
> --------------------------------------------------
> +where the `git://` URL points to your <<public-repositories,public
> +repository>>.
>
> Here are some of the scripts that simplify all this even further.
The request-pull checks a lot more than "does a merge base exist?",
no? Does the examples in this flow push out what you want to be
pulled _before_ running this step?
^ permalink raw reply
* Re: [PATCH v2 03/15] user-manual: Use 'remote add' to setup push URLs
From: W. Trevor King @ 2013-02-10 22:19 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Git
In-Reply-To: <20130210220848.GB11720@elie.Belkin>
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
On Sun, Feb 10, 2013 at 02:08:48PM -0800, Jonathan Nieder wrote:
> For everyday interactive configuration editing, config files have some
> good advantages:
>
> - The settings are easy to read, well organized, and all in one place
> - The file can include comments.
I'm convinced, although the settings are in at least three places
(--system, --global, and --local). Throwing in the XDG stuff stirs up
the file locations, but it's probably safe to assume (at the moment),
that anyone going that route knows what they're doing ;). If we just
assume `.git/config` and `~/.gitconfig` we should be pretty safe…
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 09/15] user-manual: Use 'git config --global user.*' for setup
From: Junio C Hamano @ 2013-02-10 22:12 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <b363f5b410098302a02af2d79b5b68ee79210be2.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> A simple command line call is easier than spawning an editor,
> especially for folks new to ideas like the "command line" and "text
> editors". This is also the approach suggested by 'git commit' if you
> try and commit without having configured user.name or user.email.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 8bf37b3..e2e0c86 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -991,9 +991,16 @@ Developing with Git
> Telling Git your name
> ---------------------
>
> -Before creating any commits, you should introduce yourself to Git. The
> -easiest way to do so is to make sure the following lines appear in a
> -file named `.gitconfig` in your home directory:
> +Before creating any commits, you should introduce yourself to Git.
> +The easiest way to do so is to use linkgit:git-config[1]:
> +
> +------------------------------------------------
> +$ git config --global user.name 'Your Name Comes Here'
> +$ git config --global user.email 'you@yourdomain.example.com'
> +------------------------------------------------
> +
> +Which will add the following stanza to a file named `.gitconfig` in
> +your home directory:
Looks good, even though I do not think we would want/need to confuse
the readers with an unfamiliar word "stanza".
> @@ -1001,8 +1008,9 @@ file named `.gitconfig` in your home directory:
> email = you@yourdomain.example.com
> ------------------------------------------------
>
> -(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
> -details on the configuration file.)
> +See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
> +details on the configuration file. The file is plain text, so you can
> +also edit it with your favorite editor.
>
>
> [[creating-a-new-repository]]
^ permalink raw reply
* Re: [PATCH v2 07/15] user-manual: Mention 'git remote add' for remote branch config
From: Junio C Hamano @ 2013-02-10 22:09 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <1e3996dff5c19010aca1458b202b14cbb54b5d80.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index a68d6b9..424cdd6 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2909,8 +2909,23 @@ Also note that all of the above configuration can be performed by
> directly editing the file .git/config instead of using
> linkgit:git-config[1].
>
> +You can produce a similar configuration with:
> +
> +-------------------------------------------------
> +$ git remote add example git://example.com/proj.git
> +-------------------------------------------------
> +
> +which adds the following stanza to `.git/config`:
> +
> +-------------------------------------------------
> +[remote "example"]
> + url = git://example.com/proj.git
> + fetch = +refs/heads/*:refs/remotes/example/*
> +-------------------------------------------------
> +
What the "config remoteexample.fetch" example before this hunk
teaches is stale and is a wrong advice these days. I suspect that
the original was written very soon after a separate refs/remotes/
hierarchy was introduced, back when it was considered a good and
cautious practice to notice rewinds at the remote by omitting the
"+" from fetch refspecs. I'd suggest rewriting everything after "If
there are other repositories that you also use frequently,..." of
this section.
Replace the first example after "for example, after" that uses
"config remote.example.url" with the new text in your patch, and
remove everything before "Also note that all of the above
configuration can be performed by directly editing", while keeping
examples of what various forms of "git fetch" would do with the
above configuration file, without mentioning what would happen if
you omitted "+" from them.
^ permalink raw reply
* Re: [PATCH v2 03/15] user-manual: Use 'remote add' to setup push URLs
From: Jonathan Nieder @ 2013-02-10 22:08 UTC (permalink / raw)
To: W. Trevor King; +Cc: Junio C Hamano, Git
In-Reply-To: <20130210215442.GB8000@odin.tremily.us>
W. Trevor King wrote:
> On Sun, Feb 10, 2013 at 01:33:31PM -0800, Junio C Hamano wrote:
>> The resulting text may read like so:
>> …
>
> I'm fine with this too, but if this is the suggested route, why bother
> with `git config` at all? Is it just for ease of scripting?
Yes. It can also be helpful when giving help over IRC, since you
can get reproducible results without assuming the user has a proper
text editor set up, but that is just a special case of scripting. ;-)
For everyday interactive configuration editing, config files have some
good advantages:
- The settings are easy to read, well organized, and all in one place
- The file can include comments.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 07/15] user-manual: Mention 'git remote add' for remote branch config
From: Junio C Hamano @ 2013-02-10 22:08 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <1e3996dff5c19010aca1458b202b14cbb54b5d80.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index a68d6b9..424cdd6 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2909,8 +2909,23 @@ Also note that all of the above configuration can be performed by
> directly editing the file .git/config instead of using
> linkgit:git-config[1].
>
> +You can produce a similar configuration with:
> +
> +-------------------------------------------------
> +$ git remote add example git://example.com/proj.git
> +-------------------------------------------------
> +
> +which adds the following stanza to `.git/config`:
> +
> +-------------------------------------------------
> +[remote "example"]
> + url = git://example.com/proj.git
> + fetch = +refs/heads/*:refs/remotes/example/*
> +-------------------------------------------------
> +
What the "config remoteexample.fetch" example before this hunk
teaches is stale and is a wrong advice these days. I suspect that
the original was written very soon after a separate refs/remotes/
hierarchy was introduced, back when it was considered a good and
cautious practice to notice rewinds at the remote by omitting the
"+" from fetch refspecs. I'd suggest rewriting everything after "If
there are other repositories that you also use frequently,..." of
this section.
Replace the first example after "for example, after" that uses
"config remote.example.url" with the new text in your patch, and
remove everything before "Also note that all of the above
configuration can be performed by directly editing".
^ permalink raw reply
* Re: [PATCH v2 06/15] user-manual: Give 'git push -f' as an alternative to +master
From: W. Trevor King @ 2013-02-10 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7vsj53sub1.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]
On Sun, Feb 10, 2013 at 02:00:50PM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > +Note the addition of the `+` sign. Alternatively, you can use the
> > +`-f` flag to force the remote update, as in:
> > +
> > +-------------------------------------------------
> > +$ git push -f ssh://yourserver.com/~you/proj.git master
> > +-------------------------------------------------
> > +
>
> I didn't check the surrounding examples but would it make it a bit
> too advanced to make the example flow push out more than one
> branches here (perhaps he is also updating the 'maint' branch)?
> Then use of "--force" can be explained as "Instead of adding + to
> each and every refs to be pushed, you can use a single -f to force
> everything."
>
> The mistake I would want to avoid teaching the readers is to replace
>
> push $there +master maint
>
> with
>
> push -f $there master maint
>
> or even worse
>
> push -f $there
> push -f
If you feel the need to explain it to the list, we should probably
have an explanatory example in the manual ;). What about suggesting
`--dry-run` for sanity-checking forced pushes?
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 06/15] user-manual: Give 'git push -f' as an alternative to +master
From: Junio C Hamano @ 2013-02-10 22:00 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <f0f8b77a3487be30ee4c492899fe73af05e20413.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> This mirrors existing language in the description of 'git fetch'.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 5d80b40..a68d6b9 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2045,6 +2045,13 @@ branch name with a plus sign:
> $ git push ssh://yourserver.com/~you/proj.git +master
> -------------------------------------------------
>
> +Note the addition of the `+` sign. Alternatively, you can use the
> +`-f` flag to force the remote update, as in:
> +
> +-------------------------------------------------
> +$ git push -f ssh://yourserver.com/~you/proj.git master
> +-------------------------------------------------
> +
I didn't check the surrounding examples but would it make it a bit
too advanced to make the example flow push out more than one
branches here (perhaps he is also updating the 'maint' branch)?
Then use of "--force" can be explained as "Instead of adding + to
each and every refs to be pushed, you can use a single -f to force
everything."
The mistake I would want to avoid teaching the readers is to replace
push $there +master maint
with
push -f $there master maint
or even worse
push -f $there
push -f
^ permalink raw reply
* Re: [PATCH v2 05/15] user-manual: Add a few references to 'git rebase -i'
From: W. Trevor King @ 2013-02-10 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7vzjzbsumu.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
On Sun, Feb 10, 2013 at 01:53:45PM -0800, Junio C Hamano wrote:
> This change is very good (modulo the extra blank line at the end).
Oops. Will remove from v3.
> Alternatively, we can explain only the amending of the tip commit in
> this section, removing everything else; I think that is probably a
> better option. The series of sections around here would then look
> like:
>
> * The section before this talked about a straight-forward "rebase";
>
> * This section then talks about "commit --amend", nothing else;
>
> * The next section talks about taking "format-patch A..B", flipping
> its output around and applying to A. Enhance that section with
> the material to be removed from here, which talks about applying
> "format-patch A..B" on top of the amended A.
>
> * Then add a separate section after that "Reordering or selecting
> from a patch series" section to discuss "rebase -i".
>
> Hmm?
Works for me. The 'format-patch' section is also useful, because it's
easy to understand how a mailing list could get inserted between
'format-patch' and 'am' ;).
The problem with a section on 'rebase -i' is that it does such a good
job explaining itself ;). I suppose I could add a few "screenshots"
:p.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 04/15] user-manual: Use git branch --merged
From: W. Trevor King @ 2013-02-10 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7v4nhju9z6.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 586 bytes --]
On Sun, Feb 10, 2013 at 01:37:01PM -0800, Junio C Hamano wrote:
> This is making things much less useful. "branch --merged origin"
> will show 47 different branches that you are *not* interested in the
> flow of examples in this part of the tutorial.
>
> Also, log origin..branchname allows you to notice a situation where
> some but not all of the branch was merged, too.
Good points. I'll drop this patch from v3.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Git prompt
From: Ethan Reesor @ 2013-02-10 21:54 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <20130210212538.GA11720@elie.Belkin>
That would be perfect. (And I did mean I set the login shell to
git-prompt. Additionally, the git user does not have permissions to
run any other shell.) However, when I remove the git-shell-commands
directory I get (on the local end):
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
If no one with more experience has the time to look into your
suggestion, I will try.
Thanks,
Ethan
On Sun, Feb 10, 2013 at 4:25 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ethan Reesor wrote:
>
>> I have a git user set up on my server. It's prompt is set to
>> git-prompt and it's git-shell-commands is empty.
> [...]
>> How do I make the git user work like github where, upon attempting to
>> get a prompt, the connection is closed?
>
> I assume you mean that the user's login shell is git-shell.
>
> You can disable interactive logins by removing the
> ~/git-shell-commands/ directory. Unfortunately that doesn't let you
> customize the message. Perhaps it would make sense to teach shell.c
> to look for a
>
> [shell]
> greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'
>
> setting in git's config file. What do you think?
>
> Thanks,
> Jonathan
--
Ethan Reesor (Gmail)
^ permalink raw reply
* Re: [PATCH v2 03/15] user-manual: Use 'remote add' to setup push URLs
From: W. Trevor King @ 2013-02-10 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7v8v6vua50.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On Sun, Feb 10, 2013 at 01:33:31PM -0800, Junio C Hamano wrote:
> Look at how "Fetching branches from other repositories" is done. It
> shows the use of "remote add" and then shows the result by running
> "cat" to show the contents.
>
> I think that organization is much nicer than completely hiding how
> the result looks like behind another "git config --set" call, like
> the latter half of this patch does.
I think for new users, `git config …`'s opacity may a good thing. Who
cares how Git stores the config values? Only users who like to edit
the config files by hand (like, um, me ;). For someone trying to wrap
their head around Git for the first time, the fact that you can read
and set config values which are stored somewhere should be enough.
I don't feel strongly enough in favor of `git config` to push on this
though, so I'd be happy dropping this patch in favor of:
> The resulting text may read like so:
> …
I'm fine with this too, but if this is the suggested route, why bother
with `git config` at all? Is it just for ease of scripting?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 05/15] user-manual: Add a few references to 'git rebase -i'
From: Junio C Hamano @ 2013-02-10 21:53 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <4931d9fc83155b29787a3d33a7ac87dbfaa04795.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> I think this interface is much more convenient than extended cherry
> picking or using 'git format-patch'. Inserting a number of references
> should raise awareness among new users. The previously discussed
> methods (cherry picking and format-patch-ing) are still useful,
> because all of these approaches have the same effect, which may help
> demystify the process for newbies.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index a8f792d..5d80b40 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2532,6 +2532,13 @@ return mywork to the state it had before you started the rebase:
> $ git rebase --abort
> -------------------------------------------------
>
> +If you need to reorder or edit a number of commits in a branch, it may
> +be easier to use `git rebase -i`, which allows you to reorder and
> +squash commits, as well as marking them for individual editing during
> +the rebase. See linkgit:git-rebase[1] for details, and
> +<<reordering-patch-series>> for alternatives.
> +
> +
This change is very good (modulo the extra blank line at the end).
> [[rewriting-one-commit]]
> Rewriting a single commit
> -------------------------
> @@ -2546,10 +2553,10 @@ $ git commit --amend
> which will replace the old commit by a new commit incorporating your
> changes, giving you a chance to edit the old commit message first.
>
> -You can also use a combination of this and linkgit:git-rebase[1] to
> -replace a commit further back in your history and recreate the
> -intervening changes on top of it. First, tag the problematic commit
> -with
> +You can also use a combination of `commit --amend` and
> +linkgit:git-rebase[1] (see <<using-git-rebase>>) to replace a commit
> +further back in your history and recreate the intervening changes on
> +top of it. First, tag the problematic commit with
I think this section can use a lot more love. There is no reason to
have "bad" tag (tagging the tip of mywork might have made sense in
the old days without detached HEAD or reflog), for example.
Alternatively, we can explain only the amending of the tip commit in
this section, removing everything else; I think that is probably a
better option. The series of sections around here would then look
like:
* The section before this talked about a straight-forward "rebase";
* This section then talks about "commit --amend", nothing else;
* The next section talks about taking "format-patch A..B", flipping
its output around and applying to A. Enhance that section with
the material to be removed from here, which talks about applying
"format-patch A..B" on top of the amended A.
* Then add a separate section after that "Reordering or selecting
from a patch series" section to discuss "rebase -i".
Hmm?
> -------------------------------------------------
> $ git tag bad mywork~5
> @@ -2584,6 +2591,12 @@ new commits having new object names.
> Reordering or selecting from a patch series
> -------------------------------------------
>
> +There are a number of ways you can go about editing an existing patch
> +series. The easiest way is probably by using `git rebase -i`,
> +mentioned in <<using-git-rebase>>, but whether you use
> +linkgit:git-rebase[1] or one of the methods discussed below, the
> +effect is the same. Pick whichever approach you like best.
> +
> Given one existing commit, the linkgit:git-cherry-pick[1] command
> allows you to apply the change introduced by that commit and create a
> new commit that records it. So, for example, if "mywork" points to a
^ permalink raw reply
* Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: W. Trevor King @ 2013-02-10 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7vd2w7uajk.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Sun, Feb 10, 2013 at 01:24:47PM -0800, Junio C Hamano wrote:
> I would not be surprised if some readers felt as if "then why not
> update it instead of rejecting?" were a valid question, without a
> bit more explanation.
>
> You can also push to a repository that has a working tree,
> …
Looks good to me :). Shall I just drop this patch from v3 and leave
it to you?
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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