* [PATCH 04/14] Use run_command() to spawn external diff programs instead of fork/exec.
From: Johannes Sixt @ 2007-10-19 19:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
In-Reply-To: <1192823286-9654-4-git-send-email-johannes.sixt@telecom.at>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
diff.c | 38 +++-----------------------------------
1 files changed, 3 insertions(+), 35 deletions(-)
diff --git a/diff.c b/diff.c
index 6648e01..30b7544 100644
--- a/diff.c
+++ b/diff.c
@@ -9,6 +9,7 @@
#include "xdiff-interface.h"
#include "color.h"
#include "attr.h"
+#include "run-command.h"
#ifdef NO_FAST_WORKING_DIRECTORY
#define FAST_WORKING_DIRECTORY 0
@@ -1748,40 +1749,6 @@ static void remove_tempfile_on_signal(int signo)
raise(signo);
}
-static int spawn_prog(const char *pgm, const char **arg)
-{
- pid_t pid;
- int status;
-
- fflush(NULL);
- pid = fork();
- if (pid < 0)
- die("unable to fork");
- if (!pid) {
- execvp(pgm, (char *const*) arg);
- exit(255);
- }
-
- while (waitpid(pid, &status, 0) < 0) {
- if (errno == EINTR)
- continue;
- return -1;
- }
-
- /* Earlier we did not check the exit status because
- * diff exits non-zero if files are different, and
- * we are not interested in knowing that. It was a
- * mistake which made it harder to quit a diff-*
- * session that uses the git-apply-patch-script as
- * the GIT_EXTERNAL_DIFF. A custom GIT_EXTERNAL_DIFF
- * should also exit non-zero only when it wants to
- * abort the entire diff-* session.
- */
- if (WIFEXITED(status) && !WEXITSTATUS(status))
- return 0;
- return -1;
-}
-
/* An external diff command takes:
*
* diff-cmd name infile1 infile1-sha1 infile1-mode \
@@ -1834,7 +1801,8 @@ static void run_external_diff(const char *pgm,
*arg++ = name;
}
*arg = NULL;
- retval = spawn_prog(pgm, spawn_arg);
+ fflush(NULL);
+ retval = run_command_v_opt(spawn_arg, 0);
remove_tempfile();
if (retval) {
fprintf(stderr, "external diff died, stopping at %s.\n", name);
--
1.5.3.4.315.g2ce38
^ permalink raw reply related
* [PATCH 02/14] Use start_command() in git_connect() instead of explicit fork/exec.
From: Johannes Sixt @ 2007-10-19 19:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
In-Reply-To: <1192823286-9654-2-git-send-email-johannes.sixt@telecom.at>
The child process handling is delegated to start_command() and
finish_command().
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
connect.c | 103 ++++++++++++++++++++++++++++--------------------------------
1 files changed, 48 insertions(+), 55 deletions(-)
diff --git a/connect.c b/connect.c
index e66e171..d19c7b1 100644
--- a/connect.c
+++ b/connect.c
@@ -482,11 +482,12 @@ struct child_process *git_connect(int fd[2], char *url,
char *host, *path = url;
char *end;
int c;
- int pipefd[2][2];
struct child_process *conn;
enum protocol protocol = PROTO_LOCAL;
int free_path = 0;
char *port = NULL;
+ const char **arg;
+ struct strbuf cmd;
/* Without this we cannot rely on waitpid() to tell
* what happened to our children.
@@ -572,59 +573,52 @@ struct child_process *git_connect(int fd[2], char *url,
return NULL;
}
- if (pipe(pipefd[0]) < 0 || pipe(pipefd[1]) < 0)
- die("unable to create pipe pair for communication");
conn = xcalloc(1, sizeof(*conn));
- conn->pid = fork();
- if (conn->pid < 0)
- die("unable to fork");
- if (!conn->pid) {
- struct strbuf cmd;
-
- strbuf_init(&cmd, MAX_CMD_LEN);
- strbuf_addstr(&cmd, prog);
- strbuf_addch(&cmd, ' ');
- sq_quote_buf(&cmd, path);
- if (cmd.len >= MAX_CMD_LEN)
- die("command line too long");
-
- dup2(pipefd[1][0], 0);
- dup2(pipefd[0][1], 1);
- close(pipefd[0][0]);
- close(pipefd[0][1]);
- close(pipefd[1][0]);
- close(pipefd[1][1]);
- if (protocol == PROTO_SSH) {
- const char *ssh, *ssh_basename;
- ssh = getenv("GIT_SSH");
- if (!ssh) ssh = "ssh";
- ssh_basename = strrchr(ssh, '/');
- if (!ssh_basename)
- ssh_basename = ssh;
- else
- ssh_basename++;
- if (!port)
- execlp(ssh, ssh_basename, host, cmd.buf, NULL);
- else
- execlp(ssh, ssh_basename, "-p", port, host,
- cmd.buf, NULL);
+ strbuf_init(&cmd, MAX_CMD_LEN);
+ strbuf_addstr(&cmd, prog);
+ strbuf_addch(&cmd, ' ');
+ sq_quote_buf(&cmd, path);
+ if (cmd.len >= MAX_CMD_LEN)
+ die("command line too long");
+
+ conn->in = conn->out = -1;
+ conn->argv = arg = xcalloc(6, sizeof(*arg));
+ if (protocol == PROTO_SSH) {
+ const char *ssh = getenv("GIT_SSH");
+ if (!ssh) ssh = "ssh";
+
+ *arg++ = ssh;
+ if (port) {
+ *arg++ = "-p";
+ *arg++ = port;
}
- else {
- unsetenv(ALTERNATE_DB_ENVIRONMENT);
- unsetenv(DB_ENVIRONMENT);
- unsetenv(GIT_DIR_ENVIRONMENT);
- unsetenv(GIT_WORK_TREE_ENVIRONMENT);
- unsetenv(GRAFT_ENVIRONMENT);
- unsetenv(INDEX_ENVIRONMENT);
- execlp("sh", "sh", "-c", cmd.buf, NULL);
- }
- die("exec failed");
+ *arg++ = host;
+ }
+ else {
+ /* remove these from the environment */
+ const char *env[] = {
+ ALTERNATE_DB_ENVIRONMENT,
+ DB_ENVIRONMENT,
+ GIT_DIR_ENVIRONMENT,
+ GIT_WORK_TREE_ENVIRONMENT,
+ GRAFT_ENVIRONMENT,
+ INDEX_ENVIRONMENT,
+ NULL
+ };
+ conn->env = env;
+ *arg++ = "sh";
+ *arg++ = "-c";
}
- fd[0] = pipefd[0][0];
- fd[1] = pipefd[1][1];
- close(pipefd[0][1]);
- close(pipefd[1][0]);
+ *arg++ = cmd.buf;
+ *arg = NULL;
+
+ if (start_command(conn))
+ die("unable to fork");
+
+ fd[0] = conn->out; /* read from child's stdout */
+ fd[1] = conn->in; /* write to child's stdin */
+ strbuf_release(&cmd);
if (free_path)
free(path);
return conn;
@@ -632,13 +626,12 @@ struct child_process *git_connect(int fd[2], char *url,
int finish_connect(struct child_process *conn)
{
+ int code;
if (conn == NULL)
return 0;
- while (waitpid(conn->pid, NULL, 0) < 0) {
- if (errno != EINTR)
- return -1;
- }
+ code = finish_command(conn);
+ free(conn->argv);
free(conn);
- return 0;
+ return code;
}
--
1.5.3.4.315.g2ce38
^ permalink raw reply related
* [PATCH 0/14 resend] fork/exec removal series
From: Johannes Sixt @ 2007-10-19 19:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
Here it is again, a series of patches that removes a number fork/exec pairs.
The series goes on top of the builtin-fetch pack topic, specifically,
cfa5b2b7f (Avoid scary errors...) and obsoletes q/jsi/no-fork of Lars'
patch queue.
The difference compared to the last time I sent are in:
[02/14] Use start_command() in git_connect() instead of explicit fork/exec.
[13/14] Avoid a dup2(2) in apply_filter() - start_command() can do it for us.
[14/14] Use the asyncronous function infrastructure to run the content filter.
which had conflicts with the strbuf series.
builtin-archive.c | 8 +-
builtin-fetch-pack.c | 101 +++++++++----------------
cache.h | 4 +-
connect.c | 128 +++++++++++++++----------------
convert.c | 88 ++++++++--------------
diff.c | 38 +---------
peek-remote.c | 8 +-
run-command.c | 78 +++++++++++++++++---
run-command.h | 23 ++++++
send-pack.c | 8 +-
t/t0021-conversion.sh | 7 ++-
transport.c | 9 +--
upload-pack.c | 199 ++++++++++++++++++++++---------------------------
13 files changed, 332 insertions(+), 367 deletions(-)
-- Hannes
^ permalink raw reply
* [PATCH 03/14] Use start_command() to run content filters instead of explicit fork/exec.
From: Johannes Sixt @ 2007-10-19 19:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
In-Reply-To: <1192823286-9654-3-git-send-email-johannes.sixt@telecom.at>
The previous code already used finish_command() to wait for the process
to terminate, but did not use start_command() to run it.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
convert.c | 30 +++++++-----------------------
1 files changed, 7 insertions(+), 23 deletions(-)
diff --git a/convert.c b/convert.c
index aa95834..d83c2fc 100644
--- a/convert.c
+++ b/convert.c
@@ -199,34 +199,18 @@ static int filter_buffer(const char *path, const char *src,
* Spawn cmd and feed the buffer contents through its stdin.
*/
struct child_process child_process;
- int pipe_feed[2];
int write_err, status;
+ const char *argv[] = { "sh", "-c", cmd, NULL };
memset(&child_process, 0, sizeof(child_process));
+ child_process.argv = argv;
+ child_process.in = -1;
- if (pipe(pipe_feed) < 0) {
- error("cannot create pipe to run external filter %s", cmd);
- return 1;
- }
-
- child_process.pid = fork();
- if (child_process.pid < 0) {
- error("cannot fork to run external filter %s", cmd);
- close(pipe_feed[0]);
- close(pipe_feed[1]);
- return 1;
- }
- if (!child_process.pid) {
- dup2(pipe_feed[0], 0);
- close(pipe_feed[0]);
- close(pipe_feed[1]);
- execlp("sh", "sh", "-c", cmd, NULL);
- return 1;
- }
- close(pipe_feed[0]);
+ if (start_command(&child_process))
+ return error("cannot fork to run external filter %s", cmd);
- write_err = (write_in_full(pipe_feed[1], src, size) < 0);
- if (close(pipe_feed[1]))
+ write_err = (write_in_full(child_process.in, src, size) < 0);
+ if (close(child_process.in))
write_err = 1;
if (write_err)
error("cannot feed the input to external filter %s", cmd);
--
1.5.3.4.315.g2ce38
^ permalink raw reply related
* Re: gitk patch collection pull request
From: Linus Torvalds @ 2007-10-19 19:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Paul Mackerras, git
In-Reply-To: <20071019052823.GI14735@spearce.org>
On Fri, 19 Oct 2007, Shawn O. Pearce wrote:
>
> The following changes since commit 719c2b9d926bf2be4879015e3620d27d32f007b6:
> Paul Mackerras (1):
> gitk: Fix bug causing undefined variable error when cherry-picking
The biggest problem I have with gitk is that it is almost totally useless
for when you have a file limit.
I do "gitk --merge" (which has an implicit file limit of the list
of unmerged files) or just "gitk ORIG_HEAD.. Makefile" and the *history*
of gitk looks fine.
But the diffs are crap and useless, because they contain all the stuff I
did *not* want, and hides all the relevant information.
So then I might use the nice gitk history window to see the commits, but I
will fall back on "git log -p --merge" and "git log -p ORIG_HEAD.. Makefile"
for the real work.
I had that happen unusually many times lately, since we had a fair number
of (mostly trivial) conflicts during this merge window. And it's sad. Gitk
is so good in so many other ways, and then it is so *totally* useless when
it comes to something as fundamental as just looking at the history of a
few files.
Linus
^ permalink raw reply
* Re: git on afs
From: Linus Torvalds @ 2007-10-19 19:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Todd T. Fries, git
In-Reply-To: <20071019060624.GK14735@spearce.org>
On Fri, 19 Oct 2007, Shawn O. Pearce wrote:
>
> What about this instead? It avoids the double lstat() of Todd's
> original patch but seems like it would fix the issue here. Or did
> I misunderstand the problem?
No. As far as I can tell without testing it, this patch will make it show
ignored regular files if they have DT_UNKNOWN in the directory entry (or
the filesystem doesn't support it). Not good.
Linus
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Linus Torvalds @ 2007-10-19 19:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.9999.0710190753040.19446@xanadu.home>
On Fri, 19 Oct 2007, Nicolas Pitre wrote:
> On Fri, 19 Oct 2007, Jeff King wrote:
> >
> > Ah, right. I hadn't thought of that. While it would be a nice
> > convenience feature, it's probably not worth the deep internal hackery
> > that would be required.
>
> What about a preprocessor that could match <1>@{<2>..<3>} in the
> argument list and substitute that with <1>@{<2>}..<1>@{<3>} before it is
> actually parsed?
Could be done, but I almost think it would be better to just make the
sha1_name.c interfaces take some extended data structure which allows
looking up multiple SHA1's at the same time.
Sure, we'd leave the "simple" interfaces around for users that simply want
just one SHA1 value, but that would allow us to remove duplicate code from
revision.c and rev-parse.c. And it would allow us to generally make the
SHA1 parsing fancier: there may well be other expressions that are worth
doing.
Linus
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 18:51 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Steven Grimm, Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <20071019172610.GE30825@uranus.ravnborg.org>
On Fri, 19 Oct 2007, Sam Ravnborg wrote:
> On Fri, Oct 19, 2007 at 12:12:41PM -0400, Nicolas Pitre wrote:
> > This is even more wrong.
> >
> > Agreed, indexing objects might not be the best description. It probably
> > will become "receiving objects" along with a bandwitth meter.
>
> The term 'objects' here always confuses me. What is often my first
> thing to check the number of individual commits being added after
> a git pull. Wether a commit touches one or several files is less
> important (to my way of using git).
Let me unconfuse you.
Git storage is made of, well, objects. You might think that objects are
related to the number of files concerned by a set of commits during a
pull, but this is not the case. It is well possible to have a commit
touching 100 files and have much fewer new objects created than that.
Reverting a patch, for example, would only restore a reference to older
objects in the database. The same is true if you move an entire
directory around.
The opposite is also true: you can have more new objects than modified
files for a single commit, depending on the directory depth.
So the number of objects has no exact relationship what so ever with the
number of objects. However the number of objects has a much more direct
influence on the time to perform a fetch, and that is what we're
displaying here. After all when you issue a pull and wait for it to
complete, you wait for X amount of objects to be transferred and not Y
amount of commits.
The important metric is therefore measured in "objects". But you're
free to ignore it and only look at the percentage if you prefer.
Nicolas
^ permalink raw reply
* RE: git push bug?
From: Joakim Tjernlund @ 2007-10-19 18:50 UTC (permalink / raw)
To: 'Johannes Schindelin'; +Cc: 'Steffen Prohaska', 'git'
In-Reply-To: <Pine.LNX.4.64.0710191920210.16728@wbgn129.biozentrum.uni-wuerzburg.de>
> -----Original Message-----
> From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de]
> Sent: den 19 oktober 2007 19:25
> To: Joakim Tjernlund
> Cc: Steffen Prohaska; git
> Subject: Re: git push bug?
>
> Hi,
>
> On Fri, 19 Oct 2007, Joakim Tjernlund wrote:
>
> > On Thu, 2007-10-18 at 23:00 +0100, Johannes Schindelin wrote:
> > >
> > > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> > >
> > > > First, I didn't know that I could do that. Secondly, I was also
> > > > looking do v2.6.23:linus refspecs
> > >
> > >
> > > First, then our documentation could be better. How?
> >
> > Well, it isn't clear to me how all this is supposed to work
> and what is
> > bugs. Clearifying that would help.
> >
> > For instances I did a push with v2.6.23:refs/heads/linus
> and now I got a
> > branch with the SHA1 of v2.6.23
> > tag(0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d) in it. Makes
> gitk display
> > that branch as "linus^{}".
>
> It strikes me as really odd that you would _want_ to create a branch
> remotely, that has _never_ existed locally.
It strikes me as really odd that a core developers like yourself
hasn't tried to justify/explain why push works as it does.
As I am trying to convince our dev. group here to move to git instead of subversion, I
need to learn how git works. Now I have gotten to the push function and I need
to know what can be done with push and how, pitfalls too. As I go along I find behavior
that I find odd and report these to the list.
git push <repo> v2.6.23:refs/heads/linus
will make a tag look like a branch
git push <repo> linus:linus
won't let me create the remote branch linus but
git push <repo> linus
will
git push <repo> :linus
OOPS, now I just deleted remote branch linus, no warning
git push <repo> linus:refs/head/linus
creates a branch that is invisible(wont show in git branch -a)
git push <repo> linus:refs/heads/newbranch
creates remote branch newbranch, but you have to know the magic words
refs/heads/ to do it.
Se what I mean?
>
> > > Second, why not "git checkout -b linus v2.6.23 && git push origin
> > > linus"?
> >
> > An extra checkout that takes time but works.
>
> Not only that: before trying to publish something, I would
> have expected
> you to have that branch locally, and that you actually worked on it.
>
> > Doesn't make the above "weiredness" go away though.
>
> Yes it does.
No it doesn't. If someone else in my group wants to create a branch they
might do the same mistakes as I did.
>
> git checkout -b <branchname> resolves to the commit that the
> tag pointed
> to. So it would not push a tag, which you did.
>
> Of course you could do what you planned to do, if you knew
> git better.
> But you are not familiar enough with git's inner workings yet, so I
> suggest to stay with things for now that work _always_, and
> exactly as
> expected.
>
> Such as creating a branch locally, with exactly the name that
> you plan it
> to have remotely, and then pushing it with "git push origin
> <branchname>".
> Easy as apple pie.
>
> Ciao,
> Dscho
>
>
>
^ permalink raw reply
* Re: git on afs
From: Linus Torvalds @ 2007-10-19 17:59 UTC (permalink / raw)
To: Todd T. Fries; +Cc: git, Shawn O. Pearce, Brandon Casey
In-Reply-To: <200710190719.21660.todd@fries.net>
On Fri, 19 Oct 2007, Todd T. Fries wrote:
>
> If DT_UNKNOWN exists, then we have to do a stat() of some form to
> find out the right type.
>
> This is difficult to fix properly to avoid the extra stat() since
> inside the switch logic we do the recursion, but we might have
> avoided it earlier because of the exclusion.
>
> I'll send a separate diff for an updated link() vs rename() diff.
>
> I've attached an updated diff that should address concerns of everyone
> who gave me feedback on my dir.c changes.
>
> Better?
Yes. I think this is ok, although I also did this alternate patch that is
anal about not bothering to call "lstat()" if it can decide that the path
is ignored even before that.
That happened in the case of a pathname that was ignored, and we did not
ask for "dir->show_ignored". That test used to be *together* with the
"DTYPE(de) != DT_DIR", but splitting the two tests up means that we can do
that (common) test before we even bother to calculate the real dtype.
Of course, that optimization only matters for systems that don't have, or
don't fill in DTYPE properly, but I get a bit anal about these kinds of
optimizations.
I also clarified the real relationship between "exclude" and
"dir->show_ignored". It used to do
if (exclude != dir->show_ignored) {
..
which wasn't exactly obvious, because it triggers for two different cases:
- the path is marked excluded, but we are not interested in ignored
files: ignore it
- the path is *not* excluded, but we *are* interested in ignored files:
ignore it unless it's a directory, in which case we might have ignored
files inside the directory and need to recurse into it).
so this splits them into those two cases, since the first case doesn't
even care about the type.
I also made a the DT_UNKNOWN case a separate helper function, and added
some commentary to the cases.
Does this patch work for you?
Linus
---
dir.c | 52 ++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/dir.c b/dir.c
index eb6c3ab..f843c4d 100644
--- a/dir.c
+++ b/dir.c
@@ -443,6 +443,24 @@ static int in_pathspec(const char *path, int len, const struct path_simplify *si
return 0;
}
+static int get_dtype(struct dirent *de, const char *path)
+{
+ int dtype = DTYPE(de);
+ struct stat st;
+
+ if (dtype != DT_UNKNOWN)
+ return dtype;
+ if (lstat(path, &st))
+ return dtype;
+ if (S_ISREG(st.st_mode))
+ return DT_REG;
+ if (S_ISDIR(st.st_mode))
+ return DT_DIR;
+ if (S_ISLNK(st.st_mode))
+ return DT_LNK;
+ return dtype;
+}
+
/*
* Read a directory tree. We currently ignore anything but
* directories, regular files and symlinks. That's because git
@@ -466,7 +484,7 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
exclude_stk = push_exclude_per_directory(dir, base, baselen);
while ((de = readdir(fdir)) != NULL) {
- int len;
+ int len, dtype;
int exclude;
if ((de->d_name[0] == '.') &&
@@ -486,24 +504,30 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
if (exclude && dir->collect_ignored
&& in_pathspec(fullname, baselen + len, simplify))
dir_add_ignored(dir, fullname, baselen + len);
- if (exclude != dir->show_ignored) {
- if (!dir->show_ignored || DTYPE(de) != DT_DIR) {
+
+ /*
+ * Excluded? If we don't explicitly want to show
+ * ignored files, ignore it
+ */
+ if (exclude && !dir->show_ignored)
+ continue;
+
+ dtype = get_dtype(de, fullname);
+
+ /*
+ * Do we want to see just the ignored files?
+ * We still need to recurse into directories,
+ * even if we don't ignore them, since the
+ * directory may contain files that we do..
+ */
+ if (!exclude && dir->show_ignored) {
+ if (dtype != DT_DIR)
continue;
- }
}
- switch (DTYPE(de)) {
- struct stat st;
+ switch (dtype) {
default:
continue;
- case DT_UNKNOWN:
- if (lstat(fullname, &st))
- continue;
- if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode))
- break;
- if (!S_ISDIR(st.st_mode))
- continue;
- /* fallthrough */
case DT_DIR:
memcpy(fullname + baselen + len, "/", 2);
len++;
^ permalink raw reply related
* [PATCH] git-cherry-pick: improve description of -x.
From: Ralf Wildenhues @ 2007-10-19 17:41 UTC (permalink / raw)
To: git
Reword the first sentence of the description of -x, in order to
make it easier to read and understand.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
I have two issues with "git-cherry-pick -x": When reading its manpage
description for the first time, I completely failed to understand the
first sentence, and had to try it out in order to understand.
Further, I am surprised that -x seems to be nonfunctional when the
cherry pick introduces a conflict. Example:
git init
echo >dummy
git add dummy
git commit -m dummy
git checkout -b br
echo one >file
git add file
git commit -m one
echo two >>file
git commit -a -m two
git checkout master
git cherry-pick -x br # conflict, tells me "-c ..." arg to use
# for the commit later
echo '1d
w' | ed file # resolve conflict
git add file
git commit -c ...
The prototype commit message now does not contain the
| (cherry picked from commit ...).
Is that by design (because there were conflicts) or an omission?
In case of the former, maybe the description of -x should mention this.
Thanks,
Ralf
Documentation/git-cherry-pick.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 47b1e8c..c7d83ce 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -27,10 +27,10 @@ OPTIONS
message prior committing.
-x::
- Cause the command to append which commit was
- cherry-picked after the original commit message when
- making a commit. Do not use this option if you are
- cherry-picking from your private branch because the
+ When recording the commit, the original commit message will
+ be appended with a note that indicates which commit this
+ change was cherry-picked from. Do not use this option if
+ you are cherry-picking from your private branch because the
information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
--
1.5.3.1.153.g89df5
^ permalink raw reply related
* [PATCH] gitk.txt: Fix markup.
From: Ralf Wildenhues @ 2007-10-19 17:24 UTC (permalink / raw)
To: git
For the manpage, avoid generating an em dash in code.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
Documentation/gitk.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index e9f82b9..8dbfb0d 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -69,7 +69,7 @@ gitk --since="2 weeks ago" \-- gitk::
The "--" is necessary to avoid confusion with the *branch* named
'gitk'
-gitk --max-count=100 --all -- Makefile::
+gitk --max-count=100 --all \-- Makefile::
Show at most 100 changes made to the file 'Makefile'. Instead of only
looking for changes in the current branch look in all branches.
--
1.5.3.1.153.g89df5
^ permalink raw reply related
* Re: git push bug?
From: Johannes Schindelin @ 2007-10-19 17:24 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Steffen Prohaska, git
In-Reply-To: <1192805255.1875.25.camel@gentoo-jocke.transmode.se>
Hi,
On Fri, 19 Oct 2007, Joakim Tjernlund wrote:
> On Thu, 2007-10-18 at 23:00 +0100, Johannes Schindelin wrote:
> >
> > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> >
> > > First, I didn't know that I could do that. Secondly, I was also
> > > looking do v2.6.23:linus refspecs
> >
> >
> > First, then our documentation could be better. How?
>
> Well, it isn't clear to me how all this is supposed to work and what is
> bugs. Clearifying that would help.
>
> For instances I did a push with v2.6.23:refs/heads/linus and now I got a
> branch with the SHA1 of v2.6.23
> tag(0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d) in it. Makes gitk display
> that branch as "linus^{}".
It strikes me as really odd that you would _want_ to create a branch
remotely, that has _never_ existed locally.
> > Second, why not "git checkout -b linus v2.6.23 && git push origin
> > linus"?
>
> An extra checkout that takes time but works.
Not only that: before trying to publish something, I would have expected
you to have that branch locally, and that you actually worked on it.
> Doesn't make the above "weiredness" go away though.
Yes it does.
git checkout -b <branchname> resolves to the commit that the tag pointed
to. So it would not push a tag, which you did.
Of course you could do what you planned to do, if you knew git better.
But you are not familiar enough with git's inner workings yet, so I
suggest to stay with things for now that work _always_, and exactly as
expected.
Such as creating a branch locally, with exactly the name that you plan it
to have remotely, and then pushing it with "git push origin <branchname>".
Easy as apple pie.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Sam Ravnborg @ 2007-10-19 17:26 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Steven Grimm, Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710191211210.19446@xanadu.home>
On Fri, Oct 19, 2007 at 12:12:41PM -0400, Nicolas Pitre wrote:
> On Fri, 19 Oct 2007, Steven Grimm wrote:
>
> > On 19/10/2007, Jeff King <peff@peff.net> wrote:
> > > This makes the fetch output much more terse. It is likely to
> > > be very controversial. Here's an example of the new output:
> > >
> > > Indexing objects: 100% (1061/1061), done.
> > > Resolving deltas: 100% (638/638), done.
> >
> > Those two lines are actually my beef with the fetch output. As a newbie, I had
> > no idea what "Indexing objects" actually meant. We have this thing called "the
> > index" in git so I would expect "Indexing objects" to have something to do
> > with that, but it doesn't seem to.
> >
> > How about something more descriptive of the high-level operation that's going
> > on, along the lines of:
> >
> > Gathering changes from remote: 100% (1061/1061), done.
> > Applying changes locally: 100% (638/638), done.
>
> This is even more wrong.
>
> Agreed, indexing objects might not be the best description. It probably
> will become "receiving objects" along with a bandwitth meter.
The term 'objects' here always confuses me. What is often my first
thing to check the number of individual commits being added after
a git pull. Wether a commit touches one or several files is less
important (to my way of using git).
Sam
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Johannes Schindelin @ 2007-10-19 17:19 UTC (permalink / raw)
To: Mike Hommey; +Cc: Scott Parish, Johannes Sixt, git
In-Reply-To: <20071019164816.GA24573@glandium.org>
Hi,
On Fri, 19 Oct 2007, Mike Hommey wrote:
> On Fri, Oct 19, 2007 at 04:27:39PM +0200, Johannes Schindelin wrote:
> > While reading this, I have to wonder why it is not just simpler to try
> > with builtin_exec_path first, and if that fails, just let exec() find the
> > program in the PATH?
>
> Why not try the directory where the git executable is, too ?
I commented on that. If the git command was not specified with an
absolute path, then make it absolute (and only if not even a relative path
was specified, ignore this altogether since git is in the PATH).
I was a bit terse on the issue I have to admit, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Mike Hommey @ 2007-10-19 16:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Parish, Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0710191616490.16728@wbgn129.biozentrum.uni-wuerzburg.de>
On Fri, Oct 19, 2007 at 04:27:39PM +0200, Johannes Schindelin wrote:
> While reading this, I have to wonder why it is not just simpler to try
> with builtin_exec_path first, and if that fails, just let exec() find the
> program in the PATH?
Why not try the directory where the git executable is, too ?
Mike
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Johannes Sixt @ 2007-10-19 14:34 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071019141805.GE1463@srparish.net>
Scott Parish schrieb:
> On Fri, Oct 19, 2007 at 03:21:12PM +0200, Johannes Sixt wrote:
>
>> Scott Parish schrieb:
>>> I have a situation where software for a distribution is installed
>>> into a fake "prefix" and then moved to one of several potential
>>> places to be used by users. Given that the final location isn't
>>> static, i can't depend on builtin_exec_path. I'd really like users
>>> to be able to get started with git as easily as possible. With the
>>> current setup, they would have to create and maintain either an
>>> GIT_EXEC_PATH or an alias for including --exec-path, as well as a
>>> MANPATH and PERL5LIB. This seem like an unnessisary burden.
>> Interesting. How does this compare to this 2-patch-series:
>>
>> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=e479ea2f911b8c70a269ba59372a4fef90f8907c
>> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=00a4ff4f3f8ec7e6b3ac15456f00b22b03f438ae
>>
>> which I had come up with to accomplish something very similar
>> (on Windows). Your approach looks superior, but I hadn't gone
>> into depths, yet.
>
> I know very little about what's available on windows. Looking at
> your code, it looks like the command isn't passed in in argv[0] and
> that it contains the windows style path seperators. My code currently
> assumes that PATH is a colon separated list, and that directories
> are separated with '/'. How should these assumptions change for
> windows?
The question is rather whether my patches would be sufficient to also
achieve your requirements. They turn bultin_exec_path into a non-constant
that derives exec-path from argv[0] (which on Windows happens to be
available in the global _pgmptr). Isn't this enough, or at least the essence
of what you need?
(How to get to the value of _pgmptr, ie. argv[0], on non-Windows is a
secondary matter.)
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 16:12 UTC (permalink / raw)
To: Steven Grimm; +Cc: Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <4718D25A.7040109@midwinter.com>
On Fri, 19 Oct 2007, Steven Grimm wrote:
> On 19/10/2007, Jeff King <peff@peff.net> wrote:
> > This makes the fetch output much more terse. It is likely to
> > be very controversial. Here's an example of the new output:
> >
> > Indexing objects: 100% (1061/1061), done.
> > Resolving deltas: 100% (638/638), done.
>
> Those two lines are actually my beef with the fetch output. As a newbie, I had
> no idea what "Indexing objects" actually meant. We have this thing called "the
> index" in git so I would expect "Indexing objects" to have something to do
> with that, but it doesn't seem to.
>
> How about something more descriptive of the high-level operation that's going
> on, along the lines of:
>
> Gathering changes from remote: 100% (1061/1061), done.
> Applying changes locally: 100% (638/638), done.
This is even more wrong.
Agreed, indexing objects might not be the best description. It probably
will become "receiving objects" along with a bandwitth meter.
Nicolas
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 15:57 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <28B30BAE-9482-4219-924B-F0EDFB2936FB@wincent.com>
On 19 Oct 2007, at 7:33:39 AM, Wincent Colaiuta wrote:
>> What you want to happen is the following:
>>
>> git show HEAD:A.txt > path/B.txt
>> git add path/B.txt
>> mv A.txt B.txt
>> git rm A.txt
>>
>> Is this correct?
>
> Here you're copying the content of A.txt as it was in the last
> (HEAD) commit, but from what the poster said he wants the content
> of A.txt as it is staged in the index (that is, there may be staged
> but uncomitted changes).
>
>> Better:
>>
>>> mv A.txt path/B.txt
>>> Point the index entry for A.txt to path/B.txt
>
> Yes, that is basically what he was asking for, as I read it.
You're right.
There is the subtlety in the first case that he's already staged
something.
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Steven Grimm @ 2007-10-19 15:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <4718D25A.7040109@midwinter.com>
(Sorry for the repeat; my mail client tried to send this as HTML at
first and the git list rejected it.)
On 19/10/2007, Jeff King <peff@peff.net> wrote:
> This makes the fetch output much more terse. It is likely to
> be very controversial. Here's an example of the new output:
>
> Indexing objects: 100% (1061/1061), done.
> Resolving deltas: 100% (638/638), done.
Those two lines are actually my beef with the fetch output. As a newbie,
I had no idea what "Indexing objects" actually meant. We have this thing
called "the index" in git so I would expect "Indexing objects" to have
something to do with that, but it doesn't seem to.
How about something more descriptive of the high-level operation that's
going on, along the lines of:
Gathering changes from remote: 100% (1061/1061), done.
Applying changes locally: 100% (638/638), done.
-Steve
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Steven Grimm @ 2007-10-19 15:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
On 19/10/2007, Jeff King <peff@peff.net> wrote:
> This makes the fetch output much more terse. It is likely to
> be very controversial. Here's an example of the new output:
>
> Indexing objects: 100% (1061/1061), done.
> Resolving deltas: 100% (638/638), done.
Those two lines are actually my beef with the fetch output. As a newbie,
I had no idea what "Indexing objects" actually meant. We have this thing
called "the index" in git so I would expect "Indexing objects" to have
something to do with that, but it doesn't seem to.
How about something more descriptive of the high-level operation that's
going on, along the lines of:
Gathering changes from remote: 100% (1061/1061), done.
Applying changes locally: 100% (638/638), done.
-Steve
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 15:03 UTC (permalink / raw)
To: Karl Hasselström
Cc: Theodore Tso, Santi Béjar, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <20071019143844.GB23765@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1393 bytes --]
On Fri, 19 Oct 2007, Karl Hasselström wrote:
> On 2007-10-19 07:38:22 -0400, Theodore Tso wrote:
>
> > Finally, one last question --- am I the only one who had to take a
> > second look at the whether the arrow should be <- or ->? The
> > question is whether we are saying "gitk is moving to include all of
> > spearce/gitk"; but I could also see it stated that we are assigning
> > refs/heads/gitk with refs/remotes/spearce/gitk, in which case the
> > arrow should be reversed. Or maybe:
> >
> > ==> git://repo.or.cz/git/spearce.git
> > * branch gitk := spearce/gitk (new)
> > * branch maint := spearce/maint 1aa3d01..e7187e4
> > * branch master := spearce/master de61e42..7840ce6
> > * branch next := spearce/next 895be02..2fe5433
> > + branch pu := spearce/pu 89fa332...1e4c517
> > * branch todo := spearce/todo (new)
>
> I think the reasoning behind the "foo -> spearce/foo" syntax is that
> "(refs/heads/)foo" in the remote repository has been fetched to
> "(refs/remotes/)spearce/foo" in the local repository.
Well, the important thing is that the _content_ is moving from the
remote repository to the local one. That's how the arrow should be
interpreted conceptually. The fact that technically we end up assigning
the local ref with the remote value is a technical issue.
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 14:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Johannes Sixt, Theodore Tso, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0710191640250.16728@wbgn129.biozentrum.uni-wuerzburg.de>
On Fri, 19 Oct 2007, Johannes Schindelin wrote:
> Better to say (forced) if need be. But I do not think so. I like Hannes'
> proposal as-is.
I'm of that opinion too. Except maybe using a space instead of * for
fast forward, so the other types stand out more.
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 14:54 UTC (permalink / raw)
To: Johannes Sixt
Cc: Santi Béjar, Theodore Tso, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <4718C1DE.5030708@viscovery.net>
On Fri, 19 Oct 2007, Johannes Sixt wrote:
> The '*' could go away, then the '+' is more visible.
Agreed. ' ' = fast forward, '+' = forced update, and '!' = refused.
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 14:52 UTC (permalink / raw)
To: Santi Béjar
Cc: Johannes Sixt, Theodore Tso, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 900 bytes --]
On Fri, 19 Oct 2007, Santi Béjar wrote:
> I like it too. I would like to add some more descripton, because I
> think for newbies the .. and ... can be overlooked. Something like:
>
> $ git fetch spearce
> ...
> URL: git://repo.or.cz/git/spearce.git
> * (new) spearce/gitk: new branch 'gitk'
> * 1aa3d01..e7187e4 spearce/maint: fast forward to branch 'maint'
> * de61e42..7840ce6 spearce/master: fast forward to branch 'master'
> * 895be02..2fe5433 spearce/next: fast forward to branch 'next'
> + 89fa332...1e4c517 spearce/pu: forcing update to non-fast forward branch 'pu'
> * (new) spearce/todo: new branch spearce/todo
Well, I don't like it as much. First I don't think newbies will care
much more even if the type of update is spelled out verbosely. Better
keep it short and add all the necessary information in the fetch man
page instead.
Nicolas
^ permalink raw reply
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