* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 14:52 UTC (permalink / raw)
To: Santi Béjar
Cc: Johannes Sixt, Theodore Tso, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 900 bytes --]
On Fri, 19 Oct 2007, Santi Béjar wrote:
> I like it too. I would like to add some more descripton, because I
> think for newbies the .. and ... can be overlooked. Something like:
>
> $ git fetch spearce
> ...
> URL: git://repo.or.cz/git/spearce.git
> * (new) spearce/gitk: new branch 'gitk'
> * 1aa3d01..e7187e4 spearce/maint: fast forward to branch 'maint'
> * de61e42..7840ce6 spearce/master: fast forward to branch 'master'
> * 895be02..2fe5433 spearce/next: fast forward to branch 'next'
> + 89fa332...1e4c517 spearce/pu: forcing update to non-fast forward branch 'pu'
> * (new) spearce/todo: new branch spearce/todo
Well, I don't like it as much. First I don't think newbies will care
much more even if the type of update is spelled out verbosely. Better
keep it short and add all the necessary information in the fetch man
page instead.
Nicolas
^ permalink raw reply
* Re: git push bug?
From: Joakim Tjernlund @ 2007-10-19 14:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, git
In-Reply-To: <Pine.LNX.4.64.0710182259190.25221@racer.site>
On Thu, 2007-10-18 at 23:00 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
>
> > On Thu, 2007-10-18 at 17:21 +0100, Johannes Schindelin wrote:
> >
> > > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> > >
> > > > Seems like it is a bit too easy to make mistakes here. Why can I
> > > > delete a branch with :linus but not create one with linus:linus?
> > >
> > > I wonder why you bother with the colon at all. Just
> > >
> > > git push <remote> linus
> > >
> > > and be done with it. The colon is only there to play interesting
> > > games, not something as simple as "push this branch" or "push this
> > > tag".
> >
> > First, I didn't know that I could do that. Secondly, I was also looking
> > do v2.6.23:linus refspecs
>
>
> First, then our documentation could be better. How?
Well, it isn't clear to me how all this is supposed to work and
what is bugs. Clearifying that would help.
For instances I did a push with v2.6.23:refs/heads/linus and now
I got a branch with the SHA1 of v2.6.23 tag(0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d)
in it. Makes gitk display that branch as "linus^{}".
>
> Second, why not "git checkout -b linus v2.6.23 && git push origin linus"?
An extra checkout that takes time but works. Doesn't make the above
"weiredness" go away though.
Jocke
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Johannes Schindelin @ 2007-10-19 14:41 UTC (permalink / raw)
To: Santi Béjar
Cc: Nicolas Pitre, Johannes Sixt, Theodore Tso, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
Hi,
On Fri, 19 Oct 2007, Santi B?jar wrote:
> On 10/19/07, Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 19 Oct 2007, Johannes Sixt wrote:
> >
> > > Theodore Tso schrieb:
> > > > ==> git://repo.or.cz/git/spearce.git
> > > > * branch gitk -> spearce/gitk (new)
> > > > * branch maint -> spearce/maint 1aa3d01..e7187e4
> > > > * branch master -> spearce/master de61e42..7840ce6
> > > > * branch next -> spearce/next 895be02..2fe5433
> > > > + branch pu -> spearce/pu 89fa332...1e4c517
> > > > * branch todo -> spearce/todo (new)
> > >
> > > > As far as the padding, it would be a pain to figure out how to make
> > > > the right hand column be padded so that it starts 3 spaces after the
> > > > longest " * branch foo -> bar" line, but that would look the best.
> > >
> > > But this way it wouldn't be difficult at all:
> > >
> > > ==> git://repo.or.cz/git/spearce.git
> > > * (new) gitk -> spearce/gitk
> > > * 1aa3d01..e7187e4 maint -> spearce/maint
> > > * de61e42..7840ce6 master -> spearce/master
> > > * 895be02..2fe5433 next -> spearce/next
> > > + 89fa332...1e4c517 pu -> spearce/pu
> > > * (new) todo -> spearce/todo
> >
> > Actually I think this is the best format so far: one line per branch, no
> > terminal width issue (long branch names are simply wrapped), the
> > old..new info is there also with the single character marker to quickly
> > notice the type of update.
>
> I like it too. I would like to add some more descripton, because I
> think for newbies the .. and ... can be overlooked. Something like:
>
> $ git fetch spearce
> ...
> URL: git://repo.or.cz/git/spearce.git
> * (new) spearce/gitk: new branch 'gitk'
Nah, that is just duplication.
> * 1aa3d01..e7187e4 spearce/maint: fast forward to branch 'maint'
> * de61e42..7840ce6 spearce/master: fast forward to branch 'master'
> * 895be02..2fe5433 spearce/next: fast forward to branch 'next'
> + 89fa332...1e4c517 spearce/pu: forcing update to non-fast forward branch 'pu'
Better to say (forced) if need be. But I do not think so. I like Hannes'
proposal as-is.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Karl Hasselström @ 2007-10-19 14:40 UTC (permalink / raw)
To: Santi Béjar
Cc: Nicolas Pitre, Johannes Sixt, Theodore Tso, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
On 2007-10-19 16:31:08 +0200, Santi Béjar wrote:
> I would also put 'URL:' instead '==>'.
Seconded.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Johannes Sixt @ 2007-10-19 14:40 UTC (permalink / raw)
To: Santi Béjar
Cc: Nicolas Pitre, Theodore Tso, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
Santi Béjar schrieb:
> On 10/19/07, Nicolas Pitre <nico@cam.org> wrote:
>> On Fri, 19 Oct 2007, Johannes Sixt wrote:
>>> ==> git://repo.or.cz/git/spearce.git
>>> * (new) gitk -> spearce/gitk
>>> * 1aa3d01..e7187e4 maint -> spearce/maint
>>> * de61e42..7840ce6 master -> spearce/master
>>> * 895be02..2fe5433 next -> spearce/next
>>> + 89fa332...1e4c517 pu -> spearce/pu
>>> * (new) todo -> spearce/todo
>
> I like it too. I would like to add some more descripton, because I
> think for newbies the .. and ... can be overlooked.
The '*' could go away, then the '+' is more visible.
-- Hanes
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Karl Hasselström @ 2007-10-19 14:38 UTC (permalink / raw)
To: Theodore Tso
Cc: Santi Béjar, Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <20071019113822.GB16726@thunk.org>
On 2007-10-19 07:38:22 -0400, Theodore Tso wrote:
> Finally, one last question --- am I the only one who had to take a
> second look at the whether the arrow should be <- or ->? The
> question is whether we are saying "gitk is moving to include all of
> spearce/gitk"; but I could also see it stated that we are assigning
> refs/heads/gitk with refs/remotes/spearce/gitk, in which case the
> arrow should be reversed. Or maybe:
>
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk := spearce/gitk (new)
> * branch maint := spearce/maint 1aa3d01..e7187e4
> * branch master := spearce/master de61e42..7840ce6
> * branch next := spearce/next 895be02..2fe5433
> + branch pu := spearce/pu 89fa332...1e4c517
> * branch todo := spearce/todo (new)
I think the reasoning behind the "foo -> spearce/foo" syntax is that
"(refs/heads/)foo" in the remote repository has been fetched to
"(refs/remotes/)spearce/foo" in the local repository.
I might be deluded, though.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Santi Béjar @ 2007-10-19 14:31 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Sixt, Theodore Tso, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710191009330.19446@xanadu.home>
On 10/19/07, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 19 Oct 2007, Johannes Sixt wrote:
>
> > Theodore Tso schrieb:
> > > ==> git://repo.or.cz/git/spearce.git
> > > * branch gitk -> spearce/gitk (new)
> > > * branch maint -> spearce/maint 1aa3d01..e7187e4
> > > * branch master -> spearce/master de61e42..7840ce6
> > > * branch next -> spearce/next 895be02..2fe5433
> > > + branch pu -> spearce/pu 89fa332...1e4c517
> > > * branch todo -> spearce/todo (new)
> >
> > > As far as the padding, it would be a pain to figure out how to make
> > > the right hand column be padded so that it starts 3 spaces after the
> > > longest " * branch foo -> bar" line, but that would look the best.
> >
> > But this way it wouldn't be difficult at all:
> >
> > ==> git://repo.or.cz/git/spearce.git
> > * (new) gitk -> spearce/gitk
> > * 1aa3d01..e7187e4 maint -> spearce/maint
> > * de61e42..7840ce6 master -> spearce/master
> > * 895be02..2fe5433 next -> spearce/next
> > + 89fa332...1e4c517 pu -> spearce/pu
> > * (new) todo -> spearce/todo
>
> Actually I think this is the best format so far: one line per branch, no
> terminal width issue (long branch names are simply wrapped), the
> old..new info is there also with the single character marker to quickly
> notice the type of update.
I like it too. I would like to add some more descripton, because I
think for newbies the .. and ... can be overlooked. Something like:
$ git fetch spearce
...
URL: git://repo.or.cz/git/spearce.git
* (new) spearce/gitk: new branch 'gitk'
* 1aa3d01..e7187e4 spearce/maint: fast forward to branch 'maint'
* de61e42..7840ce6 spearce/master: fast forward to branch 'master'
* 895be02..2fe5433 spearce/next: fast forward to branch 'next'
+ 89fa332...1e4c517 spearce/pu: forcing update to non-fast forward branch 'pu'
* (new) spearce/todo: new branch spearce/todo
I would also put 'URL:' instead '==>'.
Santi
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Johannes Schindelin @ 2007-10-19 14:31 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Sixt, Theodore Tso, Santi Béjar, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710191009330.19446@xanadu.home>
Hi,
On Fri, 19 Oct 2007, Nicolas Pitre wrote:
> On Fri, 19 Oct 2007, Johannes Sixt wrote:
>
> > ==> git://repo.or.cz/git/spearce.git
> > * (new) gitk -> spearce/gitk
> > * 1aa3d01..e7187e4 maint -> spearce/maint
> > * de61e42..7840ce6 master -> spearce/master
> > * 895be02..2fe5433 next -> spearce/next
> > + 89fa332...1e4c517 pu -> spearce/pu
> > * (new) todo -> spearce/todo
>
> Actually I think this is the best format so far: one line per branch, no
> terminal width issue (long branch names are simply wrapped), the
> old..new info is there also with the single character marker to quickly
> notice the type of update.
Yes. Definitely my favourite so far, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Johannes Schindelin @ 2007-10-19 14:27 UTC (permalink / raw)
To: Scott Parish; +Cc: Johannes Sixt, git
In-Reply-To: <20071019130402.GD1463@srparish.net>
Hi,
On Fri, 19 Oct 2007, Scott Parish wrote:
> + check PATH for the location of git
Okay, but better do it only if the current exec_path did not succeed to
find something, to stay as backwards compatible as possible.
> + the checking of argv[0] was restricted to absolute paths; remove
> that restriction so it also works when called with a relative
> path (eg ../../otheruser/usr/bin/git)
This will utterly break down when you try to do things in a subdirectory
of your project. git will cd up, and the relative path will no longer be
relative.
> + try to guess and set the env for the typical relative locations for
> MANPATH and PERL5LIB based off exec_path
Now this is ugly. At least make it a separate patch.
> +/* Return the first path in PATH that git is found in or NULL if not found */
> +char *git_path_from_env(void)
> +{
> + const char *env_paths = getenv("PATH");
> + const char *git = "/git";
> + int git_len = strlen(git);
> + char *paths, *path, *colon, *git_path;
> + int path_len;
> + struct stat st;
> +
> + if (!env_paths)
> + return NULL;
> +
> + path_len = strlen(env_paths);
> + path = paths = xmalloc(path_len + 1);
> + memcpy(paths, env_paths, path_len + 1);
> +
> + while ((char *)1 != path) {
> + if ((colon = strchr(path, ':')))
> + *colon = 0;
> +
> + path_len = strlen(path);
> + git_path = xmalloc(path_len + git_len + 1);
> + memcpy(git_path, path, path_len);
> + memcpy(git_path + path_len, git, git_len + 1);
> +
> + if (!stat(git_path, &st)) { /* found */
> + free(paths);
> + git_path[path_len] = 0;
> + return git_path;
> + }
> +
> + free(git_path);
> + path = colon + 1;
> + }
> +
> + free(paths);
> + return NULL;
> +}
I am convinced that this function will look a lot less ugly when you use
strbufs. And I'd call it "find_git_in_path()".
> /* Returns the highest-priority, location to look for git programs. */
> const char *git_exec_path(void)
> {
> - const char *env;
> + const char *env, *path;
>
> if (current_exec_path)
> return current_exec_path;
>
> env = getenv(EXEC_PATH_ENVIRONMENT);
> if (env && *env) {
> + current_exec_path = env;
> return env;
> }
>
> + if ((path = git_path_from_env())) {
> + current_exec_path = path;
> + return path;
> + }
> +
> + current_exec_path = builtin_exec_path;
> return builtin_exec_path;
> }
As I said, I'd rather have git try with builtin_exec_path first, and only
if that fails, search through the PATH, for the _current_ command.
> -static void prepend_to_path(const char *dir, int len)
> +static void prepend_to_env(const char *env, const char *basedir,
I do not like this rename. It makes things more obscure, rather than
clearing things up.
> + const char *subdir, const char *env_default)
> {
> - const char *old_path = getenv("PATH");
> - char *path;
> - int path_len = len;
> -
> - if (!old_path)
> - old_path = "/usr/local/bin:/usr/bin:/bin";
> -
> - path_len = len + strlen(old_path) + 1;
> -
> - path = xmalloc(path_len + 1);
> + const char *old = getenv(env);
> + int basedir_len = strlen(basedir);
> + int subdir_len = strlen(subdir);
> + char *new;
> + int old_len;
> +
> + if (!old)
> + old = env_default;
> +
> + old_len = strlen(old);
> +
> + new = xmalloc(basedir_len + subdir_len + old_len + 1);
> +
> + memcpy(new, basedir, basedir_len);
> + memcpy(new + basedir_len, subdir, subdir_len);
> + memcpy(new + basedir_len + subdir_len, old, old_len + 1);
> +
> + if (setenv(env, new, 1))
> + fprintf(stderr, "Setenv failed: %s\n", strerror(errno));
> +
> + free(new);
> +}
Again, this would be so much more elegant using strbufs.
>
> - memcpy(path, dir, len);
> - path[len] = ':';
> - memcpy(path + len + 1, old_path, path_len - len);
> +static void prepend_to_envs(const char *dir, int len)
> +{
> + char *slash;
> + char *basedir;
> +
> + /* basedir is dir with "/bin" stripped off */
> + basedir = xmalloc(len + 1);
> + memcpy(basedir, dir, len + 1);
> +
> + if ((slash = strrchr(basedir, '/'))) {
> + *slash = 0;
> + while (slash == basedir + --len) /* found trailing slash */
> + if ((slash = strrchr(basedir, '/')))
> + *slash = 0;
> + }
>
> - setenv("PATH", path, 1);
> + prepend_to_env("PATH", basedir, "/bin:",
> + "/usr/local/bin:/usr/bin:/bin");
> + prepend_to_env("MANPATH", basedir, "/share/man:",
> + "/usr/local/share/man:/usr/share/man");
> + prepend_to_env("PERL5LIB", basedir, "/lib/perl5:",
> + "/usr/lib/perl5");
>
> - free(path);
> + free(basedir);
> }
As I said, this is so controversial it belongs into an own patch.
> @@ -414,8 +444,7 @@ int main(int argc, const char **argv)
> */
> if (slash) {
> *slash++ = 0;
> - if (*cmd == '/')
> - exec_path = cmd;
> + exec_path = cmd;
As I said, this breaks down. This alone is enough reason to move it to
its own patch. And I strongly suggest the use of make_path_absolute()
(with an xstrdup()).
> @@ -453,14 +482,15 @@ int main(int argc, const char **argv)
> /*
> * We execute external git command via execv_git_cmd(),
> * which looks at "--exec-path" option, GIT_EXEC_PATH
> - * environment, and $(gitexecdir) in Makefile while built,
> - * in this order. For scripted commands, we prepend
> - * the value of the exec_path variable to the PATH.
> + * environment, PATH environment, and $(gitexecdir) in
> + * Makefile while built, in this order. For scripted
> + * commands, we prepend the value of the exec_path
> + * variable to the PATH.
While reading this, I have to wonder why it is not just simpler to try
with builtin_exec_path first, and if that fails, just let exec() find the
program in the PATH?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Scott Parish @ 2007-10-19 14:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4718AF48.9020607@viscovery.net>
On Fri, Oct 19, 2007 at 03:21:12PM +0200, Johannes Sixt wrote:
> Scott Parish schrieb:
> > I have a situation where software for a distribution is installed
> > into a fake "prefix" and then moved to one of several potential
> > places to be used by users. Given that the final location isn't
> > static, i can't depend on builtin_exec_path. I'd really like users
> > to be able to get started with git as easily as possible. With the
> > current setup, they would have to create and maintain either an
> > GIT_EXEC_PATH or an alias for including --exec-path, as well as a
> > MANPATH and PERL5LIB. This seem like an unnessisary burden.
>
> Interesting. How does this compare to this 2-patch-series:
>
> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=e479ea2f911b8c70a269ba59372a4fef90f8907c
> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=00a4ff4f3f8ec7e6b3ac15456f00b22b03f438ae
>
> which I had come up with to accomplish something very similar
> (on Windows). Your approach looks superior, but I hadn't gone
> into depths, yet.
I know very little about what's available on windows. Looking at
your code, it looks like the command isn't passed in in argv[0] and
that it contains the windows style path seperators. My code currently
assumes that PATH is a colon separated list, and that directories
are separated with '/'. How should these assumptions change for
windows?
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 14:14 UTC (permalink / raw)
To: Johannes Sixt
Cc: Theodore Tso, Santi Béjar, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <4718A3AB.7090301@viscovery.net>
On Fri, 19 Oct 2007, Johannes Sixt wrote:
> Theodore Tso schrieb:
> > ==> git://repo.or.cz/git/spearce.git
> > * branch gitk -> spearce/gitk (new)
> > * branch maint -> spearce/maint 1aa3d01..e7187e4
> > * branch master -> spearce/master de61e42..7840ce6
> > * branch next -> spearce/next 895be02..2fe5433
> > + branch pu -> spearce/pu 89fa332...1e4c517
> > * branch todo -> spearce/todo (new)
>
> > As far as the padding, it would be a pain to figure out how to make
> > the right hand column be padded so that it starts 3 spaces after the
> > longest " * branch foo -> bar" line, but that would look the best.
>
> But this way it wouldn't be difficult at all:
>
> ==> git://repo.or.cz/git/spearce.git
> * (new) gitk -> spearce/gitk
> * 1aa3d01..e7187e4 maint -> spearce/maint
> * de61e42..7840ce6 master -> spearce/master
> * 895be02..2fe5433 next -> spearce/next
> + 89fa332...1e4c517 pu -> spearce/pu
> * (new) todo -> spearce/todo
Actually I think this is the best format so far: one line per branch, no
terminal width issue (long branch names are simply wrapped), the
old..new info is there also with the single character marker to quickly
notice the type of update.
Nicolas
^ permalink raw reply
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Dan McGee @ 2007-10-19 14:11 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019134339.GA21852@coredump.intra.peff.net>
Ahh, shoot. Forgot to reply to all.
On 10/19/07, Jeff King <peff@peff.net> wrote:
> It is based on Shawn's next, 2fe5433b. Are you sure you're not doing
> something silly like executing an older version of git that is in your
> PATH?
Yeah, just tried that again, definitely using the right version of
git. Before I apply your patch, both my test script and your addition
to t5400 fail. After applying your patch, my test script fails but
your addition to t5400 succeeds. Could this be something where
git-push and git-send-pack are not interacting correctly?
-Dan
^ permalink raw reply
* Re: git stash apply usability issues
From: David Kastrup @ 2007-10-19 13:57 UTC (permalink / raw)
To: git
In-Reply-To: <20071019132753.GA23765@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-10-18 21:31:56 -0400, Shawn O. Pearce wrote:
>
>> Johannes Sixt <j.sixt@viscovery.net> wrote:
>
>> > (2) when 'git stash apply' runs merge-recursive, it treats the
>> > current state as 'ours' and the stash as 'theirs'. IMHO it should
>> > be the other way round: I have stashed away changes to a binary
>> > file. Then committed a different modification to it, and now want
>> > to apply the stash. This results in a conflict that leaves the
>> > current state in the working tree, but I had preferred that the
>> > stashed binary file were in the working tree now.
>> >
>> > What do other git-stash users think about changing the order?
>>
>> The current order is the same order that git-rebase uses. I'm not
>> saying its correct, just that its the same as rebase.
>
> FWIW, StGit push works the same way. The idea being that the current
> HEAD is our current state ("ours"), and the patch we're pushing is
> some change we want to apply ("theirs"). I always felt that this was a
> very natural order of things. But I guess the philosophy in the
> "stash" case is subtly different, so maybe the change is warranted
> there.
Well, maybe one should then just name this "current" and "separate"
instead of "ours" and "theirs".
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Johannes Sixt @ 2007-10-19 13:21 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071019130402.GD1463@srparish.net>
Scott Parish schrieb:
> I have a situation where software for a distribution is installed
> into a fake "prefix" and then moved to one of several potential
> places to be used by users. Given that the final location isn't
> static, i can't depend on builtin_exec_path. I'd really like users
> to be able to get started with git as easily as possible. With the
> current setup, they would have to create and maintain either an
> GIT_EXEC_PATH or an alias for including --exec-path, as well as a
> MANPATH and PERL5LIB. This seem like an unnessisary burden.
Interesting. How does this compare to this 2-patch-series:
http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=e479ea2f911b8c70a269ba59372a4fef90f8907c
http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=00a4ff4f3f8ec7e6b3ac15456f00b22b03f438ae
which I had come up with to accomplish something very similar
(on Windows). Your approach looks superior, but I hadn't gone
into depths, yet.
-- Hannes
^ permalink raw reply
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Jeff King @ 2007-10-19 13:43 UTC (permalink / raw)
To: Dan McGee; +Cc: Shawn O. Pearce, git
In-Reply-To: <449c10960710190638j5823b19dl903ae369965e884e@mail.gmail.com>
On Fri, Oct 19, 2007 at 08:38:06AM -0500, Dan McGee wrote:
> origin(junio)/master: 58ba4f6
> origin(junio)/next: fe96ee67ec5840
> spearce/master: 7840ce6cb24a9d
> spearce/next: 2fe5433b416f0df
>
> Can you let me know what commit you based the patch off of? I'm at
> work for the next 8 hours or so, so I can't look in to this a whole
> lot until tonight.
It is based on Shawn's next, 2fe5433b. Are you sure you're not doing
something silly like executing an older version of git that is in your
PATH?
-Peff
^ permalink raw reply
* [PATCH-resent] gitk: fix in procedure drawcommits
From: Michele Ballabio @ 2007-10-19 13:44 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Paul Mackerras
In-Reply-To: <20071019052823.GI14735@spearce.org>
This patch indroduces a check before unsetting an array element.
Without this, gitk may complain with
can't unset "prevlines(...)": no such element in array
when scrolling happens.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
There's an error that seems to occur in gitk only on
mutt's imported repo, but I don't know why. This is
hopefully the right fix.
An example of this error:
can't unset "prevlines(a3b4383d69e0754346578c85ba8ff7c05bd88705)": no such element in array
can't unset "prevlines(a3b4383d69e0754346578c85ba8ff7c05bd88705)": no such element in array
while executing
"unset prevlines($lid)"
(procedure "drawcommits" line 39)
invoked from within
"drawcommits $row $endrow"
(procedure "drawfrac" line 10)
invoked from within
"drawfrac $f0 $f1"
(procedure "scrollcanv" line 3)
invoked from within
"scrollcanv .tf.histframe.csb 0.00672513 0.0087015"
gitk | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..527b716 100755
--- a/gitk
+++ b/gitk
@@ -3697,7 +3697,9 @@ proc drawcommits {row {endrow {}}} {
if {[info exists lineends($r)]} {
foreach lid $lineends($r) {
- unset prevlines($lid)
+ if {[info exists prevlines($lid)]} {
+ unset prevlines($lid)
+ }
}
}
set rowids [lindex $rowidlist $r]
--
1.5.3
^ permalink raw reply related
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Dan McGee @ 2007-10-19 13:38 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071019122755.GA17002@coredump.intra.peff.net>
On 10/19/07, Jeff King <peff@peff.net> wrote:
> On Fri, Oct 19, 2007 at 07:10:42AM -0500, Dan McGee wrote:
>
> > Hmm. For some reason this passes with your test case, but not with my
> > original bash test script[1]. Did you try it with this?
> >
> > [1] http://www.toofishes.net/uploads/
>
> I didn't try it until you sent your message, but your test seems to work
> fine for me. My patch is on top of 'next', which is what I usually run.
> I haven't looked into 'master' (I assumed since the bug was reproducible
> in both, it would be the same in both, but that is perhaps not the
> case).
Still getting this error:
error: remote 'refs/heads/working' is not a strict subset of local ref
'refs/heads/working'. maybe you are not up-to-date and need to pull
first?
error: failed to push to '/tmp/testpush'
I've tried applying the patch on the following commits, and maybe I'm
smoking something but I can't get it to pass my test script.
origin(junio)/master: 58ba4f6
origin(junio)/next: fe96ee67ec5840
spearce/master: 7840ce6cb24a9d
spearce/next: 2fe5433b416f0df
Can you let me know what commit you based the patch off of? I'm at
work for the next 8 hours or so, so I can't look in to this a whole
lot until tonight.
-Dan
^ permalink raw reply
* stash clear, was Re: git: avoiding merges, rebasing
From: Johannes Schindelin @ 2007-10-19 13:37 UTC (permalink / raw)
To: Eric Blake; +Cc: bug-gnulib, Bruno Haible, git
In-Reply-To: <47023699.3080606@byu.net>
Hi,
On Tue, 2 Oct 2007, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [adding the git list]
>
> According to Bruno Haible on 10/2/2007 5:50 AM:
> > Hello Benoit,
> >
> >>> $ git stash
> >>> $ git pull
> >>> $ git stash apply
> >>> $ git stash clean ; typo!
> >>> $ git stash clear ; fatal correction to typo!
> >>>
> >>> and lost 20 modified files. Well, not really lost. Just took me a
> >>> while to
> >> I don't really see how and why you "lost 20 modified files".
> >
> > I lost modifications to 20 files. "git stash clean" moved these modifications
> > into a stash named "clean", and "git stash clear" killed it.
>
> While we're at it, I wish 'git stash clear' would take an optional
> argument that says which stash(es) to clear, rather than blindly
> clearing the entire stash.
I'd rather avoid "enhancing" stash clear. IMHO it is a little
misdesigned, making it way too easy to hang yourself.
Instead, how about writing a stash pop? "git stash pop [<stash>]". It
would literally just call git stash apply && git reflog delete. Should
not be too difficult, now that I provided "git reflog delete" ;-)
Maybe even deprecating "git stash clear", or doing away with it
altogether.
Ciao,
Dscho
^ permalink raw reply
* Re: git stash apply usability issues
From: Karl Hasselström @ 2007-10-19 13:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <20071019013156.GU14735@spearce.org>
On 2007-10-18 21:31:56 -0400, Shawn O. Pearce wrote:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
> > (2) when 'git stash apply' runs merge-recursive, it treats the
> > current state as 'ours' and the stash as 'theirs'. IMHO it should
> > be the other way round: I have stashed away changes to a binary
> > file. Then committed a different modification to it, and now want
> > to apply the stash. This results in a conflict that leaves the
> > current state in the working tree, but I had preferred that the
> > stashed binary file were in the working tree now.
> >
> > What do other git-stash users think about changing the order?
>
> The current order is the same order that git-rebase uses. I'm not
> saying its correct, just that its the same as rebase.
FWIW, StGit push works the same way. The idea being that the current
HEAD is our current state ("ours"), and the patch we're pushing is
some change we want to apply ("theirs"). I always felt that this was a
very natural order of things. But I guess the philosophy in the
"stash" case is subtly different, so maybe the change is warranted
there.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Subversion developer: svn is for dumb people
From: Pierre Habouzit @ 2007-10-19 13:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, 'git'
In-Reply-To: <Pine.LNX.4.64.0710191514190.16728@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]
On Fri, Oct 19, 2007 at 01:17:05PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 19 Oct 2007, Pierre Habouzit wrote:
>
> > On Thu, Oct 18, 2007 at 02:25:36PM +0000, Steven Grimm wrote:
> > > Thought folks here might get a kick out of this:
> > >
> > > http://blog.red-bean.com/sussman/?p=79
> > >
> > > Okay, my summary is slightly facetious, but that's basically the gist
> > > of what he's saying: you should choose Subversion rather than a DVCS
> > > because most of your users won't be smart enough to use the better
> > > tool.
> > >
> > > I can't say he's completely wrong, especially about the 20/80% idea
> > > (though I think "20%" is generous), but some of his specific arguments
> > > about DVCS are on the bogus side. "Centralized systems encourage code
> > > reviews," for one -- I challenge him to find a project with a more
> > > pervasive and effective code-reviewing culture than the git project.
> >
> > Your argument is also bogus.
> >
> > IMNSHO, peer reviewing has nothing to do with git, svn, or $SCM. It's
> > a social pattern. There are people that do it because they understand
> > it's a good and necessary sound thing to do, and there are the others.
> > Guess what, it has a lot to do with the 20%/80% line (that I would have
> > more described as the 2/98 but well…).
>
> I tend to disagree. Git at least _enables_ you to have the
> one-committer-per-repository scheme, it even _encourages_ it to a certain
> extent.
>
> And once you go that route, it is easy to see that the committer says "I
> will not let that _crap_ enter my repository." Bingo, peer review.
>
> Compare that to a centralised repository, where more often than not, the
> administrator is not even part of the developer community! It is much
> easier not to feel too responsible for the code you are committing there.
I agree, that's why I said that git made it easier. WHat I pretend to
be wrong is to say that a SCM will make people review code or not. Git
merely help people that want to always review code to be completely sure
some review has happened before the code is merged. But nothing in git
forbids you to use the big fat <centralized repo with everyone having
push access to it>-mode.
--
·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: Subversion developer: svn is for dumb people
From: Johannes Schindelin @ 2007-10-19 13:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Steven Grimm, 'git'
In-Reply-To: <20071019113447.GC4404@artemis.corp>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1726 bytes --]
Hi,
On Fri, 19 Oct 2007, Pierre Habouzit wrote:
> On Thu, Oct 18, 2007 at 02:25:36PM +0000, Steven Grimm wrote:
> > Thought folks here might get a kick out of this:
> >
> > http://blog.red-bean.com/sussman/?p=79
> >
> > Okay, my summary is slightly facetious, but that's basically the gist
> > of what he's saying: you should choose Subversion rather than a DVCS
> > because most of your users won't be smart enough to use the better
> > tool.
> >
> > I can't say he's completely wrong, especially about the 20/80% idea
> > (though I think "20%" is generous), but some of his specific arguments
> > about DVCS are on the bogus side. "Centralized systems encourage code
> > reviews," for one -- I challenge him to find a project with a more
> > pervasive and effective code-reviewing culture than the git project.
>
> Your argument is also bogus.
>
> IMNSHO, peer reviewing has nothing to do with git, svn, or $SCM. It's
> a social pattern. There are people that do it because they understand
> it's a good and necessary sound thing to do, and there are the others.
> Guess what, it has a lot to do with the 20%/80% line (that I would have
> more described as the 2/98 but well…).
I tend to disagree. Git at least _enables_ you to have the
one-committer-per-repository scheme, it even _encourages_ it to a certain
extent.
And once you go that route, it is easy to see that the committer says "I
will not let that _crap_ enter my repository." Bingo, peer review.
Compare that to a centralised repository, where more often than not, the
administrator is not even part of the developer community! It is much
easier not to feel too responsible for the code you are committing there.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 13:15 UTC (permalink / raw)
To: Santi Béjar; +Cc: Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <8aa486160710190303l4ce996daqf5c8025c857ea8@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 993 bytes --]
On Fri, 19 Oct 2007, Santi Béjar wrote:
> Another possibility is with just some minor reductions from the
> current output, as:
>
> $ git fetch spearce
> ...
> >From git://repo.or.cz/git/spearce
> * spearce/gitk: fast forward to branch 'gitk'
> old..new: 0d6df4d..2b5afb7
> * spearce/maint: fast forward to branch 'maint'
> old..new: 1aa3d01..e7187e4
> * spearce/master: fast forward to branch 'master'
> old..new: de61e42..7840ce6
> * spearce/next: fast forward to branch 'next'
> old..new: 895be02..2fe5433
> * spearce/pu: forcing update to non-fast forward branch 'pu'
> old...new: 89fa332...1e4c517
>
> This way it is slightly less terse than the other proposals but not
> that cryptic and it normally fits in one line without padding. And I
> really like to see what has changed explicitly with the old..new line.
I think the advantage of having only one line of output per branch
really outweight the need for old..new notation. Do you really benefit
from it?
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 13:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
On Fri, 19 Oct 2007, Shawn O. Pearce wrote:
> What about this on top of Jeff's patch?
>
> $ git fetch jc
> ...
> ==> git://repo.or.cz/alt-git.git
> * tag junio-gpg-pub ......................... (new)
> * tag v1.5.0 .......................... (tag moved)
>
> $ git fetch me
> ...
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> spearce/gitk ............... (new)
> * branch maint -> spearce/maint
> * branch master -> spearce/master
> * branch next -> spearce/next
> * branch pu -> spearce/pu ......... (forced update)
> * branch todo -> spearce/todo ............... (new)
>
> The width of the terminal is computed to produce the ... padding.
> I used a very narrow terminal to produce the above so it doesn't
> linewrap badly in email. If we cannot get the terminal width then
> we just don't produce the padding.
I like it.
I would change the '*' to a '+' for a forced update (for similarity with
the + notation in refspecs), and a '!' instead of a '-' for refused
update which might be more indicative of a refusal.
Nicolas
^ permalink raw reply
* [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Scott Parish @ 2007-10-19 13:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <47185DAF.7060809@viscovery.net>
I have a situation where software for a distribution is installed
into a fake "prefix" and then moved to one of several potential
places to be used by users. Given that the final location isn't
static, i can't depend on builtin_exec_path. I'd really like users
to be able to get started with git as easily as possible. With the
current setup, they would have to create and maintain either an
GIT_EXEC_PATH or an alias for including --exec-path, as well as a
MANPATH and PERL5LIB. This seem like an unnessisary burden.
I'd like to make it so that git works equally well when it is ran
via an absolute path (already partially works), relative path, or
from the PATH. (in saying "equally well" i'm including perl commands
and help commands)
To do this i've had to make the following changes:
+ check PATH for the location of git
+ the checking of argv[0] was restricted to absolute paths; remove
that restriction so it also works when called with a relative
path (eg ../../otheruser/usr/bin/git)
+ try to guess and set the env for the typical relative locations for
MANPATH and PERL5LIB based off exec_path
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 50 ++++++++++++++++++++++++++++++++++++++-
git.c | 76 +++++++++++++++++++++++++++++++++++++++++------------------
2 files changed, 102 insertions(+), 24 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..c6ecca9 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -13,19 +13,67 @@ void git_set_exec_path(const char *exec_path)
}
+/* Return the first path in PATH that git is found in or NULL if not found */
+char *git_path_from_env(void)
+{
+ const char *env_paths = getenv("PATH");
+ const char *git = "/git";
+ int git_len = strlen(git);
+ char *paths, *path, *colon, *git_path;
+ int path_len;
+ struct stat st;
+
+ if (!env_paths)
+ return NULL;
+
+ path_len = strlen(env_paths);
+ path = paths = xmalloc(path_len + 1);
+ memcpy(paths, env_paths, path_len + 1);
+
+ while ((char *)1 != path) {
+ if ((colon = strchr(path, ':')))
+ *colon = 0;
+
+ path_len = strlen(path);
+ git_path = xmalloc(path_len + git_len + 1);
+ memcpy(git_path, path, path_len);
+ memcpy(git_path + path_len, git, git_len + 1);
+
+ if (!stat(git_path, &st)) { /* found */
+ free(paths);
+ git_path[path_len] = 0;
+ return git_path;
+ }
+
+ free(git_path);
+ path = colon + 1;
+ }
+
+ free(paths);
+ return NULL;
+}
+
+
/* Returns the highest-priority, location to look for git programs. */
const char *git_exec_path(void)
{
- const char *env;
+ const char *env, *path;
if (current_exec_path)
return current_exec_path;
env = getenv(EXEC_PATH_ENVIRONMENT);
if (env && *env) {
+ current_exec_path = env;
return env;
}
+ if ((path = git_path_from_env())) {
+ current_exec_path = path;
+ return path;
+ }
+
+ current_exec_path = builtin_exec_path;
return builtin_exec_path;
}
diff --git a/git.c b/git.c
index 9eaca1d..252ee7c 100644
--- a/git.c
+++ b/git.c
@@ -6,26 +6,56 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
-static void prepend_to_path(const char *dir, int len)
+static void prepend_to_env(const char *env, const char *basedir,
+ const char *subdir, const char *env_default)
{
- const char *old_path = getenv("PATH");
- char *path;
- int path_len = len;
-
- if (!old_path)
- old_path = "/usr/local/bin:/usr/bin:/bin";
-
- path_len = len + strlen(old_path) + 1;
-
- path = xmalloc(path_len + 1);
+ const char *old = getenv(env);
+ int basedir_len = strlen(basedir);
+ int subdir_len = strlen(subdir);
+ char *new;
+ int old_len;
+
+ if (!old)
+ old = env_default;
+
+ old_len = strlen(old);
+
+ new = xmalloc(basedir_len + subdir_len + old_len + 1);
+
+ memcpy(new, basedir, basedir_len);
+ memcpy(new + basedir_len, subdir, subdir_len);
+ memcpy(new + basedir_len + subdir_len, old, old_len + 1);
+
+ if (setenv(env, new, 1))
+ fprintf(stderr, "Setenv failed: %s\n", strerror(errno));
+
+ free(new);
+}
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
+static void prepend_to_envs(const char *dir, int len)
+{
+ char *slash;
+ char *basedir;
+
+ /* basedir is dir with "/bin" stripped off */
+ basedir = xmalloc(len + 1);
+ memcpy(basedir, dir, len + 1);
+
+ if ((slash = strrchr(basedir, '/'))) {
+ *slash = 0;
+ while (slash == basedir + --len) /* found trailing slash */
+ if ((slash = strrchr(basedir, '/')))
+ *slash = 0;
+ }
- setenv("PATH", path, 1);
+ prepend_to_env("PATH", basedir, "/bin:",
+ "/usr/local/bin:/usr/bin:/bin");
+ prepend_to_env("MANPATH", basedir, "/share/man:",
+ "/usr/local/share/man:/usr/share/man");
+ prepend_to_env("PERL5LIB", basedir, "/lib/perl5:",
+ "/usr/lib/perl5");
- free(path);
+ free(basedir);
}
static int handle_options(const char*** argv, int* argc, int* envchanged)
@@ -414,8 +444,7 @@ int main(int argc, const char **argv)
*/
if (slash) {
*slash++ = 0;
- if (*cmd == '/')
- exec_path = cmd;
+ exec_path = cmd;
cmd = slash;
}
@@ -453,14 +482,15 @@ int main(int argc, const char **argv)
/*
* We execute external git command via execv_git_cmd(),
* which looks at "--exec-path" option, GIT_EXEC_PATH
- * environment, and $(gitexecdir) in Makefile while built,
- * in this order. For scripted commands, we prepend
- * the value of the exec_path variable to the PATH.
+ * environment, PATH environment, and $(gitexecdir) in
+ * Makefile while built, in this order. For scripted
+ * commands, we prepend the value of the exec_path
+ * variable to the PATH.
*/
if (exec_path)
- prepend_to_path(exec_path, strlen(exec_path));
+ prepend_to_envs(exec_path, strlen(exec_path));
exec_path = git_exec_path();
- prepend_to_path(exec_path, strlen(exec_path));
+ prepend_to_envs(exec_path, strlen(exec_path));
while (1) {
/* See if it's an internal command */
--
1.5.3.4.206.g58ba4-dirty
^ permalink raw reply related
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Johannes Sixt @ 2007-10-19 12:31 UTC (permalink / raw)
To: Theodore Tso
Cc: Santi Béjar, Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <20071019113822.GB16726@thunk.org>
Theodore Tso schrieb:
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> spearce/gitk (new)
> * branch maint -> spearce/maint 1aa3d01..e7187e4
> * branch master -> spearce/master de61e42..7840ce6
> * branch next -> spearce/next 895be02..2fe5433
> + branch pu -> spearce/pu 89fa332...1e4c517
> * branch todo -> spearce/todo (new)
> As far as the padding, it would be a pain to figure out how to make
> the right hand column be padded so that it starts 3 spaces after the
> longest " * branch foo -> bar" line, but that would look the best.
But this way it wouldn't be difficult at all:
==> git://repo.or.cz/git/spearce.git
* (new) gitk -> spearce/gitk
* 1aa3d01..e7187e4 maint -> spearce/maint
* de61e42..7840ce6 master -> spearce/master
* 895be02..2fe5433 next -> spearce/next
+ 89fa332...1e4c517 pu -> spearce/pu
* (new) todo -> spearce/todo
(I don't know where to put the label 'branch'.)
BTW, I like the ID ranges, too, and have used the information
occasionally.
-- Hannes
^ 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