* Re: git-bisect is magical
From: Linus Torvalds @ 2006-01-11 2:58 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dq1o88$1bm$1@sea.gmane.org>
On Tue, 10 Jan 2006, walt wrote:
>
> Linus Torvalds wrote:
> [...]
> > So when you say "git checkout origin", it actually _switches_ to the
> > origin branch (which is just my state) and checks that out.
>
> I think we are finally homing in on the very roots of my ignorance!
>
> When you use the word 'switches' my eyes go glassy, just like when
> my wife starts telling me everything I've done wrong today...
Ahhah.
> Please --> what am I switching *from* when I switch to 'origin'?
> (Think: this guy is a total dumbshit! How can I possibly dumb-
> down this basic knowledge any dumber?)
Ok, this clearly isn't described well enough in any docs, so let me try,
and hopefully somebody (hint hint) will go "Ahh, I wish that had been
described in xyz - here's a patch to do so".
Anyway, the notion of multiple "branches" aka "heads of development" is
pretty ingrained in git. It's really how _everything_ subtle gets done
(merging, you name it - sometimes the branch may be a temporary unnamed
head that is just inside a script, but the _concept_ is always there).
There's one _special_ branch, which is the "active" one. The only git
trees without an active branch are the so-called "bare" git trees, which
are the .git directory contents directly, without any checked-out state.
Those are only used for distribution - no development can ever happen in
them, because they simply don't have any active branch to do development
_in_.
But for any normal git repository, you'll have one active branch, which is
the one that your working directory actually represents. It's also the one
we call "HEAD", since the HEAD thing is the thing that points to the
active branch.
Your HEAD can point to _any_ branch, but the default one is called
"master". That's the branch you get when you clone another repository, or
when you just start a new git repository from scratch with "git-init-db".
But you can "switch" between branches at any time by just doing a simple
"git checkout <branchname>". That will conceptually totally blow away your
working directory contents (well, all of it that git knows about, anyway),
and replace them with the contents that the _other_ branch contains. Now,
I say "conceptually", because in practice this is heavily optimized, so
that any files that don't change aren't actually re-written, so you can
switch between two branches that are similar quite cheaply.
So when you did "git checkout origin", you basically blew away all the
development you had done in the default "master" branch, and switched to
_another_ branch. The "origin" branch is the one that is generated for you
automatically when you clone a repository from somewhere else: it
initially contains the state of that other repository at the time of the
clone, and a "git pull origin" will actually both "fetch" that branch (so
that the "origin" branch is kept up-to-date with the original source)
_and_ merge that branch into your HEAD (normally "master").
> I know this is really bone-head-basic-stuff, but I'm quite sure
> that this lies at the heart of my confusion.
>
> When I finally understand this kindergarten material I can graduate
> to first grade :o)
Well, at least _some_ of this is described in Documentation/git-pull.txt
and Documentation/tutorial.txt. So if you haven't looked into those
before, try them now. And if you have, they clearly need more effort.
I'm really bad at documentation. I'm more than happy trying to answer
emailed questions (at least if I get the feeling that the person asking
the questions is really trying to learn, which you've done admirably), but
that doesn't mean that I'm good at writing the docs. So I'm hoping that
some of this can find itself into a FAQ or one of the existing docs,
thanks to somebody else editing it..
Linus
^ permalink raw reply
* Re: git-bisect is magical
From: Junio C Hamano @ 2006-01-11 2:47 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dq1o88$1bm$1@sea.gmane.org>
walt <wa1ter@myrealbox.com> writes:
> Linus Torvalds wrote:
> [...]
>> So when you say "git checkout origin", it actually _switches_ to the
>> origin branch (which is just my state) and checks that out.
>
> Please --> what am I switching *from* when I switch to 'origin'?
Short version: if you have only two branches "master" and
"origin", then obviously there is only one "the other one" ;-).
Longer version:
At the very beginning, you started your repository like this:
$ git clone git://git.kernel.org/some/where mine
$ cd mine
You can say:
$ git branch
And you would see:
$ git branch
* master
origin
So you have two branches, and you are on "master" right now.
Your working tree files are associated with one branch at any
moment, and "git branch" shows you which branch you are on.
That branch is "the current branch". When you make your
commits, you will commit into that branch. The commit-producing
commands include "git commit", "git am", "git pull", "git
merge", "git revert" and "git cherry-pick". They all create a
new commit on your "current branch". The difference among them
is where the commit you create takes the modifications from
(commit from the index file and the working tree, am from a
mailbox, pull and merge from a different branch, and revert and
cherry-pick from an existing commit).
You usually work in your "master" branch. But you do not have
to. Suppose you are working on maintaining some product, and
you have a couple of trivial bugfixes you can make and one
rather involved enhancement. What you could do is to have more
than one branches, and use "master" for what are ready to be
consumed by other people, and another branch for your
developments.
Your repository at one point might look like this:
$ git show-branch
* [master] trivial fix #2
! [devel] work in progress #3
--
+ [devel] work in progress #3
+ [devel^] work in progress #2
+ [devel~2] work in progress #1
+ [master] trivial fix #2
+ [master^] trivial fix #1
++ [master~2] released frotz gadget
You are on the "master" branch, and committed two trivial fixes
on top of it since your last release. But in the meantime you
found time to do independent enhancements, not yet finished but
slowly progressing. You hope to be able to complete the
development and include that in the master branch eventually,
but not yet.
How you would end up to something like above would go like this:
1. You have just released frotz gadget. Your "master" branch
is at that commit, and you do not have the "devel" branch
yet.
2. You are inspired by somebody to enhance frotz in a novel
way. You start hacking and accumulate some changes in the
working tree files, but now you realize it will be a bigger
task than you initially thought. In the meantime, you got a
couple of bug reports and you think you know how to fix them
trivially. But unfortunately, your working tree files are
currently in a great mess. Then:
$ git checkout -b devel
This creates a new branch ("devel") based on the current
branch head (remember, you were on "master" branch), and
switches to that new branch. It is a short-hand for the two
command sequence:
$ git branch devel
$ git checkout devel
This takes your working tree changes with you, so at this
point if you do "git diff", you will see your changes. You
commit this mess (do not worry about "presentable history"
yet; you will be cleaning up the mess later anyway before
you merge).
$ git add new-files-you-created
$ git commit -a -m 'work in progress #1'
3. Now you can switch mood and can work on the trivial fixes.
Go back to the "master" branch:
$ git checkout master
you'll notice that all the mess you made while working on
devel has been cleaned up --- WIP edits are gone, and if you
made new files for "devel" they are gone too. You start
from the state immediately after release, and work on fixes,
and commit:
$ edit for trivial fix number 1
$ git commit -a -m 'trivial fix #1'
$ edit for trivial fix number 2
$ git commit -a -m 'trivial fix #2'
4. Now fixes are out of your way, you can go back to work on
the enhancements. The same thing as step 3.
$ git checkout devel
$ edit / test / commit
Eventually what you do in your devel branch comes to maturity
and ready for public consumption. How would you make sure when?
For that, you would create a throw-away test branch and try
things out:
$ git branch -f test master
$ git checkout test
$ git merge 'development trial' test devel
This would create something like this:
$ git show-branch
! [master] trivial fix #2
! [devel] work in progress #3
* [test] development trial
---
+ [test] development trial
++ [devel] work in progress #3
++ [devel^] work in progress #2
++ [devel~2] work in progress #1
+ + [master] trivial fix #2
+ + [master^] trivial fix #1
+++ [master~2] released frotz gadget
You merged "devel" and "master" in "test" branch, so that you
can test your development along with the other fixes you had in
the "master" branch since your "devel" branch forked. Try
things out and if you find the result satisfactory, then you
know what you have in "devel" is good for public consumption.
There are three ways to bring the "devel" into "master" at this
moment. It depends on how much you care about clean history.
A) just merge.
$ git checkout master
$ git pull . devel
This is the simplest, but you would see all the real history
in "devel" branch, things like "work in progress #n" commit
log messages.
B) refactor and linearize.
$ git format-patch -k -m -o ./+redo master..devel
This leaves a patchfile per commit in devel branch in +redo/
directory. You can edit the commit log message and patch
just as if you are preparing them for e-mail submission to
another project maintainer. Once you are done editing:
$ git checkout master
$ git am -k -3 ./+redo/0*.txt
to apply them on top of the master branch.
C) linearize without refactoring.
$ git checkout devel
$ git rebase master
$ git checkout master
$ git pull . devel
This "rebases" the development branch (the first two steps),
and then pulls the result into the "master" branch (the
rest). It should give you the same result as approach B) if
you do not edit your +redo/ files at all.
Once you are done, you can clean up by
$ git branch -D test devel
^ permalink raw reply
* [PATCH] Exec git programs without using PATH.
From: Michal Ostrowski @ 2006-01-11 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vd5iz4mt7.fsf@assigned-by-dhcp.cox.net>
The git suite may not be in PATH (and thus programs such as
git-send-pack could not exec git-rev-list). Thus there is a need for
logic that will locate these programs. Modifying PATH is not
desirable as it result in behavior differing from the user's
intentions, as we may end up prepending "/usr/bin" to PATH.
- git C programs will use exec*_git_cmd() APIs to exec sub-commands.
- exec*_git_cmd() will execute a git program by searching for it in
the following directories:
1. --exec-path (as used by "git")
2. The GIT_EXEC_PATH environment variable.
3. $(gitexecdir) as set in Makefile (default value $(bindir)).
- git potty will modify PATH as before to enable shell scripts to
invoke "git-foo" commands.
Ideally, shell scripts should use the git potty to become independent of
PATH, and then modifying PATH will not be necessary.
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
Makefile | 21 ++++++++--
daemon.c | 3 +
exec_cmd.c | 118
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
exec_cmd.h | 10 +++++
fetch-clone.c | 7 +--
git.c | 54 ++++++--------------------
receive-pack.c | 2 -
run-command.c | 9 +++-
run-command.h | 2 -
send-pack.c | 8 ++--
shell.c | 2 -
upload-pack.c | 7 ++-
12 files changed, 181 insertions(+), 62 deletions(-)
create mode 100644 exec_cmd.c
create mode 100644 exec_cmd.h
d6dbbb5b9b47c37f44c3494962b9fa534677729f
diff --git a/Makefile b/Makefile
index c9c15b5..912c223 100644
--- a/Makefile
+++ b/Makefile
@@ -68,6 +68,7 @@ ALL_LDFLAGS = $(LDFLAGS)
prefix = $(HOME)
bindir = $(prefix)/bin
+gitexecdir = $(prefix)/bin
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
@@ -141,7 +142,7 @@ PROGRAMS = \
git-describe$X
# what 'all' will build and 'install' will install.
-ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
+ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@@ -173,7 +174,7 @@ DIFF_OBJS = \
LIB_OBJS = \
blob.o commit.o connect.o count-delta.o csum-file.o \
- date.o diff-delta.o entry.o ident.o index.o \
+ date.o diff-delta.o entry.o exec_cmd.o ident.o index.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
@@ -184,6 +185,16 @@ LIB_OBJS = \
LIBS = $(LIB_FILE)
LIBS += -lz
+
+# .exec_cmd.gitexecdir stores $(gitexecir) used to compile exec_cmd.o
+# If it has changed, store the new value and force exec_cmd.o to be
rebuilt
+ifneq ($(shell cat .exec_cmd.gitexecdir 2>/dev/null),$(gitexecdir))
+.PHONY: exec_cmd.c
+$(shell echo $(gitexecdir) > .exec_cmd.gitexecdir)
+endif
+
+exec_cmd.o: CFLAGS+=-DGIT_EXEC_PATH=\"$(gitexecdir)\"
+
# Shell quote;
# Result of this needs to be placed inside ''
shq = $(subst ','\'',$(1))
@@ -366,13 +377,13 @@ LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(ALL_PROGRAMS)
+all: $(ALL_PROGRAMS) git$X
all:
$(MAKE) -C templates
git$X: git.c $(LIB_FILE)
- $(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
+ $(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -468,7 +479,9 @@ check:
install: all
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitexecdir))
$(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) git$X $(call shellquote,$(DESTDIR)$(gitexecdir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
diff --git a/daemon.c b/daemon.c
index 3bd1426..bb014fa 100644
--- a/daemon.c
+++ b/daemon.c
@@ -9,6 +9,7 @@
#include <syslog.h>
#include "pkt-line.h"
#include "cache.h"
+#include "exec_cmd.h"
static int log_syslog;
static int verbose;
@@ -227,7 +228,7 @@ static int upload(char *dir)
snprintf(timeout_buf, sizeof timeout_buf, "--timeout=%u", timeout);
/* git-upload-pack only ever reads stuff, so this is safe */
- execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf,
".", NULL);
+ execl_git_cmd("upload-pack", "--strict", timeout_buf, ".", NULL);
return -1;
}
diff --git a/exec_cmd.c b/exec_cmd.c
new file mode 100644
index 0000000..a3bd40a
--- /dev/null
+++ b/exec_cmd.c
@@ -0,0 +1,118 @@
+#include "cache.h"
+#include "exec_cmd.h"
+#define MAX_ARGS 32
+
+extern char **environ;
+static const char *builtin_exec_path = GIT_EXEC_PATH;
+static const char *current_exec_path = NULL;
+
+void git_set_exec_path(const char *exec_path)
+{
+ current_exec_path = exec_path;
+}
+
+
+/* Returns the highest-priority, location to look for git programs. */
+const char *git_exec_path()
+{
+ const char *env;
+
+ if (current_exec_path)
+ return current_exec_path;
+
+ env = getenv("GIT_EXEC_PATH");
+ if (env) {
+ return env;
+ }
+
+ return builtin_exec_path;
+}
+
+
+int execv_git_cmd(char **argv)
+{
+ char git_command[PATH_MAX + 1];
+ char *tmp;
+ int len, err, i;
+ const char *paths[] = { current_exec_path,
+ getenv("GIT_EXEC_PATH"),
+ builtin_exec_path,
+ NULL };
+
+ for (i = 0; i < 4; ++i) {
+ const char *exec_dir = paths[i];
+ if (!exec_dir) continue;
+
+ if (*exec_dir != '/') {
+ if (!getcwd(git_command, sizeof(git_command))) {
+ fprintf(stderr, "git: cannot determine "
+ "current directory\n");
+ exit(1);
+ }
+ len = strlen(git_command);
+
+ /* Trivial cleanup */
+ while (!strncmp(exec_dir, "./", 2)) {
+ exec_dir += 2;
+ while (*exec_dir == '/')
+ exec_dir++;
+ }
+ snprintf(git_command + len, sizeof(git_command) - len,
+ "/%s", exec_dir);
+ } else {
+ strcpy(git_command, exec_dir);
+ }
+
+ len = strlen(git_command);
+ len += snprintf(git_command + len, sizeof(git_command) - len,
+ "/git-%s", argv[0]);
+
+ if (sizeof(git_command) <= len) {
+ fprintf(stderr,
+ "git: command name given is too long.\n");
+ break;
+ }
+
+ /* 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] = git_command;
+
+ /* execve() can only ever return if it fails */
+ execve(git_command, argv, environ);
+
+ err = errno;
+
+ argv[0] = tmp;
+ }
+ return -1;
+
+}
+
+
+int execl_git_cmd(char *cmd,...)
+{
+ int argc;
+ char *argv[MAX_ARGS + 1];
+ char *arg;
+ va_list param;
+
+ va_start(param, cmd);
+ argv[0] = cmd;
+ argc = 1;
+ while (argc < MAX_ARGS) {
+ arg = argv[argc++] = va_arg(param, char *);
+ if (!arg)
+ break;
+ }
+ va_end(param);
+ if (MAX_ARGS <= argc)
+ return error("too many args to run %s", cmd);
+
+ argv[argc] = NULL;
+ return execv_git_cmd(argv);
+}
diff --git a/exec_cmd.h b/exec_cmd.h
new file mode 100644
index 0000000..06d5ec3
--- /dev/null
+++ b/exec_cmd.h
@@ -0,0 +1,10 @@
+#ifndef __GIT_EXEC_CMD_H_
+#define __GIT_EXEC_CMD_H_
+
+extern void git_set_exec_path(const char *exec_path);
+extern const char* git_exec_path();
+extern int execv_git_cmd(char **argv); /* NULL terminated */
+extern int execl_git_cmd(char *cmd, ...);
+
+
+#endif /* __GIT_EXEC_CMD_H_ */
diff --git a/fetch-clone.c b/fetch-clone.c
index f46fe6e..859f400 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "exec_cmd.h"
#include <sys/wait.h>
static int finish_pack(const char *pack_tmp_name, const char *me)
@@ -27,8 +28,7 @@ static int finish_pack(const char *pack_
dup2(pipe_fd[1], 1);
close(pipe_fd[0]);
close(pipe_fd[1]);
- execlp("git-index-pack","git-index-pack",
- "-o", idx, pack_tmp_name, NULL);
+ execl_git_cmd("index-pack", "-o", idx, pack_tmp_name, NULL);
error("cannot exec git-index-pack <%s> <%s>",
idx, pack_tmp_name);
exit(1);
@@ -105,8 +105,7 @@ int receive_unpack_pack(int fd[2], const
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-unpack-objects", "git-unpack-objects",
- quiet ? "-q" : NULL, NULL);
+ execl_git_cmd("unpack-objects", quiet ? "-q" : NULL, NULL);
die("git-unpack-objects exec failed");
}
close(fd[0]);
diff --git a/git.c b/git.c
index 5e7da74..fdd02ed 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@
#include <stdarg.h>
#include <sys/ioctl.h>
#include "git-compat-util.h"
+#include "exec_cmd.h"
#ifndef PATH_MAX
# define PATH_MAX 4096
@@ -233,14 +234,11 @@ int main(int argc, char **argv, char **e
{
char git_command[PATH_MAX + 1];
char wd[PATH_MAX + 1];
- int i, len, show_help = 0;
- char *exec_path = getenv("GIT_EXEC_PATH");
+ int i, show_help = 0;
+ char *exec_path;
getcwd(wd, PATH_MAX);
- if (!exec_path)
- exec_path = GIT_EXEC_PATH;
-
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -256,10 +254,11 @@ int main(int argc, char **argv, char **e
if (!strncmp(arg, "exec-path", 9)) {
arg += 9;
- if (*arg == '=')
+ if (*arg == '=') {
exec_path = arg + 1;
- else {
- puts(exec_path);
+ git_set_exec_path(exec_path);
+ } else {
+ puts(git_exec_path());
exit(0);
}
}
@@ -275,48 +274,21 @@ int main(int argc, char **argv, char **e
if (i >= argc || show_help) {
if (i >= argc)
- cmd_usage(exec_path, NULL);
+ cmd_usage(git_exec_path(), NULL);
show_man_page(argv[i]);
}
- if (*exec_path != '/') {
- if (!getcwd(git_command, sizeof(git_command))) {
- fprintf(stderr,
- "git: cannot determine current directory\n");
- exit(1);
- }
- len = strlen(git_command);
+ exec_path = git_exec_path();
+ prepend_to_path(exec_path, strlen(exec_path));
- /* Trivial cleanup */
- while (!strncmp(exec_path, "./", 2)) {
- exec_path += 2;
- while (*exec_path == '/')
- exec_path++;
- }
- snprintf(git_command + len, sizeof(git_command) - len,
- "/%s", exec_path);
- }
- else
- strcpy(git_command, exec_path);
- len = strlen(git_command);
- prepend_to_path(git_command, len);
-
- len += snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[i]);
- if (sizeof(git_command) <= len) {
- fprintf(stderr, "git: command name given is too long.\n");
- exit(1);
- }
-
- /* execve() can only ever return if it fails */
- execve(git_command, &argv[i], envp);
+ execv_git_cmd(argv + i);
if (errno == ENOENT)
- cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
+ cmd_usage(git_exec_path(), "'%s' is not a git-command",
+ argv[i]);
fprintf(stderr, "Failed to run command '%s': %s\n",
git_command, strerror(errno));
-
return 1;
}
diff --git a/receive-pack.c b/receive-pack.c
index f847ec2..8e78e32 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -257,7 +257,7 @@ static void read_head_info(void)
static const char *unpack(int *error_code)
{
- int code = run_command(unpacker, NULL);
+ int code = run_command_v_opt(1, &unpacker, RUN_GIT_CMD);
*error_code = 0;
switch (code) {
diff --git a/run-command.c b/run-command.c
index 8bf5922..b3d287e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include <sys/wait.h>
+#include "exec_cmd.h"
int run_command_v_opt(int argc, char **argv, int flags)
{
@@ -13,9 +14,13 @@ int run_command_v_opt(int argc, char **a
int fd = open("/dev/null", O_RDWR);
dup2(fd, 0);
dup2(fd, 1);
- close(fd);
+ close(fd);
+ }
+ if (flags & RUN_GIT_CMD) {
+ execv_git_cmd(argv);
+ } else {
+ execvp(argv[0], (char *const*) argv);
}
- execvp(argv[0], (char *const*) argv);
die("exec %s failed.", argv[0]);
}
for (;;) {
diff --git a/run-command.h b/run-command.h
index 2469eea..ef3ee05 100644
--- a/run-command.h
+++ b/run-command.h
@@ -12,7 +12,7 @@ enum {
};
#define RUN_COMMAND_NO_STDIO 1
-
+#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
int run_command_v_opt(int argc, char **argv, int opt);
int run_command_v(int argc, char **argv);
int run_command(const char *cmd, ...);
diff --git a/send-pack.c b/send-pack.c
index cd36193..4a420a6 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -26,11 +26,11 @@ static int is_zero_sha1(const unsigned c
static void exec_pack_objects(void)
{
static char *args[] = {
- "git-pack-objects",
+ "pack-objects",
"--stdout",
NULL
};
- execvp("git-pack-objects", args);
+ execv_git_cmd(args);
die("git-pack-objects exec failed (%s)", strerror(errno));
}
@@ -39,7 +39,7 @@ static void exec_rev_list(struct ref *re
static char *args[1000];
int i = 0;
- args[i++] = "git-rev-list"; /* 0 */
+ args[i++] = "rev-list"; /* 0 */
args[i++] = "--objects"; /* 1 */
while (refs) {
char *buf = malloc(100);
@@ -58,7 +58,7 @@ static void exec_rev_list(struct ref *re
refs = refs->next;
}
args[i] = NULL;
- execvp("git-rev-list", args);
+ execv_git_cmd(args);
die("git-rev-list exec failed (%s)", strerror(errno));
}
diff --git a/shell.c b/shell.c
index cd31618..0d4891f 100644
--- a/shell.c
+++ b/shell.c
@@ -12,7 +12,7 @@ static int do_generic_cmd(const char *me
my_argv[1] = arg;
my_argv[2] = NULL;
- return execvp(me, (char**) my_argv);
+ return execv_git_cmd((char**) my_argv);
}
static struct commands {
diff --git a/upload-pack.c b/upload-pack.c
index 1834b6b..d198055 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -4,6 +4,7 @@
#include "tag.h"
#include "object.h"
#include "commit.h"
+#include "exec_cmd.h"
static const char upload_pack_usage[] = "git-upload-pack [--strict]
[--timeout=nn] <dir>";
@@ -60,7 +61,7 @@ static void create_pack_file(void)
close(0);
close(fd[0]);
close(fd[1]);
- *p++ = "git-rev-list";
+ *p++ = "rev-list";
*p++ = "--objects";
if (create_full_pack || MAX_NEEDS <= nr_needs)
*p++ = "--all";
@@ -79,13 +80,13 @@ static void create_pack_file(void)
buf += 41;
}
*p++ = NULL;
- execvp("git-rev-list", argv);
+ execv_git_cmd(argv);
die("git-upload-pack: unable to exec git-rev-list");
}
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-pack-objects", "git-pack-objects", "--stdout", NULL);
+ execl_git_cmd("pack-objects", "--stdout", NULL);
die("git-upload-pack: unable to exec git-pack-objects");
}
--
0.99.9m-g5a22
^ permalink raw reply related
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Michal Ostrowski @ 2006-01-11 2:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vd5iz4mt7.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-01-10 at 16:42 -0800, Junio C Hamano wrote:
> Michal Ostrowski <mostrows@watson.ibm.com> writes:
>
> > How about searching for executables in the following places, and in this
> > order:
> >
> > 1. --exec-path setting, if any
> > 2. GIT_EXEC_PATH env var, if set
> > 3. PATH (never modified)
> > 4. Value of ${bindir} at build time
>
> and then make the rule for git things:
>
> 1. --exec-path
> 2. GIT_EXEC_PATH environment
> 3. $(gitexecdir)
>
> in this order. Non git things should just use $PATH without
> looking at anything else --- as long as a hook script calls a git
> wrapper (i.e. "git foo" not "git-foo") I think things should
> work fine.
>
The patch that follows implements your suggested search order and
includes suggested Makefile changes.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* git-local-fetch and objects/info/alternates.
From: Tom Prince @ 2006-01-11 1:53 UTC (permalink / raw)
To: git
Is there some way to make git-local-fetch not try to copy files if the
source repository is in the destinations objects/info/alternates?
^ permalink raw reply
* Re: git-bisect is magical
From: walt @ 2006-01-11 1:50 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601101308540.4939@g5.osdl.org>
Linus Torvalds wrote:
[...]
> So when you say "git checkout origin", it actually _switches_ to the
> origin branch (which is just my state) and checks that out.
I think we are finally homing in on the very roots of my ignorance!
When you use the word 'switches' my eyes go glassy, just like when
my wife starts telling me everything I've done wrong today...
Please --> what am I switching *from* when I switch to 'origin'?
(Think: this guy is a total dumbshit! How can I possibly dumb-
down this basic knowledge any dumber?)
I know this is really bone-head-basic-stuff, but I'm quite sure
that this lies at the heart of my confusion.
When I finally understand this kindergarten material I can graduate
to first grade :o)
Thanks for your patience!
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Junio C Hamano @ 2006-01-11 0:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43C44CF2.5050808@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Johannes Schindelin wrote:
>> Wouldn't it make much more sense to have a switch in the Makefile,
>> which says *if* we have a libexec/ directory?
>
> No, it wouldn't, because then we can't use a different release of the
> git-tools without re-compiling the potty.
True, but *please* stop calling "git wrapper" a potty. It gives
me an impression that it is not connected to the plumbing.
I do not do Porcelain, but I do not do plastics nor glass either
;-).
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Junio C Hamano @ 2006-01-11 0:42 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Andreas Ericsson, git
In-Reply-To: <1136924980.11717.603.camel@brick.watson.ibm.com>
Michal Ostrowski <mostrows@watson.ibm.com> writes:
> How about searching for executables in the following places, and in this
> order:
>
> 1. --exec-path setting, if any
> 2. GIT_EXEC_PATH env var, if set
> 3. PATH (never modified)
> 4. Value of ${bindir} at build time
My preference is to first do this to the Makefile:
-- >8 --
diff --git a/Makefile b/Makefile
index 5817e86..b1e3055 100644
--- a/Makefile
+++ b/Makefile
@@ -71,6 +71,7 @@ ALL_LDFLAGS = $(LDFLAGS)
prefix = $(HOME)
bindir = $(prefix)/bin
+gitexecdir = $(prefix)/bin
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
@@ -144,7 +145,7 @@ PROGRAMS = \
git-describe$X
# what 'all' will build and 'install' will install.
-ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
+ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@@ -368,13 +369,13 @@ LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(ALL_PROGRAMS)
+all: $(ALL_PROGRAMS) git$X
all:
$(MAKE) -C templates
git$X: git.c $(LIB_FILE)
- $(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
+ $(CC) -DGIT_EXEC_PATH='"$(gitexecdir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
$(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -470,7 +471,9 @@ check:
install: all
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitexecdir))
+ $(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(gitexecdir))
+ $(INSTALL) git$X $(call shellquote,$(DESTDIR)$(bindir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
-- 8< --
and then make the rule for git things:
1. --exec-path
2. GIT_EXEC_PATH environment
3. $(gitexecdir)
in this order. Non git things should just use $PATH without
looking at anything else --- as long as a hook script calls a git
wrapper (i.e. "git foo" not "git-foo") I think things should
work fine.
> ... The patch I sent out this morning
> attempts to do this. (I'll append again to avoid confusion with
> previous patches)...
> + if (flags & RUN_GIT_CMD) {
> + execv_git_cmd(argv);
> + } else {
> + execvp(argv[0], (char *const*) argv);
> }
This bit sounds good, but if you were to go this route I'd
suggest to rename your exec_git_cmd() to execl_git_cmd() (and
terminate the vararg list with NULL) for naming consistency.
execv_git_cmd() is good---we do not *want* execvp_git_cmd(),
because we do not run git subcommand using PATH.
^ permalink raw reply related
* Re: git pull on Linux/ACPI release tree
From: Andreas Ericsson @ 2006-01-11 0:26 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90601101233h5def4840k315be9520796b5e@mail.gmail.com>
Martin Langhoff wrote:
> On 1/11/06, Adrian Bunk <bunk@stusta.de> wrote:
>
>>I am using the workaround of carrying the patches in a mail folder,
>>applying them in a batch, and not pulling from your tree between
>>applying a batch of patches and you pulling from my tree.
>
>
> In that case, there's a mostly automated way of doing that if you read
> the last couple lines of git-rebase, using something along the lines
> of
>
> git-format-patch <yours> <linus> | git-am -3 -k
>
Isn't this rebase in a nutshell ?
>
>>I'd say the main problem is that git with several other projects like
>>cogito and stg on top of it allow many different workflows. But finding
>>the one that suits one's needs without doing something in a wrong way
>>is non-trivial.
>
>
> You are right about that, but much of the space (of what workflows are
> interesting) is still being explored, and git and the porcelains
> reacting to people's interests. So it's still a moving target. A fast
> moving target.
>
Good thing there are competent people around to snipe those targets in
mid-stride. :)
I for one was amazed at how much easier git was to work with than any of
the other scm's I've tried (quite a few, I never really liked any of
them), and I really like the fact that it's flexible enough to suit
(almost) all our needs. The only thing I haven't really found it to be
satisfactory for is our collection of RPM spec-files and their
respective patches, where we not so much change files as continuously
replace them completely. Perhaps that's changed now that most
git-commands can be run from subdirs.
So, kudos to Linus for inventing it, Junio for nursing it, and the other
129 developers that have so far contributed to the current release.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Andreas Ericsson @ 2006-01-11 0:10 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0601102200040.31923@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>>>>>git programs exec other git programs, but they also exec non-git
>>>>>programs. I think it is not appropriate to change PATH (via
>>>>>prepend_to_path) because this may result in unexpected behavior when
>>>>>exec'ing non-git programs:
>>>>
>>>>This is a valid concern.
>>>
>>>Why? If what is prepended to PATH only contains git programs?
>>>
>>
>>
>>If git is installed with prefix=/usr, then that won't be the case.
>
>
> Okay, so here we have the problem: Two completely different setups. One
> into a standard location on the PATH (which used to be the default), the
> other with a libexec/ directory (which some want in the future). And a git
> wrapper which makes no difference between both.
>
> Wouldn't it make much more sense to have a switch in the Makefile, which
> says *if* we have a libexec/ directory?
No, it wouldn't, because then we can't use a different release of the
git-tools without re-compiling the potty.
void prepend_to_path(old_path, to_prep)
{
if (strstr(old_path, to_prep))
return;
really_prepend_to_path(old_path, to_prep);
}
would work just fine though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Andreas Ericsson @ 2006-01-11 0:06 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Junio C Hamano, git
In-Reply-To: <1136924980.11717.603.camel@brick.watson.ibm.com>
Michal Ostrowski wrote:
> On Tue, 2006-01-10 at 11:47 -0800, Junio C Hamano wrote:
>
>>
>>>Good point. Perhaps we should only prepend to path when the directory
>>>isn't already in $PATH, or append rather than prepend.
>>
>>I think appending not prepending would stop letting me say
>>
>> $ GIT_EXEC_PATH=/usr/libexec/git-core/0.99.9k git foo
>>
>>to try out older version, if I have more recent git in my PATH.
>>But I agree with Michal it is not nice to affect invocations of
>>"diff" (and things spawned from hooks, which would inherit PATH
>>from receive-pack).
>>
So how about prepending only when the directory isn't already in the
PATH? That can be done with a two-line patch to git.c only.
It will break the "diff in another dir" scenario in the highly unlikely
event that the other diff is located in the same dir as the git suite,
isn't supposed to be used, and the directory in question isn't in $PATH
already. People who have such a setup will be too ashamed to admit it,
so we're not likely to be blamed for it either. ;)
>>
>
>
> How about searching for executables in the following places, and in this
> order:
>
> 1. --exec-path setting, if any
> 2. GIT_EXEC_PATH env var, if set
> 3. PATH (never modified)
> 4. Value of ${bindir} at build time
>
This is more or less what's done today, with the exception that $PATH
isn't searched and it throws an error immediately no matter where
exec_path (the git.c variable) came from.
Adding $PATH to the search-pattern would be a simple matter of falling
back to execvp() if execve(), but then we could end up with running
programs from a different release while the user thinks he/she's
specifically running 1.0.3... Tricky problem, really.
>
> Secondly, the shell scripts as is cannot utilize this search order as
> long as they don't religiously use the git potty internally. If we were
> to "sed -e 's/git-/git /g' -i git*.sh" (grotesquely simplified of
> course) then they would.
>
I think this has been done, but as it happened to be convenient. I'd
prefer if the git potty could keep prepending the GIT_EXEC_PATH to the
path, really. We're bound to run into setup-related problems otherwise,
such as;
Alice writes a script that works fine for her and her friends, so she
shares it freely with Bob and whoever else might be listening. Bob's
git-tools aren't in the $PATH but he keeps the potty handy at all times.
He can't always run it through the potty because in some code-paths
Alice's script uses git-tools without going through the potty. Bob
thinks Alice puts entropy in her programs on purpose, so Alice flees,
sobbing and shaking in anger and betrayed trust. The two never speak again.
Luckily, Bruce Schneier shows up and saves the day.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] glossary: explain "master" and "origin"
From: walt @ 2006-01-10 23:33 UTC (permalink / raw)
To: git
In-Reply-To: <dq1cdd$rob$1@sea.gmane.org>
walt wrote:
> J. Bruce Fields wrote:
> [...]
>> Most projects have one upstream
>> project which they track. This is is the branch used for
>> tracking that project...
>
> s/This/'origin'/
>
> Lordy, I think many of the world's problems could be solved just
> by forbidding the use of pronouns entirely!
Now that I've had another beer, it occurs to me that a 'pronoun'
is nothing more or less than a 'pointer' to a noun.
Well! We all know that pointers are a major source of bugs in
C code. Is it possible that lint could be taught to detect
ambiguous pronouns in everyday speech?
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Alex Riesen @ 2006-01-10 22:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <86sls0498w.fsf@blue.stonehenge.com>
Randal L. Schwartz, Sat, Jan 07, 2006 11:34:23 +0100:
> >> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> So I'd prefer not touching for (@df) { print H "$_\n" } loops.
> >>
> >> Being as I'm a *bit* familiar with Perl, I'd write that as:
> >>
> >> print H "$_\0" for @deletedfiles;
> >>
>
> Alex> Does not work for old Perl
>
> Correct. It was added for Perl 5.5, first released on 22 July 1998.
>
> Are you really saying you need this code to run on Perl 5.4?
No, probably not. I definitely don't care, just wanted to point it
out as another one kind of a strange setup (as if activestat perl +
cygwin isn't enough...)
^ permalink raw reply
* Re: [PATCH] glossary: explain "master" and "origin"
From: walt @ 2006-01-10 22:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060110213645.GF13450@fieldses.org>
J. Bruce Fields wrote:
[...]
> Most projects have one upstream
> project which they track. This is is the branch used for
> tracking that project...
s/This/'origin'/
Lordy, I think many of the world's problems could be solved just
by forbidding the use of pronouns entirely!
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Alex Riesen @ 2006-01-10 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6dcl49x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sat, Jan 07, 2006 11:29:46 +0100:
> >>
> >> print H "$_\0" for @deletedfiles;
> >
> > Does not work for old Perl
>
> How old may I ask?
>
5.4, probably. I never seen it anymore. Was a standard installation of
some Solaris box.
^ permalink raw reply
* Re: [PATCH] stgit: typo fixes
From: Catalin Marinas @ 2006-01-10 21:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1136913240.2444.1.camel@dv>
On 10/01/06, Pavel Roskin <proski@gnu.org> wrote:
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Applied, thanks.
> - # if modes are the same (git-read-tree probably dealed with it)
> + # if modes are the same (git-read-tree probably dealt with it)
I think both are correct (at least in the UK).
--
Catalin
^ permalink raw reply
* Re: [PATCH] glossary: explain "master" and "origin"
From: Johannes Schindelin @ 2006-01-10 21:40 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, junkio
In-Reply-To: <20060110213645.GF13450@fieldses.org>
Hi,
On Tue, 10 Jan 2006, J. Bruce Fields wrote:
> On Tue, Jan 10, 2006 at 10:26:46PM +0100, Johannes Schindelin wrote:
> > +origin::
> > + The default upstream branch. Most projects have one upstream
> > + project which is tracked, and augmented with local changes which
> > + eventually get merged back. You never commit to this branch,
> > + unless you are maintaining the upstream project.
>
> The last line is somewhat confusing--a naive reader might take it to
> mean that as an upstream maintainer it would make sense to commit to a
> branch named "origin". How about something like this?
>
> "The default upstream branch. Most projects have one upstream
> project which they track. This is is the branch used for
> tracking that project. New updates from upstream will be
> fetched into this branch, but you should never commit to it
> yourself."
It is probably safer. Note: I actually commit to the origin branch in one
of my projects, and I follow it directly by a "git push origin".
Ciao,
Dscho
P.S.: I just noted that some of the tabs were turned into spaces. Does
asciidoc mind?
^ permalink raw reply
* Re: [PATCH] glossary: explain "master" and "origin"
From: J. Bruce Fields @ 2006-01-10 21:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0601102226130.649@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Jan 10, 2006 at 10:26:46PM +0100, Johannes Schindelin wrote:
> +origin::
> + The default upstream branch. Most projects have one upstream
> + project which is tracked, and augmented with local changes which
> + eventually get merged back. You never commit to this branch,
> + unless you are maintaining the upstream project.
The last line is somewhat confusing--a naive reader might take it to
mean that as an upstream maintainer it would make sense to commit to a
branch named "origin". How about something like this?
"The default upstream branch. Most projects have one upstream
project which they track. This is is the branch used for
tracking that project. New updates from upstream will be
fetched into this branch, but you should never commit to it
yourself."
--b.
^ permalink raw reply
* [PATCH] glossary: explain "master" and "origin"
From: Johannes Schindelin @ 2006-01-10 21:26 UTC (permalink / raw)
To: git, junkio
If you are a long time git user/developer, you forget that to a new git
user, these words have not the same meaning as to you.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/glossary.txt | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 2331be5..4ef7d2a 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -111,6 +111,17 @@ branch::
a particular revision, which is called the branch head. The
branch heads are stored in `$GIT_DIR/refs/heads/`.
+master::
+ The default branch. Whenever you create a git repository, a branch
+ named "master" is created, and becomes the active branch. In most
+ cases, this contains the local development.
+
+origin::
+ The default upstream branch. Most projects have one upstream
+ project which is tracked, and augmented with local changes which
+ eventually get merged back. You never commit to this branch,
+ unless you are maintaining the upstream project.
+
ref::
A 40-byte hex representation of a SHA1 pointing to a particular
object. These may be stored in `$GIT_DIR/refs/`.
^ permalink raw reply related
* Re: git-bisect is magical
From: Linus Torvalds @ 2006-01-10 21:17 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dq168p$3kt$1@sea.gmane.org>
On Tue, 10 Jan 2006, walt wrote:
>
> Just by stumbling around and trying things at random, I did a
> 'git-checkout origin' which *seemed* to resolve the merge-conflict,
> but left me feeling uneasy because I don't really understand what
> I'm doing. Can you give a short explanation of the difference
> between 'git reset --hard origin' and 'git-checkout origin'?
"git checkout" actually checks out a different branch (unless, to confuse
things, you ask it to just check out a specific _file_, in which case it
stays on the same branch).
So when you say "git checkout origin", it actually _switches_ to the
origin branch (which is just my state) and checks that out.
When you then do a "git pull", you'll just be pulling my newer state into
that older content branch, and it will resolve beautifully as a
fast-forward with no merge at all.
The downside with being in the "origin" branch is that if you now do any
kind of real development, you've now made "origin" mean something else
than it traditionally means - now it's no longer a branch tracking the
origin of your code, now it's an active development branch.
Do "git checkout master" to go back to where you used to be.
In contrast, a "git reset --hard origin" would have reset your _current_
branch to the state that the "origin" branch was in (and forced a checkout
of that exact state too - that's what the "--hard" flag means).
So when you say "git checkout origin", you should read it as "check out
the origin branch", and thus it makes perfect sense that "origin" now
becomes your current branch. In contrast, when you say "git reset --hard
origin", you should mentally read that as "reset the state of my current
tree to the same state as the origin branch".
The naming does make sense, but you just have to get used to what
"checkout" means (in its two different guises - checking out a file being
different from checking out a full tree) and what "reset" means.
> > An even better option is obviously to figure out _why_ that commit broke
> > for you in the first place, and get it fixed up-stream...
>
> I'm still waiting for the insulting email from the developer ;o) How
> long should I wait for a response before I start bugging other people?
Hey, send out the report to linux-kernel, and if it is a serious problem,
just cc me and Andrew (and whoever else seems to be most relevant for the
area: networking goes to David Miller, drivers mostly to Greg or Jeff etc
etc). Regardless, you should always cc at least the people who signed off
on the commit, since they want to know that they signed off on something
that turned out to be buggy.
Linus
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Junio C Hamano @ 2006-01-10 21:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michal Ostrowski, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0601102054200.27363@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Why? If what is prepended to PATH only contains git programs?
Recall the "diff" example Michal gave us.
^ permalink raw reply
* Re: [PATCH 2/2] Remember and use GIT_EXEC_PATH on exec()'s
From: Johannes Schindelin @ 2006-01-10 21:03 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <1136925066.11717.605.camel@brick.watson.ibm.com>
Hi,
On Tue, 10 Jan 2006, Michal Ostrowski wrote:
> On Tue, 2006-01-10 at 20:55 +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 10 Jan 2006, Junio C Hamano wrote:
> >
> > > Michal Ostrowski <mostrows@watson.ibm.com> writes:
> > >
> > > > git programs exec other git programs, but they also exec non-git
> > > > programs. I think it is not appropriate to change PATH (via
> > > > prepend_to_path) because this may result in unexpected behavior when
> > > > exec'ing non-git programs:
> > >
> > > This is a valid concern.
> >
> > Why? If what is prepended to PATH only contains git programs?
> >
>
>
> If git is installed with prefix=/usr, then that won't be the case.
Okay, so here we have the problem: Two completely different setups. One
into a standard location on the PATH (which used to be the default), the
other with a libexec/ directory (which some want in the future). And a git
wrapper which makes no difference between both.
Wouldn't it make much more sense to have a switch in the Makefile, which
says *if* we have a libexec/ directory? This switch would decide if we
ever prepend the path with the libexec/ directory or not.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Johannes Schindelin @ 2006-01-10 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601101151090.4939@g5.osdl.org>
Hi,
On Tue, 10 Jan 2006, Linus Torvalds wrote:
> So having multiple bad commits is _never_ interesting.
Okay, I got it. A bug is supposed to be inherited by *all* its
descendants. Good.
I have to keep in mind that a commit is not actually a patch set, but can
be two or more (in case of a merge). So, a bug can be present in a
development line for a long, long time, but be visible only after a merge.
Since that commit can be compared to at least two trees, one of these
diffs must show the bug.
Thanks,
Dscho
^ permalink raw reply
* Re: git-bisect is magical
From: walt @ 2006-01-10 20:43 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601101143180.4939@g5.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 10 Jan 2006, Linus Torvalds wrote:
>> You can _undo_ the revert, so it's not permanent in that sense. Just do
>>
>> git reset --hard origin
>>
>> and your "master" branch will be forced back to the state that "origin"
>> was in.
>
> Btw, you can try this (careful - it will also undo any dirty state you
> have in your working tree), and then do the "pull" again (which should now
> be a trivial fast-forward) and then just try to do the "git revert" on the
> new state.
Just by stumbling around and trying things at random, I did a
'git-checkout origin' which *seemed* to resolve the merge-conflict,
but left me feeling uneasy because I don't really understand what
I'm doing. Can you give a short explanation of the difference
between 'git reset --hard origin' and 'git-checkout origin'?
> An even better option is obviously to figure out _why_ that commit broke
> for you in the first place, and get it fixed up-stream...
I'm still waiting for the insulting email from the developer ;o) How
long should I wait for a response before I start bugging other people?
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-10 20:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: Brown, Len, David S. Miller, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20060110201909.GB3911-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
On Tue, 10 Jan 2006, Adrian Bunk wrote:
>
> > Now, in this model, you're not really using git as a distributed system.
> > In this model, you're using git to track somebody elses tree, and track a
> > few patches on top of it, and then "git rebase" is a way to move the base
> > that you're tracking your patches against forwards..
>
> I am using the workaround of carrying the patches in a mail folder,
> applying them in a batch, and not pulling from your tree between
> applying a batch of patches and you pulling from my tree.
Yes, that also works.
I think "quilt" is really the right thing here, although stg may be even
easier due to the more direct git integration. But with a smallish number
of patches, just doing patch management by hand is obviously simply not a
huge problem either, so extra tools may just end up confusing the issue.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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