* Re: [PATCH] Use the best available exec path only
From: Johannes Schindelin @ 2007-11-11 20:50 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Brian Gernhardt, Git Mailing List
In-Reply-To: <20071111203318.GA32671@atjola.homenet>
Hi,
On Sun, 11 Nov 2007, Bj?rn Steinbrink wrote:
> On 2007.11.11 11:43:02 -0800, Junio C Hamano wrote:
> > Brian Gernhardt <benji@silverinsanity.com> writes:
> >
> > > I'm sorry, I should have been more clear. I was referring to the
> > > GIT_EXEC_PATH build variable, not the environment variable. The git
> > > wrapper always adds the path determined during build to the front of
> > > PATH. When I was changing my build script, this got set to "/usr/
> > > local/bin" (I usually use /usr/local/stow/git, instead). Since I
> > > have a /usr/local/bin/vim, PATH for git-commit.sh during the test
> > > was:
> > >
> > > - my git build directory
> > > - /usr/local/bin (containing a symlink vi -> vim)
> > > - the t/trash directory, added by the test via `PATH=".:$PATH"`
> > > (containing the test vi script)
> > > - my normal path
> >
> > Maybe that is what is broken. t/test-lib.sh makes the environment
> > variable point at the build directory, and that should override the
> > path that is compiled in, shouldn't it?
>
> Maybe you prefer this patch then? "make test" survived up to 9101/25,
> but that fails with the current master anyway and I didn't bother to run
> the remaining tests manually, so it seems to be fine. Might break some
> weird setups that rely on being able to set multiple additional paths
> though (not that I think that that is a good idea to begin with).
>
> Bj?rn
> ---
> Instead of adding all possible exec paths to PATH, only add the best
> one, following the same rules that --exec-path, without arguments, uses
> to figure out which path to display.
>
> Signed-off-by: Bj?rn Steinbrink <B.Steinbrink@gmx.de>
> ---
For easy application by the maintainer, please make the commit message the
first part, then have a single "---", and then the quoted mail.
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 2d0a758..9c376ad 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -48,9 +48,7 @@ void setup_path(const char *cmd_path)
>
> strbuf_init(&new_path, 0);
>
> - add_path(&new_path, argv_exec_path);
> - add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
> - add_path(&new_path, builtin_exec_path);
> + add_path(&new_path, git_exec_path());
> add_path(&new_path, cmd_path);
I wonder why cmd_path is still there, then. (I'd have expected something
like
add_path(&new_path, cmd_path ? cmd_path : git_exec_path());
In related news, IMO cmd_path should be made absolute if it is not already
the case.
Ciao,
Dscho
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Steffen Prohaska @ 2007-11-11 20:59 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711111136s20616468sd70b4bb19e7f3d0c@mail.gmail.com>
On Nov 11, 2007, at 8:36 PM, Jon Smirl wrote:
> On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> On Nov 11, 2007, at 7:02 PM, Jon Smirl wrote:
>>
>>> Is the remote config not correct?
>>
>> This is the configuration for remote "dreamhost". In your
>> previous mail you also mentioned a remote "linus". But
>> this seems to be unrelated to your question.
>>
>>
>>> [remote "dreamhost"]
>>> url = ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git
>>> fetch = +refs/heads/*:refs/remotes/dreamhost/*
>>
>> correct. This fetches the branches from the remote and stores
>> them locally as remote tracking branches "dreamhost/<branch>".
>>
>>> push = +refs/heads/*:refs/remotes/linus/*
>>
>> This "renames" your branches when you push. Your local branches
>> get pushed to "dreamhost" and are stored there as remote branches
>> "linus/<branch>". From your previous mail I assume you like to store
>> them as normal branches. You'd need to say
>
> I did this part incorrectly. I was trying to push my local definition
> of the linus remote to the dreamhost repo so that when someone clones
> dreamhost linus would be defined in their repo.
>
> jonsmirl@terra:~/mpc5200b$ git remote show linus
> * remote linus
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> linux-2.6.git
>
> How do I push the definition of the linus remote repo?
You can't. Remotes are local to a repository. They cannot be
"pushed" nor will they be "cloned" or "fetched".
Steffen
^ permalink raw reply
* Re: [PATCH] Use the best available exec path only
From: Jakub Narebski @ 2007-11-11 21:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711112047170.4362@racer.site>
Johannes Schindelin wrote:
> On Sun, 11 Nov 2007, Björn Steinbrink wrote:
>>
>> ---
>> Instead of adding all possible exec paths to PATH, only add the best
>> one, following the same rules that --exec-path, without arguments, uses
>> to figure out which path to display.
>>
>> Signed-off-by: Bj?rn Steinbrink <B.Steinbrink@gmx.de>
>> ---
>
> For easy application by the maintainer, please make the commit message the
> first part, then have a single "---", and then the quoted mail.
There are two conventions, for slightly different cases:
1. Commit message, then diffstat / single "---", then comments,
then patch
2. Email (for example long discussion), then separator BUT NOT "---";
use for example "-- >8 --" (cut here scissors), then commit message,
then diffstat and patch, beginning with "---".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Junio C Hamano @ 2007-11-11 21:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0711111103240.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sat, 10 Nov 2007, Ask Bj?rn Hansen wrote:
>
>> For new users the superfluous programs are a burden making it harder to
>> learn how everything works.
>
> This should be a non-issue. We really should start deprecating
> "git-<command>" in favour of "git <command>" for real.
>
> New users should not even be told that this is correct usage.
>
> My reason? We have plumbing, and we will always have plumbing, as
> commands. A regular git user does not _want_ to see that. Without said
> deprecation she _will_, however.
If you can write "git-commit" and "git commit" interchangeably
while you cannot say "git-cat-file" and are forced to say "git
cat-file", I suspect that would lead to a great confusion and
unhappy users.
I wonder if making the distinction between plumbing and
porcelain in the git(7) page even more cleaner would help.
^ permalink raw reply
* Re: [PATCH] Use the best available exec path only
From: Björn Steinbrink @ 2007-11-11 21:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Brian Gernhardt, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711112047170.4362@racer.site>
On 2007.11.11 20:50:40 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Bj?rn Steinbrink wrote:
>
> > On 2007.11.11 11:43:02 -0800, Junio C Hamano wrote:
> > > Brian Gernhardt <benji@silverinsanity.com> writes:
> > >
> > > > I'm sorry, I should have been more clear. I was referring to the
> > > > GIT_EXEC_PATH build variable, not the environment variable. The git
> > > > wrapper always adds the path determined during build to the front of
> > > > PATH. When I was changing my build script, this got set to "/usr/
> > > > local/bin" (I usually use /usr/local/stow/git, instead). Since I
> > > > have a /usr/local/bin/vim, PATH for git-commit.sh during the test
> > > > was:
> > > >
> > > > - my git build directory
> > > > - /usr/local/bin (containing a symlink vi -> vim)
> > > > - the t/trash directory, added by the test via `PATH=".:$PATH"`
> > > > (containing the test vi script)
> > > > - my normal path
> > >
> > > Maybe that is what is broken. t/test-lib.sh makes the environment
> > > variable point at the build directory, and that should override the
> > > path that is compiled in, shouldn't it?
> >
> > Maybe you prefer this patch then? "make test" survived up to 9101/25,
> > but that fails with the current master anyway and I didn't bother to run
> > the remaining tests manually, so it seems to be fine. Might break some
> > weird setups that rely on being able to set multiple additional paths
> > though (not that I think that that is a good idea to begin with).
> >
> > Bj?rn
> > ---
> > Instead of adding all possible exec paths to PATH, only add the best
> > one, following the same rules that --exec-path, without arguments, uses
> > to figure out which path to display.
> >
> > Signed-off-by: Bj?rn Steinbrink <B.Steinbrink@gmx.de>
> > ---
>
> For easy application by the maintainer, please make the commit message the
> first part, then have a single "---", and then the quoted mail.
OK.
> > diff --git a/exec_cmd.c b/exec_cmd.c
> > index 2d0a758..9c376ad 100644
> > --- a/exec_cmd.c
> > +++ b/exec_cmd.c
> > @@ -48,9 +48,7 @@ void setup_path(const char *cmd_path)
> >
> > strbuf_init(&new_path, 0);
> >
> > - add_path(&new_path, argv_exec_path);
> > - add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
> > - add_path(&new_path, builtin_exec_path);
> > + add_path(&new_path, git_exec_path());
> > add_path(&new_path, cmd_path);
>
> I wonder why cmd_path is still there, then. (I'd have expected something
> like
>
> add_path(&new_path, cmd_path ? cmd_path : git_exec_path());
Wouldn't that break setups where only the "git" wrapper is in $PATH?
cmd_path is just the path to the called executable (argv[0]). As I read
the code, it seems that cmd_path is just a worst case fallback, when the
"real" exec path is messed up somehow. I figured that I'd better keep
it, instead of just dropping it without knowing its intended purpose.
But if you're going to change anything about it, I'd guess that the only
option is to drop it, or change its relative position in PATH.
> In related news, IMO cmd_path should be made absolute if it is not already
> the case.
add_path() already takes care of that.
Björn
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Jon Smirl @ 2007-11-11 21:20 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <B5C127C0-04B8-4469-B6DD-C8B5335BBA88@zib.de>
On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
> > jonsmirl@terra:~/mpc5200b$ git remote show linus
> > * remote linus
> > URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> > linux-2.6.git
> >
> > How do I push the definition of the linus remote repo?
>
> You can't. Remotes are local to a repository. They cannot be
> "pushed" nor will they be "cloned" or "fetched".
Dreamhost is way slow compared to kernel.org, so it is better to clone
from kernel.org first and then pull from dreamhost. What is the right
sequence of commands so that a new user will end up with a kernel they
can use 'git pull' on to get updates from dreamhost? I'll add these to
the repo description page.
I'm trying this locally and I can't figure out the right sequence of
git command to redirect origin from kernel.org to dreamhost.
Doing this was bad, it messed up my heads.
jonsmirl@terra:~/foo/digispeaker$ git remote rm origin
error: unable to resolve reference refs/remotes/origin/master: No such
file or directory
update-ref -d refs/remotes/origin/master
6e800af233e0bdf108efb7bd23c11ea6fa34cdeb: command returned error: 1
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] fix index-pack with packs >4GB containing deltas on 32-bit machines
From: Junio C Hamano @ 2007-11-11 21:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711102319470.21255@xanadu.home>
Looks obviously correct. Thanks.
^ permalink raw reply
* Obscure commit message formatting issue
From: Daniel Barkalow @ 2007-11-11 21:28 UTC (permalink / raw)
To: Junio C Hamano, git
The current code drops extra blank lines between the first line of a
commit message (the summary line) and the remainder. That is:
This is the summary
This is another bit
This is a third bit
turns into:
Subject: This is the summary
Other-Headers:
This is another bit
This is a third bit
This is an issue if you want to generate an email whose body starts with a
blank line, and I assume (although I haven't tried), that rebase would
lose a blank line out of commits formatted like that. We don't seem to
have any tests that require that line to get suppressed, and we also don't
suppress any other blank lines. Is there some reason to do it?
I'd guess that the "first" handling in pp_remainder() was intended to skip
the blank line between the summary line and the body, but that line has
already been consumed by other code.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: t7005 and vi in GIT_EXEC_PATH
From: Junio C Hamano @ 2007-11-11 21:29 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v3avcefg9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> I'm sorry, I should have been more clear. I was referring to the
>> GIT_EXEC_PATH build variable, not the environment variable. The git
>> wrapper always adds the path determined during build to the front of
>> PATH. When I was changing my build script, this got set to "/usr/
>> local/bin" (I usually use /usr/local/stow/git, instead). Since I have
>> a /usr/local/bin/vim, PATH for git-commit.sh during the test was:
>>
>> - my git build directory
>> - /usr/local/bin (containing a symlink vi -> vim)
>> - the t/trash directory, added by the test via `PATH=".:$PATH"`
>> (containing the test vi script)
>> - my normal path
>
> Maybe that is what is broken. t/test-lib.sh makes the
> environment variable point at the build directory, and that
> should override the path that is compiled in, shouldn't it?
Ah, nevermind. I did not see the other messages in the thread.
^ permalink raw reply
* Re: [PATCH] Use the best available exec path only
From: Johannes Schindelin @ 2007-11-11 21:40 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Brian Gernhardt, Git Mailing List
In-Reply-To: <20071111211732.GA11871@atjola.homenet>
Hi,
On Sun, 11 Nov 2007, Bj?rn Steinbrink wrote:
> > In related news, IMO cmd_path should be made absolute if it is not
> > already the case.
>
> add_path() already takes care of that.
Yeah, and cmd_path is not used otherwise. Sorry for the noise.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Move stripspace() and launch_editor() to strbuf.c
From: Junio C Hamano @ 2007-11-11 21:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0711111728380.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> These functions are already declared in strbuf.h, so it is only
> logical to move their implementations to the corresponding file.
> Particularly, since strbuf.h is in LIB_H, but both functions
> were missing from libgit.a.
I think this makes sense for stripspace(), but I have trouble
with launch_editor().
I do not object to have a function in strbuf API that takes a
buffer, allows the end user to interactively edit its content
and returns the updated content. The function was perfectly
fine as a special purpose helper for git-commit and git-tag, but
if you look at the current launch_editor(), it is not suitable
as a generic strbuf library function:
* "Launch" feels as if we are initiating an async operation and
returning from the function without waiting for its
completion, but this is not "launch" but "launch, wait and
return the resulting string". Probably this should be called
edit_buffer() or something like that.
* Instead of dying, it should return exit code and have the
caller choose to die or take any alternative action. The
library function definitely should not say "if you are in an
environment where we cannot let you interactively edit, use
-F or -m option".
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Steffen Prohaska @ 2007-11-11 22:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711111320u1deafe69r96d64babbb893adf@mail.gmail.com>
On Nov 11, 2007, at 10:20 PM, Jon Smirl wrote:
> On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>> jonsmirl@terra:~/mpc5200b$ git remote show linus
>>> * remote linus
>>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>> linux-2.6.git
>>>
>>> How do I push the definition of the linus remote repo?
>>
>> You can't. Remotes are local to a repository. They cannot be
>> "pushed" nor will they be "cloned" or "fetched".
>
> Dreamhost is way slow compared to kernel.org, so it is better to clone
> from kernel.org first and then pull from dreamhost. What is the right
> sequence of commands so that a new user will end up with a kernel they
> can use 'git pull' on to get updates from dreamhost? I'll add these to
> the repo description page.
>
> I'm trying this locally and I can't figure out the right sequence of
> git command to redirect origin from kernel.org to dreamhost.
How about the following (untested sequence)
mkdir linux-2.6
cd linux-2.6
git init
git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/
torvalds/linux-2.6.git
git remote add origin ssh://jonsmirl1@git.digispeaker.com/~/
mpc5200b.git
git fetch linus
git fetch origin
git checkout -b master origin/master
The general idea should be correct. You have a non-standard
setup, so avoid git-clone.
Steffen
^ permalink raw reply
* Re: Obscure commit message formatting issue
From: Junio C Hamano @ 2007-11-11 22:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711111559220.29952@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> The current code drops extra blank lines between the first line of a
> commit message (the summary line) and the remainder.
The patch application side does even more. It not just strips
off the leading or trailing blank lines, but duplicate blank
lines in the middle and trailing whitespaces at the end of each
line.
I am of two minds about the formatting side.
The behaviour you found does not go far enough to correct all of
the above whitespace breakage the application side will fix up
on the generation side -- it only corrects one of them. We
might want to do more, instead of less that you seem to be
implying to favor.
^ permalink raw reply
* Re: [PATCH 5/6] builtin-commit: resurrect behavior for multiple -m options
From: Pierre Habouzit @ 2007-11-11 22:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711112039130.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 3190 bytes --]
On Sun, Nov 11, 2007 at 08:42:48PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Pierre Habouzit wrote:
>
> > On Sun, Nov 11, 2007 at 05:36:39PM +0000, Johannes Schindelin wrote:
> > >
> > > When more than one -m option is given, the message does not replace
> > > the previous, but is appended.
> > >
> > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > ---
> > > builtin-commit.c | 26 ++++++++++++++++++++------
> > > 1 files changed, 20 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/builtin-commit.c b/builtin-commit.c
> > > index 66d7e5e..069d180 100644
> > > --- a/builtin-commit.c
> > > +++ b/builtin-commit.c
> > > @@ -30,13 +30,27 @@ static char *use_message_buffer;
> > > static const char commit_editmsg[] = "COMMIT_EDITMSG";
> > > static struct lock_file lock_file;
> > >
> > > -static char *logfile, *force_author, *message, *template_file;
> > > +static char *logfile, *force_author, *template_file;
> > > static char *edit_message, *use_message;
> > > static int all, edit_flag, also, interactive, only, amend, signoff;
> > > static int quiet, verbose, untracked_files, no_verify;
> > >
> > > static int no_edit, initial_commit, in_merge;
> > > const char *only_include_assumed;
> > > +struct strbuf message;
> >
> > Unless I'm mistaken `static` keywords are missign for`message` and
> > `only_include_assumed`.
>
> Oh yeah. Will fix.
>
> > And you _have_ to initialize message with STRBUF_INIT (remember of the
> > slop).
>
> Not in this case, since I do not use message.buf as long as message.len ==
> 0. But I agree it would be cleaner to just use STRBUF_INIT.
I know that you don't use it, but who knows where this code will be
headed in its future right ? :) It's just good practice.
> > > +static int opt_parse_m(const struct option *opt, const char *arg, int unset)
> > > +{
> > > + struct strbuf *buf = opt->value;
> > > + if (unset)
> > > + strbuf_setlen(buf, 0);
> > > + else {
> > > + strbuf_addstr(buf, arg);
> > > + strbuf_addch(buf, '\n');
> > > + strbuf_addch(buf, '\n');
> > > + }
> > > + return 0;
> > > +}
> >
> > I believe such a callback could live in parse-options.[hc]. The need
> > to aggregate all string arguments into a strbuf looks generic enough to
> > me. Why are you adding two '\n' btw ? Isn't one enough ?
>
> Well, this empty line is needed to stay backwards compatible. It was
> added to pass the test that Junio added to 'next'. As such, this function
> is not really generic enough, right?
Well, you can make it generic enough using the defval to point to a
delimiter to use between lines :) But it's probably an overkill, and yes
if the "\n\n" is to be kept, then it's not generic "enough".
> Well, I meant to mention it in the cover letter. My preference is to do
> away with the extra empty line. But this might break existing setups
> depending on that behaviour.
Right.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] builtin-commit: resurrect behavior for multiple -m options
From: Pierre Habouzit @ 2007-11-11 22:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711112039130.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Sun, Nov 11, 2007 at 08:42:48PM +0000, Johannes Schindelin wrote:
> Well, I meant to mention it in the cover letter. My preference is to do
> away with the extra empty line. But this might break existing setups
> depending on that behaviour.
In fact I believe what matters is that if there is more than one -m,
you have a \n\n between the first and the second one, else it'll break
subjects, and that sucks, so I'd say we have to stay with "\n\n" at
least for the first aggregation, and I'm unsure if it's worth the hassle
to count how many times we aggregated to use '\n' then.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Theodore Tso @ 2007-11-11 22:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <7vd4ugcwkm.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > This should be a non-issue. We really should start deprecating
> > "git-<command>" in favour of "git <command>" for real.
> >
> > New users should not even be told that this is correct usage.
> >
>
> If you can write "git-commit" and "git commit" interchangeably
> while you cannot say "git-cat-file" and are forced to say "git
> cat-file", I suspect that would lead to a great confusion and
> unhappy users.
One of the reasons why I use git-diff and git-commit and in particular
"git-rebase --interactive master" very often is that it allows my
shell's bang completion to work. (i.e., "!git-rebase"). If we tell
people they can not use "git-rebase", and must instead use "git
rebase" instead, I would consider that pretty annoying/obnoxious.
- Ted
^ permalink raw reply
* Re: [PATCH] Move stripspace() and launch_editor() to strbuf.c
From: Johannes Schindelin @ 2007-11-11 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtznsbgcc.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > These functions are already declared in strbuf.h, so it is only
> > logical to move their implementations to the corresponding file.
> > Particularly, since strbuf.h is in LIB_H, but both functions
> > were missing from libgit.a.
>
> I think this makes sense for stripspace(), but I have trouble
> with launch_editor().
>
> I do not object to have a function in strbuf API that takes a
> buffer, allows the end user to interactively edit its content
> and returns the updated content. The function was perfectly
> fine as a special purpose helper for git-commit and git-tag, but
> if you look at the current launch_editor(), it is not suitable
> as a generic strbuf library function:
>
> * "Launch" feels as if we are initiating an async operation and
> returning from the function without waiting for its
> completion, but this is not "launch" but "launch, wait and
> return the resulting string". Probably this should be called
> edit_buffer() or something like that.
>
> * Instead of dying, it should return exit code and have the
> caller choose to die or take any alternative action. The
> library function definitely should not say "if you are in an
> environment where we cannot let you interactively edit, use
> -F or -m option".
All valid points. Will add to my TODO list and repost when done.
Maybe call_editor() instead of edit_buffer()? Since we technically read
the file specified by "path" into the buffer "buffer", after having called
the editor.
Ciao,
Dscho
^ permalink raw reply
* Re: Obscure commit message formatting issue
From: Daniel Barkalow @ 2007-11-11 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprygbfwf.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Nov 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > The current code drops extra blank lines between the first line of a
> > commit message (the summary line) and the remainder.
>
> The patch application side does even more. It not just strips
> off the leading or trailing blank lines, but duplicate blank
> lines in the middle and trailing whitespaces at the end of each
> line.
>
> I am of two minds about the formatting side.
>
> The behaviour you found does not go far enough to correct all of
> the above whitespace breakage the application side will fix up
> on the generation side -- it only corrects one of them. We
> might want to do more, instead of less that you seem to be
> implying to favor.
What I'm actually doing is working on a cover letter implementation. I'd
like to use the same code that generates the subject line and message for
patches to generate the cover letter text from some source material, if
there is source material, but have "insert text here" markers if there is
no pre-existing text. But the "insert text here" marker for a paragraph
looks odd if it's a single line of vertical space, and it's annoying if
the space is full of text that has to be removed, and it's again odd if
the text isn't centered. So I want it to start with a blank line. But the
current code can't generate a text like that.
Reversability isn't all that important to me in this case, although it
seems to me to be generally desirable for rebase. For email that actually
goes through people, I'd expect it to get further manipulated by humans,
so it doesn't matter so much there, aside from being able to arrange the
input so that you can get the intermediate form you want.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [BUG] git-rebase fails when a commit message contains a diff
From: Björn Steinbrink @ 2007-11-11 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jonas Fonseca, git
In-Reply-To: <7v1wb0xhxq.fsf@gitster.siamese.dyndns.org>
On 2007.11.08 18:37:37 -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 8 Nov 2007, Junio C Hamano wrote:
> >
> >> I wonder if this is a sensible thing to do, regardless of the issue of
> >> commit log message that contains anything.
> >>
> >> The patch replaces git-rebase with git-rebase--interactive. The only
> >> difference from the existing "git-rebase -i" is if the command is called
> >> without "-i" the initial "here is the to-do list. please rearrange the
> >> lines, modify 'pick' to 'edit' or whatever as appropriate" step is done
> >> without letting the user edit the list.
> >
> > Hmm. I don't know, really. I had the impression that the "git
> > format-patch | git am" pipeline would be faster.
>
> Heh, I did not read rebase--interactive carefully enough.
>
> Unless told to use merge with "rebase -m", rebase replays the
> change by extracting and applying patches, and speed comparison
> was about that vs merge based replaying; I thought make_patch
> was done in order to avoid using cherry-pick (which is based on
> merge-recursive) and doing patch application with three-way
> fallback. Apparently that is not what "interactive" does.
>
> Perhaps pick_one () could be taught to perform the 3-way
> fallback dance git-am plays correctly. The patch I sent to make
> git-rebase--interactive take over git-rebase would then become
> quite reasonable, I would think.
Note that git-rebase--interactive also doesn't really support the
--strategy parameter which git-rebase handles using git-merge-* instead
of git-am. Only merge commits during a -i -p run actually apply the
strategy.
Björn
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Junio C Hamano @ 2007-11-11 22:35 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <20071111222117.GA7392@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > This should be a non-issue. We really should start deprecating
>> > "git-<command>" in favour of "git <command>" for real.
>> >
>> > New users should not even be told that this is correct usage.
>>
>> If you can write "git-commit" and "git commit" interchangeably
>> while you cannot say "git-cat-file" and are forced to say "git
>> cat-file", I suspect that would lead to a great confusion and
>> unhappy users.
>
> One of the reasons why I use git-diff and git-commit and in particular
> "git-rebase --interactive master" very often is that it allows my
> shell's bang completion to work. (i.e., "!git-rebase"). If we tell
> people they can not use "git-rebase", and must instead use "git
> rebase" instead, I would consider that pretty annoying/obnoxious.
Oh, of course.
But my impression was that Johannes was talking about
deprecating git-<foo> form only for plumbing, so that the users
will only see git-<foo> for the Porcelain. That would not break
your bang completion for the porcelain commands.
If Johannes was talking about deprecating all git-<foo> form,
then that would indeed break your bang completion, but it has
conceptually a much bigger problem. The topic was about fixing
"a new user sees too many git commands and gets scared" problem.
Deprecaing all git-<foo> form just replaces the problem with "a
new user sees too many git subcommands and gets scared" problem,
without solving anything.
^ permalink raw reply
* Re: Obscure commit message formatting issue
From: Johannes Schindelin @ 2007-11-11 22:43 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711111706490.29952@iabervon.org>
Hi,
On Sun, 11 Nov 2007, Daniel Barkalow wrote:
> On Sun, 11 Nov 2007, Junio C Hamano wrote:
>
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> > > The current code drops extra blank lines between the first line of a
> > > commit message (the summary line) and the remainder.
> >
> > The patch application side does even more. It not just strips
> > off the leading or trailing blank lines, but duplicate blank
> > lines in the middle and trailing whitespaces at the end of each
> > line.
> >
> > I am of two minds about the formatting side.
> >
> > The behaviour you found does not go far enough to correct all of
> > the above whitespace breakage the application side will fix up
> > on the generation side -- it only corrects one of them. We
> > might want to do more, instead of less that you seem to be
> > implying to favor.
>
> What I'm actually doing is working on a cover letter implementation.
Funny.
I am in the middle of cleaning out my personal git branch that has a messy
history, since I never rebased, but always merged. Now I decided to go
with rebasing.
And there I found an implementation of a cover letter. You might want to
be interested ;-)
http://repo.or.cz/w/git/dscho.git?a=shortlog;h=cover-letter
Ciao,
Dscho
^ permalink raw reply
* Re: Local branch to remote branch translation
From: Jon Smirl @ 2007-11-11 22:46 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <A7871D5B-9E05-4F9B-92AC-B74ECF35460B@zib.de>
On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Nov 11, 2007, at 10:20 PM, Jon Smirl wrote:
>
> > On 11/11/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >>> jonsmirl@terra:~/mpc5200b$ git remote show linus
> >>> * remote linus
> >>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> >>> linux-2.6.git
> >>>
> >>> How do I push the definition of the linus remote repo?
> >>
> >> You can't. Remotes are local to a repository. They cannot be
> >> "pushed" nor will they be "cloned" or "fetched".
> >
> > Dreamhost is way slow compared to kernel.org, so it is better to clone
> > from kernel.org first and then pull from dreamhost. What is the right
> > sequence of commands so that a new user will end up with a kernel they
> > can use 'git pull' on to get updates from dreamhost? I'll add these to
> > the repo description page.
> >
> > I'm trying this locally and I can't figure out the right sequence of
> > git command to redirect origin from kernel.org to dreamhost.
>
> How about the following (untested sequence)
>
> mkdir linux-2.6
> cd linux-2.6
> git init
> git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/
> torvalds/linux-2.6.git
> git remote add origin ssh://jonsmirl1@git.digispeaker.com/~/
> mpc5200b.git
> git fetch linus
> git fetch origin
> git checkout -b master origin/master
>
> The general idea should be correct. You have a non-standard
> setup, so avoid git-clone.
What should I do to standardize the setup so that 'clone/pull' will
work on it? I created a master branch. I gave up on fighting with
gitweb and no branch named master.
I'd like to do this, but I can't figure out how.
git clone linus
move origin to digispeaker
git pull
There doesn't seem to be a simple way to redirect the origin.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Johannes Schindelin @ 2007-11-11 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, Ask Bjørn Hansen, Daniel Barkalow, git
In-Reply-To: <7vabpkbebj.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Nov 2007, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
>
> > On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> > This should be a non-issue. We really should start deprecating
> >> > "git-<command>" in favour of "git <command>" for real.
> >> >
> >> > New users should not even be told that this is correct usage.
> >>
> >> If you can write "git-commit" and "git commit" interchangeably
> >> while you cannot say "git-cat-file" and are forced to say "git
> >> cat-file", I suspect that would lead to a great confusion and
> >> unhappy users.
> >
> > One of the reasons why I use git-diff and git-commit and in particular
> > "git-rebase --interactive master" very often is that it allows my
> > shell's bang completion to work. (i.e., "!git-rebase"). If we tell
> > people they can not use "git-rebase", and must instead use "git
> > rebase" instead, I would consider that pretty annoying/obnoxious.
>
> Oh, of course.
>
> But my impression was that Johannes was talking about
> deprecating git-<foo> form only for plumbing, so that the users
> will only see git-<foo> for the Porcelain. That would not break
> your bang completion for the porcelain commands.
>
> If Johannes was talking about deprecating all git-<foo> form,
> then that would indeed break your bang completion, but it has
> conceptually a much bigger problem. The topic was about fixing
> "a new user sees too many git commands and gets scared" problem.
> Deprecaing all git-<foo> form just replaces the problem with "a
> new user sees too many git subcommands and gets scared" problem,
> without solving anything.
I beg to differ. The biggest problem with a new user seeing all those
completions is that this user is scared.
Just taking away that first shock would be helping very much. I mean, we
_still_ have the reputation of being more complex than other SCMs, but I
do not think that this reputation is completely deserved.
However, reputations are formed by first time impressions. It is _hard_
to get rid of a bad first time impression.
But yes, I was only proposing to deprecate all usage of git-<bla> in the
documentation.
Maybe I'm wrong. Wouldn't be the first time.
Ciao,
Dscho
^ permalink raw reply
* Re: Obscure commit message formatting issue
From: Daniel Barkalow @ 2007-11-11 22:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711112240350.4362@racer.site>
On Sun, 11 Nov 2007, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Nov 2007, Daniel Barkalow wrote:
>
> > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> >
> > > Daniel Barkalow <barkalow@iabervon.org> writes:
> > >
> > > > The current code drops extra blank lines between the first line of a
> > > > commit message (the summary line) and the remainder.
> > >
> > > The patch application side does even more. It not just strips
> > > off the leading or trailing blank lines, but duplicate blank
> > > lines in the middle and trailing whitespaces at the end of each
> > > line.
> > >
> > > I am of two minds about the formatting side.
> > >
> > > The behaviour you found does not go far enough to correct all of
> > > the above whitespace breakage the application side will fix up
> > > on the generation side -- it only corrects one of them. We
> > > might want to do more, instead of less that you seem to be
> > > implying to favor.
> >
> > What I'm actually doing is working on a cover letter implementation.
>
> Funny.
>
> I am in the middle of cleaning out my personal git branch that has a messy
> history, since I never rebased, but always merged. Now I decided to go
> with rebasing.
>
> And there I found an implementation of a cover letter. You might want to
> be interested ;-)
>
> http://repo.or.cz/w/git/dscho.git?a=shortlog;h=cover-letter
I actually started from the patch you sent me a while back, but using code
from pretty.c instead of generating the message directly. I'll have to
check whether you added anything since the patch I got.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Move stripspace() and launch_editor() to strbuf.c
From: Junio C Hamano @ 2007-11-11 22:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711112227420.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Maybe call_editor() instead of edit_buffer()? Since we technically read
> the file specified by "path" into the buffer "buffer", after having called
> the editor.
Calling $EDITOR to edit the buffer is an implementation detail
of letting the user edit the buffer. I think the function name
should express what it does more than how it does it.
My suggested name does not convey the "letting the user" part,
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