* Re: [PATCH] Invoke git-repo-config directly.
From: Andreas Ericsson @ 2006-03-16 14:39 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060316162709.6f383f95.tihirvon@gmail.com>
Timo Hirvonen wrote:
> On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)
> Mark Wooding <mdw@distorted.org.uk> wrote:
>
>
>>By the way, am I the only person who /likes/ having all the git-*
>>programs on his path? It makes shell completion work fairly well
>>without having to install strange completion scripts which get out of
>>date for one thing.
>
>
> I like git-* for the same reason. But if git potty had aliases for long
> commands then git-* commands would become irrelevant. Especially
> "git co" would be nice. It even would be faster to type than
> git-ch<tab>c<tab>o<tab> ;)
>
It would indeed, and it should also be fairly trivial. However, adding
short-hands that are identical with cvs and svn but does a totally
different thing (well, not really different, but cvs users will be
surprised) is not necessarily a good thing.
It would be better, imo, to add ambiguity detection for commands that
lacks an exact match. That way "git br" and "git branch" would be
identical and the logic only needs doing once. I'm not terribly excited
about it though, so...
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-reset and clones
From: Paul Jakma @ 2006-03-16 14:34 UTC (permalink / raw)
To: git list
Hi,
Next dumb question:
If a git repository has a reset HEAD~X done, then any later pulls in
clone repositories get /really/ upset, with:
$ git pull
* refs/heads/origin: does not fast forward to branch 'master' of
/home/paul/foo-git/;
Type of thing. This seems to be a similar issue to:
http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
The question is has this improved at all since last year? Is there
anything the origin repository maintainer (the one who did reset) can
do to recover from this?
I'm guessing the answer is:
Yes:
1. where git-reset has already been done, manually update the
refs back to the previous HEAD
2. then use git-revert, and continue to use git-revert only.
My question then would be, presuming some innocent repository
maintainer has already done 1, what's the easiest way to accomplish
1?
(they shouldn't have done it obviously, but assume they're git
newbies, made an honest mistake and now need to recover, preferably
without having to involve those who pull).
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Be cautious in your daily affairs.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Timo Hirvonen @ 2006-03-16 14:27 UTC (permalink / raw)
To: git
In-Reply-To: <slrne1inu0.fr9.mdw@metalzone.distorted.org.uk>
On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)
Mark Wooding <mdw@distorted.org.uk> wrote:
> By the way, am I the only person who /likes/ having all the git-*
> programs on his path? It makes shell completion work fairly well
> without having to install strange completion scripts which get out of
> date for one thing.
I like git-* for the same reason. But if git potty had aliases for long
commands then git-* commands would become irrelevant. Especially
"git co" would be nice. It even would be faster to type than
git-ch<tab>c<tab>o<tab> ;)
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Andreas Ericsson @ 2006-03-16 13:53 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne1inu0.fr9.mdw@metalzone.distorted.org.uk>
Mark Wooding wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>
>
>>*1* BTW, I just noticed that git-sh-setup needs to be on user's
>>PATH, so we probably have to inline and duplicate the git_exec()
>>shell function definition at the beginning of each script after
>>all, when we make the initial ". git-sh-setup" inclusion to
>>honor GIT_EXEC_PATH without munging the user's PATH.
>
>
> . ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
>
> isn't too grim, and shows how the git_exec shell function can be made
> somewhat terser.
>
But it breaks the convenience when testing.
> By the way, am I the only person who /likes/ having all the git-*
> programs on his path? It makes shell completion work fairly well
> without having to install strange completion scripts which get out of
> date for one thing.
>
I like it too, but I don't use it unless I can't remember what the
command was named (finger-training). It shouldn't be too difficult to
make git.c write its own auto-generated bash-completion rules. If
someone would care to teach me the syntax I'd gladly hack up a patch for
it. This is a Good Thing, since it means it would also work for the
internal commands, which bash's path-completion doesn't.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Mark Wooding @ 2006-03-16 12:53 UTC (permalink / raw)
To: git
In-Reply-To: <7v64mebxsu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> *1* BTW, I just noticed that git-sh-setup needs to be on user's
> PATH, so we probably have to inline and duplicate the git_exec()
> shell function definition at the beginning of each script after
> all, when we make the initial ". git-sh-setup" inclusion to
> honor GIT_EXEC_PATH without munging the user's PATH.
. ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
isn't too grim, and shows how the git_exec shell function can be made
somewhat terser.
By the way, am I the only person who /likes/ having all the git-*
programs on his path? It makes shell completion work fairly well
without having to install strange completion scripts which get out of
date for one thing.
-- [mdw]
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Andreas Ericsson @ 2006-03-16 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Qingning Huo, git
In-Reply-To: <7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> And the second issue is the last point in the "implications"
> list above. You are right, and I stand corrected. Our scripts
> should consistently use dash form.
>
> One thing that bothers me is that we need to keep encouraging
> users to use dashless form from the command line, while we
> update our scripts to use dash form. What a contradicting and
> confusing situation X-<.
>
One of the two reasons for rewriting the git wrapper in C was the
performance penalty that came from having it as a shell-script while it
was desirable from a porcelainish standpoint to use the dash-less form
since we thought even then that "git" would always be in PATH while
"git-foo" was to be moved to the still-imaginary GIT_EXEC_PATH.
The prepending of the GIT_EXEC_PATH to PATH was a laziness workaround
for scripts that use the dashed form until we'd had time to change
those, although I see from the commit-message that it's a far cry from
abundantly clear (reading it now I even think it's clear I meant the
other way around, although I remember I didn't). Anyways, the relative
parts are these, from commit 8e49d50388211a0f3e7286f6ee600bf7736f4814
---8<---8<---8<---
The location of the GIT_EXEC_PATH (name discussion's closed,
thank gods) can be obtained by running
git --exec-path
which will hopefully give porcelainistas ample time to adapt their
heavy-duty loops to call the core programs directly and thus save
the extra fork() / execve() overhead, although that's not really
necessary any more.
The --exec-path value is prepended to $PATH, so the git-* programs
should Just Work without ever requiring any changes to how they call
other programs in the suite.
Some timing values for 10000 invocations of git-var >&/dev/null:
git.sh: 24.194s
git.c: 9.044s
git-var: 7.377s
---8<---8<---8<---
From the timing values there I think the performance issues of using
the dash-less form can just be ignored. Very rarely will a porcelainish
wrapper do 10000 invocations of git commands where less than 2 seconds
will be a large percentage of the overall runtime.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-16 10:14 UTC (permalink / raw)
To: Qingning Huo; +Cc: git
In-Reply-To: <20060316075324.GA19650@pfit.vm.bytemark.co.uk>
Qingning Huo <qhuo@mayhq.org> writes:
> On Wed, Mar 15, 2006 at 03:35:36PM -0800, Junio C Hamano wrote:
>> I think some historical background is in order.
>> ...
> Thanks for the historical background.
Sorry, it just occurred to me that I was totally confused, and I
apologize for giving only half of the historical background,
without giving the "end of the story -- conclusion", which I did
not remember until now.
What we ended up deciding after that "My /usr/bin/git is sane
but /usr/bin/diff is wrong so I have /home/$u/bin/diff and
/home/$u/bin is listed earlier in my $PATH" discussion, as I
remember, was this:
* We expect users to invoke things on the command line via the
"git" wrapper. Either having the directory that has our
"git" in earlier on the PATH, or giving the full path to it
as the command (your use of alias qualifies as the latter).
* One of the important things the "git" wrapper does is to
prefix GIT_EXEC_PATH to the $PATH environment before invoking
the "git-foo" commands [*1*].
* "git-foo" command, if it is written in a scripting language,
can safely assume "git-bar" is found on the PATH while it is
executing. If it is C-level and uses exec[vl]_git_cmd() to
run the subcommand, it would also work fine (it will use the
right GIT_EXEC_PATH).
This has a few implications:
* By doing the above setup, we are effectively punting on the
original issue. First of all, it is very inconceivable that
/usr/bin/git is sane, and /usr/bin/diff is not (git wants a
working diff after all). If the user is overriding
/usr/bin/diff by having a better diff under /home/$u/bin/, he
could have his own copy of git under /home/$u/bin/ as well
(more likely, the person with correct privilege to installed
/usr/bin/git would have replaced faulty /usr/bin/diff). More
importantly, when bindir and gitexecdir are split, gitexecdir
will not be /usr/bin (bindir will be). It will more likely
to be /usr/lib/git/exec, and it would contain only git-*
things; prefixing that directory to PATH would not mask the
/home/$u/bin/diff or anything else non-git the user wanted to
mask stuff from /usr/bin with, so the original issue becomes
moot at that point.
* Typing "git-foo" on the command line would work most of the
time, if git is built with gitexecdir set to standard bin
directory (the way our Makefile is shipped). git-foo will be
found on your PATH, and it will find "git-bar" on your PATH.
However, when we split bindir and gitexecdir, typing
"git-foo" on the command line without having GIT_EXEC_PATH on
your PATH would stop working, so users have been encouraged
to train their fingers to use dashless form ever since
GIT_EXEC_PATH was introduced [*2*].
* If "git-foo" invoked from the command line (without necessary
GIT_EXEC_PATH prefixing done by the "git" wrapper) tries to
run "git", the right git needs to be found on your PATH,
otherwise things may not necessarily work (your setup
violates this). But people have been encouraged to say "git
foo" to begin with, so this is probably not a big
deal. Retraining people to say "git foo" instead of "git-foo"
is a bigger issue compared to this.
* If "git foo" is typed on the command line, underlying
"git-foo" is run with GIT_EXEC_PATH prefixed, so it will find
"git-bar". If the script uses "git bar", "git" needs to be
found either in GIT_EXEC_PATH or on your PATH, since our
Makefile does not install "git" in gitexecdir. Right now, we
have bindir == gitexecdir, so "git bar" in "git-foo" script
will work fine and this is a non-issue, but when we split
them, it will break your setup, so we need to address this
before that happens.
So in short, there are two real issues with your original
"git-push misbehaves". One is that it broke because it was
spelled with dash. I think "git push" shouldn't misbehave even
with your setup, because the "git" wrapper, before it calls
"git-push", should set up the PATH so that its exec-path is in
front of anything you have in your original PATH (either
/usr/bin or ~/opt/bin), and should find the right "git".
And the second issue is the last point in the "implications"
list above. You are right, and I stand corrected. Our scripts
should consistently use dash form.
One thing that bothers me is that we need to keep encouraging
users to use dashless form from the command line, while we
update our scripts to use dash form. What a contradicting and
confusing situation X-<.
[Footnote]
*1* The "remove prefixing from git.c" patch I sent out earlier
tonight is wrong. That's the crucial piece to make this whole
setup work.
*2* I think I've been careful enough to use dashless form in the
examples I give in my list postings, but I am not sure how
successful I have been.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-16 8:26 UTC (permalink / raw)
To: Qingning Huo; +Cc: git
In-Reply-To: <20060316075324.GA19650@pfit.vm.bytemark.co.uk>
Qingning Huo <qhuo@mayhq.org> writes:
> So we recognize the full path approach is desired,
I said "if you can work problems your environment has _without_
doing the full path thing, then it would be ideal".
I never said full path is desired -- I despise full path, in
fact. It makes certain things very inconvenient.
> ...but because of
> technique reasons (building and testing), it is not applied.
There were not even a patch. I suspect people involved in the
discussion realized that approach was unworkably cumbersome.
In our Makefile, we have sed script mechanism to replace tokens
so we _could_ change our sources to do something like this:
diff --git a/git-commit.sh b/git-commit.sh
index 330a434..10835c6 100755
--- a/git-commit.sh
+++ b/git-commit.sh
...
@@ -115,7 +115,7 @@ run_status () {
echo '#
# Initial commit
#'
- git-ls-files |
+ @@GIT_PATH@@git-ls-files |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
@@ -126,7 +126,7 @@ run_status () {
committable="$?"
fi
- git-diff-files --name-status |
+ @@GIT_PATH@@git-diff-files --name-status |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
...
and sed it out with 's/@@GIT_PATH@@/$(gitexecdir_SQ)/g'.
However, you have to realize that I often want to try things out
*without* running "make", let alone installing. The current way
things are set up lets me say:
$ GIT_EXEC_PATH=$my_git_source \
sh -x $my_git_source/git-commit.sh
to see where things break. Changing things the way I quoted
above would make things _extremely_ inconvenient for me.
And it is ugly. "Making things ugly and inconvenient for what
purpose?" is the question I have to ask myself at this point.
And if the answer is "to support unusual configuration which,
quite frankly, I think is broken", then...
We could probably define a shell function that looks like:
git_exec () {
cmd="$1"
shift
case "${GIT_EXEC_PATH+set}" in
set) ;;
*) GIT_EXEC_PATH='@@GIT_EXEC_PATH@@' ;;
esac
"$GIT_EXEC_PATH/git-$cmd" "$@"
}
in git-sh-setup [*1*], and then rewrite the above to something
like this instead:
diff --git a/git-commit.sh b/git-commit.sh
index 330a434..8a73420 100755
--- a/git-commit.sh
+++ b/git-commit.sh
...
@@ -115,7 +115,7 @@ run_status () {
echo '#
# Initial commit
#'
- git-ls-files |
+ git_exec ls-files |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
@@ -126,7 +126,7 @@ run_status () {
committable="$?"
fi
- git-diff-files --name-status |
+ git_exec diff-files --name-status |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
...
But that does not cover Perl nor Python scripts, and does not
address the ugliness either.
[Footnote]
*1* BTW, I just noticed that git-sh-setup needs to be on user's
PATH, so we probably have to inline and duplicate the git_exec()
shell function definition at the beginning of each script after
all, when we make the initial ". git-sh-setup" inclusion to
honor GIT_EXEC_PATH without munging the user's PATH.
Which is not a big deal by itself, since we preprocess
*.{sh,perl,py} files anyway, but still it leaves a _big_
ugliness factor.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-16 7:57 UTC (permalink / raw)
To: Qingning Huo; +Cc: git
In-Reply-To: <20060316075324.GA19650@pfit.vm.bytemark.co.uk>
Qingning Huo <qhuo@mayhq.org> writes:
> I cannot uninstall /usr/bin/git. It is not under my control. I am
> wondering whether I should move my home dir to the front of the PATH.
That's what I found your configuration quite unusual.
When people have standard system executable directories such as
/usr/bin and /bin and private directories like /home/$u/bin and
/usr/local/bin on their PATH, private directories always come
before the system directories, so that things in the system
directories (often you do not have write permission to) can be
overriden by private directories (which is under your control).
I've never seen anybody sane to have system path before private
ones.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-16 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Qingning Huo, Linus Torvalds, git
In-Reply-To: <7vlkvbffhz.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 15, 2006 at 03:35:36PM -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Wed, 15 Mar 2006, Junio C Hamano wrote:
> >>
> >> If we do the dash-form for consistency's sake, we should do
> >> PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
> >> so.
> >
> > Yes. That would make sense too. Then git-setup-sh would look more like
> > what the builtin git.c does.
>
> I think some historical background is in order.
>
> We started without bindir vs execdir distinction but we wanted a
> way to someday migrate out of putting everything in bindir. As
> one part of the solution, "git" wrapper was invented, and as the
> result of that effort, some parts of the scripts, and lot of
> documentation pages and sample scripts, lost dashes.
>
> Historically, git tools have always wanted everything git-* to
> be found on user's PATH, and we were alarmed to see 100+ git-*
> commands in /usr/bin. That's why "git" wrapper and
> GIT_EXEC_PATH environment were invented. People can have
> /usr/bin/git and no other git-* on their PATH, because that
> "git" knows where to find the rest of git-* commands. For that
> to work, the scripts should know where to find the rest -- and
> cleanest way is to run others via "git foo" form.
>
> Consistency via s/git-foo/git foo/g _is_ the goal, but that kind
> of change interferes with the other patches that do the real
> work, and it is kind of boring, so nobody has done wholesale
> clean-up of all the scripts.
Thanks for the historical background.
> Invoking with the full path is not an option -- it makes
> building and testing-before-installing process too cumbersome.
> You are welcome to try and send in a patch to do that if (and
> only if) you volunteer to go the whole nine yards, but I have to
> warn you that that approach is something we have already
> considered and discarded, one reason why is because it makes the
> testsuite unworkable (testing needs to be done before
> installing).
So we recognize the full path approach is desired, but because of
technique reasons (building and testing), it is not applied. I would
like to have a look of the said patch. Can you give me some pointers?
> If you want to use the other "git" (GNU interactive tools, which
> I once heard is changing its name to gitfm or something like
> that -- how nice of them -- but has it ever happened?), and if
> you want to have /usr/bin (which has that "git") and then
> /other/bin (which has on-topic "git") on your PATH, in that
> order, that would be a problem. Saying just "git" would invoke
> other "git" that does not know what to do.
This is exactly the problem I want to solve. In this case, I alias git
to use our git program.
> If you can solve that without hardcoding the full path in our
> scripts, that would be ideal. But otherwise, especially with
> changing things back to "git-foo" form without making sure going
> backward in that way would not hinder the migration out of
> /usr/bin, then that creates more problems than it solves.
We do not hard code the full path in the script. We can use a function
gitexec() (in git-sh-setup) similiar to execv_git_cmd(). gitexec
searches git-command in GIT_EXEC_PATH, and then libexedir. libexedir is
hardcoded in git-sh-setup. But can be override by the environment
GIT_EXEC_PATH. The make test target should set GIT_EXEC_PATH to the
build directory.
The remaining job is search and replace. If we call gitexec() git(), we
can even keep the "git command" form unchanged. But I prefer explicit
gitexec().
> I _think_ the simplest fix is to change the order of directories
> you list on your PATH so that "git" is found before GNU
> interactive tool, which is my impression that most people seem
> to do (many in fact do not have GNU interactive tool on their
> PATH anywhere).
I cannot uninstall /usr/bin/git. It is not under my control. I am
wondering whether I should move my home dir to the front of the PATH.
But a good tool should not force users to change their settings.
Qingning
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-16 6:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Qingning Huo, git
In-Reply-To: <Pine.LNX.4.64.0603151450070.3618@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 15 Mar 2006, Junio C Hamano wrote:
>>
>> If we do the dash-form for consistency's sake, we should do
>> PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
>> so.
>
> Yes. That would make sense too. Then git-setup-sh would look more like
> what the builtin git.c does.
I actually think what git.c does is _wrong_.
Believe it or not, there are people with bizarre configurations
just like Qingning's is bizarre in different sense [*1*]. They
have diff they do not like (either broken or inadequete)
installed under /usr/bin, and they install GNU diff under
/home/$u/bin, and have their PATH set so that /home/$u/bin/diff
is found before /usr/bin/diff (up to here, there is nothing
bizarre). However, somehow they have the latest "git" installed
under /usr/bin (this _is_ the bizarre part).
Earlier, we prepended GIT_EXEC_PATH to user-supplied PATH when
C-level routines needed to exec git programs. This breaks that
"bizarre" setup -- for such a setup, GIT_EXEC_PATH is currently
set to /usr/bin and when we try to exec "diff", we ended up
running /usr/bin/diff. So in order to work this around, we
introduced exec[vl]_git_cmd() wrappers which use --exec-path
(if the command supports per invocation override), GIT_EXEC_PATH
environment, and then gitexecdir in Makefile when it was built,
in this order. "git" wrapper should know about this, but the
older code was never removed when we introduced exec_cmd.c.
I think we need to do something like the attached patch.
[Footnote]
*1* I first wrote "configuration even more bizarre than
Qingning's", but before sending the message out I came to
senses. We have to admit that that configuration is quite
unusual, and I would say it is the one more bizarre than the one
in question here. When people have standard system executable
directories such as /usr/bin and /bin and private directories
like /home/$u/bin and /usr/local/bin on their PATH, private
directories always come before the system directories, so that
things in the system directories (often you do not have write
permission to) can be overriden by private directories (which is
under your control).
-- >8 --
diff --git a/git.c b/git.c
index 0b40e30..25e6a4e 100644
--- a/git.c
+++ b/git.c
@@ -219,25 +219,6 @@ static void cmd_usage(int show_all, cons
exit(1);
}
-static void prepend_to_path(const char *dir, int len)
-{
- char *path, *old_path = getenv("PATH");
- int path_len = len;
-
- if (!old_path)
- old_path = "/usr/local/bin:/usr/bin:/bin";
-
- path_len = len + strlen(old_path) + 1;
-
- path = malloc(path_len + 1);
-
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
-
- setenv("PATH", path, 1);
-}
-
static void show_man_page(const char *git_cmd)
{
const char *page;
@@ -447,18 +428,6 @@ int main(int argc, const char **argv, ch
}
argv[0] = cmd;
- /*
- * We search for git commands in the following order:
- * - git_exec_path()
- * - the path of the "git" command if we could find it
- * in $0
- * - the regular PATH.
- */
- if (exec_path)
- prepend_to_path(exec_path, strlen(exec_path));
- exec_path = git_exec_path();
- prepend_to_path(exec_path, strlen(exec_path));
-
/* See if it's an internal command */
handle_internal_command(argc, argv, envp);
^ permalink raw reply related
* Re: [PATCH 3/3] blame: Rename detection (take 2)
From: Junio C Hamano @ 2006-03-16 0:31 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <20060310092141.24015.42482.stgit@c165>
Very nice. It even works with that "insanely fast rename
detector" by Linus ;-)
An example, from an early part of "git blame git-format-patch.sh":
0acfc972 git-format-patch-script (Junio C Hamano 2005-07-05 13:19:05 -0700
0acfc972 git-format-patch-script (Junio C Hamano 2005-07-05 13:19:05 -0700
0acfc972 git-format-patch-script (Junio C Hamano 2005-07-05 13:19:05 -0700
19bb7327 git-format-patch.sh (Mike McCormack 2006-03-06 22:12:12 +0900 6)
66f04f38 git-format-patch.sh (Andreas Ericsso 2006-02-07 09:37:54 +0000 7)
66f04f38 git-format-patch.sh (Andreas Ericsso 2006-02-07 09:37:54 +0000 8)
66f04f38 git-format-patch.sh (Andreas Ericsso 2006-02-07 09:37:54 +0000 9)
66f04f38 git-format-patch.sh (Andreas Ericsso 2006-02-07 09:37:54 +0000 10)
However, I think this underlines that chopping people's names to
the first 15 bytes (or any length for that matter) does not buy
you much.
^ permalink raw reply
* Re: [patch] fix imap-send for OSX
From: Junio C Hamano @ 2006-03-15 23:50 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86slpj5ljp.fsf@blue.stonehenge.com>
Thanks.
How much would we care about non GNU libc I wonder. We could
just lose that private definition, and say
#define _GNU_SOURCE
#include <stdio.h>
instead, in git-compat-util.h.
But let's leave that to later rounds.
^ permalink raw reply
* Re: [PATCH] Let merge set the default strategy.
From: Junio C Hamano @ 2006-03-15 23:40 UTC (permalink / raw)
To: Mark Hollomon; +Cc: git
In-Reply-To: <1142463103-6986-markhollomon@comcast.net>
Mark Hollomon <markhollomon@comcast.net> writes:
> If the user does not set a merge strategy for git-pull,
> let git-merge calculate a default strategy.
Makes lot of sense, thanks.
> This may be preferable to the earlier patch involving
> NO_PYTHON.
Which earlier patch???
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-15 23:35 UTC (permalink / raw)
To: Qingning Huo; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0603151450070.3618@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 15 Mar 2006, Junio C Hamano wrote:
>>
>> If we do the dash-form for consistency's sake, we should do
>> PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
>> so.
>
> Yes. That would make sense too. Then git-setup-sh would look more like
> what the builtin git.c does.
I think some historical background is in order.
We started without bindir vs execdir distinction but we wanted a
way to someday migrate out of putting everything in bindir. As
one part of the solution, "git" wrapper was invented, and as the
result of that effort, some parts of the scripts, and lot of
documentation pages and sample scripts, lost dashes.
Historically, git tools have always wanted everything git-* to
be found on user's PATH, and we were alarmed to see 100+ git-*
commands in /usr/bin. That's why "git" wrapper and
GIT_EXEC_PATH environment were invented. People can have
/usr/bin/git and no other git-* on their PATH, because that
"git" knows where to find the rest of git-* commands. For that
to work, the scripts should know where to find the rest -- and
cleanest way is to run others via "git foo" form.
Consistency via s/git-foo/git foo/g _is_ the goal, but that kind
of change interferes with the other patches that do the real
work, and it is kind of boring, so nobody has done wholesale
clean-up of all the scripts.
Invoking with the full path is not an option -- it makes
building and testing-before-installing process too cumbersome.
You are welcome to try and send in a patch to do that if (and
only if) you volunteer to go the whole nine yards, but I have to
warn you that that approach is something we have already
considered and discarded, one reason why is because it makes the
testsuite unworkable (testing needs to be done before
installing).
If you want to use the other "git" (GNU interactive tools, which
I once heard is changing its name to gitfm or something like
that -- how nice of them -- but has it ever happened?), and if
you want to have /usr/bin (which has that "git") and then
/other/bin (which has on-topic "git") on your PATH, in that
order, that would be a problem. Saying just "git" would invoke
other "git" that does not know what to do.
If you can solve that without hardcoding the full path in our
scripts, that would be ideal. But otherwise, especially with
changing things back to "git-foo" form without making sure going
backward in that way would not hinder the migration out of
/usr/bin, then that creates more problems than it solves.
So that is why I said I would prefer dashless form.
I _think_ the simplest fix is to change the order of directories
you list on your PATH so that "git" is found before GNU
interactive tool, which is my impression that most people seem
to do (many in fact do not have GNU interactive tool on their
PATH anywhere).
^ permalink raw reply
* [patch] fix imap-send for OSX
From: Randal L. Schwartz @ 2006-03-15 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6avgxva.fsf@assigned-by-dhcp.cox.net>
This patch works... I've been using it to stay current.
---
imap-send.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
ba458b49b860488c25cf57dabbb5db97f12e41f2
diff --git a/imap-send.c b/imap-send.c
index 1b38b3a..e33c78b 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -372,7 +372,7 @@ free_generic_messages( message_t *msgs )
}
static int
-vasprintf( char **strp, const char *fmt, va_list ap )
+git_vasprintf( char **strp, const char *fmt, va_list ap )
{
int len;
char tmp[1024];
@@ -402,7 +402,7 @@ nfsnprintf( char *buf, int blen, const c
static int
nfvasprintf( char **str, const char *fmt, va_list va )
{
- int ret = vasprintf( str, fmt, va );
+ int ret = git_vasprintf( str, fmt, va );
if (ret < 0)
die( "Fatal: Out of memory\n");
return ret;
--
1.2.4.g5593
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply related
* Re: [PATCH] Invoke git-repo-config directly.
From: Linus Torvalds @ 2006-03-15 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Qingning Huo, git
In-Reply-To: <7vek13ieap.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Mar 2006, Junio C Hamano wrote:
>
> If we do the dash-form for consistency's sake, we should do
> PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
> so.
Yes. That would make sense too. Then git-setup-sh would look more like
what the builtin git.c does.
Linus
^ permalink raw reply
* [PATCH] Let merge set the default strategy.
From: Mark Hollomon @ 2006-03-15 22:51 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, markhollomon
If the user does not set a merge strategy for git-pull,
let git-merge calculate a default strategy.
This may be preferable to the earlier patch involving
NO_PYTHON.
Signed-off-by: Mark Hollomon <markhollomon@comcast.net>
---
git-pull.sh | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
54e2c920b8ad979bc75d25ae73300be6077f46a0
diff --git a/git-pull.sh b/git-pull.sh
index 6caf1aa..7764b70 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -71,19 +71,15 @@ case "$merge_head" in
;;
?*' '?*)
var=`git repo-config --get pull.octopus`
- if test '' = "$var"
+ if test '' != "$var"
then
- strategy_default_args='-s octopus'
- else
strategy_default_args="-s $var"
fi
;;
*)
var=`git repo-config --get pull.twohead`
- if test '' = "$var"
- then
- strategy_default_args='-s recursive'
- else
+ if test '' != "$var"
+ then
strategy_default_args="-s $var"
fi
;;
--
1.2.4.gea75
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-03-15 22:13 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
- git-svn updates (Eric Wong)
- git-blame knows about renames (Fredrik Kuivinen)
- imap-send (Mike McCormack with fixes from Johannes Schindelin
and Marco Roeland)
- cvsimport only updates tracking branch (Matthias Urlichs)
- repo-config fix (Jonas Fonseca)
- fmt-merge-msg cleanup (Linus Torvalds)
- format-patch attachments enhancements (Mike McCormack)
- delitifier cleanup and performance fix (Nicolas Pitre)
- remove end-of-line period from git-pull message (Olaf Hering)
- http-push and fetch updates (Nick Hengeveld)
- rev-list and revision walker performance fix (Matthias Urlichs)
- annotate RPM packaging workaround (sean)
- assorted doc fixes (Francis Daly, Fredrik Kuivinen)
- assorted test fixes (Mark Wooding, me)
- improve git wrapper --help output (Fredrik Kuivinen)
- checkout-index --temp (Shawn Pearce)
- no more --standalone to fsck-objects
- rev-list path limiter fix at boundary
- git-diff: -p disables rename detection
As you can see from the above, the core part does not have
drastic changes these days anymore. Just some boring fixes with
a handful new and interesting developments.
In the "next" branch is the "insanely fast rename detection".
I've done some minor fixups to its hash function to be usable on
both 32-bit and 64-bit machines but otherwise it is what was
posted by Linus to the list. It completes the rename detection
between v2.6.12 and v2.6.14 kernel source under 5 seconds on my
Duron 750 with slow disks, where the current "master" branch
version takes about 60 seconds.
Also I've been keeping ls-{tree,files} --abbrev patches and
refs/remotes patch from Eric Wong in 'next' and 'pu'. I haven't
seen anybody jumps up and down to have them merged to "master",
nor have been asked to push them out sooner so that a widely
used Porcelain or two can take advantage of them, and that's the
only reason why they are not in "master". In other words, while
I do not have much against them, it would be nicer to have a
convincing argument why they are must-have's or even
better-have's before they graduate.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-15 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbrie79.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 15, 2006 at 01:35:22PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Linus Torvalds <torvalds@osdl.org> writes:
> >
> >> I agree that it is inconsistent as-is. So a patch to make it use the
> >> "git-repo-config" form (the argument being that internally, we use the
> >> full names) might be good if just for consistency.
> >
> > If we do the dash-form for consistency's sake,...
>
> Probably I should add that personally my preference is to standardize on
> the dashless form.
>
That would remove the possibility to run "git-push" in my scenario. And
what is the benefit? Wasting CPU cycles to an extra execve?
Duplicating git --exec-path to PATH?
Personally I recommend to always run git helper programs with absolute
path, this would remove all confusions, not play with users' PATH
environment, and save CPU cycles.
Qingning
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-15 21:35 UTC (permalink / raw)
To: git
In-Reply-To: <7vek13ieap.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
(replying to myself ...)
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> I agree that it is inconsistent as-is. So a patch to make it use the
>> "git-repo-config" form (the argument being that internally, we use the
>> full names) might be good if just for consistency.
>
> If we do the dash-form for consistency's sake,...
Probably I should add that personally my preference is to standardize on
the dashless form.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-15 21:33 UTC (permalink / raw)
To: Qingning Huo; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0603141506130.3618@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I agree that it is inconsistent as-is. So a patch to make it use the
> "git-repo-config" form (the argument being that internally, we use the
> full names) might be good if just for consistency.
If we do the dash-form for consistency's sake, we should do
PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
so. For scripts that do not use git-setup-sh they must have
their own.
This would make difference if/when we switch to
/usr/lib/git/exec, but until then it is not.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-15 20:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603141506130.3618@g5.osdl.org>
On Tue, Mar 14, 2006 at 03:07:39PM -0800, Linus Torvalds wrote:
> On Tue, 14 Mar 2006, Qingning Huo wrote:
> > We have "git-read-tree" and "git repo-config" at the same time. Are
> > there any rules saying which form should be preferred? How about pick
> > one form and stick to it?
>
> I agree that it is inconsistent as-is. So a patch to make it use the
> "git-repo-config" form (the argument being that internally, we use the
> full names) might be good if just for consistency.
>
Can these two patches be accepted then? What do others think?
Qingning
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Andreas Ericsson @ 2006-03-15 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Jakma, git, Linus Torvalds
In-Reply-To: <7vlkvbik8f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Can't this be done by updating .git/index first and then use the
>>temporary index to commit? Then .git/index would match the current
>>tree and everybody would be happy with very little tweaking. Doing the
>>temporary index commit first could cause data-loss as described above
>>if the updating of .git/index somehow fails and the user is unaware of
>>it (or what to do to fix it).
>
>
> You have to think about how to rewind it when the user decides
> later not to commit by for example giving an empty commit
> message or killing the editor. The order of things need to be
> to populate the index to be committed so that we can give
> preview in the commit log template upon 'commit -v', spawn the
> editor and get the final version of log, and then make a
> commit. So it may or may not be doable -- I haven't thought
> about it through, and currently have not much incentive nor
> inclination to think about it myself right now.
>
cp .git/index .git/pre-commit-index
and roll it back if the user aborts. Should work, but like you I don't
need that functionality, so...
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: seperate commits for objects already updated in index?
From: Junio C Hamano @ 2006-03-15 19:25 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Paul Jakma, git, Linus Torvalds
In-Reply-To: <44181DFE.7080204@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Can't this be done by updating .git/index first and then use the
> temporary index to commit? Then .git/index would match the current
> tree and everybody would be happy with very little tweaking. Doing the
> temporary index commit first could cause data-loss as described above
> if the updating of .git/index somehow fails and the user is unaware of
> it (or what to do to fix it).
You have to think about how to rewind it when the user decides
later not to commit by for example giving an empty commit
message or killing the editor. The order of things need to be
to populate the index to be committed so that we can give
preview in the commit log template upon 'commit -v', spawn the
editor and get the final version of log, and then make a
commit. So it may or may not be doable -- I haven't thought
about it through, and currently have not much incentive nor
inclination to think about it myself right now.
^ 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