* Re: [PATCH 8/8] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-10-28 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxzvwvde.fsf@gitster.siamese.dyndns.org>
On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> git push reports errors if a remote ref is not a strict subset
>> of a local ref. The push wouldn't be a fast-forward and is
>> therefore refused. This is in general a good idea.
>
>> This commit teaches git push to be quiet if the local is a strict
>> subset of the remote and no refspec is explicitly specified on
>> the command line. If the --verbose flag is used a "note:" is
>> printed for each ignored branch.
>
> What happens to the summary reporting after such a push? Does
> it say "branch foo was not pushed because you did not touch it
> since you fetched and it is already stale with respect to the
> remote side which has updates since then"?
It says nothing, it's quiet, as promised in the commit message ;)
That's the point of this patch.
But I see your point. Maybe it should say something like
"ignored 2 branches, which are strict subsets of remote."
"use --verbose for details."
?
> How does this interact with the "pretend we have fetched
> immediately after we pushed by updating the corresponding remote
> tracking branch" logic?
I doesn't change a remote tracking branch. I'll add a test
confirming this.
Steffen
^ permalink raw reply
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Junio C Hamano @ 2007-10-28 8:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <79CE31EE-0975-48EB-8B3E-FC9D6A8EB3E4@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> So the idea of --symbolic is really to return the argv as is?
> No change whatsoever allowed. Why would someone need this?
> Is it only for convenience when writing shell code?
rev-parse _is_ for convenience for writing shell scripts, to
sift various parameters into "rev-list arguments" and "non
rev-list arguments".
^ permalink raw reply
* Re: [PATCH 1/8] push: change push to fail if short ref name does not exist
From: Steffen Prohaska @ 2007-10-28 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabq3wvd6.fsf@gitster.siamese.dyndns.org>
On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> You can use a branch's shortname to push it. Push used to create
>> the branch on the remote side if it did not yet exist. If you
>> specified the wrong branch accidentally it was created. A safety
>> valve that pushes only existing branches may help to avoid
>> errors.
>
> I do not agree with this change.
>
> If you misspelled the branch name (by the way, it is not a
> "shortname", but what follows refs/heads/ is _the_ name of the
> branch)
True. Is "short refname" the correct wording?
> "frotz" as "frtoz", and if a branch with the misspelled
> name did _not_ exist locally, it would fail, with or without
> this change, which is a good thing.
>
> But if you named "nitfol" that exists locally when you meant to
> push "frotz" out, if "nitfol" remotely existed, we will push
> that anyway by mistake, even with this change. It will prevent
> the push only when "nitfol" did not happen to exist at the
> remote side.
My proposed change is more defensive than the current
implementation. It allows distinguishing between "push existing
branch" and "create new branch on the remote side", which I
believe is a good thing. The current implementation uses
the same command line in both cases.
Daniel suggested that git push should print a recommendation
what full ref to use. This would make it easy to correct
the command. Ot you could use the '--create' flag to make
your intention explicit.
If we take the "push origin HEAD" patch, the existence check is
even more important. If you're on the wrong branch and push HEAD
you may be surprised if a new branch is created. This can be
avoided by requiring either a full ref or the '--create' flag.
> Earlier there was a discussion to introduce an optional
> configuration that makes "git push" without any parameter to
> push only the current branch out, in order to help people who
> work with shared remote central repository. That might be a
> better alternative to avoid pushing out wrong branch by
> mistake. That approach would also make your 8/8 unnecessary.
I didn't have the impression that the discussion went in
this direction. There were quite a few people who just said
"git push" is the counter-part of "git fetch". Therefore
"git push" pushes _all_ branches. Period.
With "git push HEAD" 5/8 you could now push only the current branch
(its existence would be verified if 1/8 is also accepted).
8/8 solves a different issue, too. I never advance local branches if
I do not intend to push them. Therefore I can always say "git push"
without any argument. It does always the right thing for me; except
for the annoying error messages that are avoided by 8/8. With 8/8
I can push several local branches while ignoring the ones that I'm
not interested in.
Steffen
^ permalink raw reply
* [RFH] gcc constant expression warning...
From: Junio C Hamano @ 2007-10-28 8:46 UTC (permalink / raw)
To: git
With the recent gcc, we get:
sha1_file.c: In check_packed_git_:
sha1_file.c:527: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is always false
sha1_file.c:527: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is always false
when compiling with
-O2 -Werror -Wall -Wold-style-definition \
-ansi -pedantic -std=c99 -Wdeclaration-after-statement
The offending lines are:
if (idx_size != min_size) {
/* make sure we can deal with large pack offsets */
off_t x = 0x7fffffffUL, y = 0xffffffffUL;
if (x > (x + 1) || y > (y + 1)) {
munmap(idx_map, idx_size);
^ permalink raw reply
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Steffen Prohaska @ 2007-10-28 8:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071028080654.GS14735@spearce.org>
On Oct 28, 2007, at 9:06 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
>>> Steffen Prohaska <prohaska@zib.de> writes:
>>>> @@ -213,6 +215,7 @@ int cmd_rev_parse(int argc, const char **argv,
>>>> const char *prefix)
>>>> {
>>>> int i, as_is = 0, verify = 0;
>>>> unsigned char sha1[20];
>>>> + char* real_name = 0;
>>>
>>> Pointer sign '*' in git sources go next to the name not the
>>> type, as:
>>>
>>> char *real_name = NULL;
>>
>> I know and I tried hard to follow this convention, although
>> I think its the wrong choice ;)
>
> Oh, hmm...
>
> char* a, b;
>
> What's the type of b? If you said "char*" you're wrong.
I know. Obviously, you need a combination of conventions.
- '*' is part of the type; put it there.
- Only define a single variable per statement.
My combined rule avoids your question. I typically use C++,
which make the second rule easier to follow, because you
defer defining variables until you really need them. There's
no need to save space at the start of the function block by
defining several variables in a single line.
> Git's style of putting the * next to the name makes it far easier to
> spot these sort of typing problems. At least that's my take on it.
Let's stop this discussion here. I'm not proposing to change the
rules. I'll follow the git coding conventions when submitting
patches to git, even if it's sometimes hard for me. I already packed
as much as possible in my editor configuration. Unfortunately,
I can't teach vim to always place the '*' correctly. At least I
don't know how to do this.
Steffen
^ permalink raw reply
* Re: [PATCH 6/7] walk $PATH to generate list of commands for "help -a"
From: Scott Parish @ 2007-10-28 9:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl3vzrs5.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 27, 2007 at 11:18:02PM -0700, Junio C Hamano wrote:
> > We walk all the paths in $PATH collecting the names of "git-*"
> > commands. To help distinguish between the main git commands
> > and commands picked up elsewhere (probably extensions) we
> > print them seperately. The main commands are the ones that
> > are found in the first directory in $PATH that contains the
> > "git" binary.
>
> This is not right. $(gitexecdir) in Makefile is designed to
> allow distros to move git-* commands out of the primary user
> $PATH directories and install only "git" wrapper in /usr/bin.
> "Use the directory 'git' is in" rule breaks this.
>
> The "main commands" should be the first of argv_exec_path,
> EXEC_PATH_ENVIRONMENT or builtin_exec_path.
This is after we've already prepended the above three paths (if
they're specified) to $PATH, so yes, generally they should be in
one of those directories, but more generally, it will be in one of
the directories in $PATH.
Its not clear to me what exactly you're looking for me to change,
just the wording i'm using in my comment? Or are you refering to
the approach?
When i email the changes, should i keep emailing the whole
patch series, or just the few patches that have changed?
Thanks
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* [PATCH] git.el: Fix typo in "Reverted file" message.
From: Alexandre Julliard @ 2007-10-28 10:05 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 4286d16..8cfbdd7 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -955,7 +955,7 @@ Return the list of files that haven't been handled."
(when modified
(apply #'git-call-process-env nil nil "checkout" "HEAD" modified))
(git-update-status-files (append added modified) 'uptodate)
- (git-success-message "Reverted" files))))
+ (git-success-message "Reverted" (git-get-filenames files)))))
(defun git-resolve-file ()
"Resolve conflicts in marked file(s)."
--
1.5.3.4.404.g5a866
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH] git.el: Fix typo in git-update-saved-file error handling.
From: Alexandre Julliard @ 2007-10-28 10:05 UTC (permalink / raw)
To: git
Spotted by Matthieu Lemerre.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 8cfbdd7..0e5091c 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1353,7 +1353,7 @@ Commands:
"Update the corresponding git-status buffer when a file is saved.
Meant to be used in `after-save-hook'."
(let* ((file (expand-file-name buffer-file-name))
- (dir (condition-case nil (git-get-top-dir (file-name-directory file))))
+ (dir (condition-case nil (git-get-top-dir (file-name-directory file)) (error nil)))
(buffer (and dir (git-find-status-buffer dir))))
(when buffer
(with-current-buffer buffer
--
1.5.3.4.404.g5a866
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH] git.el: Refresh only the changed file marks when marking/unmarking all.
From: Alexandre Julliard @ 2007-10-28 10:06 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 0e5091c..e5ee8ce 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -842,7 +842,8 @@ Return the list of files that haven't been handled."
"Mark all files."
(interactive)
(unless git-status (error "Not in git-status buffer."))
- (ewoc-map (lambda (info) (setf (git-fileinfo->marked info) t) t) git-status)
+ (ewoc-map (lambda (info) (unless (git-fileinfo->marked info)
+ (setf (git-fileinfo->marked info) t))) git-status)
; move back to goal column after invalidate
(when goal-column (move-to-column goal-column)))
@@ -850,7 +851,9 @@ Return the list of files that haven't been handled."
"Unmark all files."
(interactive)
(unless git-status (error "Not in git-status buffer."))
- (ewoc-map (lambda (info) (setf (git-fileinfo->marked info) nil) t) git-status)
+ (ewoc-map (lambda (info) (when (git-fileinfo->marked info)
+ (setf (git-fileinfo->marked info) nil)
+ t)) git-status)
; move back to goal column after invalidate
(when goal-column (move-to-column goal-column)))
--
1.5.3.4.404.g5a866
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH 6/7] walk $PATH to generate list of commands for "help -a"
From: Junio C Hamano @ 2007-10-28 10:07 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071028094530.GA7749@srparish.net>
Scott Parish <sRp@srparish.net> writes:
> On Sat, Oct 27, 2007 at 11:18:02PM -0700, Junio C Hamano wrote:
>
>> > We walk all the paths in $PATH collecting the names of "git-*"
>> > commands. To help distinguish between the main git commands
>> > and commands picked up elsewhere (probably extensions) we
>> > print them seperately. The main commands are the ones that
>> > are found in the first directory in $PATH that contains the
>> > "git" binary.
>> ...
> Its not clear to me what exactly you're looking for me to change,
> just the wording i'm using in my comment? Or are you refering to
> the approach?
"git" binary will be found as /usr/bin/git while git-foo will be
found as /usr/libexec/git/git-foo in such an installation that
takes advantage of $(gitexecdir). And /usr/libexec/git/git will
not exist. Using existence of /usr/bin/git (I am referring to
your 'first directory on $PATH that contains the "git" binary'
above) as the cue for the location of "main commands" is wrong.
> When i email the changes, should i keep emailing the whole
> patch series, or just the few patches that have changed?
It's up to you. Obviously, if you are replacing 2 patches out
of 100-patch series, you would not want to resend the whole
thing, though ;-)
^ permalink raw reply
* [PATCH] git.el: Run git-gc --auto after commits.
From: Alexandre Julliard @ 2007-10-28 10:07 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index e5ee8ce..e147da0 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -796,6 +796,7 @@ Return the list of files that haven't been handled."
(with-current-buffer buffer (erase-buffer))
(dolist (info files) (git-set-fileinfo-state info 'uptodate))
(git-call-process-env nil nil "rerere")
+ (git-call-process-env nil nil "gc" "--auto")
(git-refresh-files)
(git-refresh-ewoc-hf git-status)
(message "Committed %s." commit)
--
1.5.3.4.404.g5a866
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: Many gits are offline this week
From: Mike Hommey @ 2007-10-28 10:07 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <863awq5p1y.fsf@blue.stonehenge.com>
On Thu, Oct 04, 2007 at 06:27:05PM -0700, Randal L. Schwartz wrote:
> >>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
>
> Shawn> Dscho and I will be (at least mostly) offline for the next four
> Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
> Shawn> Mentor Summit.
>
> Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
> 12 october. Too bad you're just going to miss that. :)
Not that it's hard to find, but just for the record, Randal's talk can
be viewed on http://video.google.com/videoplay?docid=1251251453592758541
Mike
^ permalink raw reply
* Re: [RFH] gcc constant expression warning...
From: Florian Weimer @ 2007-10-28 10:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7dnvd6w.fsf@gitster.siamese.dyndns.org>
* Junio C. Hamano:
> The offending lines are:
>
> if (idx_size != min_size) {
> /* make sure we can deal with large pack offsets */
> off_t x = 0x7fffffffUL, y = 0xffffffffUL;
> if (x > (x + 1) || y > (y + 1)) {
> munmap(idx_map, idx_size);
x and y must be unsigned for this test to work (signed overflow is
undefined).
^ permalink raw reply
* How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-28 10:57 UTC (permalink / raw)
To: git
I'm reading code of git.
When I type
gtlg --topo-order --pretty=oneline --abbrev-commit e92ea624 -p
in directory git cloned from git.git, I get
e92ea62... Merge branch 'master' of git://repo.or.cz/git-gui
c80d25d... git-gui: Correct 'git gui blame' in a subdirectory
diff --git a/git-gui.sh b/git-gui.sh
index 743b7d4..fa30ccc 100755
--- a/git-gui.sh
+++ b/git-gui.sh
...
git-gui.sh is in the git-gui directory but we see a/git-gui.sh here
other than a/git-gui/git-gui.sh.
And in git://repo.or.cz/git-gui, I see git-gui.sh in the top directory
I just wonder how does this happen and how to merge
git://repo.or.cz/git-gui into git.git this way?
--
franky
^ permalink raw reply
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-28 11:00 UTC (permalink / raw)
To: git
In-Reply-To: <46dff0320710280357u23927960hd204760b3d664ce2@mail.gmail.com>
On 10/28/07, Yin Ping <pkufranky@gmail.com> wrote:
> When I type
> gtlg --topo-order --pretty=oneline --abbrev-commit e92ea624 -p
Sorry, my fault. gtlg is an alias for git-log
> franky
>
--
franky
^ permalink raw reply
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Peter Baumann @ 2007-10-28 11:14 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710280400v523e2130nd3286a88a4920a9c@mail.gmail.com>
On Sun, Oct 28, 2007 at 07:00:54PM +0800, Yin Ping wrote:
> On 10/28/07, Yin Ping <pkufranky@gmail.com> wrote:
>
> > When I type
> > gtlg --topo-order --pretty=oneline --abbrev-commit e92ea624 -p
> Sorry, my fault. gtlg is an alias for git-log
>
> > franky
> >
>
Have a look at the subtree merge strategy [1] and at the following
explanations how git-gui got initally merged.
-Peter
[1]: http://www.gelato.unsw.edu.au/archives/git/0702/40139.html
[2]: http://www.gelato.unsw.edu.au/archives/git/0702/39661.html
^ permalink raw reply
* Re: [PATCH 6/7] walk $PATH to generate list of commands for "help -a"
From: Scott Parish @ 2007-10-28 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodejv9gt.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 28, 2007 at 03:07:14AM -0700, Junio C Hamano wrote:
> Scott Parish <sRp@srparish.net> writes:
>
> > On Sat, Oct 27, 2007 at 11:18:02PM -0700, Junio C Hamano wrote:
> >
> >> > We walk all the paths in $PATH collecting the names of "git-*"
> >> > commands. To help distinguish between the main git commands
> >> > and commands picked up elsewhere (probably extensions) we
> >> > print them seperately. The main commands are the ones that
> >> > are found in the first directory in $PATH that contains the
> >> > "git" binary.
> >> ...
> > Its not clear to me what exactly you're looking for me to change,
> > just the wording i'm using in my comment? Or are you refering to
> > the approach?
>
> "git" binary will be found as /usr/bin/git while git-foo will be
> found as /usr/libexec/git/git-foo in such an installation that
> takes advantage of $(gitexecdir). And /usr/libexec/git/git will
> not exist. Using existence of /usr/bin/git (I am referring to
> your 'first directory on $PATH that contains the "git" binary'
> above) as the cue for the location of "main commands" is wrong.
Thanks for the clarification, that would be a problem. I've modified
the patch to list the main commands from git_exec_path(); i have
mixed feelings, but curious what you think.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* [PATCH 5/7] use only the $PATH for exec'ing git commands
From: Scott R Parish @ 2007-10-28 11:17 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193474215-6728-5-git-send-email-srp@srparish.net>
We need to correctly set up $PATH for non-c based git commands.
Since we already do this, we can just use that $PATH and execvp,
instead of looping over the paths with execve.
This patch adds a setup_path() function to exec_cmd.c, which sets
the $PATH order correctly for our search order. execv_git_cmd() is
stripped down to setting up argv and calling execvp(). git.c's
main() only only needs to call setup_path().
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 121 ++++++++++++++++++++++++++----------------------------------
exec_cmd.h | 1 +
git.c | 43 +++------------------
3 files changed, 60 insertions(+), 105 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 8b681d0..53d0f3c 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -29,85 +29,68 @@ const char *git_exec_path(void)
return builtin_exec_path;
}
+static void add_path(struct strbuf *out, const char *path)
+{
+ if (path && *path) {
+ if (is_absolute_path(path))
+ strbuf_addstr(out, path);
+ else
+ strbuf_addstr(out, make_absolute_path(path));
+
+ strbuf_addch(out, ':');
+ }
+}
+
+void setup_path(const char *cmd_path)
+{
+ const char *old_path = getenv("PATH");
+ struct strbuf new_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, cmd_path);
+
+ if (old_path)
+ strbuf_addstr(&new_path, old_path);
+ else
+ strbuf_addstr(&new_path, "/usr/local/bin:/usr/bin:/bin");
+
+ setenv("PATH", new_path.buf, 1);
+
+ strbuf_release(&new_path);
+}
int execv_git_cmd(const char **argv)
{
- char git_command[PATH_MAX + 1];
- int i;
- const char *paths[] = { argv_exec_path,
- getenv(EXEC_PATH_ENVIRONMENT),
- builtin_exec_path };
-
- for (i = 0; i < ARRAY_SIZE(paths); ++i) {
- size_t len;
- int rc;
- const char *exec_dir = paths[i];
- const char *tmp;
-
- if (!exec_dir || !*exec_dir) continue;
-
- if (*exec_dir != '/') {
- if (!getcwd(git_command, sizeof(git_command))) {
- fprintf(stderr, "git: cannot determine "
- "current directory: %s\n",
- strerror(errno));
- break;
- }
- len = strlen(git_command);
-
- /* Trivial cleanup */
- while (!prefixcmp(exec_dir, "./")) {
- exec_dir += 2;
- while (*exec_dir == '/')
- exec_dir++;
- }
-
- rc = snprintf(git_command + len,
- sizeof(git_command) - len, "/%s",
- exec_dir);
- if (rc < 0 || rc >= sizeof(git_command) - len) {
- fprintf(stderr, "git: command name given "
- "is too long.\n");
- break;
- }
- } else {
- if (strlen(exec_dir) + 1 > sizeof(git_command)) {
- fprintf(stderr, "git: command name given "
- "is too long.\n");
- break;
- }
- strcpy(git_command, exec_dir);
- }
-
- len = strlen(git_command);
- rc = snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[0]);
- if (rc < 0 || rc >= sizeof(git_command) - len) {
- fprintf(stderr,
- "git: command name given is too long.\n");
- break;
- }
+ struct strbuf cmd;
+ const char *tmp;
- /* argv[0] must be the git command, but the argv array
- * belongs to the caller, and my be reused in
- * subsequent loop iterations. Save argv[0] and
- * restore it on error.
- */
+ strbuf_init(&cmd, 0);
+ strbuf_addf(&cmd, "git-%s", argv[0]);
- tmp = argv[0];
- argv[0] = git_command;
+ /* argv[0] must be the git command, but the argv array
+ * belongs to the caller, and my be reused in
+ * subsequent loop iterations. Save argv[0] and
+ * restore it on error.
+ */
+ tmp = argv[0];
+ argv[0] = cmd.buf;
- trace_argv_printf(argv, -1, "trace: exec:");
+ trace_argv_printf(argv, -1, "trace: exec:");
- /* execve() can only ever return if it fails */
- execve(git_command, (char **)argv, environ);
+ /* execvp() can only ever return if it fails */
+ execvp(cmd.buf, (char **)argv);
- trace_printf("trace: exec failed: %s\n", strerror(errno));
+ trace_printf("trace: exec failed: %s\n", strerror(errno));
- argv[0] = tmp;
- }
- return -1;
+ argv[0] = tmp;
+ strbuf_release(&cmd);
+
+ return -1;
}
diff --git a/exec_cmd.h b/exec_cmd.h
index da99287..a892355 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -3,6 +3,7 @@
extern void git_set_argv_exec_path(const char *exec_path);
extern const char* git_exec_path(void);
+extern void setup_path(const char *);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
diff --git a/git.c b/git.c
index c7cabf5..4e10581 100644
--- a/git.c
+++ b/git.c
@@ -6,28 +6,6 @@
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)
-{
- 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);
-
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
-
- setenv("PATH", path, 1);
-
- free(path);
-}
-
static int handle_options(const char*** argv, int* argc, int* envchanged)
{
int handled = 0;
@@ -408,7 +386,7 @@ int main(int argc, const char **argv)
{
const char *cmd = argv[0] ? argv[0] : "git-help";
char *slash = strrchr(cmd, '/');
- const char *exec_path = NULL;
+ const char *cmd_path = NULL;
int done_alias = 0;
/*
@@ -418,10 +396,7 @@ int main(int argc, const char **argv)
*/
if (slash) {
*slash++ = 0;
- if (*cmd == '/')
- exec_path = cmd;
- else
- exec_path = xstrdup(make_absolute_path(cmd));
+ cmd_path = cmd;
cmd = slash;
}
@@ -458,16 +433,12 @@ int main(int argc, const char **argv)
cmd = argv[0];
/*
- * 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.
+ * We use PATH to find git commands, but we prepend some higher
+ * precidence paths: the "--exec-path" option, the GIT_EXEC_PATH
+ * environment, and the $(gitexecdir) from the Makefile at build
+ * time.
*/
- if (exec_path)
- prepend_to_path(exec_path, strlen(exec_path));
- exec_path = git_exec_path();
- prepend_to_path(exec_path, strlen(exec_path));
+ setup_path(cmd_path);
while (1) {
/* See if it's an internal command */
--
1.5.3.4.401.g19778-dirty
^ permalink raw reply related
* [PATCH 6/7] include $PATH in generating list of commands for "help -a"
From: Scott R Parish @ 2007-10-28 11:18 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193474215-6728-6-git-send-email-srp@srparish.net>
Git had previously been using the $PATH for scripts--a previous
patch moved exec'ed commands to also use the $PATH. For consistency
"help -a" should also list commands in the $PATH.
The main commands are still listed from the git_exec_path(), but
the $PATH is walked and other git commands (probably extensions) are
listed.
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 162 +++++++++++++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 124 insertions(+), 38 deletions(-)
diff --git a/help.c b/help.c
index 34ac5db..2534bf0 100644
--- a/help.c
+++ b/help.c
@@ -37,24 +37,28 @@ static inline void mput_char(char c, unsigned int num)
putchar(c);
}
-static struct cmdname {
- size_t len;
- char name[1];
-} **cmdname;
-static int cmdname_alloc, cmdname_cnt;
-
-static void add_cmdname(const char *name, int len)
+static struct cmdnames {
+ int alloc;
+ int cnt;
+ struct cmdname {
+ size_t len;
+ char name[1];
+ } **names;
+} main_cmds, other_cmds;
+
+static void add_cmdname(struct cmdnames *cmds, const char *name, int len)
{
struct cmdname *ent;
- if (cmdname_alloc <= cmdname_cnt) {
- cmdname_alloc = cmdname_alloc + 200;
- cmdname = xrealloc(cmdname, cmdname_alloc * sizeof(*cmdname));
+ if (cmds->alloc <= cmds->cnt) {
+ cmds->alloc = cmds->alloc + 200;
+ cmds->names = xrealloc(cmds->names,
+ cmds->alloc * sizeof(*cmds->names));
}
ent = xmalloc(sizeof(*ent) + len);
ent->len = len;
memcpy(ent->name, name, len);
ent->name[len] = 0;
- cmdname[cmdname_cnt++] = ent;
+ cmds->names[cmds->cnt++] = ent;
}
static int cmdname_compare(const void *a_, const void *b_)
@@ -64,7 +68,44 @@ static int cmdname_compare(const void *a_, const void *b_)
return strcmp(a->name, b->name);
}
-static void pretty_print_string_list(struct cmdname **cmdname, int longest)
+static void uniq(struct cmdnames *cmds)
+{
+ int i, j;
+
+ if (!cmds->cnt)
+ return;
+
+ for (i = j = 1; i < cmds->cnt; i++) {
+ if (strcmp(cmds->names[i]->name, cmds->names[i-1]->name)) {
+ cmds->names[j++] = cmds->names[i];
+ }
+ }
+
+ cmds->cnt = j;
+}
+
+static void subtract_cmds(struct cmdnames *a, struct cmdnames *b) {
+ int ai, aj, bi;
+ int cmp;
+
+ ai = aj = bi = 0;
+ while (ai < a->cnt && bi < b->cnt) {
+ cmp = strcmp(a->names[ai]->name, b->names[bi]->name);
+ if (cmp < 0)
+ a->names[aj++] = a->names[ai++];
+ else if (cmp == 0)
+ ai++, bi++;
+ else if (cmp > 0)
+ bi++;
+ }
+
+ while (ai < a->cnt)
+ a->names[aj++] = a->names[ai++];
+
+ a->cnt = aj;
+}
+
+static void pretty_print_string_list(struct cmdnames *cmds, int longest)
{
int cols = 1, rows;
int space = longest + 1; /* min 1 SP between words */
@@ -73,9 +114,7 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
if (space < max_cols)
cols = max_cols / space;
- rows = (cmdname_cnt + cols - 1) / cols;
-
- qsort(cmdname, cmdname_cnt, sizeof(*cmdname), cmdname_compare);
+ rows = (cmds->cnt + cols - 1) / cols;
for (i = 0; i < rows; i++) {
printf(" ");
@@ -83,31 +122,29 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
for (j = 0; j < cols; j++) {
int n = j * rows + i;
int size = space;
- if (n >= cmdname_cnt)
+ if (n >= cmds->cnt)
break;
- if (j == cols-1 || n + rows >= cmdname_cnt)
+ if (j == cols-1 || n + rows >= cmds->cnt)
size = 1;
- printf("%-*s", size, cmdname[n]->name);
+ printf("%-*s", size, cmds->names[n]->name);
}
putchar('\n');
}
}
-static void list_commands(const char *exec_path)
+static unsigned int list_commands_in_dir(struct cmdnames *cmds, const char *dir)
{
unsigned int longest = 0;
const char *prefix = "git-";
int prefix_len = strlen(prefix);
- DIR *dir = opendir(exec_path);
+ DIR *dirp = opendir(dir);
struct dirent *de;
+ struct stat st;
- if (!dir || chdir(exec_path)) {
- fprintf(stderr, "git: '%s': %s\n", exec_path, strerror(errno));
- exit(1);
- }
+ if (!dirp || chdir(dir))
+ return 0;
- while ((de = readdir(dir)) != NULL) {
- struct stat st;
+ while ((de = readdir(dirp)) != NULL) {
int entlen;
if (prefixcmp(de->d_name, prefix))
@@ -125,16 +162,67 @@ static void list_commands(const char *exec_path)
if (longest < entlen)
longest = entlen;
- add_cmdname(de->d_name + prefix_len, entlen);
+ add_cmdname(cmds, de->d_name + prefix_len, entlen);
+ }
+ closedir(dirp);
+
+ return longest;
+}
+
+static void list_commands(void)
+{
+ unsigned int longest = 0;
+ unsigned int len;
+ const char *env_path = getenv("PATH");
+ char *paths, *path, *colon;
+ const char *exec_path = git_exec_path();
+
+ if (exec_path)
+ longest = list_commands_in_dir(&main_cmds, exec_path);
+
+ if (!env_path) {
+ fprintf(stderr, "PATH not set\n");
+ exit(1);
+ }
+
+ path = paths = xstrdup(env_path);
+ while (1) {
+ if ((colon = strchr(path, ':')))
+ *colon = 0;
+
+ len = list_commands_in_dir(&other_cmds, path);
+ longest = MAX(longest, len);
+
+ if (!colon)
+ break;
+ path = colon + 1;
+ }
+ free(paths);
+
+ qsort(main_cmds.names, main_cmds.cnt,
+ sizeof(*main_cmds.names), cmdname_compare);
+ uniq(&main_cmds);
+
+ qsort(other_cmds.names, other_cmds.cnt,
+ sizeof(*other_cmds.names), cmdname_compare);
+ uniq(&other_cmds);
+ subtract_cmds(&other_cmds, &main_cmds);
+
+ if (main_cmds.cnt) {
+ printf("available git commands in '%s'\n", exec_path);
+ printf("----------------------------");
+ mput_char('-', strlen(exec_path));
+ putchar('\n');
+ pretty_print_string_list(&main_cmds, longest);
+ putchar('\n');
+ }
+
+ if (other_cmds.cnt) {
+ printf("git commands available from elsewhere on your $PATH\n");
+ printf("---------------------------------------------------\n");
+ pretty_print_string_list(&other_cmds, longest);
+ putchar('\n');
}
- closedir(dir);
-
- printf("git commands available in '%s'\n", exec_path);
- printf("----------------------------");
- mput_char('-', strlen(exec_path));
- putchar('\n');
- pretty_print_string_list(cmdname, longest);
- putchar('\n');
}
void list_common_cmds_help(void)
@@ -188,7 +276,6 @@ int cmd_version(int argc, const char **argv, const char *prefix)
int cmd_help(int argc, const char **argv, const char *prefix)
{
const char *help_cmd = argc > 1 ? argv[1] : NULL;
- const char *exec_path = git_exec_path();
if (!help_cmd) {
printf("usage: %s\n\n", git_usage_string);
@@ -198,8 +285,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a")) {
printf("usage: %s\n\n", git_usage_string);
- if(exec_path)
- list_commands(exec_path);
+ list_commands();
exit(0);
}
--
1.5.3.4.401.g19778-dirty
^ permalink raw reply related
* Re: [RFH] gcc constant expression warning...
From: Antti-Juhani Kaijanaho @ 2007-10-28 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7dnvd6w.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> kirjoitti 28.10.2007:
> With the recent gcc, we get:
>
> sha1_file.c: In check_packed_git_:
> sha1_file.c:527: warning: assuming signed overflow does not
> occur when assuming that (X + c) < X is always false
> sha1_file.c:527: warning: assuming signed overflow does not
> occur when assuming that (X + c) < X is always false
>
> when compiling with
>
> -O2 -Werror -Wall -Wold-style-definition \
> -ansi -pedantic -std=c99 -Wdeclaration-after-statement
-ansi and -std=c99 in the same command line is a bit weird, BTW :)
> The offending lines are:
>
> if (idx_size != min_size) {
> /* make sure we can deal with large pack offsets */
> off_t x = 0x7fffffffUL, y = 0xffffffffUL;
> if (x > (x + 1) || y > (y + 1)) {
> munmap(idx_map, idx_size);
The second if line invokes undefined behavior if off_t cannot represent
0x7fffffffUL + 1. GCC apparently takes that as a license to ignore
overflow and rewrite that if as "if (0) { ...".
A fast fix is to compile with -fwrapv or with -fno-strict-overflow:
-fstrict-overflow
Allow the compiler to assume strict signed overflow rules, depending
on the language being compiled. For C (and C++) this means that
overflow when doing arithmetic with signed numbers is undefined,
which means that the compiler may assume that it will not happen.
This permits various optimizations. For example, the compiler will
assume that an expression like i + 10 > i will always be true for
signed i. This assumption is only valid if signed overflow is
undefined, as the expression is false if i + 10 overflows when using
twos complement arithmetic. When this option is in effect any
attempt to determine whether an operation on signed numbers will
overflow must be written carefully to not actually involve overflow.
See also the -fwrapv option. Using -fwrapv means that signed
overflow is fully defined: it wraps. When -fwrapv is used, there is
no difference between -fstrict-overflow and -fno-strict-overflow.
With -fwrapv certain types of overflow are permitted. For example,
if the compiler gets an overflow when doing arithmetic on constants,
the overflowed value can still be used with -fwrapv, but not
otherwise.
The -fstrict-overflow option is enabled at levels -O2, -O3, -Os.
-fwrapv
This option instructs the compiler to assume that signed arithmetic
overflow of addition, subtraction and multiplication wraps around
using twos-complement representation. This flag enables some
optimizations and disables others. This option is enabled by default
for the Java front-end, as required by the Java language
specification.
(From the GCC 4.2.2 manual.)
A correct fix would be to check for the size of off_t in some other (and
defined) manner, but I don't know off_t well enough to suggest one.
Considering that the size of off_t won't change at runtime, the test
ought to be compile (or configure) time. Reading POSIX, there seem to
be some rather cumbersome sysconf stuff one could test for, and of
course CHAR_BIT * sizeof(off_t) also tells one something. GNU autoconf
might also have a solution at hand.
--
Antti-Juhani Kaijanaho, Jyväskylä, Finland
^ permalink raw reply
* Re: [PATCH 6/7] include $PATH in generating list of commands for "help -a"
From: Junio C Hamano @ 2007-10-28 11:32 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1193570329-11656-1-git-send-email-srp@srparish.net>
Scott R Parish <srp@srparish.net> writes:
> + while (1) {
> + if ((colon = strchr(path, ':')))
> + *colon = 0;
> +
> + len = list_commands_in_dir(&other_cmds, path);
> + longest = MAX(longest, len);
Where do we borrow this MAX() macro?
On Linux with glibc, /usr/include/sys/param.h which is included
by git-compat-util.h (meaning, for everybody) is where we find
it, but that somehow does not sound portable assumption.
^ permalink raw reply
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-28 12:44 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20071028111443.GA29183@xp.machine.xx>
On 10/28/07, Peter Baumann <waste.manager@gmx.de> wrote:
> Have a look at the subtree merge strategy [1] and at the following
> explanations how git-gui got initally merged.
>
> -Peter
>
> [1]: http://www.gelato.unsw.edu.au/archives/git/0702/40139.html
> [2]: http://www.gelato.unsw.edu.au/archives/git/0702/39661.html
>
3x. I have seen that subtree stategy is introduced in commit 68fa.
However, I don't find any description in manual of git-merge. Should
this be added to this manual or any other document?
--
franky
^ permalink raw reply
* [PATCH] gitweb : disambiguate heads and tags withs the same name
From: Guillaume Seguin @ 2007-10-28 13:12 UTC (permalink / raw)
To: pasky; +Cc: git
Avoid wrong disambiguation that would link logs/trees of tags and heads which
share the same name to the same page, leading to a disambiguation that would
prefer the tag, thus making it impossible to access the corresponding
head log and
tree without hacking the url by hand.
---
gitweb/gitweb.perl | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 48e21da..f918c00 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3534,6 +3534,7 @@ sub git_tags_body {
for (my $i = $from; $i <= $to; $i++) {
my $entry = $taglist->[$i];
my %tag = %$entry;
+ my $name = "refs/tags/$tag{'name'}";
my $comment = $tag{'subject'};
my $comment_short;
if (defined $comment) {
@@ -3570,8 +3571,8 @@ sub git_tags_body {
"<td class=\"link\">" . " | " .
$cgi->a({-href => href(action=>$tag{'reftype'},
hash=>$tag{'refid'})}, $tag{'reftype'});
if ($tag{'reftype'} eq "commit") {
- print " | " . $cgi->a({-href => href(action=>"shortlog",
hash=>$tag{'name'})}, "shortlog") .
- " | " . $cgi->a({-href => href(action=>"log",
hash=>$tag{'name'})}, "log");
+ print " | " . $cgi->a({-href => href(action=>"shortlog",
hash=>$name)}, "shortlog") .
+ " | " . $cgi->a({-href => href(action=>"log", hash=>$name)}, "log");
} elsif ($tag{'reftype'} eq "blob") {
print " | " . $cgi->a({-href => href(action=>"blob_plain",
hash=>$tag{'refid'})}, "raw");
}
@@ -3597,6 +3598,7 @@ sub git_heads_body {
for (my $i = $from; $i <= $to; $i++) {
my $entry = $headlist->[$i];
my %ref = %$entry;
+ my $name = "refs/heads/$ref{'name'}";
my $curr = $ref{'id'} eq $head;
if ($alternate) {
print "<tr class=\"dark\">\n";
@@ -3606,13 +3608,13 @@ sub git_heads_body {
$alternate ^= 1;
print "<td><i>$ref{'age'}</i></td>\n" .
($curr ? "<td class=\"current_head\">" : "<td>") .
- $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'name'}),
+ $cgi->a({-href => href(action=>"shortlog", hash=>$name),
-class => "list name"},esc_html($ref{'name'})) .
"</td>\n" .
"<td class=\"link\">" .
- $cgi->a({-href => href(action=>"shortlog",
hash=>$ref{'name'})}, "shortlog") . " | " .
- $cgi->a({-href => href(action=>"log", hash=>$ref{'name'})},
"log") . " | " .
- $cgi->a({-href => href(action=>"tree", hash=>$ref{'name'},
hash_base=>$ref{'name'})}, "tree") .
+ $cgi->a({-href => href(action=>"shortlog", hash=>$name)},
"shortlog") . " | " .
+ $cgi->a({-href => href(action=>"log", hash=>$name)}, "log") . " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$name,
hash_base=>$name)}, "tree") .
"</td>\n" .
"</tr>";
}
--
1.5.3.4.395.g85b0
^ permalink raw reply related
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Steffen Prohaska @ 2007-10-28 13:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710271748440.7345@iabervon.org>
On Oct 27, 2007, at 11:53 PM, Daniel Barkalow wrote:
> On Sat, 27 Oct 2007, Steffen Prohaska wrote:
>
>> "git rev-parse --symbolic" used to return the ref name as it was
>> specified on the command line. This is changed to returning the
>> full matched ref name, i.e. "git rev-parse --symbolic master"
>> now typically returns "refs/heads/master".
>>
>> Note, this changes output of an established command. It might
>> break existing setups. I checked that it does not break scripts
>> in git.git.
>
> I think this makes the --create option to push unnecessary, as
> interactive
> users could use a suggested explicit value (or whatever they actually
> meant), while scripts could replace $name with $(git rev-parse --
> symbolic
> $name) as easily as they could add --create, and by more explicit
> as to
> what they're doing.
I'll remove 4/8 (git rev-parse --symbolic) from the patch
series. It is not directly related to the push behaviour
and Junio pointed out that the old behavior of git rev-parse
must be maintained as is. I'm not particularly interested in
modifying git rev-parse. If someone else is, feel free to take
over my patch.
I'll keep the '--create' flag. Its intention is obvious and easy
to explain to users. Much easier than
"git rev-parse --dwim_ref ..." or something similar.
Steffen
^ permalink raw reply
* Re: [PATCH 6/7] include $PATH in generating list of commands for "help -a"
From: Scott Parish @ 2007-10-28 14:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5p7v5j7.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 28, 2007 at 04:32:12AM -0700, Junio C Hamano wrote:
> Scott R Parish <srp@srparish.net> writes:
>
> > + while (1) {
> > + if ((colon = strchr(path, ':')))
> > + *colon = 0;
> > +
> > + len = list_commands_in_dir(&other_cmds, path);
> > + longest = MAX(longest, len);
>
> Where do we borrow this MAX() macro?
>
> On Linux with glibc, /usr/include/sys/param.h which is included
> by git-compat-util.h (meaning, for everybody) is where we find
> it, but that somehow does not sound portable assumption.
Awesome catch
sRp
--
Scott Parish
http://srparish.net/
^ 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