* Re: [RFC/PATCH] Detailed diagnostic when parsing an object name fails.
From: Matthieu Moy @ 2009-11-30 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtywbkc05.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> $ ../git show HEAD:test-lib.sh
>> fatal: Path 't/test-lib.sh' exists, but not 'test-lib.sh'.
>> Did you mean 'HEAD:t/test-lib.sh'?
>
> The first thought that comes to mind is that if it makes more sense to
> just fall back to the interpretation of the input when the tool has
> already figured out to second guess the intention of the user like the
> above message does.
>
> That would obviously break scripts that try to make sure the _absense_ of
> a path in a tree-ish (or in the index if you lack "HEAD" in your example),
> expecting:
>
> git rev-parse HEAD:test-lib.sh ||
> echo "test-lib.sh shouldn't be at the top level"
There's another (more important IMO) problem: if HEAD contains both
file.txt and subdir/file.txt, then what should
cd subdir
git show HEAD:file.txt
do? Allowing HEAD:file-in-a-subdirectory.txt would indirectly mean
teaching users to use in, and they'd be bitten by an ambiguous
behavior one day or another ...
> Perhaps the second step would be to teach the machinery to understand a
> syntax like "<tree-ish>:./<path>" and have it prefix the path to the
> current subdirectory from the root of the work tree, and with such an
> enhancement, the suggestion given by this patch would probably change to
> "Did you mean 'HEAD:./test-lib.sh'?", but that would be a separate
> topic.
Exactly. I think this HEAD:./relative-path syntax has been discussed
here already, but I don't remember the outcome of the discussion. If
it's ever implemented, my patch, modified as you suggest will help
users to discover the feature ;-).
BTW, I finally had time to write a test. Current version below FYI
(fixed a segfault discovered by testing too), but I'll resend properly
when I get enough feedback.
>From 1bc1c8d114b538f57a5ba4a501436229d644d587 Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Mon, 30 Nov 2009 17:32:39 +0100
Subject: [PATCH] Detailed diagnosis when parsing an object name fails.
The previous error message was the same in many situations (unknown
revision or path not in the working tree). We try to help the user as
much as possible to understand the error, especially with the
sha1:filename notation. In this case, we say whether the sha1 or the
filename is problematic, and diagnose the confusion between
relative-to-root and relative-to-$PWD confusion precisely.
The 6 new error messages are tested.
---
cache.h | 6 ++-
setup.c | 15 +++++-
sha1_name.c | 95 ++++++++++++++++++++++++++++++++++++++--
t/t1506-rev-parse-diagnosis.sh | 67 ++++++++++++++++++++++++++++
4 files changed, 176 insertions(+), 7 deletions(-)
create mode 100755 t/t1506-rev-parse-diagnosis.sh
diff --git a/cache.h b/cache.h
index 0e69384..5c8cb5f 100644
--- a/cache.h
+++ b/cache.h
@@ -708,7 +708,11 @@ static inline unsigned int hexval(unsigned char c)
#define DEFAULT_ABBREV 7
extern int get_sha1(const char *str, unsigned char *sha1);
-extern int get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode);
+static inline get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode)
+{
+ return get_sha1_with_mode_1(str, sha1, mode, 0, NULL);
+}
+extern int get_sha1_with_mode_1(const char *str, unsigned char *sha1, unsigned *mode, int fatal, const char *prefix);
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
extern char *sha1_to_hex(const unsigned char *sha1); /* static buffer result! */
extern int read_ref(const char *filename, unsigned char *sha1);
diff --git a/setup.c b/setup.c
index f67250b..3094e8b 100644
--- a/setup.c
+++ b/setup.c
@@ -74,6 +74,18 @@ int check_filename(const char *prefix, const char *arg)
die_errno("failed to stat '%s'", arg);
}
+static void NORETURN die_verify_filename(const char *prefix, const char *arg)
+{
+ unsigned char sha1[20];
+ unsigned mode;
+ /* try a detailed diagnostic ... */
+ get_sha1_with_mode_1(arg, sha1, &mode, 1, prefix);
+ /* ... or fall back the most general message. */
+ die("ambiguous argument '%s': unknown revision or path not in the working tree.\n"
+ "Use '--' to separate paths from revisions", arg);
+
+}
+
/*
* Verify a filename that we got as an argument for a pathspec
* entry. Note that a filename that begins with "-" never verifies
@@ -87,8 +99,7 @@ void verify_filename(const char *prefix, const char *arg)
die("bad flag '%s' used after filename", arg);
if (check_filename(prefix, arg))
return;
- die("ambiguous argument '%s': unknown revision or path not in the working tree.\n"
- "Use '--' to separate paths from revisions", arg);
+ die_verify_filename(prefix, arg);
}
/*
diff --git a/sha1_name.c b/sha1_name.c
index 44bb62d..030e2ac 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -804,7 +804,77 @@ int get_sha1(const char *name, unsigned char *sha1)
return get_sha1_with_mode(name, sha1, &unused);
}
-int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
+static void diagnose_invalid_sha1_path(const char *prefix,
+ const char *filename,
+ const char *tree_sha1,
+ const char *object_name)
+{
+ struct stat st;
+ unsigned char sha1[20];
+ unsigned mode;
+
+ if (!prefix)
+ prefix = "";
+
+ if (!lstat(filename, &st))
+ die("Path '%s' exists on disk, but not in '%s'.",
+ filename, object_name);
+ if (errno == ENOENT || errno == ENOTDIR) {
+ char *fullname = malloc(strlen(filename)
+ + strlen(prefix) + 1);
+ strcpy(fullname, prefix);
+ strcat(fullname, filename);
+
+ if (!get_tree_entry(tree_sha1, fullname,
+ sha1, &mode)) {
+ die("Path '%s' exists, but not '%s'.\n"
+ "Did you mean '%s:%s'?",
+ fullname,
+ filename,
+ object_name,
+ fullname);
+ }
+ die("Path '%s' does not exist in '%s'",
+ filename, object_name);
+ }
+}
+
+static void diagnose_invalid_index_path(int stage,
+ const char *prefix,
+ const char *filename)
+{
+ struct stat st;
+
+ if (!prefix)
+ prefix = "";
+
+ if (!lstat(filename, &st))
+ die("Path '%s' exists on disk, but not in the index.", filename);
+ if (errno == ENOENT || errno == ENOTDIR) {
+ struct cache_entry *ce;
+ int pos;
+ int namelen = strlen(filename) + strlen(prefix);
+ char *fullname = malloc(namelen + 1);
+ strcpy(fullname, prefix);
+ strcat(fullname, filename);
+ pos = cache_name_pos(fullname, namelen);
+ if (pos < 0)
+ pos = -pos - 1;
+ ce = active_cache[pos];
+ if (ce_namelen(ce) == namelen &&
+ !memcmp(ce->name, fullname, namelen))
+ die("Path '%s' is in the index, but not '%s'.\n"
+ "Did you mean ':%d:%s'?",
+ fullname, filename,
+ stage, fullname);
+
+ die("Path '%s' does not exist (neither on disk nor in the index).",
+ filename);
+ }
+}
+
+
+int get_sha1_with_mode_1(const char *name, unsigned char *sha1, unsigned *mode, int fatal, const char *prefix)
{
int ret, bracket_depth;
int namelen = strlen(name);
@@ -850,6 +920,8 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
}
pos++;
}
+ if (fatal)
+ diagnose_invalid_index_path(stage, prefix, cp);
return -1;
}
for (cp = name, bracket_depth = 0; *cp; cp++) {
@@ -862,9 +934,24 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
}
if (*cp == ':') {
unsigned char tree_sha1[20];
- if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1,
- mode);
+ char *object_name;
+ if (fatal) {
+ object_name = malloc(cp-name+1);
+ strncpy(object_name, name, cp-name);
+ object_name[cp-name] = '\0';
+ }
+ if (!get_sha1_1(name, cp-name, tree_sha1)) {
+ const char *filename = cp+1;
+ ret = get_tree_entry(tree_sha1, filename, sha1, mode);
+ if (fatal)
+ diagnose_invalid_sha1_path(prefix, filename,
+ tree_sha1, object_name);
+
+ return ret;
+ } else {
+ if (fatal)
+ die("Invalid object name '%s'.", object_name);
+ }
}
return ret;
}
diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh
new file mode 100755
index 0000000..8112d56
--- /dev/null
+++ b/t/t1506-rev-parse-diagnosis.sh
@@ -0,0 +1,67 @@
+#!/bin/sh
+
+test_description='test git rev-parse diagnosis for invalid argument'
+
+exec </dev/null
+
+. ./test-lib.sh
+
+HASH_file=
+
+test_expect_success 'set up basic repo' '
+ echo one > file.txt &&
+ mkdir subdir &&
+ echo two > subdir/file.txt &&
+ echo three > subdir/file2.txt &&
+ git add . &&
+ git commit -m init &&
+ echo four > index-only.txt &&
+ git add index-only.txt &&
+ echo five > disk-only.txt
+'
+
+test_expect_success 'correct file objects' '
+ HASH_file=$(git rev-parse HEAD:file.txt) &&
+ git rev-parse HEAD:subdir/file.txt &&
+ git rev-parse :index-only.txt &&
+ cd subdir &&
+ git rev-parse HEAD:file.txt &&
+ git rev-parse HEAD:subdir/file2.txt &&
+ test $HASH_file = $(git rev-parse HEAD:file.txt) &&
+ test $HASH_file = $(git rev-parse :file.txt) &&
+ test $HASH_file = $(git rev-parse :0:file.txt) &&
+ cd ..
+'
+
+test_expect_success 'incorrect revision id' '
+ test_must_fail git rev-parse foobar:file.txt 2>&1 |
+ grep "Invalid object name '"'"'foobar'"'"'." &&
+ test_must_fail git rev-parse foobar 2>&1 |
+ grep "unknown revision or path not in the working tree."
+'
+
+test_expect_success 'incorrect file in sha1:path' '
+ test_must_fail git rev-parse HEAD:nothing.txt 2>&1 |
+ grep "fatal: Path '"'"'nothing.txt'"'"' does not exist in '"'"'HEAD'"'"'" &&
+ test_must_fail git rev-parse HEAD:index-only.txt 2>&1 |
+ grep "fatal: Path '"'"'index-only.txt'"'"' exists on disk, but not in '"'"'HEAD'"'"'." &&
+ cd subdir &&
+ test_must_fail git rev-parse HEAD:file2.txt 2>&1 |
+ grep "Did you mean '"'"'HEAD:subdir/file2.txt'"'"'?" &&
+ cd ..
+'
+
+test_expect_success 'incorrect file in :path and :0:path' '
+ test_must_fail git rev-parse :nothing.txt 2>&1 |
+ grep "fatal: Path '"'"'nothing.txt'"'"' does not exist (neither on disk nor in the index)." &&
+ test_must_fail git rev-parse :1:nothing.txt 2>&1 |
+ grep "Path '"'"'nothing.txt'"'"' does not exist (neither on disk nor in the index)." &&
+ cd subdir &&
+ test_must_fail git rev-parse :file2.txt 2>&1 |
+ grep "Did you mean '"'"':0:subdir/file2.txt'"'"'?" &&
+ cd .. &&
+ test_must_fail git rev-parse :disk-only.txt 2>&1 |
+ grep "fatal: Path '"'"'disk-only.txt'"'"' exists on disk, but not in the index."
+'
+
+test_done
--
1.6.6.rc0.256.g6060
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply related
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Brandon Casey @ 2009-11-30 21:17 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Sverre Rabbelier, git
In-Reply-To: <20091130205453.GA20348@coredump.intra.peff.net>
Jeff King wrote:
> On Mon, Nov 30, 2009 at 12:07:40PM -0600, Brandon Casey wrote:
>> ps. There's something eerily familiar about this patch.
>
> Hmmm. Yes, I didn't search before writing it, but you probably mean:
>
> http://article.gmane.org/gmane.comp.version-control.git/127172
:) yeah, that was it, nbd.
> But that is missing the NO-PYTHON bit in GIT-BUILD-OPTIONS (did you
> forget it there, or was it part of some other patch that also didn't get
> applied?).
It was 1/2 of that series.
> Also, I am tempted to move the GIT-BUILD-OPTIONS invocation _up_. It
> is about reading config and should probably come before we start doing
> _anything_.
>
> So maybe this instead:
<snip the patch>
Looks fine to me.
No strong opinion on whether the BUILD-OPTIONS thing should be
at the beginning of the script, or in the place where you placed
it.
-brandon
^ permalink raw reply
* Re: "git merge" merges too much!
From: Dmitry Potapov @ 2009-11-30 21:17 UTC (permalink / raw)
To: The Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <m1NFBAx-000kmgC@most.weird.com>
On Mon, Nov 30, 2009 at 01:40:38PM -0500, Greg A. Woods wrote:
>
> While it may be quite convenient in small projects to quickly move a
> single working directory from one branch to another and do various
> builds and tests from the result, large projects (say where a compile
> takes the better part of a working day or more and where testing
> requires multi-day processes) demand that working directories remain
> "stable", and multiple lines of development therefore demand multiple
> working directories.
It depends on the project and what tools are used, but using ccache and
proper dependencies help a lot to reduce the cost of switching. In fact,
it may be faster to switch to another branch and have to recompile a few
files than to go into another working directory, because when you go to
another working directory, you hit cold cache and things get very slow.
And then if a project is huge and takes a lot of time to compile and
test everything, I do not think, it is a good idea to build that in your
work tree. Instead, you make a shanshot using git-archive and then run
full build and test on it. In this way, you know that you test exactly
what you have committed (you can amend any commit later until you
publish it).
Dmitry
^ permalink raw reply
* [PATCH/RFC] Add a --bouquet option to git rev-list
From: Nathan W. Panike @ 2009-11-30 20:55 UTC (permalink / raw)
To: git
Add a command line option to rev-list so the command 'git rev-list --bouquet'
shows all revisions that are ancestors of refs which share history with HEAD.
Signed-off-by: Nathan W. Panike <nathan.panike@gmail.com>
---
I have a repository with the following structure:
B
/
A'--A--C
\
D
E'--E
Thus the command 'git merge base E A' returns nothing, as there is no common
history. The E history contains stuff that is derived from the other history
(A, B, C, or D). Often I find myself doing the following:
git checkout C
gitk $(include_forks) &
<View history, make changes, merges, et cetera>
git checkout E
<go back to gitk, only see history for B, C, etc>
Now the 'include_forks' command is a bash function in my .bashrc:
include_forks ()
{
local head="$(git show -s --pretty=format:'%H' HEAD)";
echo "HEAD $(git for-each-ref --format='%(refname)' \
refs/heads refs/remotes | while read ref; do \
if test "$(git merge-base HEAD ${ref}^{commit})" != ""; \
then echo ${ref}; fi; done)"
}
The shell thus intercepts my command and I must restart gitk to see the history
of E.
With this patch, I can issue the command 'gitk --bouquet' and when I checkout
E, I can 'reload' in gitk and see the history of E automatically.
If there is an easier way to do this in git, please let me know. Otherwise,
please let me know how to improve this patch.
revision.c | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index a8a3c3a..ba367cc 100644
--- a/revision.c
+++ b/revision.c
@@ -699,6 +699,31 @@ static int handle_one_ref(const char *path, const unsigned char *sha1, int flag,
return 0;
}
+static int handle_one_connected_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct all_refs_cb *cb = cb_data;
+ struct object *object = get_reference(cb->all_revs, path, sha1,
+ cb->all_flags);
+ struct commit *r;
+ static int got_head = 1;
+ static struct commit *head_commit;
+ static int head_nr = 0;
+ if(got_head) {
+ got_head=head_ref(handle_one_ref,cb);
+ if(got_head)
+ return 1;
+ if(cb && cb->all_revs && cb->all_revs->pending.nr > 0) {
+ head_nr = cb->all_revs->pending.nr - 1;
+ head_commit = (struct commit*)&cb->all_revs->pending.objects->item[head_nr];
+ }
+ }
+ r = lookup_commit_reference_gently(sha1,1);
+ if(r != NULL && head_commit)
+ if(get_merge_bases_many(head_commit,1,&r,1))
+ add_pending_object(cb->all_revs, object, path);
+ return 0;
+}
+
static void handle_refs(struct rev_info *revs, unsigned flags,
int (*for_each)(each_ref_fn, void *))
{
@@ -708,6 +733,15 @@ static void handle_refs(struct rev_info *revs, unsigned flags,
for_each(handle_one_ref, &cb);
}
+static void handle_connected_refs(struct rev_info *revs, unsigned flags,
+ int (*for_each)(each_ref_fn, void *))
+{
+ struct all_refs_cb cb;
+ cb.all_revs = revs;
+ cb.all_flags = flags;
+ for_each(handle_one_connected_ref, &cb);
+}
+
static void handle_one_reflog_commit(unsigned char *sha1, void *cb_data)
{
struct all_refs_cb *cb = cb_data;
@@ -1352,6 +1386,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
handle_refs(revs, flags, for_each_remote_ref);
continue;
}
+ if (!strcmp(arg, "--bouquet")) {
+ handle_connected_refs(revs, flags, for_each_ref);
+ continue;
+ }
if (!strcmp(arg, "--reflog")) {
handle_reflog(revs, flags);
continue;
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH] reset: add --quiet option
From: Stephen Boyd @ 2009-11-30 21:45 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530911300219j51e21e2cwae17d4248400a345@mail.gmail.com>
On Mon, Nov 30, 2009 at 2:19 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> I thought somebody would complain about loosing that string. In any
> case, first step is adding --query to 'git reset', second step is
> moving all OPT_BOOLEAN('q' to OPT__QUIET; there are other commands
> doing the same.
>
If you're already touching the line why not just do it once? I agree a
follow-up patch to cover the other commands would be good.
^ permalink raw reply
* Re: equal-tree-merges as way to make rebases fast-forward-able
From: Nanako Shiraishi @ 2009-11-30 22:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bernhard R. Link, git
In-Reply-To: <7v8wdnooza.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> To avoid that, I think (1) the marker has to be more reliable than just
> "happens to have the same tree", and (2) the traversal done by Porcelains
> (your patches 3 thru 5) by default should be unaware of eqt.
>
> I don't know what a suitable marker should look like, though. The marker
> must be easily identifiable by the lowest level rev-list machinery, so it
> needs to be a sign left somewhere in the commit object. Perhaps making it
> require to have the same tree as all its parents _and_ a well-known marker
> string in the log message (and nothing else) would be a good start.
I think you can record a merge commit that has an unusual
list of parents for this. For example, you can record the
latest version twice, as the first and the second parents,
and make the previous version the third parent. Because
such a merge can't be created with git-merge command, you
can reliably tell that it is an unusual 'marker' merge.
No matter what techinique is used to mark the special
'marker', if it happens in real life for two or more people
who worked independantly to arrive at the same conclusion,
I don't think dismissing it as 'by chance' and discarding
the contribution from the second branch is a good solution.
If git is meant to work smoothly in projects where more than
one person see and accept patches from the same origin, the
condition is not met 'by chance'; the tool is by design
supposed to handle it as a regular situation.
On the other hand, if you made the marker reliable, I think
you don't have to disable this feature by default like you
said in your (2).
As a side note, I have a bug to report. I tried this sequence
of commands to make sure git-merge doesn't record the same
parent twice (the last git-merge is made on the slave branch
and tries to have slave, master and slave as its three
parents).
% git init
% echo hello >world
% git add . ; git commit -m first
% echo again >world
% git commit -a -m master
% git checkout -b slave master^
% echo again >world
% git commit -a -m slave
% git merge master slave
But I got the "usage: ..." error message from git-merge.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Johan Herland @ 2009-11-30 22:31 UTC (permalink / raw)
To: Jeff King; +Cc: git, Brandon Casey, Junio C Hamano, Sverre Rabbelier
In-Reply-To: <tzCtKYIbFlbIbn30IPnqgVxpN1o3NxDP88NXFHHufBYXMjZJIG1Gyw@cipher.nrlssc.navy.mil>
On Monday 30 November 2009, Brandon Casey wrote:
> Jeff King wrote:
> > On Mon, Nov 30, 2009 at 12:07:40PM -0600, Brandon Casey wrote:
> >> ps. There's something eerily familiar about this patch.
> >
> > Hmmm. Yes, I didn't search before writing it, but you probably mean:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/127172
> >
> :) yeah, that was it, nbd.
Oops. I got Brandon's patches in my local tree, but I never got around to
resend the series until Sverre picked up and refactored it. Sorry for the
screwup.
> > But that is missing the NO-PYTHON bit in GIT-BUILD-OPTIONS (did you
> > forget it there, or was it part of some other patch that also didn't
> > get applied?).
>
> It was 1/2 of that series.
Indeed.
> > Also, I am tempted to move the GIT-BUILD-OPTIONS invocation _up_. It
> > is about reading config and should probably come before we start doing
> > _anything_.
> >
> > So maybe this instead:
>
> <snip the patch>
>
> Looks fine to me.
As with Brandon's original patch, this is of course
Acked-by: Johan Herland <johan@herland.net>
> No strong opinion on whether the BUILD-OPTIONS thing should be
> at the beginning of the script, or in the place where you placed
> it.
Me neither.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Git open calls fail on NFS-mounted NTFS volume
From: Kai Lanz @ 2009-11-30 23:09 UTC (permalink / raw)
To: git
There are several places in the code where git calls open() with the
flag
O_EXCL. This causes a problem for us when the current directory is on an
NFS-mounted NTFS volume shared by an NAS fileserver. The open fails with
"EACCES: Permission denied", even though the user has full read/write
permissions on the target directory.
I used a tiny C program to confirm that the O_EXCL flag is the culprit;
removing that flag from the open() call allows the open to succeed. Of
course, the call also succeeds, with the O_EXCL flag in place, if the
current directory is on an NFS-mounted UNIX filesystem.
We're looking into ways to work around this; one way would be to hack
the git
source and remove all the O_EXCL flags (are they really needed?), but
I'm
afraid that might break git in horrible ways. Another way might be to
mount
the NTFS volume via CIFS instead of NFS. But first I wanted to ask if
anyone
here can offer a solution based on changing our git configuration or
our NFS
mount options or the NTFS volume settings. (At present we have no
gitconfig
file, so all settings are default).
Git version is 1.6.5.3, running on x86_64 RHEL-4, kernel 2.6.9-89.
The error
the user sees is:
> cd /WWW
> git init
fatal: cannot copy '/usr/local/share/git-core/templates/info/exclude' to
'/WWW/.git/info/exclude': Permission denied
Using strace, we can see the offending call:
open("/WWW/.git/info/exclude", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1
EACCES
(Permission denied)
We know the user has permission to create this file because he can cd
into
/WWW/.git/info and copy exclude there from the templates directory by
hand.
--
Kai Lanz Stanford University School of Earth Sciences
^ permalink raw reply
* [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-11-30 23:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jay Soffian, git, Bert Wesarg
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
builtin-remote.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 7916626..bb72e27 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -272,7 +272,9 @@ static int get_ref_states(const struct ref *remote_refs, struct ref_states *stat
die("Could not get fetch map for refspec %s",
states->remote->fetch_refspec[i]);
- states->new.strdup_strings = states->tracked.strdup_strings = 1;
+ states->new.strdup_strings =
+ states->tracked.strdup_strings =
+ states->stale.strdup_strings = 1;
for (ref = fetch_map; ref; ref = ref->next) {
unsigned char sha1[20];
if (!ref->peer_ref || read_ref(ref->peer_ref->name, sha1))
@@ -768,7 +770,7 @@ static void clear_push_info(void *util, const char *string)
static void free_remote_ref_states(struct ref_states *states)
{
string_list_clear(&states->new, 0);
- string_list_clear(&states->stale, 0);
+ string_list_clear(&states->stale, 1);
string_list_clear(&states->tracked, 0);
string_list_clear(&states->heads, 0);
string_list_clear_func(&states->push, clear_push_info);
--
1.6.6.rc0.253.g1ec3
^ permalink raw reply related
* Re: [PATCH 1/6] stg mail: Refactor __send_message and friends
From: Alex Chiang @ 2009-11-30 23:58 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <4B123B48.4050405@treskal.com>
* Karl Wiberg <kha@treskal.com>:
> Alex Chiang wrote:
>
>> + if (smtppassword and not smtpuser):
>> + raise CmdException, 'SMTP password supplied, username needed'
>> + if (smtpusetls and not smtpuser):
>> + raise CmdException, 'SMTP over TLS requested, username needed'
>
> Python style nit: Use "raise Exception('message')" in new code. (And
> yes, I know you just moved these lines around.)
Changed, thanks.
^ permalink raw reply
* Re: [PATCH 3/6] stg mail: make __send_message do more
From: Alex Chiang @ 2009-11-30 23:59 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0911291323l35cb3624td3cbc393bf4513b3@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
>
> > Factor out the common code required to send either a cover mail
> > or patch, and implement it in __send_message.
>
> Nice code size reduction.
Thanks.
> > + msg_id = email.Utils.make_msgid('stgit')
> > + build = { 1: __build_cover, 4: __build_message }
> > + msg = build[len(args)](tmpl, msg_id, options, *args)
> > +
> > + from_addr, to_addrs = __parse_addresses(msg)
> > + msg_str = msg.as_string(options.mbox)
> > + if options.mbox:
> > + out.stdout_raw(msg_str + '\n')
> > + return msg_id
> > +
> > + outstr = { 1: 'the cover message', 4: 'patch "%s"' % args[0] }
> > + out.start('Sending ' + outstr[len(args)])
>
> You could consolidate the two dictionaries like this, to avoid making
> the same choice twice and make the code more pleasant to read:
>
> (build, outstr) = { 1: (__build_cover, 'the cover message'), 4:
> (__build_message, 'patch "%s"' % args[0]) }
Hm, I don't think that's valid. I ended up doing something like
this:
d = { 'cover': (__build_cover, 'the cover message'),
'patch': (__build_message, 'patch "%s"' % args[0]) }
(build, outstr) = d[type]
> > + # give recipients a chance of receiving related patches in correct order
> > + # patch_nr < total_nr
> > + if len(args) == 1 or (len(args) == 4 and args[1] < args[2]):
> > + sleep = options.sleep or config.getint('stgit.smtpdelay')
> > + time.sleep(sleep)
>
> Hmm. I must say I find all the args[x] a bit hard to read. I'd prefer
> symbolic names.
Ok, I changed this up.
Thanks for the review.
/ac
^ permalink raw reply
* Re: [PATCH 5/6] stg mail: add basic support for git send-email
From: Alex Chiang @ 2009-12-01 0:00 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0911291354m674d3698m929a1d542a59ed9f@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
>
> > + # XXX: yuck, there's gotta be a more pythonic way. Ideally we'd like
> > + # to use the git_opts dictionary as our mapping between stg mail and
> > + # git send-email; extract k, v pairs from git_opts, and use those
> > + # to iterate across options somehow.
> > + git_opts = { 'to': '--to=', 'cc': '--cc=', 'bcc': '--bcc=' }
> > + if options.to:
> > + for a in options.to:
> > + cmd.append("--to=%s" % a)
> > + if options.cc:
> > + for a in options.cc:
> > + cmd.append("--cc=%s" % a)
> > + if options.bcc:
> > + for a in options.bcc:
> > + cmd.append("--bcc=%s" % a)
> > + if not options.auto:
> > + cmd.append("--suppress-cc=body")
>
> Like this?
>
> for x in ['to', 'cc', 'bcc']:
> if getattr(options, x):
> cmd.extend('--%s=%s' % (x, a) for a in getattr(options, x))
Yeah, that looks nice. Re-implemented with your suggestion.
> > + (fd, path) = mkstemp()
> > + os.write(fd, msg.as_string(options.mbox))
> > + os.close(fd)
> > +
> > + try:
> > + cmd.append(path)
> > + call(cmd)
> > + except Exception, err:
> > + os.unlink(path)
> > + raise CmdException, str(err)
> > +
> > + os.unlink(path)
>
> To avoid having to remember to call unlink in all paths, you can write
>
> try:
> try:
> cmd.append(path)
> call(cmd)
> except Exception, e:
> raise CmdException(str(e))
> finally:
> os.unlink(path)
>
> (The combined try...except...finally statement didn't appear until
> python 2.5, but we'd like to stay compatible with 2.4.)
This statement confuses me a bit. The way I read it, I shouldn't
use your suggestion due to compat reasons?
Thanks,
/ac
^ permalink raw reply
* Re: [StGit RFC PATCH 0/6] add support for git send-email
From: Alex Chiang @ 2009-12-01 0:02 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0911291405i6f052216q8717c34063320592@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
>
> > stg mail still has some nice features over git send-email, such
> > as the -v command line parameter and --prefix. Maybe at some point
> > in the future, we can migrate those features into git send-email and
> > continue thinning out stg mail.
>
> Yes. But note that we tend to be conservative and not require a
> too-new git, so a patch adding such a dependency would have to wait a
> while. (I'm currently carrying two such patches in my experimental
> branch.)
Understood. For now, of course, all the changes that I'm
proposing should work with bog-standard, oldish git, since I
don't think the git send-email interface has changed in a while.
> > But I wanted to get some feedback first to make sure I'm going in the
> > right direction before going too much further.
>
> I've read the patches, and it looks about right from where I stand.
Thank you very much for the review.
> Did you remember to run the regression tests? It's very helpful when
> reviewing to know that the regression suite passes at every point in
> the series.
Good idea. I've been running t/t1900-mail.sh at each stage since
my changes seem rather localized to sending mail.
Should I be running the entire suite?
/ac
^ permalink raw reply
* Re: help reverting a merge
From: Justin P. Mattock @ 2009-12-01 0:06 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Couder, git
In-Reply-To: <20091130081315.GA587@coredump.intra.peff.net>
First things first is I owe you a great thanks
for teaching me how to do a rebase.. :-)
took a while, and still a bit confusing
but I managed to do exactly what you
had written down.
bad thing is somehow the bisect came up
with no results. probably will do another bisect,
just to make sure things are in the right
direction, and the try the rebase again.
Again Thanks for the help/info on this.
Justin P. Mattock
^ permalink raw reply
* Re: equal-tree-merges as way to make rebases fast-forward-able
From: Junio C Hamano @ 2009-12-01 0:20 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Bernhard R. Link, git
In-Reply-To: <20091201071234.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I think you can record a merge commit that has an unusual
> list of parents for this. For example, you can record the
> latest version twice, as the first and the second parents,
> and make the previous version the third parent. Because
> such a merge can't be created with git-merge command, you
> can reliably tell that it is an unusual 'marker' merge.
That's too ugly a hack, and hints an undesirable attitude that this will
be the last feature that needs such cleverness, without leaving the door
open for others who need similar "magic marker" capability added to commit
objects. The approach will not scale, unless you consider "first and
second parents being the same means it is 'rebased branches magic', and
first, second and third parents being the same means some other matic,
etc." as scalable.
As I said, if the approach this series takes turns out to be useful, it is
Ok to implement it as a new header in the commit object if necessary.
We try very hard to avoid adding random headers to commits because a
commit that records the same history should be named the same way in the
object store namespace and adding random headers will make it easier to
create the same commit with different names, but what we are discussing
is a special purpose pseudo commit and it _is_ a feature that the object
name of a commit, after SHA-1 hashing, is different with and without the
special header in this case.
> No matter what techinique is used to mark the special
> 'marker', if it happens in real life for two or more people
> who worked independantly to arrive at the same conclusion,
> I don't think dismissing it as 'by chance' and discarding
> the contribution from the second branch is a good solution.
> If git is meant to work smoothly in projects where more than
> one person see and accept patches from the same origin, the
> condition is not met 'by chance'; the tool is by design
> supposed to handle it as a regular situation.
I said the same thing, and I agree that two (or more) people creating the
same state should be treated as a normal event. But I am not so sure
about a merge that binds two such histories together. The person who
makes such a merge can go on without making one as far as tree-state is
concerned (i.e. such a merge will result in the same tree with both
parents), and the _only_ reason a merge between the two branches is
created is to cauterize one (or both) of the branches, declare that
everything that happened in the branch is now part of this branch.
In other words, such a merge is an operation to purely affect the history
and not contents.
As J6t pointed out, when we tell the revision walking machinery to limit
by path, we already simplify the history we show to the user, and if path
happens to name the whole tree, such a history is already simplified to
show only one side of the story. So perhaps it is not as grave an offence
to ignore contribution from one side when both of the parents of a merge
record the same tree as I originally thought. It also justifies not
introducing a new header in commits. The implementation of Bernhard's
series might become simpler if it used the trick to use "." pathspec
internally instead of introducing a new traversal option to the revision
machinery.
> On the other hand, if you made the marker reliable, I think
> you don't have to disable this feature by default like you
> said in your (2).
That is true, but as you may be able to tell, I am undecided if the marker
should be _that_ explicit, or should be implicit and the fact that a merge
that whose all parents have the same tree should make it automatically a
marker (iow, I earlier said "misidentify" but now I am wondering if it
makes sense to define any merge with the property an "alternative history
binding marker", no matter how it was created).
> As a side note, I have a bug to report. I tried this sequence
> of commands to make sure git-merge doesn't record the same
> parent twice (the last git-merge is made on the slave branch
> and tries to have slave, master and slave as its three
> parents).
>
> % git init
> % echo hello >world
> % git add . ; git commit -m first
> % echo again >world
> % git commit -a -m master
> % git checkout -b slave master^
> % echo again >world
> % git commit -a -m slave
> % git merge master slave
>
> But I got the "usage: ..." error message from git-merge.
Well, you did not quote the usage string you got, but it should have began
like this:
usage: git merge [options] <remote>...
or: git merge [options] <msg> HEAD <remote>
The parser misinterpreted your request as the latter form (which is
ancient and probably predates your involvement with the git project),
noticed that you did not give any <remote> commit, and then gave the
usage message.
I think we really should start deprecating the ancient form, but the
original sample script using this syntax from Linus was copied by many
people and are still found everywhere, I think, and people may still
use their scripts that were written with the ancient syntax.
In any case, at least this patch will make it start behaving a bit
more sanely.
-- >8 --
Subject: Do not misidentify "git merge foo HEAD" as an old-style invocation
This was misinterpreted as an ancient style "git merge <message> HEAD
<commit> <commit>..." that merges one (or more) <commit> into the current
branch and record the resulting commit with the given message. Then a
later sanity check found that there is no <commit> specified and gave
a usage message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff --git a/builtin-merge.c b/builtin-merge.c
index e95c5dc..e5cf795 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -792,7 +792,7 @@ static int suggest_conflicts(void)
static struct commit *is_old_style_invocation(int argc, const char **argv)
{
struct commit *second_token = NULL;
- if (argc > 1) {
+ if (argc > 2) {
unsigned char second_sha1[20];
if (get_sha1(argv[1], second_sha1))
^ permalink raw reply related
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Junio C Hamano @ 2009-12-01 0:21 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Johannes Schindelin, Jay Soffian, git
In-Reply-To: <0458f16c6ce906997aaf357c0c7368841ae83c36.1259625072.git.bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Hmm, the Subject: matches what the code does, but nobody mentions why it
is necessary (iow, what breaks in the current code and what becomes better
if the patch is applied). The blank space before your "S-o-b:" line is
for you to describe these things.
> ---
> builtin-remote.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-remote.c b/builtin-remote.c
> index 7916626..bb72e27 100644
> --- a/builtin-remote.c
> +++ b/builtin-remote.c
> @@ -272,7 +272,9 @@ static int get_ref_states(const struct ref *remote_refs, struct ref_states *stat
> die("Could not get fetch map for refspec %s",
> states->remote->fetch_refspec[i]);
>
> - states->new.strdup_strings = states->tracked.strdup_strings = 1;
> + states->new.strdup_strings =
> + states->tracked.strdup_strings =
> + states->stale.strdup_strings = 1;
> for (ref = fetch_map; ref; ref = ref->next) {
> unsigned char sha1[20];
> if (!ref->peer_ref || read_ref(ref->peer_ref->name, sha1))
> @@ -768,7 +770,7 @@ static void clear_push_info(void *util, const char *string)
> static void free_remote_ref_states(struct ref_states *states)
> {
> string_list_clear(&states->new, 0);
> - string_list_clear(&states->stale, 0);
> + string_list_clear(&states->stale, 1);
> string_list_clear(&states->tracked, 0);
> string_list_clear(&states->heads, 0);
> string_list_clear_func(&states->push, clear_push_info);
> --
> 1.6.6.rc0.253.g1ec3
^ permalink raw reply
* [PATCH] git-merge: a deprecation notice of the ancient command line syntax
From: Junio C Hamano @ 2009-12-01 0:23 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Bernhard R. Link, git
In-Reply-To: <7vmy23bl4o.fsf@alter.siamese.dyndns.org>
The ancient form of git merge command used in the original sample script
has been copied from Linus and are still found everywhere, I think, and
people may still have it in their scripts, but on the other hand, it is so
unintuitive that even people reasonably familiar with git is surprised by
accidentally triggering the support to parse this ancient form.
Gently nudge people to upgrade their script to more recent and readable
style for eventual removal of the original syntax.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
And this is the first step of such a deprecation. Perhaps we start
warning in 1.7.0 and remove it in 1.8.0, or something like that.
builtin-merge.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e5cf795..4cb695e 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -789,6 +789,11 @@ static int suggest_conflicts(void)
return 1;
}
+static const char deprecation_warning[] =
+ "'git merge <msg> HEAD <commit>' is deprecated. Please update\n"
+ "your script to use 'git merge -m <msg> <commit>' instead.\n"
+ "In future versions of git, this syntax will be removed.";
+
static struct commit *is_old_style_invocation(int argc, const char **argv)
{
struct commit *second_token = NULL;
@@ -802,6 +806,7 @@ static struct commit *is_old_style_invocation(int argc, const char **argv)
die("'%s' is not a commit", argv[1]);
if (hashcmp(second_token->object.sha1, head))
return NULL;
+ warning(deprecation_warning);
}
return second_token;
}
^ permalink raw reply related
* Re: "git merge" merges too much!
From: Greg A. Woods @ 2009-12-01 0:24 UTC (permalink / raw)
To: The Git Mailing List; +Cc: Dmitry Potapov
In-Reply-To: <20091130211744.GA27278@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]
At Tue, 1 Dec 2009 00:17:44 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!
>
> It depends on the project and what tools are used, but using ccache and
> proper dependencies help a lot to reduce the cost of switching. In fact,
> it may be faster to switch to another branch and have to recompile a few
> files than to go into another working directory, because when you go to
> another working directory, you hit cold cache and things get very slow.
perhaps, sometimes, but at least with some tools that can more often
than not just end up with a confusing mess if you happen to change
something at exactly the wrong time, and with Git it seems almost too
easy to wildly change many files in the working directory, even if you
can get them back into their previous state relatively quickly
Things get even weirder if you happen to be playing with older branches
too -- most build tools don't have ability to follow files that go back
in time as they assume any product files newer than the sources are
already up-to-date, no matter how much older the sources might become on
a second build.
From a good software hygiene perspective the only safe way I can see to
build a Git working directory after manipulating any branches with Git
is to do a complete "make clean && make" cycle. That is until Git also
incorporates, or integrates with, really good build tools.... :-)
> And then if a project is huge and takes a lot of time to compile and
> test everything, I do not think, it is a good idea to build that in your
> work tree. Instead, you make a shanshot using git-archive and then run
> full build and test on it. In this way, you know that you test exactly
> what you have committed (you can amend any commit later until you
> publish it).
I think this "git-new-workdir" script is the thing to try. It probably
means keeping separate "configuration" branches, one for each build
working directory, but I think that's OK.
These source trees are big enough that one doesn't just go throwing
around entire copies of them willy-nilly. Disk bandwidth is also a
limited resource we are very concerned about, not just disk space.
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: equal-tree-merges as way to make rebases fast-forward-able
From: Junio C Hamano @ 2009-12-01 0:25 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git
In-Reply-To: <20091130185540.GA5764@pcpool00.mathematik.uni-freiburg.de>
"Bernhard R. Link" <brlink@debian.org> writes:
>> 3-------.
>> / \
>> 0---2---W---B
>> \ /
>> 1-------Z
>>
>> That is, Z and W records the interdifff between 1 to 3 and 2 to 3
>> respectively, and B is a same-tree merge of 3, W and Z.
>
> I think changing it to get this would be easy (though only in the case
> where the very last commit was such an equal tree merge), but I do not
> think it would be actually better:
>
> - it is no longer possible to see the history of changes by just walking
> right on every equal-tree-merge.
> - commit a no longer exists. If some downstream already has
> cloned/pulled, no fast-forward is possible any more.
Oh, I wasn't suggesting you to change it to use an octopus. I however did
want to know if you considered pros-and-cons with such an alternative
(there perhaps are other approaches as well), and I agree recording one
iteration at a time like you do is better.
^ permalink raw reply
* [PATCH] builtin-commit: add --date option
From: Miklos Vajna @ 2009-12-01 0:27 UTC (permalink / raw)
To: git
This is useful in case git commit --amend is used but the user wants to
set the date of the new commit to a specified one, since GIT_AUTHOR_DATE
is ignored in such a situation.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-commit.txt | 6 +++++-
builtin-commit.c | 6 +++++-
t/t7501-commit.sh | 15 +++++++++++++++
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 3ea80c8..3b9a7c3 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
- [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
+ [--date=<date>] [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -80,6 +80,10 @@ OPTIONS
an existing commit that matches the given string and its author
name is used.
+--date=<date>::
+ Override the date used in the commit. The format is the Git
+ native one and is `<time> SP <offutc>`.
+
-m <msg>::
--message=<msg>::
Use the given <msg> as the commit message.
diff --git a/builtin-commit.c b/builtin-commit.c
index 09d2840..594328e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -52,7 +52,7 @@ static char *edit_message, *use_message;
static char *author_name, *author_email, *author_date;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, no_verify, allow_empty, dry_run;
-static char *untracked_files_arg;
+static char *untracked_files_arg, *force_date;
/*
* The default commit message cleanup mode will remove the lines
* beginning with # (shell comments) and leading and trailing
@@ -90,6 +90,7 @@ static struct option builtin_commit_options[] = {
OPT_FILENAME('F', "file", &logfile, "read log from file"),
OPT_STRING(0, "author", &force_author, "AUTHOR", "override author for commit"),
+ OPT_STRING(0, "date", &force_date, "DATE", "override date for commit"),
OPT_CALLBACK('m', "message", &message, "MESSAGE", "specify commit message", opt_parse_m),
OPT_STRING('c', "reedit-message", &edit_message, "COMMIT", "reuse and edit message from specified commit "),
OPT_STRING('C', "reuse-message", &use_message, "COMMIT", "reuse message from specified commit"),
@@ -409,6 +410,9 @@ static void determine_author_info(void)
email = xstrndup(lb + 2, rb - (lb + 2));
}
+ if (force_date)
+ date = force_date;
+
author_name = name;
author_email = email;
author_date = date;
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index a603f6d..a529701 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -211,6 +211,21 @@ test_expect_success 'amend commit to fix author' '
'
+test_expect_success 'amend commit to fix date' '
+
+ test_tick &&
+ newtick=$GIT_AUTHOR_DATE &&
+ git reset --hard &&
+ git cat-file -p HEAD |
+ sed -e "s/author.*/author $author $newtick/" \
+ -e "s/^\(committer.*> \).*$/\1$GIT_COMMITTER_DATE/" > \
+ expected &&
+ git commit --amend --date="$newtick" &&
+ git cat-file -p HEAD > current &&
+ test_cmp expected current
+
+'
+
test_expect_success 'sign off (1)' '
echo 1 >positive &&
--
1.6.5.2
^ permalink raw reply related
* Re: Git open calls fail on NFS-mounted NTFS volume
From: Junio C Hamano @ 2009-12-01 0:38 UTC (permalink / raw)
To: Kai Lanz; +Cc: git
In-Reply-To: <F7CE7D3D-9237-494C-B6C8-6B6D7AB7CE45@stanford.edu>
Kai Lanz <lanz@stanford.edu> writes:
> There are several places in the code where git calls open() with the
> flag
> O_EXCL. This causes a problem for us when the current directory is on an
> NFS-mounted NTFS volume shared by an NAS fileserver.
> ...
> Git version is 1.6.5.3, running on x86_64 RHEL-4, kernel 2.6.9-89.
I do not use nor have access to RHEL, but does this ring a bell?
https://bugzilla.redhat.com/show_bug.cgi?id=524520
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
From: Junio C Hamano @ 2009-12-01 1:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <7veinjn7nc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I had to step back a bit and ask myself what we are trying to achieve
> here. When the current blame and incremental one are both working
> perfectly and well, will there be a reason for the end users to choose
> between them when they click?
>
> My answer is no. If the incremental one gives nicer user experience in
> all cases, it will be shown without the non-incremental one; if the
> incremental one makes the server or network load too heavy, a site owner
> may decide to show only the non-incremental one.
>
> That makes my addLinks suggestion a change that would help _only_ while we
> are working kinks out of the incremental one.
>
> Let's not waste too much effort doing that. Sorry for suggesting.
>
> Letting the site owner choose if the site wants to set the "incremental if
> possible" boolean would be more than adequate, I think.
Sorry, but I guess I dropped the ball after this message. If I understand
correctly, the conclusion is that I can apply the patch in this one
From: Jakub Narebski <jnareb@gmail.com>
Subject: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
Date: Thu, 26 Nov 2009 21:12:15 +0100
Message-ID: <200911262112.16280.jnareb@gmail.com>
and shipping 1.6.6 with it (perhaps setting 'default' to '[0]' instead)
would be both reasonably safe and allows easy experimentation by willing
site owners (or individual gitweb deployment), right?
Please advice if I am mistaken.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-merge: a deprecation notice of the ancient command line syntax
From: Nicolas Pitre @ 2009-12-01 3:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Bernhard R. Link, git
In-Reply-To: <7vaay3bkyx.fsf_-_@alter.siamese.dyndns.org>
On Mon, 30 Nov 2009, Junio C Hamano wrote:
> The ancient form of git merge command used in the original sample script
> has been copied from Linus and are still found everywhere, I think, and
> people may still have it in their scripts, but on the other hand, it is so
> unintuitive that even people reasonably familiar with git is surprised by
> accidentally triggering the support to parse this ancient form.
>
> Gently nudge people to upgrade their script to more recent and readable
> style for eventual removal of the original syntax.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> And this is the first step of such a deprecation. Perhaps we start
> warning in 1.7.0 and remove it in 1.8.0, or something like that.
If this is going to be removed in the future, then it is already
deprecated. Therefore it is much better to start warning now and not
wait for 1.7.0. There is just no point delaying the advice.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-merge: a deprecation notice of the ancient command line syntax
From: Junio C Hamano @ 2009-12-01 4:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Nanako Shiraishi, Bernhard R. Link, git
In-Reply-To: <alpine.LFD.2.00.0911302251270.5820@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Mon, 30 Nov 2009, Junio C Hamano wrote:
>
>> The ancient form of git merge command used in the original sample script
>> has been copied from Linus and are still found everywhere, I think, and
>> people may still have it in their scripts, but on the other hand, it is so
>> unintuitive that even people reasonably familiar with git is surprised by
>> accidentally triggering the support to parse this ancient form.
>>
>> Gently nudge people to upgrade their script to more recent and readable
>> style for eventual removal of the original syntax.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>>
>> And this is the first step of such a deprecation. Perhaps we start
>> warning in 1.7.0 and remove it in 1.8.0, or something like that.
>
> If this is going to be removed in the future, then it is already
> deprecated. Therefore it is much better to start warning now and not
> wait for 1.7.0. There is just no point delaying the advice.
Very true.
What I am not absolutely sure about is if the presense of the support for
ancient usage hurts people in real life so much that it is better to
remove it than keep it. At least we saw one example of a user (who is not
a novice) getting puzzled by it, but that may not be enough datapoint to
decide with.
^ permalink raw reply
* Re: Unable to checkout a particular SVN revision
From: Marc Liyanage @ 2009-12-01 4:59 UTC (permalink / raw)
To: git; +Cc: Daniele Segato
In-Reply-To: <1259513411.32532.22.camel@localhost>
On 29.11.2009, at 08:50, Daniele Segato wrote:
> You had to understand the difference between a distributed version
> control system (git) and a centralized version control system (svn).
I understand that, I use (pure) git for all my personal projects, and it works great.
And even as a front end for SVN, I am *very* happy with what I got from git-svn so far, I think it is an excellent tool, even better than the actual SVN client. I track an SVN repository in my local git master branch, then branch off locally for development, send patches for review, reorder/consolidate/squash commits back onto my master branch and then dcommit that back to SVN. All that is great.
I would like to understand why
git svn clone -r n <url>
does not work as expected while
git svn clone -r m <url>
does work perfectly fine, if that m revision number happens to have been committed on the particular SVN branch I cloned (you left off that -r in your git svn clone examples). As it is, I have to hunt for the next lower or higher revision number that happens to be on that branch.
I might be doing a poor job explaining what my question is... Basically, what prevents that operation from doing the same thing that SVN does? Lack of information, i.e. should I just clone higher up in the tree?
______________________________
Marc Liyanage
www.entropy.ch
skype mliyanage
iChat liyanage@mac.com
^ 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