* 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
* Re: [PATCH v2 04/15] user-manual: Use git branch --merged
From: Junio C Hamano @ 2013-02-10 21:37 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <c8abf7a75a59302e6bdc66eee13eb2ec53b26b46.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> Use 'git branch --merged origin'. This feature was introduced by
> 049716b (branch --merged/--no-merged: allow specifying arbitrary
> commit, 2008-07-08), after the documentation that's being replaced
> moved into the manual with 9e2163ea (user-manual: move
> howto/using-topic-branches into manual, 2007-05-13).
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 53f73c3..a8f792d 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2267,10 +2267,10 @@ then pulled by Linus, and finally coming back into your local
> You detect this when the output from:
>
> -------------------------------------------------
> -$ git log origin..branchname
> +$ git branch --merged origin
> -------------------------------------------------
>
> -is empty. At this point the branch can be deleted:
> +lists the branch. At this point the branch can be deleted:
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.
^ permalink raw reply
* Re: [PATCH v2 03/15] user-manual: Use 'remote add' to setup push URLs
From: Junio C Hamano @ 2013-02-10 21:33 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <44d89e81a8465d3bbf50b106a8a844c9d90ac384.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> There is no need to use here documents to setup this configuration.
> It is easier, less confusing, and more robust to use Git's
> configuration tools directly.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 8524c08..53f73c3 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1994,14 +1994,17 @@ default. See the description of the receive.denyCurrentBranch option
> in linkgit:git-config[1] for details.
>
> As with `git fetch`, you may also set up configuration options to
> -save typing; so, for example, after
> +save typing; so, for example, after either
>
> --------------------------------------------------
> -$ cat >>.git/config <<EOF
> -[remote "public-repo"]
> - url = ssh://yourserver.com/~you/proj.git
> -EOF
> --------------------------------------------------
> +------------------------------------------------
> +$ git remote add public-repo ssh://yourserver.com/~you/proj.git
> +------------------------------------------------
> +
> +or, more explicitly,
> +
> +------------------------------------------------
> +$ git config remote.public-repo.url ssh://yourserver.com/~you/proj.git
> +------------------------------------------------
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. The resulting text may read
like so:
...
save typing; so for example:
------------
$ git remote add public-repo yourserver.com:proj.git
------------
will add this to your configuration:
------------
$ cat .git/config
...
[remote "public-repo"]
url = yourserver.com:proj.git
...
------------
which lets you do the same push with just
------------
$ git push public-repo master
------------
^ permalink raw reply
* Re: Git prompt
From: Jonathan Nieder @ 2013-02-10 21:25 UTC (permalink / raw)
To: Ethan Reesor; +Cc: git, Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <CAE_TNikk-9sYVRQRwRecNpp3otQ+oc=uV9SPu+7pAkCUNbcUoQ@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: Junio C Hamano @ 2013-02-10 21:24 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <ba62167be6df7a6ba666373913bfd235bcc29c9d.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> acd2a45 (Refuse updating the current branch in a non-bare repository
> via push, 2009-02-11) changed the default to refuse such a push, but
> it forgot to update the docs.
>
> 7d182f5 (Documentation: receive.denyCurrentBranch defaults to
> 'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to
> update the user manual.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 222545b..8524c08 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1988,8 +1988,10 @@ handling this case.
> Note that the target of a "push" is normally a
> <<def_bare_repository,bare>> repository. You can also push to a
> repository that has a checked-out working tree, but the working tree
> -will not be updated by the push. This may lead to unexpected results if
> -the branch you push to is the currently checked-out branch!
> +will not be updated by the push. To protect against this, pushes to
> +the currently checked-out branch of a repository are denied by
> +default. See the description of the receive.denyCurrentBranch option
> +in linkgit:git-config[1] for details.
Nobody else felt the same logic gap between "will not be updated"
and "to protect against this" I sensed while reading this?
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,
but a push to the currently checked out branch is denied for
two reasons:
(1) if the push were allowed to update the working tree to
match the pushed commit, it will overwrite and lose the
work in progress in the working tree;
(2) the push does _not_ update the working tree for the
above reason, but then if the push were allowed to
update the tip of the branch, the next commit made based
on the work done in the working tree will be based on
the state of the tree _before_ the push but will be
recorded as a descendant of the pushed commit, reverting
changes to the contents made by the pushed commit.
If you want to handle the above two risks yourself (e.g. you
can promise that you will never make changes to the files in
the working tree or make commit from the working tree, and
install a post-push hook that does "git reset --hard" to
match the working tree state to the commit that was pushed),
you can override this by setting receive.denyCurrentBranch.
It almost makes me wonder if it also makes sense to supersede the
denyCurrentBranch setting with a new receive.currentBranch variable
(setting it to "deny" is equivalent to setting denyCurrentBranch to
true), and make "receive.currentBranch = reset" to allow a push and
always run "git reset --hard" afterwards.
If we were to do so, I would strongly be against adding "checkout"
mode that does "git reset --keep" instead of "--hard". Those who can
accept the unconditional ovewriting with "reset --hard" are the only
ones that are safe if "push" updated the tip of the branch and the
working tree. Updating the working tree with a "reset --keep" may
appear safe because it will catch the case where a file that needs
updating by "push" is modified, but that is an incorrect assumption.
It does not mean nobody has the contents in the editor buffer with
changes yet to be written out. An automated update to the working
tree condition has to be allowed only to a repository with nobody
sitting at the keyboard editing files in there.
^ permalink raw reply
* Git prompt
From: Ethan Reesor @ 2013-02-10 21:05 UTC (permalink / raw)
To: git
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. The server works as a
git remote using ssh and the git user. When I `ssh git@server` I get a
prompt where I can do nothing. When you ssh to github.com, you recieve
this message: "Hi username! You've successfully authenticated, but
GitHub does not provide shell access."
How do I make the git user work like github where, upon attempting to
get a prompt, the connection is closed?
--
Ethan Reesor
^ permalink raw reply
* Re: [PATCH] fixup! graph: output padding for merge subsequent parents
From: John Keeping @ 2013-02-10 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthieu Moy, Michał Kiedrowicz
In-Reply-To: <7vliawt19c.fsf@alter.siamese.dyndns.org>
On Sun, Feb 10, 2013 at 11:30:39AM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > Can you squash this into the first commit before you do?
> >
> > Matthieu is correct that the graph_is_commit_finished() check isn't
> > needed in the loop now that we've pulled it out to be checked first -
> > the value returned can't change during the loop. I've left the early
> > return out.
> >
> > graph.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/graph.c b/graph.c
> > index 2a3fc5c..56f970f 100644
> > --- a/graph.c
> > +++ b/graph.c
> > @@ -1237,7 +1237,7 @@ void graph_show_commit(struct git_graph *graph)
> > shown_commit_line = 1;
> > }
> >
> > - while (!shown_commit_line && !graph_is_commit_finished(graph)) {
> > + while (!shown_commit_line) {
> > shown_commit_line = graph_next_line(graph, &msgbuf);
> > fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
> > if (!shown_commit_line)
>
> 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.
John
^ permalink raw reply
* Pushing a git repository to a new server
From: Ethan Reesor @ 2013-02-10 21:00 UTC (permalink / raw)
To: git
I'm looking to make a command to push a git repo to a new server. The
way I just did it is as follows:
localhost> git clone --bare /path/to/MyRepo /path/to/tmpdir/MyRepo.git
localhost> tar xz /path/to/tmpdir/MyRepo.git | ssh myuser@remotehost
tar cz \~/ # If I don't escape '~', my local machine expands it
localhost> ssh myuser@remotehost
remotehost> sudo chown -R git:git MyRepo.git
The reason I had to use my user is the git user's shell is git-prompt
and ~git/git-shell-commands is empty. I have repos set up using
'git@remotehost:MyOtherRepo.git' as the remote and everything works.
How do I make a git command that can talk to the server using
git-prompt like the other commands do?
--
Ethan Reesor
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Robert Zeh @ 2013-02-10 20:18 UTC (permalink / raw)
To: Martin Fick; +Cc: Junio C Hamano, Ramkumar Ramachandra, Git List, Duy Nguyen
In-Reply-To: <201302101226.12646.mfick@codeaurora.org>
On Feb 10, 2013, at 1:26 PM, Martin Fick <mfick@codeaurora.org> wrote:
> On Sunday, February 10, 2013 12:03:00 pm Robert Zeh wrote:
>> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano
> <gitster@pobox.com> wrote:
>>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>>> This is much better than Junio's suggestion to study
>>>> possible implementations on all platforms and
>>>> designing a generic daemon/ communication channel.
>>>> That's no weekend project.
>>>
>>> It appears that you misunderstood what I wrote. That
>>> was not "here is a design; I want it in my system. Go
>>> implemment it".
>>>
>>> It was "If somebody wants to discuss it but does not
>>> know where to begin, doing a small experiment like
>>> this and reporting how well it worked here may be one
>>> way to do so.", nothing more.
>>
>> What if instead of communicating over a socket, the
>> daemon dumped a file containing all of the lstat
>> information after git wrote a file? By definition the
>> daemon should know about file writes.
>
> But git doesn't, how will it know when the file is written?
> Will it use inotify, or poll (kind of defeats the point)?
>
> -Martin
I was thinking it would loop on calls to stat for the file with a timeout; this is no different than what we would want to do over a socket in that we would need timeouts for network reads. But we would only be calling stat on one file, instead of the entire repo.
I think we can set things up so the file read is atomic, which means we can ignore the case of a daemon crashing midway through a conversation.
Robert
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Junio C Hamano @ 2013-02-10 20:16 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Ramkumar Ramachandra, Robert Zeh, Git List, finnag
In-Reply-To: <20130210112205.GA28434@lanh>
Duy Nguyen <pclouds@gmail.com> writes:
> On Sun, Feb 10, 2013 at 06:17:32PM +0700, Duy Nguyen wrote:
>> The following patch eliminates untracked search code. As we can see,
>> open+getdents also disappears with this patch:
>>
>> 0.462909 40950 lstat 0.462909 40950 lstat
>> 0.003417 129 brk 0.003417 129 brk
>> 0.000762 53 read 0.000762 53 read
>> 0.000720 36 open 0.000720 36 open
>> 0.000544 12 munmap 0.000454 33 close
>
> .. and the patch is missing:
>
> -- 8< --
> diff --git a/dir.c b/dir.c
> index 57394e4..1963c6f 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1439,8 +1439,10 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
> return dir->nr;
>
> simplify = create_simplify(pathspec);
> +#if 0
> if (!len || treat_leading_path(dir, path, len, simplify))
> read_directory_recursive(dir, path, len, 0, simplify);
> +#endif
The other "lstat()" experiment was a very interesting one, but this
is not yet an interesting experiment to see where in the "ignore"
codepath we are spending times.
We know that we can tell wt_status_collect_untracked() not to bother
with the untracked or ignored files with !s->show_untracked_files
already, but I think the more interesting question is if we can show
the untracked files with less overhead.
If we want to show untrackedd files, it is a given that we need to
read directories to see what paths there are on the filesystem. Is
the opendir/readdir cost dominating in the process? Are we spending
a lot of time sifting the result of opendir/readdir via the ignore
mechanism? Is reading the "ignore" files costing us much to prime
the ignore mechanism?
If readdir cost is dominant, then that makes "cache gitignore" a
nonsense proposition, I think. If you really want to "cache"
something, you need to have somebody (i.e. a daemon) who constantly
keeps an eye on the filesystem changes and can respond with the up
to date result directly to fill_directory(). I somehow doubt that
it is a direction we would want to go in, though.
^ 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