* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Linus Torvalds @ 2007-12-02 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, Steffen Prohaska, Git Mailing List
In-Reply-To: <7vmyssvn55.fsf@gitster.siamese.dyndns.org>
On Sun, 2 Dec 2007, Junio C Hamano wrote:
>
> The next issue would be to find who could pass an empty GIT_AUTHOR_DATE
> without noticing...
In the meantime, here's a not-very-well-tested patch to fsck to at least
notice this.
Of course, in the name of containment it would probably be even better if
parse_commit() did it, because then people would be unable to pull from
such a corrupt repository! But this would seem to be at least a slight
step in the right direction.
Linus
---
builtin-fsck.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index e4874f6..309212c 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -351,8 +351,48 @@ static int fsck_tree(struct tree *item)
return retval;
}
+static int parse_commit_line(struct commit *commit, const char *expect, const char *buffer)
+{
+ char *end;
+ const char *p;
+ int len = strlen(expect);
+ int saw_lt = 0;
+
+ if (memcmp(buffer, expect, len))
+ goto bad;
+ p = (char *)buffer + len;
+ if (*p != ' ')
+ goto bad;
+ while (*++p != '>') {
+ if (*p == '<')
+ saw_lt++;
+ if (!*p)
+ goto bad;
+ }
+ if (saw_lt != 1)
+ goto bad;
+ if (*++p != ' ')
+ goto bad;
+
+ /* Date in seconds since the epoch (UTC) */
+ if (strtoul(p, &end, 10) == ULONG_MAX)
+ goto bad;
+ if (*end++ != ' ')
+ goto bad;
+
+ /* TZ that date was done in */
+ if (strtoul(end, &end, 10) == ULONG_MAX)
+ goto bad;
+ if (*end++ != '\n')
+ goto bad;
+ return end - buffer;
+bad:
+ return objerror(&commit->object, "invalid format - missing or corrupt '%s'", expect);
+}
+
static int fsck_commit(struct commit *commit)
{
+ int len;
char *buffer = commit->buffer;
unsigned char tree_sha1[20], sha1[20];
@@ -370,8 +410,21 @@ static int fsck_commit(struct commit *commit)
return objerror(&commit->object, "invalid 'parent' line format - bad sha1");
buffer += 48;
}
- if (memcmp(buffer, "author ", 7))
- return objerror(&commit->object, "invalid format - expected 'author' line");
+
+ /*
+ * We check the author/committer lines for completeness.
+ * But errors here aren't fatal to the rest of the parsing.
+ */
+ len = parse_commit_line(commit, "author", buffer);
+ if (len >= 0) {
+ buffer += len;
+ len = parse_commit_line(commit, "committer", buffer);
+ if (len >= 0) {
+ buffer += len;
+ if (*buffer != '\n')
+ objerror(&commit->object, "invalid format - missing or corrupt end-of-headers");
+ }
+ }
free(commit->buffer);
commit->buffer = NULL;
if (!commit->tree)
^ permalink raw reply related
* [PATCH v4] Allow update hooks to update refs on their own.
From: Steven Grimm @ 2007-12-02 21:22 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6i8sfsa.fsf@gitster.siamese.dyndns.org>
This is useful in cases where a hook needs to modify an incoming commit
in some way, e.g., fixing whitespace errors, adding an annotation to
the commit message, noting the location of output from a profiling tool,
or committing to an svn repository using git-svn.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
Since Junio's main objection to this seemed to be the protocol
change to bypass the automatic update of the tracking ref in
git-send-pack, that code is gone (thus reverting this to the
same code change as the initial version!) and I added a section
to the git-send-pack manual page describing the automatic
tracking ref update behavior, which wasn't documented at all
before. Someone please review my terminology there.
Documentation/git-receive-pack.txt | 8 +++-
Documentation/git-send-pack.txt | 16 ++++++++
receive-pack.c | 70 +++++++++++++++++++++++-------------
3 files changed, 67 insertions(+), 27 deletions(-)
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 2633d94..115ae97 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -74,8 +74,12 @@ Note that the hook is called before the refname is updated,
so either sha1-old is 0\{40} (meaning there is no such ref yet),
or it should match what is recorded in refname.
-The hook should exit with non-zero status if it wants to disallow
-updating the named ref. Otherwise it should exit with zero.
+The hook may optionally choose to update the ref on its own, e.g.,
+if it needs to modify incoming revisions in some way. If it updates
+the ref, it should exit with a status of 100. The hook should exit
+with a status between 1 and 99 if it wants to disallow updating the
+named ref. Otherwise it should exit with zero, and the ref will be
+updated automatically.
Successful execution (a zero exit status) of this hook does not
ensure the ref will actually be updated, it is only a prerequisite.
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index a2d9cb6..db64a1b 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -115,6 +115,22 @@ Optionally, a <ref> parameter can be prefixed with a plus '+' sign
to disable the fast-forward check only on that ref.
+Remote Tracking Refs
+--------------------
+
+After successfully sending a pack to the remote, 'git-send-pack'
+updates the corresponding remote tracking ref in the local repository
+to point to the same commit as was just sent to the remote side. In
+most cases this eliminates the need to subsequently fetch from the
+remote repository since there would be nothing new to fetch.
+
+If the remote side's update hook modifies the incoming commit
+before applying it, the local repository's remote tracking ref will
+point at a different commit than the corresponding remote ref (since
+the local repository will not have a copy of the modified version).
+In that case an explicit fetch will be required.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/receive-pack.c b/receive-pack.c
index fba4cf8..ca906bf 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -18,6 +18,9 @@ static int report_status;
static char capabilities[] = " report-status delete-refs ";
static int capabilities_sent;
+/* Update hook exit code: hook has updated ref on its own */
+#define EXIT_CODE_REF_UPDATED 100
+
static int receive_pack_config(const char *var, const char *value)
{
if (strcmp(var, "receive.denynonfastforwards") == 0) {
@@ -70,8 +73,11 @@ static struct command *commands;
static const char pre_receive_hook[] = "hooks/pre-receive";
static const char post_receive_hook[] = "hooks/post-receive";
-static int hook_status(int code, const char *hook_name)
+static int hook_status(int code, const char *hook_name, int ok_start)
{
+ if (ok_start && -code >= ok_start)
+ return -code;
+
switch (code) {
case 0:
return 0;
@@ -121,7 +127,7 @@ static int run_hook(const char *hook_name)
code = start_command(&proc);
if (code)
- return hook_status(code, hook_name);
+ return hook_status(code, hook_name, 0);
for (cmd = commands; cmd; cmd = cmd->next) {
if (!cmd->error_string) {
size_t n = snprintf(buf, sizeof(buf), "%s %s %s\n",
@@ -132,7 +138,7 @@ static int run_hook(const char *hook_name)
break;
}
}
- return hook_status(finish_command(&proc), hook_name);
+ return hook_status(finish_command(&proc), hook_name, 0);
}
static int run_update_hook(struct command *cmd)
@@ -155,7 +161,8 @@ static int run_update_hook(struct command *cmd)
proc.no_stdin = 1;
proc.stdout_to_stderr = 1;
- return hook_status(run_command(&proc), update_hook);
+ return hook_status(run_command(&proc), update_hook,
+ EXIT_CODE_REF_UPDATED);
}
static const char *update(struct command *cmd)
@@ -194,32 +201,45 @@ static const char *update(struct command *cmd)
return "non-fast forward";
}
}
- if (run_update_hook(cmd)) {
- error("hook declined to update %s", name);
- return "hook declined";
- }
-
- if (is_null_sha1(new_sha1)) {
- if (!parse_object(old_sha1)) {
- warning ("Allowing deletion of corrupt ref.");
- old_sha1 = NULL;
+ switch (run_update_hook(cmd)) {
+ case 0:
+ if (is_null_sha1(new_sha1)) {
+ if (!parse_object(old_sha1)) {
+ warning ("Allowing deletion of corrupt ref.");
+ old_sha1 = NULL;
+ }
+ if (delete_ref(name, old_sha1)) {
+ error("failed to delete %s", name);
+ return "failed to delete";
+ }
+ fprintf(stderr, "%s: %s -> deleted\n", name,
+ sha1_to_hex(old_sha1));
}
- if (delete_ref(name, old_sha1)) {
- error("failed to delete %s", name);
- return "failed to delete";
+ else {
+ lock = lock_any_ref_for_update(name, old_sha1, 0);
+ if (!lock) {
+ error("failed to lock %s", name);
+ return "failed to lock";
+ }
+ if (write_ref_sha1(lock, new_sha1, "push")) {
+ return "failed to write"; /* error() already called */
+ }
}
return NULL; /* good */
- }
- else {
- lock = lock_any_ref_for_update(name, old_sha1, 0);
- if (!lock) {
- error("failed to lock %s", name);
- return "failed to lock";
- }
- if (write_ref_sha1(lock, new_sha1, "push")) {
- return "failed to write"; /* error() already called */
+
+ case EXIT_CODE_REF_UPDATED:
+ /* hook has taken care of updating ref, which means it
+ might be a different revision than we think. */
+ if (! resolve_ref(name, new_sha1, 1, NULL)) {
+ error("can't resolve ref %s after hook updated it",
+ name);
+ return "ref not resolvable";
}
return NULL; /* good */
+
+ default:
+ error("hook declined to update %s", name);
+ return "hook declined";
}
}
--
1.5.3.6.2040.g97735-dirty
^ permalink raw reply related
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Johannes Schindelin @ 2007-12-02 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, krh
In-Reply-To: <7vtzn1x7w6.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 2 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> I have made several attempts to reproduce the problem, looked a bit
> >> through the log-tree code, and checked the results of the t750* series
> >> of tests; but I have found nothing.
> >
> > I remember again. When I did "commit -s -m bla" the empty line between
> > the oneline and the signoff would be missing. But in the meantime, the
> > signoff was dragged into the strbuf and all is well.
>
> Sorry, now I am confused. Building the version before that change and
> doing "./git-commit -a -s -m bla", I do not see the extra blank line in
> the "Created commit" response, and I see a blank line before and after
> the sign-off in the "git show" output for the resulting commit.
>
> Was this unnecessary change from the beginning? I am inclined to think
> so...
IIRC I did 2150554b0ed60356d8918b610834c04ad2eecdec(builtin-commit --s:
add a newline if the last line was no S-O-B) after the commit that
Peff wants to undo.
So yes, my mistake.
Ciao,
Dscho
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Junio C Hamano @ 2007-12-02 20:48 UTC (permalink / raw)
To: Brian Downing; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <20071202193918.GQ6212@lavos.net>
bdowning@lavos.net (Brian Downing) writes:
> It looks like the "guilty" commit that allowed this behavior was:
>
> commit 13208572fbe8838fd8835548d7502202d1f7b21d
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Sun Nov 11 17:35:58 2007 +0000
>
> builtin-commit: fix --signoff
>
> The Signed-off-by: line contained a spurious timestamp. The reason was
> a call to git_committer_info(1), which automatically added the
> timestamp.
>
> Instead, fmt_ident() was taught to interpret an empty string for the
> date (as opposed to NULL, which still triggers the default behavior)
> as "do not bother with the timestamp", and builtin-commit.c uses it.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> With the above, something like:
>
> echo msg | GIT_AUTHOR_DATE='' git commit-tree sha1
>
> will produce a broken commit without a timestamp, since fmt_ident is
> also used for the committer and author lines.
>
> Personally, I think if the date_str is not NULL, it should die() on
> anything that can't successfully be parsed as a date, rather than simply
> falling back to the current time. But maybe that's a bit extreme.
Yeah, that change does look like a hack now we look at it again. It
would have been much cleaner to make the caller accept the default
behaviour of fmt_ident() and strip out the part it does not want from
the result. That way, the damage would have been much contained.
The next issue would be to find who could pass an empty GIT_AUTHOR_DATE
without noticing...
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Linus Torvalds @ 2007-12-02 20:34 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <20071202193918.GQ6212@lavos.net>
On Sun, 2 Dec 2007, Brian Downing wrote:
>
> With the above, something like:
>
> echo msg | GIT_AUTHOR_DATE='' git commit-tree sha1
>
> will produce a broken commit without a timestamp, since fmt_ident is
> also used for the committer and author lines.
Ouch. And I notice that fsck doesn't even warn about the resulting broken
commit. Partly because I was lazy, but partly because originally I was
thinking that maybe we'll have more header lines, so fsck basically just
checks the ones that git *really* cares about (parenthood and tree), and
the rest is not really even looked at (well, it does check that the next
line starts with "author", but that's it).
I guess the breakage is pretty benign, but this is still very wrong.
Junio: that broken commit seems to be in "pu" only - we should make sure
that it never makes it into next or master, so that it will eventually get
pruned out of history.
Linus
^ permalink raw reply
* [PATCH] contrib: Make remotes2config.sh script more robust
From: Jakub Narebski @ 2007-12-02 19:40 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Jakub Narebski
The remotes2config.sh script replaced all 'unsafe' characters in repo
name with '.'; include '-' in the 'safe' characters set (the set is
probably even larger).
Script required also space after "URL:", "Push:" and "Pull:" in
remotes file. This for example made the following remote
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull:+refs/heads/pu:refs/heads/pu
miss 'pu' branch (forced branch) in config file after conversion.
Allow for any number of whitespace after "URL:", "Push:", "Pull:".
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
contrib/remotes2config.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
mode change 100644 => 100755 contrib/remotes2config.sh
diff --git a/contrib/remotes2config.sh b/contrib/remotes2config.sh
old mode 100644
new mode 100755
index 5838b3a..1cda19f
--- a/contrib/remotes2config.sh
+++ b/contrib/remotes2config.sh
@@ -11,11 +11,11 @@ if [ -d "$GIT_DIR"/remotes ]; then
{
cd "$GIT_DIR"/remotes
ls | while read f; do
- name=$(printf "$f" | tr -c "A-Za-z0-9" ".")
+ name=$(printf "$f" | tr -c "A-Za-z0-9-" ".")
sed -n \
- -e "s/^URL: \(.*\)$/remote.$name.url \1 ./p" \
- -e "s/^Pull: \(.*\)$/remote.$name.fetch \1 ^$ /p" \
- -e "s/^Push: \(.*\)$/remote.$name.push \1 ^$ /p" \
+ -e "s/^URL:[ ]*\(.*\)$/remote.$name.url \1 ./p" \
+ -e "s/^Pull:[ ]*\(.*\)$/remote.$name.fetch \1 ^$ /p" \
+ -e "s/^Push:[ ]*\(.*\)$/remote.$name.push \1 ^$ /p" \
< "$f"
done
echo done
--
1.5.3.6
^ permalink raw reply related
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Brian Downing @ 2007-12-02 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <7vir3hx70y.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 02, 2007 at 10:53:33AM -0800, Junio C Hamano wrote:
> Yeah, I was wondering what that commit that records the change older
> than git or myself come to life ;-)
>
> I did rewrite the commit a few times, and it was some interaction
> between the built-in commit series, git-rebase -i and git-am, but I do
> not have the details, sorry.
It looks like the "guilty" commit that allowed this behavior was:
commit 13208572fbe8838fd8835548d7502202d1f7b21d
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Sun Nov 11 17:35:58 2007 +0000
builtin-commit: fix --signoff
The Signed-off-by: line contained a spurious timestamp. The reason was
a call to git_committer_info(1), which automatically added the
timestamp.
Instead, fmt_ident() was taught to interpret an empty string for the
date (as opposed to NULL, which still triggers the default behavior)
as "do not bother with the timestamp", and builtin-commit.c uses it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the above, something like:
echo msg | GIT_AUTHOR_DATE='' git commit-tree sha1
will produce a broken commit without a timestamp, since fmt_ident is
also used for the committer and author lines.
Personally, I think if the date_str is not NULL, it should die() on
anything that can't successfully be parsed as a date, rather than simply
falling back to the current time. But maybe that's a bit extreme.
-bcd
^ permalink raw reply
* Re: [PATCH 1/3] git-help: add -i|--info option to display info page.
From: Pascal Obry @ 2007-12-02 8:54 UTC (permalink / raw)
To: Christian Couder
Cc: Junio Hamano, git, Theodore Tso, Jakub Narebski, Alex Riesen,
Andreas Ericsson, Matthieu Moy, Eric Wong
In-Reply-To: <20071202060740.269e54ad.chriscool@tuxfamily.org>
Christian Couder a écrit :
> "git help --info XXX" will now call "info git-XXX".
If would be nice if this could be more generic. For example I'd like to
use Emacs woman mode instead of info. Can't we have something like
$ git help --ext XXX
"ext" standing for external and calling whatever command recorded into
.gitconfig for example ?
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Junio C Hamano @ 2007-12-02 19:15 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071201064916.GA7431@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> And maybe something like this on top for git-status?
>
> diff --git a/wt-status.c b/wt-status.c
> index 0e0439f..e77120d 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -250,6 +250,7 @@ static void wt_status_print_updated(struct wt_status *s)
> rev.diffopt.format_callback_data = s;
> rev.diffopt.detect_rename = 1;
> rev.diffopt.rename_limit = 100;
> + rev.diffopt.break_opt = 0;
> wt_read_cache(s);
> run_diff_index(&rev, 1);
> }
I have to wonder how much this is going to make things worse in the real
world, although I agree in the "as we already spend cycles for
detect_rename why not" sense.
With the recent change from Alex not to run status when not interactive,
it probably does not matter. If we are going to spawn an editor, we are
dealing with human interaction and even -B -M should not be too bad.
^ permalink raw reply
* Re: [PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Junio C Hamano @ 2007-12-02 19:06 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, dzwell, peff, Matthieu.Moy
In-Reply-To: <5B4BC281-10BD-437F-A956-EEB73F40A76C@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Unless by "documentation" you meant to somehow expose these in the
> interface at runtime... something like this? (applied on top of the
> patch I just sent to the list):
I did not recall (and was too lazy to check) if they were documented
already, but as you suggest, I think letting people type ? at the prompt
to get a help is always a good idea. So, instead of doing this part:
> @@ -308,7 +309,7 @@ sub list_and_choose {
> print "> ";
> }
> else {
> - print ">> ";
> + print " (?)>> ";
I'd prefer accepting '?' as a valid "help me" input and showing
appropriate help for _both_ singleton select and multiple select,
without mentioning " (?)". For this, your prompt_help_cmd needs to be
enhanced to limit the help to singleton case, though.
^ permalink raw reply
* Re: git + unison
From: J. Bruce Fields @ 2007-12-02 19:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqd4tpgepj.fsf@bauges.imag.fr>
On Sun, Dec 02, 2007 at 06:59:36PM +0100, Matthieu Moy wrote:
> What about you? What do you use to synchronize your laptop and
> desktop, or home and office? Anybody using unison and git on the same
> filesystem?
I just have a subdirectory of my home directory "local" that I tell
unison not to synchronize:
ignore = Path local
and keep all my git repos there, relying on git itself when I need to
distribute stuff--generally all my repos are associated with public
repos on a single (regularly backed-up) server, and I try not to let any
work accumulate in any particular repository for long without being
pushed to a branch in its public repo.
--b.
^ permalink raw reply
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Junio C Hamano @ 2007-12-02 18:53 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <5F1A20CC-7427-4E7A-AB95-E89C9FA17951@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> I'd like to conclude with some questions:
> - Is this commit corrupted?
> - How was the commit created?
> - Should "git fsck" detect such corruption?
> - Should gitk more gracefully handle corrupted commits?
Yeah, I was wondering what that commit that records the change older
than git or myself come to life ;-)
I did rewrite the commit a few times, and it was some interaction
between the built-in commit series, git-rebase -i and git-am, but I do
not have the details, sorry.
^ permalink raw reply
* Re: Difference in how "git status" and "git diff --name-only" lists filenames
From: Junio C Hamano @ 2007-12-02 18:44 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git
In-Reply-To: <bf7b2dda0712020604x209d6665i9ab58b32834b2cee@mail.gmail.com>
"Gustaf Hendeby" <hendeby@gmail.com> writes:
> A while ago 'git status' was patched to report relative pathnames. (I
> like that change it makes cut'n'paste easier.) However, 'git diff
> --name-only' and 'git diff --name-status' (other commands as well),
> which gives in a sense similar output has not been changed the same
> way. Is this intentionally, or just because no one has stepped up and
> provided a patch? If the difference is to stay, maybe this should be
> reflected in the help texts to avoid any confusion.
The commands output from diff always talks about paths relative to the
tree root, and scripts rely on it. The recent change made exceptions to
the status command. I agree an additional documentation to git-status
would be beneficial.
Having said that, a switch --relative-name might be an option. It could
be argued that doing it the other way around (like --full-name option to
ls-files does), defaulting to relative to cwd, would have been a getter
approach if we were doing git from scratch, though. We may still want
to do so in the longer run, but that would be a huge interface change
that would impact a lot of peoples' scripts.
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 8fd0fc6..b0cb6bc 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -40,6 +40,10 @@ OUTPUT
The output from this command is designed to be used as a commit
template comments, and all the output lines are prefixed with '#'.
+The paths mentioned in the output, unlike many other git commands, are
+made relative to the current directory, if you are working in a
+subdirectory (this is on purpose, to help cutting and pasting).
+
CONFIGURATION
-------------
^ permalink raw reply related
* Re: [PATCH] Adding menu for Emacs git.el
From: Alexandre Julliard @ 2007-12-02 18:42 UTC (permalink / raw)
To: =?utf-8?q?R=C3=A9mi=20Vanicat?=; +Cc: git
In-Reply-To: <87mysvfr7e.dlv@vanicat.homelinux.org>
"=?utf-8?q?R=C3=A9mi=20Vanicat?=" <vanicat@debian.org>, Remi Vanicat
<vanicat@debian.org> writes:
> Adding three menu to the git-status-mode of git.el : One for marking
> and unmarking, one for every thing you need when you have a conflict,
> and a last one for all the rest.
>
> Signed-off-by: Rémi Vanicat <vanicat@debian.org>
It looks good to me. A couple of minor details:
> + ["Interctive Diff File" git-diff-file-idiff t]
There's a typo here.
> + ["Show Uptodate" git-toggle-show-uptodate :style toggle :selected git-show-uptodate]
> + ["Toggle Show Ignored" git-toggle-show-ignored :style toggle :selected git-show-ignored]
> + ["Toggle Show Unknown" git-toggle-show-unknown :style toggle :selected git-show-unknown]))
I'd get rid of 'Toggle' on the last two for consistency.
BTW do you have a copyright assignment for Emacs?
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Junio C Hamano @ 2007-12-02 18:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0712021716220.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I have made several attempts to reproduce the problem, looked a bit
>> through the log-tree code, and checked the results of the t750* series
>> of tests; but I have found nothing.
>
> I remember again. When I did "commit -s -m bla" the empty line between
> the oneline and the signoff would be missing. But in the meantime, the
> signoff was dragged into the strbuf and all is well.
Sorry, now I am confused. Building the version before that change and
doing "./git-commit -a -s -m bla", I do not see the extra blank line in
the "Created commit" response, and I see a blank line before and after
the sign-off in the "git show" output for the resulting commit.
Was this unnecessary change from the beginning? I am inclined to think
so...
^ permalink raw reply
* Re: git + unison
From: Remi Vanicat @ 2007-12-02 18:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqd4tpgepj.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Hi,
>
[...]
Note that I do use I do use both unison and git, but I don't use
unison on git repository (I use git to synchronize git repository).
> So, at the moment, I have both unison and git. My fear is that unison
> touches the content of the .git/ directories. So, for example, if I
> commit on one side, and commit something else on the other side, I'll
> get unison conflicts at least on .git/refs/heads/master and
> .git/index, and resolving the conflict in favor of either side leads
> to dangling objects whith important content.
Well, at least with my configuration, when a file have been change on
both side, unison offer the possibility to transfer one way or the
other or to do nothing. I believe that if this happen, the correct
procure is to use git tool to merge (as git is better for merging
than unison, even more when we are speaking about git repository)
>
> What I'm doing right now is that I try to make sure I don't run unison
> when trees have diverged, which is not really satisfactory since 1) I
> can be wrong, and a miss-synchronization could lead to data-loss, and
> 2) that means not really taking advantage of unison.
Well, as I've already said, I use unison in an interactive way, so if
a file have been changed in both side, unison say it, ask me what to
do. So I can choose to do nothing, and to stop unison right away to
use a better tool for this task.
--
Rémi Vanicat
^ permalink raw reply
* Re: git-merge --no-commit commits
From: Jakub Narebski @ 2007-12-02 18:00 UTC (permalink / raw)
To: Vegard Nossum; +Cc: git
In-Reply-To: <19f34abd0712020918w1640389kb0ca006b2051a678@mail.gmail.com>
On Sun, 2 Dec 2007, Vegard Nossum wrote:
> On Dec 2, 2007 6:10 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Vegard Nossum" <vegard.nossum@gmail.com> writes:
>>
>>> I am using git 1.5.3.4 and just did the following (v1 and v2 are
>>> branches; v1 is a parent of v2):
>>>
>>> git checkout v1
>>> git merge --no-commit v2
>>>
>>> It simply fast-forwarded AND committed even though I explicitly told
>>> it not to. What gives?
>>
>> The --no-commit option doesn't prevent fast-forward because
>> fast-forward doesn't really _create_ a commit (and -no-commit is
>> really about commit creation). It just advanced ref (branch head).
>>
>> You probably wanted to use
>>
>> $ git merge --no-commit --no-ff v2
>
> Yes. Thanks. Isn't that counter-intuitive, though? The manpage says
> that it lets you review the changes first. I assumed this would
> include fast-forwarding as well.
But for fast-forward there are no "changes" to review. Just updating
branch head. Fast-forward means no new commit.
> There is no --no-ff in my git-merge
> manpage. Maybe I need a newer version?
It looks like it is not in any released version. I've found description
in 'master' version of Documentation/merge-options.txt
--
Jakub Narebski
Poland
^ permalink raw reply
* git + unison
From: Matthieu Moy @ 2007-12-02 17:59 UTC (permalink / raw)
To: git
Hi,
I'm wondering how dangerous the interaction of git with the unison
file synchronizer[1] can be.
Another way of asking the question can be: what's the best way to
keep two machines with many git repositories in sync?
Unison is a userland application that does bi-directional
synchronization of two directories. Typically, to keep a laptop and a
desktop synchronized (modify a file on the desktop and another on the
laptop, unison will copy the files). I find it very usefull to keep
large directories containing unrelated projects (typically,
~/teaching/, ~/research, ..., my colleagues even synchronize $HOME on
their laptops) in sync between two machines.
Actually, git achives something similar (and lot more, of course):
modify a file here, commit, modify another there, commit, and then
push & pull can do the sync. I find git excellent to manage somehow
self-contained projects (~/teaching/2007-2008/whatever-course/), but
inappropriate for $HOME or such big containers (need to run more
commands, disk-space overhead, ...).
So, at the moment, I have both unison and git. My fear is that unison
touches the content of the .git/ directories. So, for example, if I
commit on one side, and commit something else on the other side, I'll
get unison conflicts at least on .git/refs/heads/master and
.git/index, and resolving the conflict in favor of either side leads
to dangling objects whith important content.
What I'm doing right now is that I try to make sure I don't run unison
when trees have diverged, which is not really satisfactory since 1) I
can be wrong, and a miss-synchronization could lead to data-loss, and
2) that means not really taking advantage of unison.
What about you? What do you use to synchronize your laptop and
desktop, or home and office? Anybody using unison and git on the same
filesystem?
Thanks for your hints,
--
Matthieu
[1] : http://www.cis.upenn.edu/~bcpierce/unison/
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-12-02 17:23 UTC (permalink / raw)
To: Pascal Obry
Cc: Wincent Colaiuta, Jeff King, Junio C Hamano, Andreas Ericsson,
Nicolas Pitre, Linus Torvalds, Nguyen Thai Ngoc Duy, Jan Hudec,
git
In-Reply-To: <4752E3D0.6030802@obry.net>
Hi,
On Sun, 2 Dec 2007, Pascal Obry wrote:
> Johannes Schindelin a ?crit :
> > Okay, how many executables are there in your /usr/bin/? Here there
> > are 2973. Guess what. I am not intimidated by that number.
>
> Good, and look in /usr/bin, all those 2973 binary are all disconnected.
>
> Here we are speaking about a tool as a whole : Git.
No, we are speaking about different commands, such as commit, fetch, push,
etc.
I refuse to believe that you cannot see the equivalence.
> I've read many documentations before grabbing the system and I've not
> been impressed by the number of binaries in /usr/bin... Because I've
> almost never looked there.
Exactly my point.
> Most of the time I'm using "git <tab>" and the bash completion feature
> is just right for me.
Bash completion is really something fine.
But even without, I do not see a problem: many cvs users used only three
out of 32 commands (most CVS users I personally know/knew only called add,
commit and update). You could even see all 32 commands when calling the
clunky command line "cvs --help-commands". I am convinced we're already
more user-friendly than that.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] t9600: test cvsimport from CVS working tree
From: Jeff King @ 2007-12-02 17:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This test passes with v1.5.3.7, but not with v1.5.3.6.
Signed-off-by: Jeff King <peff@peff.net>
---
I wrote this to investigate a reported bug (which turned out
to be fixed by the recent cvsimport patches). No bug to fix,
but I think it's a good test to have in general.
t/t9600-cvsimport.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 29fee2d..08f0f2a 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -119,4 +119,16 @@ test_expect_success 'cvsimport.module config works' '
'
+test_expect_success 'import from a CVS working tree' '
+
+ cvs co -d import-from-wt module &&
+ cd import-from-wt &&
+ git cvsimport -a -z0 &&
+ echo 1 >expect &&
+ git log -1 --pretty=format:%s%n >actual &&
+ git diff actual expect &&
+ cd ..
+
+'
+
test_done
--
1.5.3.6.2094.g0ce9a-dirty
^ permalink raw reply related
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Johannes Schindelin @ 2007-12-02 17:18 UTC (permalink / raw)
To: Jeff King; +Cc: git, krh, gitster
In-Reply-To: <20071202165409.GA30998@coredump.intra.peff.net>
Hi,
On Sun, 2 Dec 2007, Jeff King wrote:
> On Sun, Dec 02, 2007 at 12:13:07PM +0000, Johannes Schindelin wrote:
>
> > > It would be helpful if you could remember the test case, but perhaps
> > > that is not an option at this point.
> >
> > IIRC it was "git commit -m bla".
>
> I have made several attempts to reproduce the problem, looked a bit
> through the log-tree code, and checked the results of the t750* series
> of tests; but I have found nothing.
I remember again. When I did "commit -s -m bla" the empty line between
the oneline and the signoff would be missing. But in the meantime, the
signoff was dragged into the strbuf and all is well.
ACK.
Ciao,
Dscho
^ permalink raw reply
* Re: git-merge --no-commit commits
From: Vegard Nossum @ 2007-12-02 17:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3bq99vx7t.fsf@roke.D-201>
On Dec 2, 2007 6:10 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Vegard Nossum" <vegard.nossum@gmail.com> writes:
>
> > I am using git 1.5.3.4 and just did the following (v1 and v2 are
> > branches; v1 is a parent of v2):
> >
> > git checkout v1
> > git merge --no-commit v2
> >
> > It simply fast-forwarded AND committed even though I explicitly told
> > it not to. What gives?
>
> The --no-commit option doesn't prevent fast-forward because
> fast-forward doesn't really _create_ a commit (and -no-commit is
> really about commit creation). It just advanced ref (branch head).
>
> You probably wanted to use
>
> $ git merge --no-commit --no-ff v2
>
Yes. Thanks. Isn't that counter-intuitive, though? The manpage says
that it lets you review the changes first. I assumed this would
include fast-forwarding as well. There is no --no-ff in my git-merge
manpage. Maybe I need a newer version?
> HTH
> --
> Jakub Narebski
> ShadeHawk on #git
> Poland
>
Vegard
^ permalink raw reply
* Re: git-merge --no-commit commits
From: Jakub Narebski @ 2007-12-02 17:10 UTC (permalink / raw)
To: Vegard Nossum; +Cc: git
In-Reply-To: <19f34abd0712020857m757c57cfr358a81e47f38fac8@mail.gmail.com>
"Vegard Nossum" <vegard.nossum@gmail.com> writes:
> I am using git 1.5.3.4 and just did the following (v1 and v2 are
> branches; v1 is a parent of v2):
>
> git checkout v1
> git merge --no-commit v2
>
> It simply fast-forwarded AND committed even though I explicitly told
> it not to. What gives?
The --no-commit option doesn't prevent fast-forward because
fast-forward doesn't really _create_ a commit (and -no-commit is
really about commit creation). It just advanced ref (branch head).
You probably wanted to use
$ git merge --no-commit --no-ff v2
HTH
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: problems with importing from cvs archive
From: Jeff King @ 2007-12-02 17:07 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Ed S. Peschko, git
In-Reply-To: <C4B8CB94-3B39-4C14-9134-DE43684A3AB7@yahoo.ca>
On Sun, Dec 02, 2007 at 10:14:07AM -0500, Jean-François Veillette wrote:
> Le 07-12-02 à 01:46, Ed S. Peschko a écrit :
>
>> All,
>>
>> I'm trying to use git-cvsimport to import from a CVS archive, using:
>>
>> git-cvsimport -d $CVSROOT
>
> I was able to go further just by adding the verbose mode ( -v ) :
> git cvsimport -v -d ...
There were some serious problems with the argument parsing of
git-cvsimport with respect to finding the correct module from the git
config or from your CVS working directory. This should all be fixed in
v1.5.3.7; please let me know if you still have a problem with that
version.
-Peff
^ permalink raw reply
* git-merge --no-commit commits
From: Vegard Nossum @ 2007-12-02 16:57 UTC (permalink / raw)
To: git
Hi,
I am using git 1.5.3.4 and just did the following (v1 and v2 are
branches; v1 is a parent of v2):
git checkout v1
git merge --no-commit v2
It simply fast-forwarded AND committed even though I explicitly told
it not to. What gives?
Kind regards,
Vegard Nossum
^ 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