* [PATCH] fetch-pack: check for valid commit from server
From: Nguyễn Thái Ngọc Duy @ 2011-08-19 15:11 UTC (permalink / raw)
To: git, Shawn Pearce, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1313674563-12755-1-git-send-email-pclouds@gmail.com>
A malicious server can return ACK with non-existent SHA-1 or not a
commit. lookup_commit() in this case may return NULL. Do not let
fetch-pack crash by accessing NULL address in this case.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
2011/8/19 Shawn Pearce <spearce@spearce.org>:
> 2011/8/18 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>> However it raises another question, what if the other end returns a
>> valid commit, but not the one in "have" line fetch-pack sent? Are we
>> OK with that?
>
> Not really. The server is not supposed to return a SHA-1 in the ACK
> line unless the client said it first in a have line. So aborting with
> an error is reasonable thing for a client to do.
I assumed I could check result_sha1 against sha1. If it did not match,
fetch-pack would abort. But I was wrong because fetch-pack would send
a few have lines before receiving the first ack (which carries sha1
of some 'have' line in the middle, not the last 'have'). I'd leave it
here if anyone wants to tackle it.
builtin/fetch-pack.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 4367984..561f1a3 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -395,6 +395,9 @@ static int find_common(int fd[2], unsigned char *result_sha1,
case ACK_continue: {
struct commit *commit =
lookup_commit(result_sha1);
+ if (!commit)
+ die("server ACK contained unknown commit %s",
+ sha1_to_hex(result_sha1));
if (args.stateless_rpc
&& ack == ACK_common
&& !(commit->object.flags & COMMON)) {
--
1.7.4.74.g639db
^ permalink raw reply related
* Unable to build git on Lion - missing config.h from Perl header files
From: Sorin Sbarnea @ 2011-08-19 16:31 UTC (permalink / raw)
To: git
In-Reply-To: <611AB1F99D784B92B1F7278139D6EED5@gmail.com>
Hi,
I came across the following problem while trying to build git (1.7.6) on Lion
https://github.com/mxcl/homebrew/issues/7091
The only files existing in
/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/ are
libperl.dylib andperl.h.
make[2]: *** No rule to make target
`/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h',
needed by `perl.mak'. Stop.
make[1]: *** [instlibdir] Error 2
If possible it would be a good idea to continue the discussion on
homebrew bug tracker
Thanks,
--
Sorin Sbarnea
^ permalink raw reply
* Re: [PATCH v2] xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
From: Tay Ray Chuan @ 2011-08-19 17:12 UTC (permalink / raw)
To: Jeff King
Cc: Git Mailing List, Junio C Hamano, Marat Radchenko, Johannes Sixt
In-Reply-To: <20110818224427.GB8481@sigill.intra.peff.net>
On Fri, Aug 19, 2011 at 6:44 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Aug 17, 2011 at 11:55:32PM +0800, Tay Ray Chuan wrote:
>
>> On Wed, Aug 17, 2011 at 1:21 PM, Jeff King <peff@peff.net> wrote:
>> > Wait, what? It was using 0 seconds of user time before, but still taking
>> > 8.5 seconds? What was it doing? Did you actually warm up your disk cache
>> > before taking these measurements?
>>
>> Three runs on the same machine, after a restart.
>>
>> $ time git show >/dev/null
>>
>> real 0m6.505s
>> user 0m0.031s
>> sys 0m0.015s
>> [...]
>
> So it is spending only .046s of CPU time, but is taking 6.5 seconds of
> wall clock time. Which implies to me that the dataset doesn't fit in
> your disk cache, or it is swapping a lot. Or you are on a really
> bogged-down multiuser system. :)
>
> But if I understand correctly, your patch is about increasing runtime
> performance of a slow algorithm. So is actually the improvement of an
> O(m*n) algorithm to an O(n) one, or does your new algorithm have better
> memory access patterns that avoid trashing swap?
>
> [snip]
>
> So I think your patch _is_ an improvement in algorithmic runtime. I just
> don't see how your numbers make any sense. Am I missing something? Is
> msysgit's bash "time" just broken?
Nope, available memory is more than enough, so I don't believe
swapping is taking place. I think it's more likely that it's an issue
with time on msysgit.
Johannes, care to shed some light on this?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: update-index --index-info producing spurious submodule commits
From: Junio C Hamano @ 2011-08-19 17:20 UTC (permalink / raw)
To: git; +Cc: Greg Troxel, Richard Hansen
In-Reply-To: <7vd3g272tk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> As "update-index --index-info" predates "submodule" by a few years or
> more, I wouldn't be surprised if the code didn't notice it was fed a wrong
> input and produced nonsensical result that happened to be a commit.
>
> The command could just instead barf, saying the input is wrong, but the
> option was so low-level that it was deliberately written to accept and
> store anything you throw at it --- even when it is nonsensical for the
> version of plumbing, later updates to the data structure might have made
> it making sense, which was the way to ease development of the system.
The second paragraph needs a bit of clarification. What I meant to say was
that the --index-info and its command line cousin --cacheinfo interfaces
are designed to be used like using a hex editor on the disk block device
to modify the file system in a random way, and just like a hex editor does
not prevent you from writing a data to the disk that is not understood or
misunderstood by the current filesystem implementations, ideally it should
allow you to put data that is beyond the current design of the index, so
that it can be used as a way to experiment while developing enhancements
to the index further. That in fact was how I experimented with updates to
the code to read from the index (in read-cache.c) in early days. Also they
do not even look at the object name they are given, and that is very much
deliberate---otherwise you cannot even stuff gitlinks in the index---and
in general, the less sanity-checks we do in that interface, the better off
we will be. After all we may someday start adding a tree entry in the
index for a reason unknown to us today.
I am all for documenting that today's index holds only regular blobs (mode
100644), executable blobs (mode 100755), symlink blobs (mode 120000), and
gitlinks (mode 160000), somewhere in the general part of the document not
specific to these options, and also documenting that the result of the
operation is undefined if anything outside the officially supported kinds
of input is fed to --index-info/--cacheinfo.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 0/4] git-p4: Improve branch support
From: Junio C Hamano @ 2011-08-19 18:02 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Pete Wyckoff, Tor Arvid Lund
In-Reply-To: <1313711046-23489-1-git-send-email-vitor.hda@gmail.com>
Even though this is labeled as v3, I do not see a corresponding v2 in
recent mail log. Is this an unrelated series that depends on v2 of your
"p4 rename/copy" topic?
^ permalink raw reply
* Re: [PATCH] branch.c: use the parsed branch name
From: Junio C Hamano @ 2011-08-19 18:03 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <8258e2fc0a61642053e285c4f498e7cf1d2dc7df.1313754086.git.git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> When setting up tracking info, branch.c uses the given branch specifier
> ("name"). Use the parsed name ("ref.buf") instead so that
>
> git branch --set-upstream @{-1} foo
>
> sets up tracking info for the previous branch rather than for a branch
> named "@{-1}".
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Thanks.
^ permalink raw reply
* Re: [PATCH] Disallow creating ambiguous branch names by default
From: Conrad Irwin @ 2011-08-19 18:07 UTC (permalink / raw)
To: Stephen Bash; +Cc: Junio C Hamano, git
In-Reply-To: <14776204.81375.1313675595871.JavaMail.root@mail.hq.genarts.com>
On Thu, Aug 18, 2011 at 6:53 AM, Stephen Bash <bash@genarts.com> wrote:
>
> Should case insensitive matches be added to the tests? This morning I discovered coworkers working on branches foo and Foo thinking they were on the same branch... Rather trivial to clean up, but certainly caused some confusion in the office.
>
I can certainly see the use-case, but there's definitely a step-change
between "this branch has the same name as something else", and "this
branch is going to confuse you". When trying to change the code to be
a warning as Junio suggested, I did think about expanding the
definition of ambiguous to include things that are merely confusing;
however it's not clear where to stop (i.e. should we warn about
<remotename>/<anything>, foo and f00, a branch called " " [the
non-breaking space]). There's probably an argument for more general
warning, but I don't think I understand when it should be shown
well-enough.
Conrad
^ permalink raw reply
* Re: [PATCH] Disallow creating ambiguous branch names by default
From: Conrad Irwin @ 2011-08-19 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhb5fev8a.fsf@alter.siamese.dyndns.org>
On Wed, Aug 17, 2011 at 11:41 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Conrad Irwin <conrad.irwin@gmail.com> writes:
>
>> Before this change, it was comparatively easy to create a confusingly
>
> Drop everything before the ", ".
>
>> named branch (like "origin/master" or "tag.1"). The former case is
>> particularly biting to newcomers, who suddenly find themselves needing
>> to handle nuances of the refs namespaces.
>
> If you start forbidding certain names, newcomers will need to be exposed
> the same nuances to understand why what they wanted to do is not allowed,
> so that is not an argument.
>
> My preferences (take them as "the ground rules" if you want) are:
>
> - We don't disallow what we have long allowed, without a good reason;
> - We make sure new people will get a warning with useful advice.
>
> I would be happy to see the end result that warns when the end user
> creates a branch (or a tag) that is ambiguous _when_ it is created (not
> "much later, when we noticed there are ambiguous refs"), and offers an
> advice message to use "branch -m" to rename it away (control the message
> with a new "advice.*" configuration and unless explicitly declined with
> it, always give the advice).
>
In the process of changing things around to do this, I noticed that
git checkout -M <foo> <current-branch>
surprisingly works, and does confusing things, in that you will get a:
$ git rev-parse HEAD@{1}
warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700
Presumably this is the reason that git branch -f forbids you from
changing the current branch?
If so is this a reasonable case where the current behaviour should be
forbidden (with the same error message "fatal: Cannot force update the
current branch.") — or should I just make it output a warning?
Conrad
^ permalink raw reply
* Re: [PATCH] Disallow creating ambiguous branch names by default
From: Stephen Bash @ 2011-08-19 18:15 UTC (permalink / raw)
To: Conrad Irwin; +Cc: Junio C Hamano, git
In-Reply-To: <CAOTq_ptdf3NvoeQXzdABdnU50w1ZwL=wnF6rPJvZpnqcU64-+g@mail.gmail.com>
----- Original Message -----
> From: "Conrad Irwin" <conrad.irwin@gmail.com>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: "Junio C Hamano" <gitster@pobox.com>, git@vger.kernel.org
> Sent: Friday, August 19, 2011 2:07:53 PM
> Subject: Re: [PATCH] Disallow creating ambiguous branch names by default
>
> > Should case insensitive matches be added to the tests? This morning
> > I discovered coworkers working on branches foo and Foo thinking they
> > were on the same branch... Rather trivial to clean up, but certainly
> > caused some confusion in the office.
>
> I can certainly see the use-case, but there's definitely a step-change
> between "this branch has the same name as something else", and "this
> branch is going to confuse you".
Good point. I'd be curious if any of the msys/cygwin guys can comment on if/when capitalization in branch names becomes technically ambiguous? I would think unpacked refs on a Windows machine could get complicated... And I guess factory Macs are all formated case-insensitive as well, so the same problem might apply there.
> When trying to change the code to be
> a warning as Junio suggested, I did think about expanding the
> definition of ambiguous to include things that are merely confusing;
> however it's not clear where to stop (i.e. should we warn about
> <remotename>/<anything>, foo and f00, a branch called " " [the
> non-breaking space]). There's probably an argument for more general
> warning, but I don't think I understand when it should be shown
> well-enough.
Thanks for putting the thought into it, I agree it is a slippery slope.
Stephen
^ permalink raw reply
* Re: [PATCH v3 0/4] git-p4: Improve branch support
From: Vitor Antunes @ 2011-08-19 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pete Wyckoff, Tor Arvid Lund
In-Reply-To: <7v4o1d46uk.fsf@alter.siamese.dyndns.org>
On Fri, Aug 19, 2011 at 7:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Even though this is labeled as v3, I do not see a corresponding v2 in
> recent mail log. Is this an unrelated series that depends on v2 of your
> "p4 rename/copy" topic?
You have to search in older archives... :)
http://article.gmane.org/gmane.comp.version-control.git/167998
--
Vitor Antunes
^ permalink raw reply
* Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}
From: Conrad Irwin @ 2011-08-19 18:54 UTC (permalink / raw)
To: Michael J Gruber
Cc: Nguyen Thai Ngoc Duy, Junio C Hamano, git, Sitaram Chamarty
In-Reply-To: <4E4CDBF5.4040709@drmicha.warpmail.net>
On Wed, Aug 17, 2011 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Currently, we use @{...} for:
>
> - Negative integers are "-N branch-switching ago" (only without any ref
> on the left);
> - Non-negative integers "The tip of the named ref before it was changed N
> times";
> - An approxidate that is case insensitive; or
> - "u" and "upstream".
[snip]
> The only remotely semi-plausible enhancement I could think of is perhaps
> to allow @{/regexp} to find a reflog entry that matches the given pattern,
> and in such a use case we would certainly want to take the pattern in a
> case sensitive way. This change closes the door to that, and that is the
> only downside I can think of right now.
I'm reasonably convinced by this argument as a refutation of the
consistency argument I proposed above. Given that the date format will
always be insensitive, and any enhancements added would probably want
to be case-sensitive (I can think of a few other things I'd "like",
but which are pretty silly: @{merge-base <commits>*}, @{octopus-base
<commits>*}); this syntax is always going to be inconsistent.
Additionally, as pointed out elsewhere in the thread, the most-similar
existing syntax (^{tree}) is already case-sensitive.
Given all of the above, I think that allowing @{upstream} to be
case-insensitive is certainly wrong, as it's slightly confusing and
not very useful.
Given that @{upstream} should be case-sensitive, it would be bizarre
to allow @{U} as a synonym, so I think I'm convinced that this is not
worth it, despite the convenience it brings.
On Thu, Aug 18, 2011 at 2:31 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
>>> As a simpler case, a user could tailor to her keyboard layout with
>>>
>>> git config revalias.↓ u
>>
Hmm, this opens up interesting ideas:
git config revalias.base = '! git merge-base -a "$@"'
git show HEAD@{base master}
but that seems like it's a bit over-the-top for some reason :).
Conrad
^ permalink raw reply
* Re: [PATCH v4 1/4] commit: remove global variable head_sha1[]
From: Junio C Hamano @ 2011-08-19 18:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1313765407-29925-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Thanks for a re-roll.
> @@ -1383,11 +1376,13 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> const char *index_file, *reflog_msg;
> char *nl, *p;
> unsigned char commit_sha1[20];
> + unsigned char head_sha1[20];
> struct ref_lock *ref_lock;
> struct commit_list *parents = NULL, **pptr = &parents;
> struct stat statbuf;
> int allow_fast_forward = 1;
> struct wt_status s;
> + struct commit *head_commit;
head_sha1[] is not initialized to NULs; neither is head_commit to NULL.
cmd_commit()
-> if it is an initial_commit, neither head_sha1[] nor head_commit
is defined;
-> prepare_to_commit()
-> is_a_merge(head_commit) gets called to see if this is an
empty non-merge commit if --amend was passed.
Attempting to --amend an initial commit should be an error and
parse_and_validate_options() checks that condition so the above is not
possible, but it still feels wrong.
Also wouldn't these three be equivalents?
head_commit == NULL
is_null_sha1(head_sha1)
initial_commit
Perhaps like this instead?
-- >8 --
Subject: commit: reduce use of redundant global variables
The file-scope global variable head_sha1[] was used to hold the object
name of the current HEAD commit (unless we are about to make an initial
commit). Also there is an independent "static int initial_commit".
Fix all the functions on the call-chain that use these two variables to
take a new "(const) struct commit *current_head" argument instead, and
replace their uses, e.g. "if (initial_commit)" becomes "if (!current_head)"
and a reference to "head_sha1" becomes "current_head->object.sha1".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/commit.c | 87 ++++++++++++++++++++++++++++--------------------------
1 files changed, 45 insertions(+), 42 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index e1af9b1..1a65319 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -62,8 +62,6 @@ N_("The previous cherry-pick is now empty, possibly due to conflict resolution.\
"\n"
"Otherwise, please use 'git reset'\n");
-static unsigned char head_sha1[20];
-
static const char *use_message_buffer;
static const char commit_editmsg[] = "COMMIT_EDITMSG";
static struct lock_file index_lock; /* real index */
@@ -102,7 +100,7 @@ static enum {
static char *cleanup_arg;
static enum commit_whence whence;
-static int use_editor = 1, initial_commit, include_status = 1;
+static int use_editor = 1, include_status = 1;
static int show_ignored_in_status;
static const char *only_include_assumed;
static struct strbuf message;
@@ -294,13 +292,13 @@ static void add_remove_files(struct string_list *list)
}
}
-static void create_base_index(void)
+static void create_base_index(const struct commit *current_head)
{
struct tree *tree;
struct unpack_trees_options opts;
struct tree_desc t;
- if (initial_commit) {
+ if (!current_head) {
discard_cache();
return;
}
@@ -313,7 +311,7 @@ static void create_base_index(void)
opts.dst_index = &the_index;
opts.fn = oneway_merge;
- tree = parse_tree_indirect(head_sha1);
+ tree = parse_tree_indirect(current_head->object.sha1);
if (!tree)
die(_("failed to unpack HEAD tree object"));
parse_tree(tree);
@@ -332,7 +330,8 @@ static void refresh_cache_or_die(int refresh_flags)
die_resolve_conflict("commit");
}
-static char *prepare_index(int argc, const char **argv, const char *prefix, int is_status)
+static char *prepare_index(int argc, const char **argv, const char *prefix,
+ const struct commit *current_head, int is_status)
{
int fd;
struct string_list partial;
@@ -448,7 +447,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
memset(&partial, 0, sizeof(partial));
partial.strdup_strings = 1;
- if (list_paths(&partial, initial_commit ? NULL : "HEAD", prefix, pathspec))
+ if (list_paths(&partial, !current_head ? NULL : "HEAD", prefix, pathspec))
exit(1);
discard_cache();
@@ -467,7 +466,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
(uintmax_t) getpid()),
LOCK_DIE_ON_ERROR);
- create_base_index();
+ create_base_index(current_head);
add_remove_files(&partial);
refresh_cache(REFRESH_QUIET);
@@ -516,12 +515,9 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
return s->commitable;
}
-static int is_a_merge(const unsigned char *sha1)
+static int is_a_merge(const struct commit *current_head)
{
- struct commit *commit = lookup_commit(sha1);
- if (!commit || parse_commit(commit))
- die(_("could not parse HEAD commit"));
- return !!(commit->parents && commit->parents->next);
+ return !!(current_head->parents && current_head->parents->next);
}
static const char sign_off_header[] = "Signed-off-by: ";
@@ -625,6 +621,7 @@ static char *cut_ident_timestamp_part(char *string)
}
static int prepare_to_commit(const char *index_file, const char *prefix,
+ struct commit *current_head,
struct wt_status *s,
struct strbuf *author_ident)
{
@@ -846,7 +843,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
* empty due to conflict resolution, which the user should okay.
*/
if (!commitable && whence != FROM_MERGE && !allow_empty &&
- !(amend && is_a_merge(head_sha1))) {
+ !(amend && is_a_merge(current_head))) {
run_status(stdout, index_file, prefix, 0, s);
if (amend)
fputs(_(empty_amend_advice), stderr);
@@ -1004,6 +1001,7 @@ static const char *read_commit_message(const char *name)
static int parse_and_validate_options(int argc, const char *argv[],
const char * const usage[],
const char *prefix,
+ struct commit *current_head,
struct wt_status *s)
{
int f = 0;
@@ -1024,11 +1022,8 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (!use_editor)
setenv("GIT_EDITOR", ":", 1);
- if (get_sha1("HEAD", head_sha1))
- initial_commit = 1;
-
/* Sanity check options */
- if (amend && initial_commit)
+ if (amend && !current_head)
die(_("You have nothing to amend."));
if (amend && whence != FROM_COMMIT)
die(_("You are in the middle of a %s -- cannot amend."), whence_s());
@@ -1100,12 +1095,12 @@ static int parse_and_validate_options(int argc, const char *argv[],
}
static int dry_run_commit(int argc, const char **argv, const char *prefix,
- struct wt_status *s)
+ const struct commit *current_head, struct wt_status *s)
{
int commitable;
const char *index_file;
- index_file = prepare_index(argc, argv, prefix, 1);
+ index_file = prepare_index(argc, argv, prefix, current_head, 1);
commitable = run_status(stdout, index_file, prefix, 0, s);
rollback_index_files();
@@ -1258,7 +1253,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
return 0;
}
-static void print_summary(const char *prefix, const unsigned char *sha1)
+static void print_summary(const char *prefix, const unsigned char *sha1,
+ int initial_commit)
{
struct rev_info rev;
struct commit *commit;
@@ -1380,12 +1376,13 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
struct strbuf author_ident = STRBUF_INIT;
const char *index_file, *reflog_msg;
char *nl, *p;
- unsigned char commit_sha1[20];
+ unsigned char sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = &parents;
struct stat statbuf;
int allow_fast_forward = 1;
struct wt_status s;
+ struct commit *current_head = NULL;
if (argc == 2 && !strcmp(argv[1], "-h"))
usage_with_options(builtin_commit_usage, builtin_commit_options);
@@ -1396,38 +1393,41 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (s.use_color == -1)
s.use_color = git_use_color_default;
+ if (get_sha1("HEAD", sha1))
+ current_head = NULL;
+ else {
+ current_head = lookup_commit(sha1);
+ if (!current_head || parse_commit(current_head))
+ die(_("could not parse HEAD commit"));
+ }
argc = parse_and_validate_options(argc, argv, builtin_commit_usage,
- prefix, &s);
+ prefix, current_head, &s);
if (dry_run) {
if (diff_use_color_default == -1)
diff_use_color_default = git_use_color_default;
- return dry_run_commit(argc, argv, prefix, &s);
+ return dry_run_commit(argc, argv, prefix, current_head, &s);
}
- index_file = prepare_index(argc, argv, prefix, 0);
+ index_file = prepare_index(argc, argv, prefix, current_head, 0);
/* Set up everything for writing the commit object. This includes
running hooks, writing the trees, and interacting with the user. */
- if (!prepare_to_commit(index_file, prefix, &s, &author_ident)) {
+ if (!prepare_to_commit(index_file, prefix,
+ current_head, &s, &author_ident)) {
rollback_index_files();
return 1;
}
/* Determine parents */
reflog_msg = getenv("GIT_REFLOG_ACTION");
- if (initial_commit) {
+ if (!current_head) {
if (!reflog_msg)
reflog_msg = "commit (initial)";
} else if (amend) {
struct commit_list *c;
- struct commit *commit;
if (!reflog_msg)
reflog_msg = "commit (amend)";
- commit = lookup_commit(head_sha1);
- if (!commit || parse_commit(commit))
- die(_("could not parse HEAD commit"));
-
- for (c = commit->parents; c; c = c->next)
+ for (c = current_head->parents; c; c = c->next)
pptr = &commit_list_insert(c->item, pptr)->next;
} else if (whence == FROM_MERGE) {
struct strbuf m = STRBUF_INIT;
@@ -1435,7 +1435,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (!reflog_msg)
reflog_msg = "commit (merge)";
- pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
+ pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1461,7 +1461,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = (whence == FROM_CHERRY_PICK)
? "commit (cherry-pick)"
: "commit";
- pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
+ pptr = &commit_list_insert(current_head, pptr)->next;
}
/* Finally, get the commit message */
@@ -1487,7 +1487,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
exit(1);
}
- if (commit_tree(sb.buf, active_cache_tree->sha1, parents, commit_sha1,
+ if (commit_tree(sb.buf, active_cache_tree->sha1, parents, sha1,
author_ident.buf)) {
rollback_index_files();
die(_("failed to write commit object"));
@@ -1495,7 +1495,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
strbuf_release(&author_ident);
ref_lock = lock_any_ref_for_update("HEAD",
- initial_commit ? NULL : head_sha1,
+ !current_head
+ ? NULL
+ : current_head->object.sha1,
0);
nl = strchr(sb.buf, '\n');
@@ -1510,7 +1512,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
rollback_index_files();
die(_("cannot lock HEAD ref"));
}
- if (write_ref_sha1(ref_lock, commit_sha1, sb.buf) < 0) {
+ if (write_ref_sha1(ref_lock, sha1, sb.buf) < 0) {
rollback_index_files();
die(_("cannot update HEAD ref"));
}
@@ -1532,13 +1534,14 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
struct notes_rewrite_cfg *cfg;
cfg = init_copy_notes_for_rewrite("amend");
if (cfg) {
- copy_note_for_rewrite(cfg, head_sha1, commit_sha1);
+ /* we are amending, so current_head is not NULL */
+ copy_note_for_rewrite(cfg, current_head->object.sha1, sha1);
finish_copy_notes_for_rewrite(cfg);
}
- run_rewrite_hook(head_sha1, commit_sha1);
+ run_rewrite_hook(current_head->object.sha1, sha1);
}
if (!quiet)
- print_summary(prefix, commit_sha1);
+ print_summary(prefix, sha1, !current_head);
return 0;
}
^ permalink raw reply related
* git diff --word-diff=plain
From: Elias Pipping @ 2011-08-19 19:16 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: Text/Plain, Size: 4874 bytes --]
Hello,
I mean to use `git --no-pager diff --word-diff=plain --no-index` as a
`wdiff`-replacement. I'm not sure if I should call it a bug but I've
come across a situation in which the output of GNU wdiff is by far
more helpful than that of the aforementioned git command.
I've attached the two files less and BSD-2. Here are the differences
that wdiff reveals:
% wdiff less BSD-2
[-Less License-]
[- -------------]
[--]
[-Less-]Copyright [-(C) 1984-2005 Mark Nudelman-] {+(c) <YEAR>, <OWNER>+}
{+All rights reserved.+}
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
[-notice-]
{+notice, this list of conditions and the following disclaimer+} in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE [-AUTHOR ``AS IS''-] {+COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"+}
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE [-AUTHOR-] {+COPYRIGHT OWNER OR CONTRIBUTORS+} BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
%
That's hardly any difference. Note that the file BSD-2 has an empty
line just before the first bullet point. This will cause git to treat
anything after that line as different for some reason. The resulting
diff is thus hardly useful:
% git --no-pager diff --word-diff=plain --no-index less BSD-2
diff --git a/licences/less b/licences/BSD-2
index 7e4887b..a995d54 100644
--- a/licences/less
+++ b/licences/BSD-2
@@ -1,27 +1,23 @@
[-Less License-]
[- -------------]
[-Less-]Copyright [-(C) 1984-2005 Mark Nudelman-]{+(c) <YEAR>, <OWNER>+}
{+All rights reserved.+}
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:[-1. Redistributions of source code must retain the above copyright-]
[- notice, this list of conditions and the following disclaimer.-]
[-2. Redistributions in binary form must reproduce the above copyright-]
[- notice in the documentation and/or other materials provided with -]
[- the distribution.-]
[-THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY-]
[-EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE-]
[-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR -]
[-PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE-]
[-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR -]
[-CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT -]
[-OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR -]
[-BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, -]
[-WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE -]
[-OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN -]
[-IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.-]{+1. Redistributions of source code must retain the above copyright notice,+}
{+ this list of conditions and the following disclaimer.+}
{+2. Redistributions in binary form must reproduce the above copyright+}
{+ notice, this list of conditions and the following disclaimer in the+}
{+ documentation and/or other materials provided with the distribution.+}
{+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"+}
{+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE+}
{+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE+}
{+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE+}
{+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR+}
{+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF+}
{+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS+}
{+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN+}
{+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)+}
{+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE+}
{+POSSIBILITY OF SUCH DAMAGE.+}
%
Best regards,
Elias Pipping
[-- Attachment #2: BSD-2 --]
[-- Type: Text/Plain, Size: 1295 bytes --]
Copyright (c) <YEAR>, <OWNER>
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
[-- Attachment #3: less --]
[-- Type: Text/Plain, Size: 1271 bytes --]
Less License
------------
Less
Copyright (C) 1984-2005 Mark Nudelman
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice in the documentation and/or other materials provided with
the distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
^ permalink raw reply related
* Re: [PATCH v4 4/4] Accept tags in HEAD or MERGE_HEAD
From: Junio C Hamano @ 2011-08-19 20:17 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1313765407-29925-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Junio's point, that if HEAD holds a tag, then head_sha1 and head->object.sha1
> in statement [1] are different, is entirely correct. However, favoring
> head->object.sha1 over head_sha1 is not enough. The variable head_sha1 is
> still there. Somewhere, some time, people may misuse it.
That is why I suggested _removing_ head_sha1[] altogether, so that there
is only one source of information. is_initial becomes !current_head and
head_sha1 becomes (current_head ? current_head->object.sha1 : null_sha1).
> diff --git a/commit.c b/commit.c
> index ac337c7..9e7f7ef 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -39,6 +39,25 @@ struct commit *lookup_commit_reference(const unsigned char *sha1)
> return lookup_commit_reference_gently(sha1, 0);
> }
>
> +/*
> + * Look sha1 up for a commit, defer if needed. If deference occurs,
> + * update "sha1" for consistency with retval->object.sha1. Also warn
> + * users this case because it is expected that sha1 points directly to
> + * a commit.
> + */
That's de-reference, not deference ;-). You may want to be more explicit
about what kind of de-reference you are talking about.
/*
* Get a commit object for the given sha1, unwrapping a tag object that
* point at a commit while at it. ref_name is only used when the result
* is not a commit in the error message to report where we got the sha1
* from.
*/
I actually was hoping that you would have this comment in commit.h to help
people who want to add callers of this function, not next to the
implementation.
As I said earlier, I do not think updating sha1[] here is necessary. The
caller should be updated to use c->object.sha1 instead.
> +struct commit *lookup_commit_or_die(unsigned char *sha1, const char *ref_name)
> +{
> + struct commit *c = lookup_commit_reference(sha1);
> + if (!c)
> + die(_("could not parse %s"), ref_name);
> + if (hashcmp(sha1, c->object.sha1)) {
> + warning(_("%s %s is not a commit!"),
> + ref_name, sha1_to_hex(sha1));
> + hashcpy(sha1, c->object.sha1);
> + }
> + return c;
> +}
^ permalink raw reply
* Re: [PATCH] fetch-pack: check for valid commit from server
From: Junio C Hamano @ 2011-08-19 20:18 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Shawn Pearce
In-Reply-To: <1313766693-20798-1-git-send-email-pclouds@gmail.com>
Thanks, but already queued the one from yesterday in 'maint' ;-).
^ permalink raw reply
* Re: [PATCH v4 2/2] push: Don't push a repository with unpushed submodules
From: Heiko Voigt @ 2011-08-19 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Gustafsson, git, jens.lehmann
In-Reply-To: <7v4o1ea2at.fsf@alter.siamese.dyndns.org>
Hi,
On Thu, Aug 18, 2011 at 01:32:26PM -0700, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
> > Since I do not see thisi in pu maybe you missed this? There was a series
> > containing the same patch send before which Jens asked to ignore but
> > this was the one which was meant to be included.
>
> Hmm, this is how the messages look like in my threaded MUA:
>
> [ 34: Fredrik Gustafsson ] [PATCH v4 0/2] push limitations
> [ 377: Fredrik Gustafsson ] [PATCH v4 2/2] push: Don't push a reposi...
> [ 35: Jens Lehmann ] Re: [PATCH v4 0/2] push limitations
> [ 377: Fredrik Gustafsson ] [PATCH v4 2/2] push: Don't push a reposit...
> [ 14: Heiko Voigt ]
>
> where Jens says "Please ignore this series, it slipped by accident" in the
> third one. And the second [PATCH v4 2/2] message that you are reminding me
> of (thanks!) has the identical proposed commit log message and patch text
> as the other [PATCH v4 2/2] message.
>
> So I am not sure what is going on here.
Sorry for confusing you.
There was a patch series which included a patch which was the same as
the patch I replied to. This was sent by accident since it also included
an old patch which was originally part of the 'fg/submodule-git-file-git-dir'
series.
Afterwards Fredrik also sent the same patch on its own again but forgot
to edit the subject. That was the patch to be included. But we already
discovered a small bug in the option parsing and will probably add
another patch implementing the on-demand option. So its probably simpler
if you just wait for our next iteration.
> Also I vaguely recall that I said something about the command line parser
> for this new option during the review of the previous round. Has that been
> resolved/corrected?
We plan to make the --recurse-submodules option symmetric to the one
already implemented in fetch. AFAIK, having a mixed boolean and other
values option is only possible by using a callback. To make extending it
simpler we decided to put the necessary infrastructure already in place.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH] Disallow creating ambiguous branch names by default
From: Junio C Hamano @ 2011-08-19 20:49 UTC (permalink / raw)
To: Conrad Irwin; +Cc: git
In-Reply-To: <CAOTq_ptU2QmPMMZYQLd2MFQ_=_RnADdBnoN5+v4rXh_nmpOcjw@mail.gmail.com>
Conrad Irwin <conrad.irwin@gmail.com> writes:
> In the process of changing things around to do this, I noticed that
>
> git checkout -M <foo> <current-branch>
>
> surprisingly works,...
What is "-M" supposed to do???
If you meant "-B", that should work. When I want to rewrite a topic in a
non-trivial way, I would often do:
$ git checkout HEAD^^^
work to redo what the few commits at the tip should have done,
creating commits.
$ git diff @{-1} HEAD
$ git checkout -B @{-1}
which often happens to be simpler and more flexible than the canned
rewriting options "rebase -i" can offer me.
> ... in that you will get a:
>
> $ git rev-parse HEAD@{1}
> warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700
If that is the case, then the codepath to update the reflog is
broken. That is not a reason to forbid -B, though.
But because I do not know what you meant by "checkout -M", ...
^ permalink raw reply
* Re: Unable to build git on Lion - missing config.h from Perl header files
From: David Aguilar @ 2011-08-19 20:58 UTC (permalink / raw)
To: Sorin Sbarnea; +Cc: git@vger.kernel.org
In-Reply-To: <CAGDPfJr01SPXvqDkYwingJ0Vu9DZx7GXO4G2uhFFfOWPvm1Rgw@mail.gmail.com>
On Aug 19, 2011, at 9:31 AM, Sorin Sbarnea <sorin.sbarnea@gmail.com> wrote:
> Hi,
>
> I came across the following problem while trying to build git (1.7.6) on Lion
> https://github.com/mxcl/homebrew/issues/7091
>
> The only files existing in
> /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/ are
> libperl.dylib andperl.h.
>
> make[2]: *** No rule to make target
> `/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h',
> needed by `perl.mak'. Stop.
> make[1]: *** [instlibdir] Error 2
>
> If possible it would be a good idea to continue the discussion on
> homebrew bug tracker
>
> Thanks,
> --
> Sorin Sbarnea
Did you upgrade to lion from a system where you were building previously? Did you try "make clean"?
--
David
^ permalink raw reply
* Re: [PATCH] Disallow creating ambiguous branch names by default
From: Conrad Irwin @ 2011-08-19 21:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uwh2kks.fsf@alter.siamese.dyndns.org>
On Fri, Aug 19, 2011 at 1:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> $ git rev-parse HEAD@{1}
>> warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700
>
> If that is the case, then the codepath to update the reflog is
> broken. That is not a reason to forbid -B, though.
>
> But because I do not know what you meant by "checkout -M", ...
Sorry, I meant git branch -M <foo> <current-branch>
Conrad
^ permalink raw reply
* BUG: Inconsistent handling of challenge-on-commit in git-svn
From: Thomas Robinson @ 2011-08-19 21:29 UTC (permalink / raw)
To: git
Additionally reporting the issue here, because git-svn also fails to
handle this issue gracefully. Worry not; this is something that SVN
should fix upstream as well.
I've noticed that, when a conflicting user is specified in what should
be an invalidatable portion of SVN's authentication cache, git-svn will
fail the same obscure error thrown by the SVN binary:
$ git svn dcommit
Committing to https://rf-ace.googlecode.com/svn/trunk ...
URL access forbidden for unknown reason: access to
'/svn/!svn/act/b039ca42-f359-41d0-9523-bbbca5266026' forbidden at
/usr/local/git/libexec/git-core/git-svn line 4472
The difference, of course, is that explicitly passing my credentials via
--username appears to be silently ignored, such that my workaround
posited to the SVN team below *doesn't* work in Git SVN.
This, of course, contradicts the information I could find while
searching for the problem, notably here:
http://groups.google.com/group/google-code-hosting/browse_thread/thread/72b6875507dca1d1
As such, it is possible that the cache challenge is spuriously taking
precedence over credentials specified by --username, causing an
irresolvable conflict until a user's SVN cache is cleared. This is,
needless to say, less than ideal.
My original bug report to the SVN user community follows below. Thank
you for taking the time to read this.
- Tom Robinson
---
The following is a bug report for triage and review. I've been unable to
locate an adequate fix or discussion for this issue; however, I have
found an acceptable workaround.
When built on OSX, SVN versions 1.6.16 (r1073529) and 1.6.17 (r1128011)
appear to handle authentication challenges on commit in a non-robust manner.
The testing that follows is against a Google Code project that I
currently maintain code for, which may be found here:
http://code.google.com/p/rf-ace/
Here is a sparse log of a fresh checkout and commit using SVN version
1.6.16 (r1073529) on OSX. All builds are inclusive of ra-neon:
$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace.svn
--username trobinson@systemsbiology.org
... file data ...
Checked out revision 265.
$ cd rf-ace.svn
... make some changes to existing files ...
$ svn commit
... write the log in my default editor ...
"svn-commit.tmp" 35L, 1392C written
svn: Commit failed (details follow):
svn: access to '/svn/!svn/act/c23cbe26-fda3-46d6-a358-d1d20738c4bf'
forbidden
svn: Your commit message was left in a temporary file:
svn: '/path/to/my/repo/scrubbed/from/this/report/rf-ace.svn/svn-commit.tmp'
This same behavior exhibits in 1.6.17 (r1128011), and when a log message
is given using -m.
Here is an approximately equivalent session using SVN version 1.6.11
(r934486) in CentOS 6:
$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace
--username trobinson@systemsbiology.org
... file data ...
Checked out revision 265.
$ cd rf-ace
... make some changes to existing files ...
$ svn up
... file data ...
Checked out revision 269.
$ svn commit -m "Irrelevant log message you can find in r270 of rf-ace"
Authentication realm: <https://rf-ace.googlecode.com:443> Google Code
Subversion Repository
Password for 'trobinso':
[In which I press enter here to fall back to explicit Username
specification]
Authentication realm: <https://rf-ace.googlecode.com:443> Google Code
Subversion Repository
Username: trobinson@systemsbiology.org
Password for 'trobinson@systemsbiology.org': [My correct password is
entered here]
Sending test/argparse_test.hpp
Transmitting file data .
-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:
<https://rf-ace.googlecode.com:443> Google Code Subversion Repository
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/my/home/directory/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? yes [I know, I know. See my notes
below.]
Committed revision 270.
Note that on personal dev boxes, authentication information has been
stored locally in ~/.subversion (which, I note as an aside, is something
I only do with definedly-insecure passwords like those automatically
generated by Google Code on machines that are for internal development
only). This, too, may cause the issue.
My workaround, of course, is obvious. For all versions of SVN,
specifying the username explicitly (a la "--username
trobinson@systemsbiology.org") immediately follows up with a challenge
for my password. I have not verified if this resolves future commit
attempts.
The catalyst for the issue is Google's recent transition of Google Code
login system to that of Google Accounts. In this case, for conflicting
users, the issue only exposed itself when we cut back over to our
original usernames, and I would speculate this occurs if (and only if)
the same username is specified with an alternate password (as mine was).
Thus, we have a compelling case for potentially spurious handling of
conflicting user credentials, as may well expose themselves in the
migration of Google Code SVN repositories. In which I would speculate
that the right approach would be to invalidate the cached copy of the
user's credentials and re-challenge both the username and the password.
Ideally, this behavior would be grafted into a configuration value,
should it not already exist.
As you might expect, searching for this information is nigh-impossible
for this exact edge condition, and you will probably receive several
queries of a similar nature as Google continues to transition accounts
with access to Google Code. Thus my posting of this bug report: assuming
my hypothesis is correct, it's a case of inconsistent credential
handling that results in a non-intuitive error message. As above, this
would be better handled by configurable invalidation of the user's
cached credentials.
Thus concludes my report. Please copy me on any mail you expect for me
to see, as I am not a subscriber to this list.
Best regards,
- Tom Robinson
^ permalink raw reply
* Re: Unable to build git on Lion - missing config.h from Perl header files
From: Sorin Sbarnea @ 2011-08-19 21:43 UTC (permalink / raw)
To: David Aguilar; +Cc: git@vger.kernel.org
In-Reply-To: <9B588F2F-ACDF-4DA7-BE30-E075CA729731@gmail.com>
This was a clean-new Lion install, not an upgrade. I just installed
Xcode on alternate location /Developer41 instead of /Developer
Yes, I did a `make clean` but it has no effect.
The problem is that on Lion there is no config.h in the perl
directory, only a perl.h file.
--
Sorin Sbarnea
On Fri, Aug 19, 2011 at 21:58, David Aguilar <davvid@gmail.com> wrote:
> On Aug 19, 2011, at 9:31 AM, Sorin Sbarnea <sorin.sbarnea@gmail.com> wrote:
>
>> Hi,
>>
>> I came across the following problem while trying to build git (1.7.6) on Lion
>> https://github.com/mxcl/homebrew/issues/7091
>>
>> The only files existing in
>> /System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/ are
>> libperl.dylib andperl.h.
>>
>> make[2]: *** No rule to make target
>> `/System/Library/Perl/5.12/darwin-thread-multi-2level/CORE/config.h',
>> needed by `perl.mak'. Stop.
>> make[1]: *** [instlibdir] Error 2
>>
>> If possible it would be a good idea to continue the discussion on
>> homebrew bug tracker
>>
>> Thanks,
>> --
>> Sorin Sbarnea
>
> Did you upgrade to lion from a system where you were building previously? Did you try "make clean"?
>
> --
> David
^ permalink raw reply
* Why isn't the index a tree?
From: Richard Hansen @ 2011-08-19 21:24 UTC (permalink / raw)
To: git
I expected the index to be implemented something like a ref to a tree
object (per stage) plus some stat()/assume-unchanged/etc. metadata.
Instead, it appears to be a (sorted?) flat list of full paths with their
associated SHA1s and metadata.
Is there a reason why each stage in the index isn't implemented as a tree?
If the index was a tree, I believe it would make several tasks easier:
* you could easily get the diff between stage 1 and some arbitrary
revision (e.g., git diff HEAD^^ :1:)
* you could commit and checkout empty directories
* you could use update-index --cacheinfo to directly insert/replace
an entire subdirectory
* etc.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] Disallow creating ambiguous branch names by default
From: Junio C Hamano @ 2011-08-19 21:52 UTC (permalink / raw)
To: Conrad Irwin; +Cc: git
In-Reply-To: <CAOTq_ptU2QmPMMZYQLd2MFQ_=_RnADdBnoN5+v4rXh_nmpOcjw@mail.gmail.com>
Conrad Irwin <conrad.irwin@gmail.com> writes:
> In the process of changing things around to do this, I noticed that
>
> git branch -M <foo> <current-branch>
>
> surprisingly works, and does confusing things, in that you will get a:
>
> $ git rev-parse HEAD@{1}
> warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700
>
> Presumably this is the reason that git branch -f forbids you from
> changing the current branch?
[jc: edited typo in the original command exhibition]
I also suspect that "git status" will become nonsense at that point, as
the working tree and the index were still the original state while the
commit pointed by HEAD have changed underneath you.
And you are correct to point out that it is why "git branch -f" shouldn't
touch the current branch. We should notice the situation and error out.
Patches welcome.
I initially thought that such a patch can optionally as a bonus suggest an
alternative way to confuse yourself, e.g. "git reset --soft <foo>", which
is what is happening, but I do not think it makes sense, especially with
"--soft", either.
The user is saying "I know the <current-branch> exists already, and I want
it to match the tip of <foo> branch", without saying what should happen to
what is in the working tree, so depending on what s/he wants, either "git
reset --hard <foo>" or "git reset --keep <foo>" followed by "git branch -d
foo" would be the right thing to do, and I would imagine that one could
even argue that "git branch -M <foo> <current-branch>" should do exactly
that under the hood, but the <current-branch> may be a typo and the user
may have meant to affect some other branch, so in order to play it safe,
just an error message without any advice based on a vague second-guess of
the user's intention, would be the most appropriate, I would think.
Thanks.
^ permalink raw reply
* [PATCH v4 0/2] push: submodule support
From: Fredrik Gustafsson @ 2011-08-19 22:08 UTC (permalink / raw)
To: git; +Cc: iveqy, hvoigt, jens.lehmann, gitster
The first iteration of this patch series can be found here:
http://thread.gmane.org/gmane.comp.version-control.git/176328/focus=176327
The second iteration of this patch series can be found here:
http://thread.gmane.org/gmane.comp.version-control.git/177992
The third iteration of this patch series can be found here:
http://thread.gmane.org/gmane.comp.version-control.git/179037/focus=179048
Fredrik Gustafsson (2):
push: Don't push a repository with unpushed submodules
push: teach --recurse-submodules the on-demand option
Documentation/git-push.txt | 9 ++
builtin/push.c | 26 +++++++
combine-diff.c | 2 +-
submodule.c | 161 ++++++++++++++++++++++++++++++++++++++++
submodule.h | 2 +
t/t5531-deep-submodule-push.sh | 111 +++++++++++++++++++++++++++
transport.c | 17 ++++
transport.h | 2 +
8 files changed, 329 insertions(+), 1 deletions(-)
--
1.7.6.551.gfb18e
^ permalink raw reply
* [PATCH v4 2/2] push: teach --recurse-submodules the on-demand option
From: Fredrik Gustafsson @ 2011-08-19 22:08 UTC (permalink / raw)
To: git; +Cc: iveqy, hvoigt, jens.lehmann, gitster
In-Reply-To: <1313791728-11328-1-git-send-email-iveqy@iveqy.com>
When using this option git will search for all submodules that
have changed in the revisions to be send. It will then try to
push the currently checked out branch of each submodule.
This helps when a user has finished working on a change which
involves submodules and just wants to push everything in one go.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Mentored-by: Jens Lehmann <Jens.Lehmann@web.de>
Mentored-by: Heiko Voigt <hvoigt@hvoigt.net>
---
Documentation/git-push.txt | 13 ++++--
builtin/push.c | 7 +++
submodule.c | 89 ++++++++++++++++++++++++++++++++--------
submodule.h | 1 +
t/t5531-deep-submodule-push.sh | 24 +++++++++++
transport.c | 10 ++++-
transport.h | 1 +
7 files changed, 121 insertions(+), 24 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index aede488..fe60d28 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -162,11 +162,14 @@ useful if you write an alias or script around 'git push'.
is specified. This flag forces progress status even if the
standard error stream is not directed to a terminal.
---recurse-submodules=check::
- Check whether all submodule commits used by the revisions to be
- pushed are available on a remote tracking branch. Otherwise the
- push will be aborted and the command will exit with non-zero status.
-
+--recurse-submodules=<check|on-demand>::
+ Check whether all submodule commits used by the revisions to be pushed
+ are available on a remote tracking branch. If check is used the push
+ will be aborted and the command will exit with non-zero status.
+ If on-demand is used all submodules that changed in the
+ to be pushed will be pushed. If on-demand was not able
+ to push all necessary revisions it will also be aborted and exit
+ with non-zero status.
include::urls-remotes.txt[]
diff --git a/builtin/push.c b/builtin/push.c
index 35cce53..f2ef8dd 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -224,9 +224,16 @@ static int option_parse_recurse_submodules(const struct option *opt,
const char *arg, int unset)
{
int *flags = opt->value;
+
+ if (*flags & (TRANSPORT_RECURSE_SUBMODULES_CHECK |
+ TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND))
+ die("%s can only be used once.", opt->long_name);
+
if (arg) {
if (!strcmp(arg, "check"))
*flags |= TRANSPORT_RECURSE_SUBMODULES_CHECK;
+ else if (!strcmp(arg, "on-demand"))
+ *flags |= TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND;
else
die("bad %s argument: %s", opt->long_name, arg);
} else
diff --git a/submodule.c b/submodule.c
index 45f508c..dc95498 100644
--- a/submodule.c
+++ b/submodule.c
@@ -8,7 +8,10 @@
#include "diffcore.h"
#include "refs.h"
#include "string-list.h"
+#include "transport.h"
+typedef int (*needs_push_func_t)(const char *path, const unsigned char sha1[20],
+ void *data);
static struct string_list config_name_for_path;
static struct string_list config_fetch_recurse_submodules_for_name;
static struct string_list config_ignore_for_name;
@@ -308,21 +311,24 @@ void set_config_fetch_recurse_submodules(int value)
config_fetch_recurse_submodules = value;
}
+typedef int (*module_func_t)(const char *path, const unsigned char sha1[20], void *data);
+
static int has_remote(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
return 1;
}
-static int submodule_needs_pushing(const char *path, const unsigned char sha1[20])
+int submodule_needs_pushing(const char *path, const unsigned char sha1[20], void *data)
{
+ int *needs_pushing = data;
+
if (add_submodule_odb(path) || !lookup_commit_reference(sha1))
- return 0;
+ return 1;
if (for_each_remote_ref_submodule(path, has_remote, NULL) > 0) {
struct child_process cp;
const char *argv[] = {"rev-list", NULL, "--not", "--remotes", "-n", "1" , NULL};
struct strbuf buf = STRBUF_INIT;
- int needs_pushing = 0;
argv[1] = sha1_to_hex(sha1);
memset(&cp, 0, sizeof(cp));
@@ -336,41 +342,74 @@ static int submodule_needs_pushing(const char *path, const unsigned char sha1[20
die("Could not run 'git rev-list %s --not --remotes -n 1' command in submodule %s",
sha1_to_hex(sha1), path);
if (strbuf_read(&buf, cp.out, 41))
- needs_pushing = 1;
+ *needs_pushing = 1;
finish_command(&cp);
close(cp.out);
strbuf_release(&buf);
- return needs_pushing;
+ return !*needs_pushing;
}
- return 0;
+ return 1;
+}
+
+int push_submodule(const char *path, const unsigned char sha1[20], void *data)
+{
+ if (add_submodule_odb(path) || !lookup_commit_reference(sha1))
+ return 1;
+
+ if (for_each_remote_ref_submodule(path, has_remote, NULL) > 0) {
+ struct child_process cp;
+ const char *argv[] = {"push", NULL};
+
+ memset(&cp, 0, sizeof(cp));
+ cp.argv = argv;
+ cp.env = local_repo_env;
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.out = -1;
+ cp.dir = path;
+ if (run_command(&cp))
+ die("Could not run 'git push' command in submodule %s", path);
+ close(cp.out);
+ }
+
+ return 1;
}
+struct collect_submodules_data {
+ module_func_t func;
+ void *data;
+ int ret;
+};
+
static void collect_submodules_from_diff(struct diff_queue_struct *q,
struct diff_options *options,
void *data)
{
int i;
- int *needs_pushing = data;
+ struct collect_submodules_data *me = data;
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
if (!S_ISGITLINK(p->two->mode))
continue;
- if (submodule_needs_pushing(p->two->path, p->two->sha1)) {
- *needs_pushing = 1;
+ if (!(me->ret = me->func(p->two->path, p->two->sha1, me->data)))
break;
- }
}
}
-
-static void commit_need_pushing(struct commit *commit, struct commit_list *parent, int *needs_pushing)
+static int commit_need_pushing(struct commit *commit, struct commit_list *parent,
+ module_func_t func, void *data)
{
const unsigned char (*parents)[20];
unsigned int i, n;
struct rev_info rev;
+ struct collect_submodules_data cb;
+ cb.func = func;
+ cb.data = data;
+ cb.ret = 1;
+
n = commit_list_count(parent);
parents = xmalloc(n * sizeof(*parents));
@@ -382,21 +421,23 @@ static void commit_need_pushing(struct commit *commit, struct commit_list *paren
init_revisions(&rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = collect_submodules_from_diff;
- rev.diffopt.format_callback_data = needs_pushing;
+ rev.diffopt.format_callback_data = &cb;
diff_tree_combined(commit->object.sha1, parents, n, 1, &rev);
free(parents);
+ return cb.ret;
}
-int check_submodule_needs_pushing(unsigned char new_sha1[20], const char *remotes_name)
+static int inspect_superproject_commits(unsigned char new_sha1[20], const char *remotes_name,
+ module_func_t func, void *data)
{
struct rev_info rev;
struct commit *commit;
const char *argv[] = {NULL, NULL, "--not", "NULL", NULL};
int argc = ARRAY_SIZE(argv) - 1;
char *sha1_copy;
- int needs_pushing = 0;
struct strbuf remotes_arg = STRBUF_INIT;
+ int do_continue = 1;
strbuf_addf(&remotes_arg, "--remotes=%s", remotes_name);
init_revisions(&rev, NULL);
@@ -407,13 +448,25 @@ int check_submodule_needs_pushing(unsigned char new_sha1[20], const char *remote
if (prepare_revision_walk(&rev))
die("revision walk setup failed");
- while ((commit = get_revision(&rev)) && !needs_pushing)
- commit_need_pushing(commit, commit->parents, &needs_pushing);
+ while ((commit = get_revision(&rev)) && do_continue)
+ do_continue = commit_need_pushing(commit, commit->parents, func, data);
free(sha1_copy);
strbuf_release(&remotes_arg);
- return needs_pushing;
+ return do_continue;
+}
+
+int check_submodule_needs_pushing(unsigned char new_sha1[20], const char *remotes_name)
+{
+ int needs_push = 0;
+ inspect_superproject_commits(new_sha1, remotes_name, submodule_needs_pushing, &needs_push);
+ return needs_push;
+}
+
+void push_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name)
+{
+ inspect_superproject_commits(new_sha1, remotes_name, push_submodule, NULL);
}
static int is_submodule_commit_present(const char *path, unsigned char sha1[20])
diff --git a/submodule.h b/submodule.h
index 799c22d..a0074aa 100644
--- a/submodule.h
+++ b/submodule.h
@@ -30,5 +30,6 @@ unsigned is_submodule_modified(const char *path, int ignore_untracked);
int merge_submodule(unsigned char result[20], const char *path, const unsigned char base[20],
const unsigned char a[20], const unsigned char b[20]);
int check_submodule_needs_pushing(unsigned char new_sha1[20], const char *remotes_name);
+void push_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name);
#endif
diff --git a/t/t5531-deep-submodule-push.sh b/t/t5531-deep-submodule-push.sh
index 30bec4b..35820ec 100755
--- a/t/t5531-deep-submodule-push.sh
+++ b/t/t5531-deep-submodule-push.sh
@@ -119,4 +119,28 @@ test_expect_success 'push succeeds if submodule has no remote and is on the firs
)
'
+test_expect_success 'push unpushed submodules' '
+ (
+ cd work &&
+ git checkout master &&
+ git push --recurse-submodules=on-demand ../pub.git master
+ )
+'
+
+test_expect_success 'push unpushed submodules when not needed' '
+ (
+ cd work &&
+ (
+ cd gar/bage &&
+ >junk4 &&
+ git add junk4 &&
+ git commit -m "junk4" &&
+ git push
+ ) &&
+ git add gar/bage &&
+ git commit -m "updated submodule" &&
+ git push --recurse-submodules=on-demand ../pub.git master
+ )
+'
+
test_done
diff --git a/transport.c b/transport.c
index d2725e5..59c90c7 100644
--- a/transport.c
+++ b/transport.c
@@ -1046,7 +1046,15 @@ int transport_push(struct transport *transport,
flags & TRANSPORT_PUSH_MIRROR,
flags & TRANSPORT_PUSH_FORCE);
- if ((flags & TRANSPORT_RECURSE_SUBMODULES_CHECK) && !is_bare_repository()) {
+ if ((flags & TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND) && !is_bare_repository()) {
+ struct ref *ref = remote_refs;
+ for (; ref; ref = ref->next)
+ if (!is_null_sha1(ref->new_sha1))
+ push_unpushed_submodules(ref->new_sha1,transport->remote->name);
+ }
+
+ if ((flags & (TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND |
+ TRANSPORT_RECURSE_SUBMODULES_CHECK)) && !is_bare_repository()) {
struct ref *ref = remote_refs;
for (; ref; ref = ref->next)
if (!is_null_sha1(ref->new_sha1) &&
diff --git a/transport.h b/transport.h
index 059b330..9d19c78 100644
--- a/transport.h
+++ b/transport.h
@@ -102,6 +102,7 @@ struct transport {
#define TRANSPORT_PUSH_PORCELAIN 16
#define TRANSPORT_PUSH_SET_UPSTREAM 32
#define TRANSPORT_RECURSE_SUBMODULES_CHECK 64
+#define TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND 128
#define TRANSPORT_SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)
--
1.7.6.551.gfb18e
^ permalink raw reply related
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