On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
wrote:
> What's wrong with
> $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
> $ git push --all git@remotehost:MyOtherRepo.git
> ?
Nothing, I just wanted to make myself a command to do that for me.
>> The reason I
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> +To disable interactive logins, displaying a greeting instead:
>> ++
>> +
>> +$ chsh -s /usr/bin/git-shell
>> +$ mkdir $HOME/git-shell-commands
>> +$ cat >$HOME/git-shell-commands/help <<\EOF
>> +#!/bin/sh
>> +printf '%s\n' "Hi $U
On Sun, Feb 10, 2013 at 04:00:56PM -0500, Ethan Reesor wrote:
> 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
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> Isn't that a criticism of the git-shell-commands facility in general?
>>> If it is common to have a lot of users with distinct home directories
>>> but all with git-shell as their login shell, then the
>>> git-shell
Ethan Reesor writes:
> On Mon, Feb 11, 2013 at 2:22 AM, Junio C Hamano wrote:
>> Ethan Reesor writes:
>>> Again, would it not be more elegant and powerful to A) have the
>>> shell-disabled message/hook/etc specified by git-config on some level,
>>> be it /etc/gitconfig or ~/.gitconfig, and B) h
On Mon, Feb 11, 2013 at 2:22 AM, Junio C Hamano wrote:
> Ethan Reesor writes:
>> Again, would it not be more elegant and powerful to A) have the
>> shell-disabled message/hook/etc specified by git-config on some level,
>> be it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch
>> where
Ethan Reesor writes:
>> For those who _do_ want to give customized commands to their users,
>> they can already have "help" script to give a friendly message. It
>> just felt silly to force sites to create the directory only to
>> refuse an access to the "custom commands" feature, especially whe
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Isn't that a criticism of the git-shell-commands facility in general?
>> If it is common to have a lot of users with distinct home directories
>> but all with git-shell as their login shell, then the
>> git-shell-commands should not go in their h
On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder wrote:
> Isn't that a criticism of the git-shell-commands facility in general?
> If it is common to have a lot of users with distinct home directories
> but all with git-shell as their login shell, then the
> git-shell-commands should not go in thei
Jonathan Nieder writes:
> Isn't that a criticism of the git-shell-commands facility in general?
> If it is common to have a lot of users with distinct home directories
> but all with git-shell as their login shell, then the
> git-shell-commands should not go in their home directory to begin
> wit
On Mon, Feb 11, 2013 at 2:01 AM, Junio C Hamano wrote:
> And for the remaining 20% of those who do not like the canned
> message but still do not need any custom command, I think it is way
> suboptimal to force them to create git-shell-commands directory for
> 47 users his host gives git-shell acc
Jonathan Nieder writes:
> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
> index 4fe93203..60051e63 100644
> --- a/Documentation/git-shell.txt
> +++ b/Documentation/git-shell.txt
> @@ -59,6 +59,26 @@ users to list repositories they have access to, create,
> delete, or
>
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> --- a/Documentation/git-shell.txt
>> +++ b/Documentation/git-shell.txt
>> @@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access
>> SYNOPSIS
>>
>> [verse]
>> -'git shell' [-c ]
>> +'chsh' -s $(which git-shell) g
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> The trouble is that I can't imagine a canned message that everyone
>> will like. (For example, I quite dislike the current one.) That's
>> exactly the situation in which some configurability is helpful.
>
> I am not saying we should have a perf
Jonathan Nieder writes:
> diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
> index 9b925060..4fe93203 100644
> --- a/Documentation/git-shell.txt
> +++ b/Documentation/git-shell.txt
> @@ -9,25 +9,61 @@ git-shell - Restricted login shell for Git-only SSH access
> SYNOPSIS
>
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>>> Junio C Hamano wrote:
>
Are you shooting for customizability?
>>>
>>> Yes, and the ability to generate the message dynamically.
>>
>> Hmph, if that is the case, wouldn't it be a better direction to
On Mon, Feb 11, 2013 at 1:15 AM, Jonathan Nieder wrote:
> [administrivia: please don't top-post]
> Ethan Reesor wrote:
>
>> Why not have both? That way there is a way to get a customizable
>> response that avoids Junio's complaints and there is a way to do what
>> you are trying to achieve.
>
> Wh
If I understand correctly,
in your scenario the branches with branch..pushremote
will be still included in the $git push --all?
Are you considering some way to exclude a branch from "push --all"
(branch..push = always, explicit, never... for example)?
Or maybe, if the branch is already marked as s
[administrivia: please don't top-post]
Ethan Reesor wrote:
> Why not have both? That way there is a way to get a customizable
> response that avoids Junio's complaints and there is a way to do what
> you are trying to achieve.
What was Junio's complaint?
Jonathan
--
To unsubscribe from this list
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Junio C Hamano wrote:
>>> Are you shooting for customizability?
>>
>> Yes, and the ability to generate the message dynamically.
>
> Hmph, if that is the case, wouldn't it be a better direction to give
> a better help for majority of
Why not have both? That way there is a way to get a customizable
response that avoids Junio's complaints and there is a way to do what
you are trying to achieve.
On Mon, Feb 11, 2013 at 1:09 AM, Jonathan Nieder wrote:
> Ethan Reesor wrote:
>
>>That way, there's a default s
Ethan Reesor wrote:
>That way, there's a default setting, there can
> be a system-wide message, there can be a user specific message, and
> those messages can be set via `git-commit`.
That won't let me imitate gitolite's behavior without a lot of
config file churn:
I noticed a typo I made. I meant `git-config` rather than
`git-commit`. Sorry for my mistake.
On Mon, Feb 11, 2013 at 12:57 AM, Ethan Reesor wrote:
> On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano wrote:
>> Hmph, if that is the case, wouldn't it be a better direction to give
>> a better help f
I feel like the suggestion I posted in response to Junio C Hamano
's complaint on the RFC for this patch provides a
more elegant solution to the problem of administrators wanting to
prevent interactive sessions for users with their login shell set to
git-prompt. The suggestion was as follows:
> Ho
If I disable git-shell's interactive mode by removing the
~/git-shell-commands directory, then attempts to use 'ssh' with the
git account interactively produce an error message intended for the
administrator:
$ ssh git@myserver
fatal: Interactive git shell is not enabled.
h
The original git-shell(1) manpage emphasized that the shell
supports only git transport commands, and as the shell gained
features that emphasis and focus in the manual has been lost.
Bring it back by splitting the manpage into a few short sections
and fleshing out each:
- SYNOPSIS, describing ho
On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano wrote:
> Hmph, if that is the case, wouldn't it be a better direction to give
> a better help for majority of the case where git-shell is used as
> the login shell to allow push and fetch but not for interactive
> access at all?
>
> The first step i
Jeff King wrote:
> I think what threw me off was reading the documentation part of the
> patch, which adds a note that we run "help" on startup, and then
> elaborates on the exit value. I didn't realize that the first half was
> documenting what already happened.
>
> Tweaking the third paragraph o
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> Are you shooting for customizability?
>
> Yes, and the ability to generate the message dynamically.
Hmph, if that is the case, wouldn't it be a better direction to give
a better help for majority of the case where git-shell is us
On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
> diff --git a/shell.c b/shell.c
> index 84b237fe..3abc2b84 100644
> --- a/shell.c
> +++ b/shell.c
> @@ -63,10 +63,16 @@ static void cd_to_homedir(void)
>
> static void run_shell(void)
> {
> - int done = 0;
> + int done =
On Sun, Feb 10, 2013 at 08:32:47PM -0800, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
> > Are you shooting for customizability?
>
> Yes, and the ability to generate the message dynamically.
As far as the default goes, I think the current one is OK, provided
there is an option
On Sun, Feb 10, 2013 at 08:26:09PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
>
> >> Only interactive connections. That's the existing behavior.
> >
> > Ah, sorry. I misread the patch. I see now that we already run help,
Junio C Hamano wrote:
> Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> How about this?
>>>
>>> A patch on top could change the default "git-shell-commands is not
>>> present" message if that seems worthwhile.
>>
>> Hmph.
>>
>> I wonder if rewording the message when git-shell-commmands
Jeff King wrote:
> On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
>> Only interactive connections. That's the existing behavior.
>
> Ah, sorry. I misread the patch. I see now that we already run help, and
> this is just making the exit value significant. In that case, yeah, I
>
On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
>
> >> +When run interactively (with no arguments), 'git-shell' will
> >> +automatically run `~/git-shell-commands/help` on startup, provided it
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> How about this?
>>
>> A patch on top could change the default "git-shell-commands is not
>> present" message if that seems worthwhile.
>
> Hmph.
>
> I wonder if rewording the message when git-shell-commmands directory
> is not there may be a bett
Jeff King wrote:
> On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
>> +When run interactively (with no arguments), 'git-shell' will
>> +automatically run `~/git-shell-commands/help` on startup, provided it
>> +exists. If the 'help' command fails then the interactive shell is
>> +
On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
> > This of course now means that the ~/git-shell-commands should not be
> > empty, since that is where this default command also will be present.
>
> How about this?
I like the general direction this is going, but:
> +When run in
On Sun, Feb 10, 2013 at 11:58 PM, Erik Faye-Lund wrote:
> Karsten Blees has done something similar-ish on Windows, and he posted
> the results here:
>
> https://groups.google.com/forum/#!topic/msysgit/fL_jykUmUNE/discussion
>
> I also seem to remember he doing a ReadDirectoryChangesW version, but
Jonathan Nieder writes:
> How about this?
>
> A patch on top could change the default "git-shell-commands is not
> present" message if that seems worthwhile.
Hmph.
I wonder if rewording the message when git-shell-commmands directory
is not there may be a better first step (which actually could
On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh wrote:
> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>
>>> This is much better than Junio's suggestion to study possible
>>> implementations on all platforms and designing a generic daemon/
>>> communication c
On Sun, Feb 10, 2013 at 11:45 PM, Ramkumar Ramachandra
wrote:
> So you're skipping the rest of refresh_cache_ent(), which contains our
> lstat() and returning immediately. Instead of marking paths with the
> "assume unchanged" bit, as core.ignoreStat does, you're directly
> attacking the function
On Mon, Feb 11, 2013 at 3:16 AM, Junio C Hamano wrote:
> 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 bothe
If I disable git-shell's interactive mode by removing the
~/git-shell-commands directory, then attempts to use 'ssh' with the
git account interactively produce an error message intended for the
administrator:
$ ssh git@myserver
fatal: Interactive git shell is not enabled.
h
On Mon, Feb 11, 2013 at 4:24 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> 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.
On Sun, Jan 27, 2013 at 7:39 PM, Jonathan Nieder wrote:
> Brandon Casey wrote:
>
>> --- a/log-tree.c
>> +++ b/log-tree.c
> [...]
>> @@ -208,94 +207,6 @@ void show_decorations(struct rev_info *opt, struct
>> commit *commit)
>> putchar(')');
>> }
>>
>> -/*
>> - * Search for "^[-A-Za-z]+: [^@
On Sun, Jan 27, 2013 at 7:14 PM, Jonathan Nieder wrote:
> Brandon Casey wrote:
>
>> --- a/sequencer.c
>> +++ b/sequencer.c
> [...]
>> @@ -1096,10 +1117,16 @@ void append_signoff(struct strbuf *msgbuf, int
>> ignore_footer)
>> strbuf_addch(&sob, '\n');
>> for (i = msgbuf->len - 1 - ign
On Sun, Jan 27, 2013 at 6:34 PM, Jonathan Nieder wrote:
> Brandon Casey wrote:
>
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -497,6 +558,8 @@ static int do_pick_commit(struct commit *commit, struct
>> replay_opts *opts)
>> }
>>
>> if (opts->record_origin) {
>> +
On Sun, Feb 10, 2013 at 02:09:50PM -0800, Junio C Hamano wrote:
> 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 n
Junio C Hamano 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
>> +---
On Sun, Feb 10, 2013 at 02:52:23PM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > 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
> >>
On Sun, Feb 10, 2013 at 02:45:59PM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > 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
Jeff King writes:
> 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
"W. Trevor King" writes:
> 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 ori
On Sun, Feb 10, 2013 at 02:48:01PM -0800, Junio C Hamano wrote:
> How about not saying anything and say "adds the following"?
Will do in 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
si
"W. Trevor King" 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 unfami
"W. Trevor King" 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
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
John Keeping 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
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 (Docum
"W. Trevor King" 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 repositor
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, b
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> 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: Rewrit
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
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> 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
> ---
This is a "meh" at least to me. Unless it uses something like
git archive -o
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 suppos
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> Less work and more error checking (e.g. does a merge base exist?).
>
> Signed-off-by: W. Trevor King
> ---
> Documentation/user-manual.txt | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/us
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 s
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> 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 config
"W. Trevor King" 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
> perfor
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 helpf
"W. Trevor King" 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
> perfor
On Sun, Feb 10, 2013 at 02:00:50PM -0800, Junio C Hamano wrote:
> "W. Trevor King" 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:/
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> This mirrors existing language in the description of 'git fetch'.
>
> Signed-off-by: W. Trevor King
> ---
> Documentation/user-manual.txt | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/user-manual.txt b/Docume
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 probabl
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
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
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 hidi
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> 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 for
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,
> …
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> 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 (u
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> 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
> ---
> Documentation/user-manual.txt | 17 ++
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 she
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> 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
> 'r
On Sun, Feb 10, 2013 at 11:30:39AM -0800, Junio C Hamano wrote:
> John Keeping 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
On Feb 10, 2013, at 1:26 PM, Martin Fick 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
> wrote:
>>> Ramkumar Ramachandra writes:
This is much better than Junio's suggestion to study
possible implementations on a
Duy Nguyen 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
Am 08.02.2013 21:17, schrieb Junio C Hamano:
> Ramkumar Ramachandra writes:
>
>> BTW, Is there a better way to clean out the worktree than `git rm -rf
>> .`, since that fails for submodules? The impulsive `reset --hard`
>> obviously fails because there is no HEAD.
>
> I _think_ the "git rm" is
John Keeping 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
>
On Sunday, February 10, 2013 12:03:00 pm Robert Zeh wrote:
> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano
wrote:
> > Ramkumar Ramachandra writes:
> >> This is much better than Junio's suggestion to study
> >> possible implementations on all platforms and
> >> designing a generic daemon/ commun
On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano wrote:
> Ramkumar Ramachandra 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
On Sun, Feb 10, 2013 at 12:17 PM, Duy Nguyen wrote:
> On Sun, Feb 10, 2013 at 12:24:58PM +0700, Duy Nguyen wrote:
>> On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
>> wrote:
>> > Finn notes in the commit message that it offers no speedup, because
>> > .gitignore files in every directory s
On Sun, Feb 10, 2013 at 4:47 PM, Duy Nguyen wrote:
> On Sun, Feb 10, 2013 at 12:24:58PM +0700, Duy Nguyen wrote:
>> On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
>> wrote:
>> > Finn notes in the commit message that it offers no speedup, because
>> > .gitignore files in every directory st
Junio C Hamano wrote:
> struct bp { const char *branch; const char *remotename; };
>
> static int pushremote(const char *var, const char *val, void *cb)
> {
> struct bp *bp = cb;
> const char *name, *key;
> int namelen;
>
>
On Sun, Feb 10, 2013 at 8:26 PM, demerphq wrote:
> On 10 February 2013 12:17, Duy Nguyen wrote:
>> Bear in mind though this is Linux, where lstat is fast. On systems
>> with slow lstat, these timings could look very different due to the
>> large number of lstat calls compared to open+getdents. I
On Sun, Feb 10, 2013 at 10:10:34AM -0500, W. Trevor King wrote:
> @@ -4155,8 +4156,9 @@ As a result, the general consistency of an object can
> always be tested
> independently of the contents or the type of the object: all objects can
> be validated by verifying that (a) their hashes match the
From: "W. Trevor King"
I tried to always use backticks for:
* Paths and filenames (e.g. `.git/config`)
* Compound refs (e.g. `origin/HEAD`)
* Git commands (e.g. `git log`)
* Command arguments (e.g. `--pretty`)
* URLs (e.g. `git://`), as a subset of command arguments
* Special characters (e.g. `+`
From: "W. Trevor King"
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
From: "W. Trevor King"
I hardly ever setup remote..url using 'git config'. While it
may be instructive to do so, we should also point out 'git remote
add'.
Signed-off-by: W. Trevor King
---
Documentation/user-manual.txt | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
1 - 100 of 119 matches
Mail list logo
