[PATCHv2 1/3] builtin/notes: Fix premature failure when trying to add the empty blob
This fixes a small buglet when trying to explicitly add the empty blob
as a note object using the -c or -C option to git notes add/append.
Instead of failing with a nonsensical error message indicating that the
empty blob does not exist, we should rather behave as if an empty notes
message was given (e.g. using -m "" or -F /dev/null).
The next patch contains a test that verifies the fixed behavior.
Found-by: Eric Sunshine
Signed-off-by: Johan Herland
---
builtin/notes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/notes.c b/builtin/notes.c
index 68b6cd8..9ee6816 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -266,7 +266,7 @@ static int parse_reuse_arg(const struct option *opt, const
char *arg, int unset)
if (get_sha1(arg, object))
die(_("Failed to resolve '%s' as a valid ref."), arg);
- if (!(buf = read_sha1_file(object, &type, &len)) || !len) {
+ if (!(buf = read_sha1_file(object, &type, &len))) {
free(buf);
die(_("Failed to read object '%s'."), arg);
}
--
2.0.0.rc4.501.gdaf83ca
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] t3312-notes-empty: Test that 'git notes' removes empty notes by default
On Wed, Nov 5, 2014 at 5:10 AM, Eric Sunshine wrote: [...] > write_script() would allow you to drop the #!/bin/sh and chmod lines. [...] > Rather than hard-coding this output, generating it would make the test > script less fragile: > > git log -1 >expect_missing [...] > Each -c/-C case fails for me when trying to read $empty_object. For example: > > fatal: Failed to read object 'e69de29bb2d1d6434b8b29ae775ad8c2e48c5391'. > not ok 5 - 'git notes add -c "$empty_blob"' removes empty note These are all fixed in the re-roll. Thanks for the feedback! ...Johan -- Johan Herland, www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/3] t3312-notes-empty: Test that 'git notes' removes empty notes by default
Add test cases documenting the current behavior when trying to
add/append/edit empty notes. This is in preparation for adding
--allow-empty; to allow empty notes to be stored.
Improved-by: Eric Sunshine
Signed-off-by: Johan Herland
---
t/t3312-notes-empty.sh | 48
1 file changed, 48 insertions(+)
create mode 100755 t/t3312-notes-empty.sh
diff --git a/t/t3312-notes-empty.sh b/t/t3312-notes-empty.sh
new file mode 100755
index 000..44074f6
--- /dev/null
+++ b/t/t3312-notes-empty.sh
@@ -0,0 +1,48 @@
+#!/bin/sh
+
+test_description='Test adding/editing of empty notes'
+. ./test-lib.sh
+
+write_script fake_editor <<\EOF
+ echo "$MSG" >"$1"
+EOF
+GIT_EDITOR=./fake_editor
+export GIT_EDITOR
+
+test_expect_success 'setup' '
+ test_commit one &&
+ git log -1 >expect_missing &&
+ empty_blob=$(git hash-object -w /dev/null)
+'
+
+cleanup_notes() {
+ git update-ref -d refs/notes/commits
+}
+
+verify_missing() {
+ git log -1 > actual &&
+ test_cmp expect_missing actual &&
+ ! git notes list HEAD
+}
+
+for cmd in \
+ 'add' \
+ 'add -F /dev/null' \
+ 'add -m ""' \
+ 'add -c "$empty_blob"' \
+ 'add -C "$empty_blob"' \
+ 'append' \
+ 'append -F /dev/null' \
+ 'append -m ""' \
+ 'append -c "$empty_blob"' \
+ 'append -C "$empty_blob"' \
+ 'edit'
+do
+ test_expect_success "'git notes $cmd' removes empty note" "
+ cleanup_notes &&
+ MSG= git notes $cmd &&
+ verify_missing
+ "
+done
+
+test_done
--
2.0.0.rc4.501.gdaf83ca
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/3] notes: Add --allow-empty, to allow storing empty notes
Although the "git notes" man page advertises that we support binary-safe
notes addition (using the -C option), we currently do not support adding
the empty note (i.e. using the empty blob to annotate an object). Instead,
an empty note is always treated as an intent to remove the note
altogether.
Introduce the --allow-empty option to the add/append/edit subcommands,
to explicitly allow an empty note to be stored into the notes tree.
Also update the documentation, and add test cases for the new option.
Reported-by: James H. Fisher
Improved-by: Kyle J. McKay
Signed-off-by: Johan Herland
---
Documentation/git-notes.txt | 12
builtin/notes.c | 23 ++-
notes.c | 3 +--
t/t3312-notes-empty.sh | 17 -
4 files changed, 39 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 310f0a5..851518d 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -9,10 +9,10 @@ SYNOPSIS
[verse]
'git notes' [list []]
-'git notes' add [-f] [-F | -m | (-c | -C) ] []
+'git notes' add [-f] [--allow-empty] [-F | -m | (-c | -C)
] []
'git notes' copy [-f] ( --stdin | )
-'git notes' append [-F | -m | (-c | -C) ] []
-'git notes' edit []
+'git notes' append [--allow-empty] [-F | -m | (-c | -C) ]
[]
+'git notes' edit [--allow-empty] []
'git notes' show []
'git notes' merge [-v | -q] [-s ]
'git notes' merge --commit [-v | -q]
@@ -155,6 +155,10 @@ OPTIONS
Like '-C', but with '-c' the editor is invoked, so that
the user can further edit the note message.
+--allow-empty::
+ Allow an empty note object to be stored. The default behavior is
+ to automatically remove empty notes.
+
--ref ::
Manipulate the notes tree in . This overrides
'GIT_NOTES_REF' and the "core.notesRef" configuration. The ref
@@ -287,7 +291,7 @@ arbitrary files using 'git hash-object':
$ cc *.c
$ blob=$(git hash-object -w a.out)
-$ git notes --ref=built add -C "$blob" HEAD
+$ git notes --ref=built add --allow-empty -C "$blob" HEAD
(You cannot simply use `git notes --ref=built add -F a.out HEAD`
diff --git a/builtin/notes.c b/builtin/notes.c
index 9ee6816..038a419 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -22,10 +22,10 @@
static const char * const git_notes_usage[] = {
N_("git notes [--ref ] [list []]"),
- N_("git notes [--ref ] add [-f] [-m | -F | (-c
| -C) ] []"),
+ N_("git notes [--ref ] add [-f] [--allow-empty] [-m |
-F | (-c | -C) ] []"),
N_("git notes [--ref ] copy [-f] "),
- N_("git notes [--ref ] append [-m | -F | (-c |
-C) ] []"),
- N_("git notes [--ref ] edit []"),
+ N_("git notes [--ref ] append [--allow-empty] [-m | -F
| (-c | -C) ] []"),
+ N_("git notes [--ref ] edit [--allow-empty] []"),
N_("git notes [--ref ] show []"),
N_("git notes [--ref ] merge [-v | -q] [-s ]
"),
N_("git notes merge --commit [-v | -q]"),
@@ -150,8 +150,8 @@ static void write_commented_object(int fd, const unsigned
char *object)
}
static void create_note(const unsigned char *object, struct msg_arg *msg,
- int append_only, const unsigned char *prev,
- unsigned char *result)
+ int append_only, int allow_empty,
+ const unsigned char *prev, unsigned char *result)
{
char *path = NULL;
@@ -202,7 +202,7 @@ static void create_note(const unsigned char *object, struct
msg_arg *msg,
free(prev_buf);
}
- if (!msg->buf.len) {
+ if (!allow_empty && !msg->buf.len) {
fprintf(stderr, _("Removing note for object %s\n"),
sha1_to_hex(object));
hashclr(result);
@@ -397,7 +397,7 @@ static int append_edit(int argc, const char **argv, const
char *prefix);
static int add(int argc, const char **argv, const char *prefix)
{
- int retval = 0, force = 0;
+ int retval = 0, force = 0, allow_empty = 0;
const char *object_ref;
struct notes_tree *t;
unsigned char object[20], new_note[20];
@@ -417,6 +417,8 @@ static int add(int argc, const char **argv, const char
*prefix)
{ OPTION_CALLBACK, 'C', "reuse-message", &msg, N_("object"),
N_("reuse specified note object"), PARSE_OPT_NONEG,
parse_reuse_arg},
+ OPT_BOOL(0, "allow-empty", &allow_empty,
+ N_("allow storing empty note")),
OPT__FORCE(&force, N_("replace existing notes")),
OPT_END()
};
@@ -460,7 +462,7 @@ static int add(int argc, const char **argv, const char
*prefix)
sha1_to_hex(object));
}
- create_note(object, &msg, 0, note, new_note);
+ create_note(object, &msg, 0, allow_em
Re: Odd git am behavior rewriting subject, adding "ASoC: " prefix
On Wed, Nov 5, 2014 at 2:12 PM, Joe Perches wrote: > I have a patch file created by git format-patch. > > Applying it via git am changes the subject prefix. > Anyone know why? > > $ git --version > git version 2.1.2 > > $ git am -i 0002-staging-ft1000-Logging-message-neatening.patch > Commit Body is: > -- > staging: ft1000: Logging message neatening > > Use a more common logging style. > > o Convert DEBUG macros to pr_debug > o Add pr_fmt > o Remove embedded function names from pr_debug > o Convert printks to pr_ > o Coalesce formats and align arguments > o Add missing terminating newlines > > Signed-off-by: Joe Perches > -- > Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all > > choosing "Y" emits: > > Applying: ASoC: staging: ft1000: Logging message neatening > > ASoC:? where does that come from? > > Looks like you have an apply-patch-msg hook installed. What does the output of 'ls -l .git/hooks' look like. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Opinions] Integrated tickets
Hi, many developers rely on ticket systems (githubs issues, trac, bugzilla, etc.). To me a ticket often has a relation to one or more commits. Hence, even if git is functional in an offline enviroment, I can't work fully since none of the ticket systems above is distributed. This can be solved with a distributed ticket system. Fossil SCM is one example of an integrated ticket system into a scm (although please don't think about this is something that must be web-based). So my question is: what's your opinions on building an integrated ticket system on top of git? and (maybe mostly for Junio) Would such system possible be included in git.git? TL;DR; Is an integrated ticket system something for git? -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] use child_process_init() to initialize struct child_process variables
From: "Junio C Hamano" Sent: Monday, November 03, 2014 11:42 PM Jeff King writes: I peeked at libgit2 and I think it does not support bundles at all yet, so that is safe. Grepping for "bundle" in dulwich turns up no hits, either. Looks like JGit does support them. I did a very brief test, and it seems to silently ignore a HEAD ref that has the NUL (I guess maybe it just rejects it as a malformed refname). We could make JGit happier either by: 1. Only including the symref magic in ambiguous cases, so that regular ones Just Work as usual. 2. Including two lines, like: $sha1 HEAD\0symref=refs/heads/master $sha1 HEAD which JGit does the right thing with (and git.git seems to, as well). Sounds sensible, even though it looks ugly X-<. I believe that the 'two HEADs' mechanism would also fall foul of the 'duplicate refs' warning (untested). Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] use child_process_init() to initialize struct child_process variables
From: "Jeff King" Subject: Re: [PATCH] use child_process_init() to initialize struct child_process variables On Tue, Nov 04, 2014 at 01:56:15PM -0800, Junio C Hamano wrote: >> 2. Including two lines, like: >> >> $sha1 HEAD\0symref=refs/heads/master >> $sha1 HEAD >> >> which JGit does the right thing with (and git.git seems to, >> as >> well). > > Sounds sensible, even though it looks ugly X-<. I have a mild preference for a syntax that is more similar to the on-wire protocol, so that connect.c::parse_feature_value() can be reused to parse it and possibly annotate_refs_with_symref_info() can also be reused by calling it from transport.c::get_refs_from_bundle(). Yeah, what I wrote above was the simplest thing that could work, and does not need to be the final form. I know that you already know what I'm about to describe below, Junio, but I want to expand on the situation for the benefit of onlookers (and potential implementers like Philip). I think I'm keeping up ;-) The online protocol is hampered by the "if you see something after a NUL, it is a capabilities string, and you must throw out the previous capabilities string and replace it with this one" historical rule. And that's why we cannot do: $sha1 refs/heads/master\0thin-pack side-band etc $sha1 HEAD\0symref=refs/heads/master as it would throw out "thin-pack", "side-band", etc. Instead we do it more like: $sha1 refs/heads/master\0thin-pack side-band etc symref=HEAD:refs/heads/master $sha1 HEAD to shove _all_ of the symref mappings into the capability string, rather than letting them ride along with their respective refs. The downside is that we are bounded in the number of symref mappings we can send (by the maximum length for a single pkt-line), and therefore send only the value of HEAD. The bundle code is not bound by this historical legacy, and could do it in a different (and more efficient and flexible) way. But it is probably saner to just keep them identical. It makes the code simpler, and having bundle as the only transport which has the extra flexibility does not really buy us much (and probably just invites confusion). -Peff Obviously bundles are always off-line, so it's reasonable to be cautious about using an on-line sideband method, though the re-use of a standard format is good. Finding the right parsing method will be important, as well as ensuring there are no races from the update of unsorted refs. Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd git am behavior rewriting subject, adding "ASoC: " prefix
On Wed, 2014-11-05 at 22:12 +1300, Chris Packham wrote: > On Wed, Nov 5, 2014 at 2:12 PM, Joe Perches wrote: > > I have a patch file created by git format-patch. [] > > ASoC:? where does that come from? [] > Looks like you have an apply-patch-msg hook installed. What does the > output of 'ls -l .git/hooks' look like. Correct. I didn't look there. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] lockfile.c: store absolute path
On 11/05/2014 03:23 AM, Scott Schmit wrote: > On Sun, Nov 02, 2014 at 07:24:37AM +0100, Michael Haggerty wrote: >> Locked paths can be saved in a linked list so that if something wrong >> happens, *.lock are removed. For relative paths, this works fine if we >> keep cwd the same, which is true 99% of time except: >> >> - update-index and read-tree hold the lock on $GIT_DIR/index really >> early, then later on may call setup_work_tree() to move cwd. >> >> - Suppose a lock is being held (e.g. by "git add") then somewhere >> down the line, somebody calls real_path (e.g. "link_alt_odb_entry"), >> which temporarily moves cwd away and back. >> >> During that time when cwd is moved (either permanently or temporarily) >> and we decide to die(), attempts to remove relative *.lock will fail, >> and the next operation will complain that some files are still locked. >> >> Avoid this case by turning relative paths to absolute before storing >> the path in "filename" field. > > This might be a little pathological, but it seems like this scheme would > run into trouble if the entire repo is moved while the lock is held. Correct. You shouldn't move a repository while Git operations are running in it. That would break for many reasons, not just because of this change to lockfile handling. Michael -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
imap-send: Use parse options API to determine verbosity
Signed-off-by: Bernhard Reiter
---
As requested per .
Documentation/git-imap-send.txt | 14 +-
imap-send.c | 25 +++--
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index c7c0d21..0897131 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -9,7 +9,7 @@ git-imap-send - Send a collection of patches from stdin to an
IMAP folder
SYNOPSIS
[verse]
-'git imap-send'
+'git imap-send' [-v] [-q]
DESCRIPTION
@@ -26,6 +26,18 @@ Typical usage is something like:
git format-patch --signoff --stdout --attach origin | git imap-send
+OPTIONS
+---
+
+-v::
+--verbose::
+ Be verbose.
+
+-q::
+--quiet::
+ Be quiet.
+
+
CONFIGURATION
-
diff --git a/imap-send.c b/imap-send.c
index 70bcc7a..7f40960 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -26,11 +26,19 @@
#include "credential.h"
#include "exec_cmd.h"
#include "run-command.h"
+#include "parse-options.h"
#ifdef NO_OPENSSL
typedef void *SSL;
#endif
-static const char imap_send_usage[] = "git imap-send < ";
+static int verbosity;
+
+static const char * const imap_send_usage[] = { "git imap-send [-v] [-q] <
", NULL };
+
+static struct option imap_send_options[] = {
+ OPT__VERBOSITY(&verbosity),
+ OPT_END()
+};
#undef DRV_OK
#define DRV_OK 0
@@ -38,8 +46,6 @@ static const char imap_send_usage[] = "git imap-send <
";
#define DRV_BOX_BAD -2
#define DRV_STORE_BAD -3
-static int Verbose, Quiet;
-
__attribute__((format (printf, 1, 2)))
static void imap_info(const char *, ...);
__attribute__((format (printf, 1, 2)))
@@ -418,7 +424,7 @@ static int buffer_gets(struct imap_buffer *b, char **s)
if (b->buf[b->offset + 1] == '\n') {
b->buf[b->offset] = 0; /* terminate the string
*/
b->offset += 2; /* next line */
- if (Verbose)
+ if (verbosity >= 0)
puts(*s);
return 0;
}
@@ -433,7 +439,7 @@ static void imap_info(const char *msg, ...)
{
va_list va;
- if (!Quiet) {
+ if (verbosity >= 0) {
va_start(va, msg);
vprintf(msg, va);
va_end(va);
@@ -445,7 +451,7 @@ static void imap_warn(const char *msg, ...)
{
va_list va;
- if (Quiet < 2) {
+ if (verbosity < 2) {
va_start(va, msg);
vfprintf(stderr, msg, va);
va_end(va);
@@ -522,7 +528,7 @@ static struct imap_cmd *issue_imap_cmd(struct imap_store
*ctx,
cmd->tag, cmd->cmd, cmd->cb.dlen,
CAP(LITERALPLUS) ? "+" : "");
- if (Verbose) {
+ if (verbosity >= 0) {
if (imap->num_in_progress)
printf("(%d in progress) ", imap->num_in_progress);
if (!starts_with(cmd->cmd, "LOGIN"))
@@ -1352,12 +1358,11 @@ int main(int argc, char **argv)
git_setup_gettext();
- if (argc != 1)
- usage(imap_send_usage);
-
setup_git_directory_gently(&nongit_ok);
git_imap_config();
+ argc = parse_options(argc, (const char **)argv, "", imap_send_options,
imap_send_usage, 0);
+
if (!server.port)
server.port = server.use_ssl ? 993 : 143;
--
2.1.2.557.g06ecad4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
fatal unresolved deltas error
Hi, I'm posting on behalf of Anjib Mulepati (Cc'ed) whose mails have troubles getting in here. Originally posted to git-users [*] but the problem appears to be too complicated for that list. [*] https://groups.google.com/d/topic/git-users/fnU3JtRuwH8/discussion Below is the original Anjib's message. I am trying to do push but getting this error $ git push Counting objects: 83, done. Delta compression using up to 8 threads. Compressing objects: 100% (16/16), done. Writing objects: 100% (17/17), 1.32 KiB | 0 bytes/s, done. Total 17 (delta 12), reused 0 (delta 0) remote: fatal: unresolved deltas left after unpacking error: unpack failed: unpack-objects abnormal exit To //myserver/git/apps/myApp.git ! [remote rejected] master -> master (unpacker error) error: failed to push some refs to '//myserver/git/apps/myApp.git' 1. When I do new clean of the repo in new directory (say \newRepoDir) I am getting error $ git clone //myserver/git/apps/myApp.git/ Cloning into 'MyApp'... done. fatal: unable to read tree 18295307f1270da3c09e3de91890652af4ff7ca8 warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry the checkout with 'git checkout -f HEAD' 2. When I do cat in new directory I am getting fatal: ..bad file error $ git cat-file -t 18295307f1270da3c09e3de91890652af4ff7ca8 fatal: git cat-file 18295307f1270da3c09e3de91890652af4ff7ca8: bad file 3. But if I do cat in my current working directory it can tell its tree $ git cat-file -t 18295307f1270da3c09e3de91890652af4ff7ca8 tree My git repo is in network share drive and its Windows 7 and I am working on Windows 7 machine too. As client tool I am using Git for Windows 1.9.2.msysgit.0. At this point I am thinking I have to push this tree in repo but not sure how to do it or really that a solution. Let me know what I have to do and if any further information is needed. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] t3312-notes-empty: Test that 'git notes' removes empty notes by default
Johan Herland writes:
> Add test cases documenting the current behavior when trying to
> add/append/edit empty notes. This is in preparation for adding
> --allow-empty; to allow empty notes to be stored.
>
> Signed-off-by: Johan Herland
> ---
> t/t3312-notes-empty.sh | 58
> ++
> 1 file changed, 58 insertions(+)
> create mode 100755 t/t3312-notes-empty.sh
By definition, an empty note is empty ;-) and devoid of useful
information other than a single bit, its existence. I would
understand a handful of tests that check "oh by the way, we should
also handle empty ones sensibly", but are you sure that a _new_
separate test script, not addition to existing test script, is worth
to check _only_ empty notes?
> diff --git a/t/t3312-notes-empty.sh b/t/t3312-notes-empty.sh
> new file mode 100755
> index 000..2806d27
> --- /dev/null
> +++ b/t/t3312-notes-empty.sh
> @@ -0,0 +1,58 @@
> +#!/bin/sh
> +
> +test_description='Test adding/editing of empty notes'
> +. ./test-lib.sh
> +
> +cat >fake_editor.sh <<\EOF
> +#!/bin/sh
> +echo "$MSG" >"$1"
> +echo "$MSG" >& 2
> +EOF
> +chmod a+x fake_editor.sh
> +GIT_EDITOR=./fake_editor.sh
> +export GIT_EDITOR
> +
> +test_expect_success 'setup' '
> + test_commit one &&
> + empty_blob=$(git hash-object -w /dev/null)
> +'
> +
> +cleanup_notes() {
> + git update-ref -d refs/notes/commits
> +}
> +
> +cat >expect_missing <<\EOF
> +commit d79ce1670bdcb76e6d1da2ae095e890ccb326ae9
> +Author: A U Thor
> +Date: Thu Apr 7 15:13:13 2005 -0700
> +
> +one
> +EOF
> +
> +verify_missing() {
> + git log -1 > actual &&
> + test_cmp expect_missing actual &&
> + ! git notes list HEAD
> +}
> +
> +for cmd in \
> + 'add' \
> + 'add -F /dev/null' \
> + 'add -m ""' \
> + 'add -c "$empty_blob"' \
> + 'add -C "$empty_blob"' \
> + 'append' \
> + 'append -F /dev/null' \
> + 'append -m ""' \
> + 'append -c "$empty_blob"' \
> + 'append -C "$empty_blob"' \
> + 'edit'
> +do
> + test_expect_success "'git notes $cmd' removes empty note" "
> + cleanup_notes &&
> + MSG= git notes $cmd &&
> + verify_missing
> + "
> +done
> +
> +test_done
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/3] t3312-notes-empty: Test that 'git notes' removes empty notes by default
Johan Herland writes:
> Add test cases documenting the current behavior when trying to
> add/append/edit empty notes. This is in preparation for adding
> --allow-empty; to allow empty notes to be stored.
>
> Improved-by: Eric Sunshine
> Signed-off-by: Johan Herland
> ---
> t/t3312-notes-empty.sh | 48
> 1 file changed, 48 insertions(+)
> create mode 100755 t/t3312-notes-empty.sh
>
> diff --git a/t/t3312-notes-empty.sh b/t/t3312-notes-empty.sh
> new file mode 100755
> index 000..44074f6
> --- /dev/null
> +++ b/t/t3312-notes-empty.sh
> @@ -0,0 +1,48 @@
> +#!/bin/sh
> +
> +test_description='Test adding/editing of empty notes'
> +. ./test-lib.sh
> +
> +write_script fake_editor <<\EOF
> + echo "$MSG" >"$1"
> +EOF
> +GIT_EDITOR=./fake_editor
> +export GIT_EDITOR
> +
> +test_expect_success 'setup' '
> + test_commit one &&
> + git log -1 >expect_missing &&
> + empty_blob=$(git hash-object -w /dev/null)
> +'
> +cleanup_notes() {
> + git update-ref -d refs/notes/commits
> +}
> +
> +verify_missing() {
> + git log -1 > actual &&
Hmph, it was unclear what exactly you are trying to check with this
one and the other "git log -1 >expect_missing".
Perhaps a comment that says "We are interested in the trailing
'Notes: ...' in the output" is necessary here, or (probably even
better) use the --format='%N' to make it crystal clear?
> + test_cmp expect_missing actual &&
> + ! git notes list HEAD
Isn't this test_must_fail (i.e. if somebody screws up to make "git
notes list" segfault, the test should fail, not taking the dying
with SEGV as a sign of success)?
> +}
> +
> +for cmd in \
> + 'add' \
> + 'add -F /dev/null' \
> + 'add -m ""' \
> + 'add -c "$empty_blob"' \
> + 'add -C "$empty_blob"' \
> + 'append' \
> + 'append -F /dev/null' \
> + 'append -m ""' \
> + 'append -c "$empty_blob"' \
> + 'append -C "$empty_blob"' \
> + 'edit'
> +do
> + test_expect_success "'git notes $cmd' removes empty note" "
> + cleanup_notes &&
> + MSG= git notes $cmd &&
> + verify_missing
> + "
> +done
Perhaps just a taste issue, but I would think
while read cmd
do
... that test eval with $cmd interpolation ...
done <<-\EOF
add
add -F /dev/null
...
EOF
would be easier to maintain and to read, without having to worry
about quoting and backslashing.
> +
> +test_done
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
smart http push setup/egit win7
This is yet another smart http thread. I must have read dozens of threads and
articles about setting this up but everyone seems to do it a little differently
so I can't tell what's right and what's not. First up, the environment, which
is the same for both server and test client...
Git 1.9.4
Eclipse Kepler SR2 with Egit
Windows 7
Server running Apache 2.2 with a bare repo
The client can connect to and successfully fetch the repo from the server over
https. However, when trying to push egit gives the error "remote does not
support http push." When attempting a push via bash, I get "return code 22 -
fatal: git-http-push failed."
Note that this server is also serving other apps out via https, hence the other
seemingly unrelated httpd entries. Eventually I will be implementing PKI
authentication for read/write access but I will cross that bridge when I get to
it. Also, ssh is not an option and neither is running it over plain text http
so please don't bother trying to convice me to use them. Anyway, here is the
httpd.conf. Forgive me for having to sanitize some of it.
ServerRoot "C:/progroot/servers/myserver"
ServerSignature Off
ServerTokens Prod
PidFile logs/httpsd.pid
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
TraceEnable off
LoadModule alias_module "C:/progroot/Apache2.2/modules/mod_alias.so"
LoadModule auth_basic_module "C:/progroot/Apache2.2/modules/mod_auth_basic.so"
LoadModule auth_digest_module "C:/progroot/Apache2.2/modules/mod_auth_digest.so"
LoadModule authn_file_module "C:/progroot/Apache2.2/modules/mod_authn_file.so"
LoadModule authz_host_module "C:/progroot/Apache2.2/modules/mod_authz_host.so"
LoadModule authz_user_module "C:/progroot/Apache2.2/modules/mod_authz_user.so"
LoadModule autoindex_module "C:/progroot/Apache2.2/modules/mod_autoindex.so"
LoadModule dir_module "C:/progroot/Apache2.2/modules/mod_dir.so"
LoadModule expires_module "C:/progroot/Apache2.2/modules/mod_expires.so"
LoadModule headers_module "C:/progroot/Apache2.2/modules/mod_headers.so"
LoadModule include_module "C:/progroot/Apache2.2/modules/mod_include.so"
LoadModule log_config_module
"C:/progroot/Apache2.2/modules/mod_log_config.so"
LoadModule mime_module "C:/progroot/Apache2.2/modules/mod_mime.so"
LoadModule negotiation_module
"C:/progroot/Apache2.2/modules/mod_negotiation.so"
LoadModule setenvif_module "C:/progroot/Apache2.2/modules/mod_setenvif.so"
LoadModule jk_module"C:/progroot/Apache2.2/modules/mod_jk.so"
LoadModule ssl_module"C:/progroot/Apache2.2/modules/mod_ssl.so"
LoadModule cgi_module"C:/progroot/Apache2.2/modules/mod_cgi.so"
LoadModule env_module"C:/progroot/Apache2.2/modules/mod_env.so"
ThreadsPerChild 300
MaxRequestsPerChild 0
MaxMemFree 512
EnableSendfile Off
EnableMMAP Off
UseCanonicalName Off
TypesConfig conf/mime.types
DefaultType text/plain
HostnameLookups Off
# Languages ##
AddLanguage en .en
LanguagePriority en
AddDefaultCharset ISO-8859-1
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
Listen 443
SSLPassPhraseDialog builtin
SSLSessionCache shm:logs/safe/ssl_cache(512000)
SSLSessionCacheTimeout 300
SSLOptions +StdEnvVars +ExportCertData +OptRenegotiate
SSLProtocol +TLSv1
SSLMutex default
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLInsecureRenegotiation on
DocumentRoot "C:/progroot/servers/myserver/webapps"
ServerName localhost:443
ServerAdmin m...@domain.com
ErrorLog logs/error.log
LogLevel error
SSLEngine on
SSLCertificateKeyFile ssl/mycert.key
SSLCertificateFile ssl/mycert.cer
SSLCipherSuite DHE-RSA-AES256-SHA:***
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0
force-response-1.0
SetEnvIf Request_URI \.gif$ dontlog
SetEnvIf Request_URI \.css$ dontlog
SetEnvIf Request_URI \.js$ dontlog
LogFormat "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %>s" common
CustomLog logs/access.log common env=!dontlog
Allow from All
Options +ExecCGI
AllowOverride All
SetEnv GIT_PROJECT_ROOT "c:/progroot/servers/myserver/webapps"
SetEnv GIT_HTTP_EXPORT_ALL
SetEnv REMOTE_USER=$REDIRECT_REMOTE_USER
ScriptAlias /git-core/ "C:/devapps/Git/libexec/git-core/git-http-backend.exe"
Any help trying to fix this file is appreciated
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] use child_process_init() to initialize struct child_process variables
On Wed, Nov 05, 2014 at 01:35:21PM -, Philip Oakley wrote: > >> 2. Including two lines, like: > [...] > I believe that the 'two HEADs' mechanism would also fall foul of the > 'duplicate refs' warning (untested). It didn't in my very brief testing of what I posted above, but maybe there is some other case that triggers it that I didn't exercise. I grepped through the code and the only "duplicate ref" warning I see comes from the refs.c code, which comes from commit_packed_refs(). If the duplicate line is HEAD, I think it shouldn't trigger that, as it is not a regular ref. That would explain why I didn't see it in my testing. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in log for path in case of identical commit
2014-11-04 17:21 GMT+01:00 Phil Hord : > On Fri, Oct 31, 2014 at 4:40 AM, Alexandre Garnier > wrote: >> When merging 2 branches with the same modifications on the both sides, >> depending the merge side, one branch disappear from the file history. >> >> To be more clear, there is a script in attachment to reproduce, but >> here is the result : >> $ git log --graph --oneline --all --decorate --name-status >> * 63c807f (HEAD, master) Merge branch 'branch' into 'master' >> |\ >> | * 5dc8785 (branch) Change line 15 on branch >> | | M file >> | * d9cd3ce Change line 25 on branch >> | | M file >> * | 7220d52 Change line 15 on master >> |/ >> | M file >> * 7566672 Initial commit >> A file >> >> $ git log --graph --oneline --all --decorate --name-status -- file >> * 5dc8785 (branch) Change line 15 on branch >> | M file >> * d9cd3ce Change line 25 on branch >> | M file >> * 7566672 Initial commit >> A file >> >> => The commit 7220d52 modified the file but is not shown in file >> history anymore. >> The expected result would be: >> * 5dc8785 (branch) Change line 15 on branch >> | M file >> * d9cd3ce Change line 25 on branch >> | M file >> | * 7220d52 Change line 15 on master >> |/ >> | M file >> * 7566672 Initial commit >> A file >> >> The order between the 2 commits on the branch is not important. >> If you do a 'cherry-pick 7220d52' or a 'merge --squash master' instead >> of applying the same modification for commit 5dc8785, you get the same >> result (cherry-picking was my initial use-case). >> If you do not create the commit d9cd3ce, then the file history show all >> commits. >> If you merge 'master' into 'branch', then the file history show all commits. > > This last line was confusing to me. But I think you've misinterpreted > the results a bit. There is no difference between "merge master into > branch" and "merge branch into master" in this case. The real reason > the "extra" commit is shown in the former case is that you used > '--all' (include all refs as commandline arguments) and the commit > which was being omitted was directly referenced by a ref, 'master'. > > When I remove the "--all" from your test script, I get consistent logs > for the two merges. > > Maybe this has misled your other tests as well. Read the "History > Simplification" section of "git help log". Thanks for pointing me out the 'history simplification' [1]. Didn't know about this and missed it in the large help of 'git log'. I will now use the '--full-history' option more often as it has more sense to me (but it's not available in EGit: bug #341028) [2]) [1] http://git-scm.com/docs/git-log#_history_simplification [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=341028 -- Alex -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: imap-send: Use parse options API to determine verbosity
Bernhard Reiter writes:
> Signed-off-by: Bernhard Reiter
> ---
> As requested per .
Heh, I didn't quite "request" it, but thanks for a patch anyway.
> diff --git a/imap-send.c b/imap-send.c
> index 70bcc7a..7f40960 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -26,11 +26,19 @@
> #include "credential.h"
> #include "exec_cmd.h"
> #include "run-command.h"
> +#include "parse-options.h"
> #ifdef NO_OPENSSL
> typedef void *SSL;
> #endif
>
> -static const char imap_send_usage[] = "git imap-send < ";
> +static int verbosity;
> +
> +static const char * const imap_send_usage[] = { "git imap-send [-v] [-q] <
> ", NULL };
> +
> +static struct option imap_send_options[] = {
> + OPT__VERBOSITY(&verbosity),
> + OPT_END()
> +};
>
> #undef DRV_OK
> #define DRV_OK 0
> @@ -38,8 +46,6 @@ static const char imap_send_usage[] = "git imap-send <
> ";
> #define DRV_BOX_BAD -2
> #define DRV_STORE_BAD -3
>
> -static int Verbose, Quiet;
So it used to be Verbose and Quiet both defaulting to 0 (false).
Now we have verbosity that defaults to 0, positive telling us to be
verbose and negative telling us to be quiet.
> __attribute__((format (printf, 1, 2)))
> static void imap_info(const char *, ...);
> __attribute__((format (printf, 1, 2)))
> @@ -418,7 +424,7 @@ static int buffer_gets(struct imap_buffer *b, char **s)
> if (b->buf[b->offset + 1] == '\n') {
> b->buf[b->offset] = 0; /* terminate the string
> */
> b->offset += 2; /* next line */
> - if (Verbose)
> + if (verbosity >= 0)
> puts(*s);
... which means this should be "if (0 < verbosity)", i.e. we do not
squeak without "-v", no?
> @@ -433,7 +439,7 @@ static void imap_info(const char *msg, ...)
> {
> va_list va;
>
> - if (!Quiet) {
> + if (verbosity >= 0) {
This one looks sensible; unless we are told to be "-q"uiet, we used
to give this message, and we will continue to do so.
> va_start(va, msg);
> vprintf(msg, va);
> va_end(va);
> @@ -445,7 +451,7 @@ static void imap_warn(const char *msg, ...)
> {
> va_list va;
>
> - if (Quiet < 2) {
> + if (verbosity < 2) {
> va_start(va, msg);
> vfprintf(stderr, msg, va);
> va_end(va);
The cut-off value "2" looks strange, but more importantly this
conversion looks bogus no matter what the cut-off value is.
"As long as the verbosity is smaller than this value, emit this
error message" That sounds backwards that you do not give the
message if you see sufficient number of "-v" options, doesn't it?
I think
if (-2 < verbosity)
would be in line with what the original logic seems to have wanted,
that is "If the caller did not ask us to be extra quiet (i.e. just
the regular Quiet=1 does not count), show this message".
> @@ -522,7 +528,7 @@ static struct imap_cmd *issue_imap_cmd(struct imap_store
> *ctx,
> cmd->tag, cmd->cmd, cmd->cb.dlen,
> CAP(LITERALPLUS) ? "+" : "");
>
> - if (Verbose) {
> + if (verbosity >= 0) {
Same comment as the one at hunk -418,7 above applies.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] imap-send: Use parse options API to determine verbosity
Signed-off-by: Bernhard Reiter
---
In reply to .
Thanks for bearing with me. I should've given the corresponding verbosity
values more thought myself in the first place.
Documentation/git-imap-send.txt | 14 +-
imap-send.c | 25 +++--
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index c7c0d21..0897131 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -9,7 +9,7 @@ git-imap-send - Send a collection of patches from stdin to an
IMAP folder
SYNOPSIS
[verse]
-'git imap-send'
+'git imap-send' [-v] [-q]
DESCRIPTION
@@ -26,6 +26,18 @@ Typical usage is something like:
git format-patch --signoff --stdout --attach origin | git imap-send
+OPTIONS
+---
+
+-v::
+--verbose::
+ Be verbose.
+
+-q::
+--quiet::
+ Be quiet.
+
+
CONFIGURATION
-
diff --git a/imap-send.c b/imap-send.c
index 70bcc7a..6efaae8 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -26,11 +26,19 @@
#include "credential.h"
#include "exec_cmd.h"
#include "run-command.h"
+#include "parse-options.h"
#ifdef NO_OPENSSL
typedef void *SSL;
#endif
-static const char imap_send_usage[] = "git imap-send < ";
+static int verbosity;
+
+static const char * const imap_send_usage[] = { "git imap-send [-v] [-q] <
", NULL };
+
+static struct option imap_send_options[] = {
+ OPT__VERBOSITY(&verbosity),
+ OPT_END()
+};
#undef DRV_OK
#define DRV_OK 0
@@ -38,8 +46,6 @@ static const char imap_send_usage[] = "git imap-send <
";
#define DRV_BOX_BAD -2
#define DRV_STORE_BAD -3
-static int Verbose, Quiet;
-
__attribute__((format (printf, 1, 2)))
static void imap_info(const char *, ...);
__attribute__((format (printf, 1, 2)))
@@ -418,7 +424,7 @@ static int buffer_gets(struct imap_buffer *b, char **s)
if (b->buf[b->offset + 1] == '\n') {
b->buf[b->offset] = 0; /* terminate the string
*/
b->offset += 2; /* next line */
- if (Verbose)
+ if (0 < verbosity)
puts(*s);
return 0;
}
@@ -433,7 +439,7 @@ static void imap_info(const char *msg, ...)
{
va_list va;
- if (!Quiet) {
+ if (verbosity >= 0) {
va_start(va, msg);
vprintf(msg, va);
va_end(va);
@@ -445,7 +451,7 @@ static void imap_warn(const char *msg, ...)
{
va_list va;
- if (Quiet < 2) {
+ if (-2 < verbosity) {
va_start(va, msg);
vfprintf(stderr, msg, va);
va_end(va);
@@ -522,7 +528,7 @@ static struct imap_cmd *issue_imap_cmd(struct imap_store
*ctx,
cmd->tag, cmd->cmd, cmd->cb.dlen,
CAP(LITERALPLUS) ? "+" : "");
- if (Verbose) {
+ if (0 < verbosity) {
if (imap->num_in_progress)
printf("(%d in progress) ", imap->num_in_progress);
if (!starts_with(cmd->cmd, "LOGIN"))
@@ -1352,12 +1358,11 @@ int main(int argc, char **argv)
git_setup_gettext();
- if (argc != 1)
- usage(imap_send_usage);
-
setup_git_directory_gently(&nongit_ok);
git_imap_config();
+ argc = parse_options(argc, (const char **)argv, "", imap_send_options,
imap_send_usage, 0);
+
if (!server.port)
server.port = server.use_ssl ? 993 : 143;
--
2.1.2.556.g44ebd84
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Nov 2014, #01; Wed, 5)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* jk/fetch-reflog-df-conflict (2014-11-04) 2 commits
(merged to 'next' on 2014-11-05 at b0476c9)
+ ignore stale directories when checking reflog existence
+ fetch: load all default config at startup
Corner-case bugfixes for "git fetch" around reflog handling.
Will merge to 'master'.
* js/diff-highlight-avoid-sigpipe (2014-11-04) 1 commit
(merged to 'next' on 2014-11-05 at b0fadd3)
+ diff-highlight: exit when a pipe is broken
Will merge to 'master'.
* ms/submodule-update-config-doc (2014-11-03) 1 commit
- submodule: clarify documentation for update subcommand
* nd/lockfile-absolute (2014-11-03) 1 commit
- lockfile.c: store absolute path
The lockfile API can get confused which file to clean up when the
process moved the $cwd after creating a lockfile.
Will merge to 'next' and cook throughout the remainder of the cycle.
* tm/line-log-first-parent (2014-11-04) 1 commit
(merged to 'next' on 2014-11-05 at 8a6f650)
+ line-log: fix crash when --first-parent is used
"git log --first-parent -L..." used to crash.
Will merge to 'master'.
* jh/empty-notes (2014-11-05) 3 commits
- notes: add --allow-empty, to allow storing empty notes
- t3312-notes-empty: test that 'git notes' removes empty notes by default
- builtin/notes: fix premature failure when trying to add the empty blob
* nd/gitignore-trailing-whitespace (2014-11-04) 1 commit
(merged to 'next' on 2014-11-05 at e7f43d6)
+ gitignore.txt: fix spelling of "backslash"
Will merge to 'master'.
--
[Stalled]
* je/quiltimport-no-fuzz (2014-10-21) 2 commits
- git-quiltimport: flip the default not to allow fuzz
- git-quiltimport.sh: allow declining fuzz with --exact option
"quiltimport" drove "git apply" always with -C1 option to reduce
context of the patch in order to give more chance to somewhat stale
patches to apply. Add an "--exact" option to disable, and also
"-C$n" option to customize this behaviour. The top patch
optionally flips the default to "--exact".
Waiting for an Ack.
* jc/push-cert-hmac-optim (2014-09-25) 2 commits
- receive-pack: truncate hmac early and convert only necessary bytes
- sha1_to_hex: split out "hex-format n bytes" helper and use it
This is "we could do this if we wanted to", not "we measured and it
improves performance critical codepath".
Will perhaps drop.
* nd/multiple-work-trees (2014-09-27) 32 commits
. t2025: add a test to make sure grafts is working from a linked checkout
. checkout: don't require a work tree when checking out into a new one
. git_path(): keep "info/sparse-checkout" per work-tree
. count-objects: report unused files in $GIT_DIR/worktrees/...
. gc: support prune --worktrees
. gc: factor out gc.pruneexpire parsing code
. gc: style change -- no SP before closing parenthesis
. checkout: clean up half-prepared directories in --to mode
. checkout: reject if the branch is already checked out elsewhere
. prune: strategies for linked checkouts
. checkout: support checking out into a new working directory
. use new wrapper write_file() for simple file writing
. wrapper.c: wrapper to open a file, fprintf then close
. setup.c: support multi-checkout repo setup
. setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()
. setup.c: convert check_repository_format_gently to use strbuf
. setup.c: detect $GIT_COMMON_DIR in is_git_directory()
. setup.c: convert is_git_directory() to use strbuf
. git-stash: avoid hardcoding $GIT_DIR/logs/
. *.sh: avoid hardcoding $GIT_DIR/hooks/...
. git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects
. $GIT_COMMON_DIR: a new environment variable
. commit: use SEQ_DIR instead of hardcoding "sequencer"
. fast-import: use git_path() for accessing .git dir instead of get_git_dir()
. reflog: avoid constructing .lock path with git_path
. *.sh: respect $GIT_INDEX_FILE
. git_path(): be aware of file relocation in $GIT_DIR
. path.c: group git_path(), git_pathdup() and strbuf_git_path() together
. path.c: rename vsnpath() to do_git_path()
. git_snpath(): retire and replace with strbuf_git_path()
. path.c: make get_pathname() call sites return const char *
. path.c: make get_pathname() return strbuf instead of static buffer
A replacement for contrib/workdir/git-new-workdir that does not
rely on symbolic links and make sharing of objects and refs safer
by making the borrowee and borrowers aware of each other.
A few tests need some tweaks for MinGW ($gmane/{257756,257757}).
Conflicts with rs/ref-transaction so ejected for now, waiting for a
reroll.
* mt/pat
Re: [PATCH] use child_process_init() to initialize struct child_process variables
From: "Jeff King" On Wed, Nov 05, 2014 at 01:35:21PM -, Philip Oakley wrote: >> 2. Including two lines, like: [...] I believe that the 'two HEADs' mechanism would also fall foul of the 'duplicate refs' warning (untested). It didn't in my very brief testing of what I posted above, but maybe there is some other case that triggers it that I didn't exercise. I'd been testing the inclusion of a duplicate of the ref that matched the HEAD symref (rather than HEAD itself), and had hit that message a few times, hence my concern. I grepped through the code and the only "duplicate ref" warning I see comes from the refs.c code, which comes from commit_packed_refs(). I had it from is_dup_ref(), also in refs.c, though I may have followed the call stack incorrectly back to the bundle effects. If the duplicate line is HEAD, I think it shouldn't trigger that, as it is not a regular ref. That would explain why I didn't see it in my testing. I've now also done a test and found the same (no warning/error) when there are two HEADs listed in the bundle preamble. Sorry for the confusion. -- Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] imap-send: Use parse options API to determine verbosity
Bernhard Reiter writes: > Signed-off-by: Bernhard Reiter > --- > In reply to . > > Thanks for bearing with me. I should've given the corresponding verbosity > values more thought myself in the first place. The original defined and even used these two variables, but as far as I can tell they were always set to 0 and nobody modified them. Hence, we would be OK as long as the end result will behave the same as before without any -v/-q from the command line ;-) Thanks. This version looks more sensible. > - if (argc != 1) > - usage(imap_send_usage); > - > setup_git_directory_gently(&nongit_ok); > git_imap_config(); > > + argc = parse_options(argc, (const char **)argv, "", imap_send_options, > imap_send_usage, 0); > + ... except we might want to check argc here and say something about missing or excess parameters, which was lost in the change in this hunk. I think (without giving it a real thought, though ;-) you would expect that nothing remains on the command line after parse_options() has done its thing, no? > if (!server.port) > server.port = server.use_ssl ? 993 : 143; -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] imap-send: Use parse options API to determine verbosity
Junio C Hamano writes:
> Thanks. This version looks more sensible.
>
>> -if (argc != 1)
>> -usage(imap_send_usage);
>> -
>> setup_git_directory_gently(&nongit_ok);
>> git_imap_config();
>>
>> + argc = parse_options(argc, (const char **)argv, "",
>> imap_send_options, imap_send_usage, 0);
>> +
>
> ... except we might want to check argc here and say something about
> missing or excess parameters, which was lost in the change in this
> hunk. I think (without giving it a real thought, though ;-) you
> would expect that nothing remains on the command line after
> parse_options() has done its thing, no?
>
>
>> if (!server.port)
>> server.port = server.use_ssl ? 993 : 143;
So here is what I ended up queuing for now. I think the new check
on argc is correct but I wouldn't be surprised if I had off-by-one
error or something silly like that ;-).
-- >8 --
From: Bernhard Reiter
Date: Wed, 5 Nov 2014 15:29:21 +0100
Subject: [PATCH] imap-send: use parse options API to determine verbosity
The -v/-q options were sort-of supported but without using the
parse-options API, and were not documented.
Signed-off-by: Bernhard Reiter
Signed-off-by: Junio C Hamano
---
Documentation/git-imap-send.txt | 14 +-
imap-send.c | 28 ++--
2 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index c7c0d21..0897131 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -9,7 +9,7 @@ git-imap-send - Send a collection of patches from stdin to an
IMAP folder
SYNOPSIS
[verse]
-'git imap-send'
+'git imap-send' [-v] [-q]
DESCRIPTION
@@ -26,6 +26,18 @@ Typical usage is something like:
git format-patch --signoff --stdout --attach origin | git imap-send
+OPTIONS
+---
+
+-v::
+--verbose::
+ Be verbose.
+
+-q::
+--quiet::
+ Be quiet.
+
+
CONFIGURATION
-
diff --git a/imap-send.c b/imap-send.c
index 70bcc7a..7f9d30e 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -26,11 +26,19 @@
#include "credential.h"
#include "exec_cmd.h"
#include "run-command.h"
+#include "parse-options.h"
#ifdef NO_OPENSSL
typedef void *SSL;
#endif
-static const char imap_send_usage[] = "git imap-send < ";
+static int verbosity;
+
+static const char * const imap_send_usage[] = { "git imap-send [-v] [-q] <
", NULL };
+
+static struct option imap_send_options[] = {
+ OPT__VERBOSITY(&verbosity),
+ OPT_END()
+};
#undef DRV_OK
#define DRV_OK 0
@@ -38,8 +46,6 @@ static const char imap_send_usage[] = "git imap-send <
";
#define DRV_BOX_BAD -2
#define DRV_STORE_BAD -3
-static int Verbose, Quiet;
-
__attribute__((format (printf, 1, 2)))
static void imap_info(const char *, ...);
__attribute__((format (printf, 1, 2)))
@@ -418,7 +424,7 @@ static int buffer_gets(struct imap_buffer *b, char **s)
if (b->buf[b->offset + 1] == '\n') {
b->buf[b->offset] = 0; /* terminate the string
*/
b->offset += 2; /* next line */
- if (Verbose)
+ if (0 < verbosity)
puts(*s);
return 0;
}
@@ -433,7 +439,7 @@ static void imap_info(const char *msg, ...)
{
va_list va;
- if (!Quiet) {
+ if (0 <= verbosity) {
va_start(va, msg);
vprintf(msg, va);
va_end(va);
@@ -445,7 +451,7 @@ static void imap_warn(const char *msg, ...)
{
va_list va;
- if (Quiet < 2) {
+ if (-2 < verbosity) {
va_start(va, msg);
vfprintf(stderr, msg, va);
va_end(va);
@@ -522,7 +528,7 @@ static struct imap_cmd *issue_imap_cmd(struct imap_store
*ctx,
cmd->tag, cmd->cmd, cmd->cb.dlen,
CAP(LITERALPLUS) ? "+" : "");
- if (Verbose) {
+ if (0 < verbosity) {
if (imap->num_in_progress)
printf("(%d in progress) ", imap->num_in_progress);
if (!starts_with(cmd->cmd, "LOGIN"))
@@ -1352,12 +1358,14 @@ int main(int argc, char **argv)
git_setup_gettext();
- if (argc != 1)
- usage(imap_send_usage);
-
setup_git_directory_gently(&nongit_ok);
git_imap_config();
+ argc = parse_options(argc, (const char **)argv, "", imap_send_options,
imap_send_usage, 0);
+
+ if (argc)
+ usage_with_options(imap_send_usage, imap_send_options);
+
if (!server.port)
server.port = server.use_ssl ? 993 : 143;
--
2.2.0-rc0-55-gac00a8d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More major
Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
Hi, I installed git 2.1.3 on sparc 8 by source code with make install, however I got git core dump during 'git clone'. I used command as below to compile and install: ./configure --prefix=/usr/local/git-2.1.3/ --enable-pthreads sudo gmake NO_GETTEXT=1 install Below I pasted the gdb bt full details, does anyone have any idea why this happened? Thanks very much! Victor (gdb) bt full #0 0xff0332ec in strlen () from /usr/lib/libc.so.1 No symbol table info available. #1 0xff0866b8 in _doprnt () from /usr/lib/libc.so.1 No symbol table info available. #2 0xff088ac0 in vsnprintf () from /usr/lib/libc.so.1 No symbol table info available. #3 0x00137c18 in vreportf (prefix=0x190038 "cannot create thread: %s", err=0x190038 "cannot create thread: %s", params=0xffbef280) at usage.c:12 msg = "cannot create thread: \0d~▒▒▒\201\001\001\0\0\036\rP\0\034▒\0\0\034▒\0\0\036\rP", '\0' , "▒\f\027\004▒\f\027\b▒\v▒▒▒\v▒▒\177\f\027$▒\v▒\b\0\036\rP", '\0' , "\001\0\030▒0\0\0\0\001\0\034▒\0\0\0\0/\0\0\0\0▒\003▒@", '\0' , "\201\001\001\0\0\036\rP\0\0\0\0\0\0\0\001\0\031\032\220\0\0\0\0\0\030▒0\0\0\0\0\0\0\0\v", '\0' ... #4 0x00137f6c in error (err=0x196128 "error: ") at usage.c:147 No locals. #5 0x00112aa0 in start_async (async=0xffbef5b0) at run-command.c:727 -- View this message in context: http://git.661346.n2.nabble.com/Installed-git-2-1-3-on-sparc-8-but-got-core-dump-during-git-clone-tp7620692.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
On Wed, Nov 05, 2014 at 09:19:04PM -0800, victor wrote: > (gdb) bt full > #0 0xff0332ec in strlen () from /usr/lib/libc.so.1 > No symbol table info available. > #1 0xff0866b8 in _doprnt () from /usr/lib/libc.so.1 > No symbol table info available. > #2 0xff088ac0 in vsnprintf () from /usr/lib/libc.so.1 > No symbol table info available. > #3 0x00137c18 in vreportf (prefix=0x190038 "cannot create thread: %s", > err=0x190038 "cannot create thread: %s", params=0xffbef280) > at usage.c:12 > msg = "cannot create thread: > \0d~▒▒▒\201\001\001\0\0\036\rP\0\034▒\0\0\034▒\0\0\036\rP", '\0' times>, > "▒\f\027\004▒\f\027\b▒\v▒▒▒\v▒▒\177\f\027$▒\v▒\b\0\036\rP", '\0' > , > "\001\0\030▒0\0\0\0\001\0\034▒\0\0\0\0/\0\0\0\0▒\003▒@", '\0' 12 times>, > "\201\001\001\0\0\036\rP\0\0\0\0\0\0\0\001\0\031\032\220\0\0\0\0\0\030▒0\0\0\0\0\0\0\0\v", > '\0' ... > #4 0x00137f6c in error (err=0x196128 "error: ") at usage.c:147 > No locals. > #5 0x00112aa0 in start_async (async=0xffbef5b0) at run-command.c:727 We tried to start a thread in start_async, but it failed. We then pass the error number to strerror(), and try to print the result. That seems to involve feeding garbage to vsnprintf, so presumably what strerror() handed us back was garbage. Are you sure that pthreads really work on your platform? Between the thread failure and the garbage strerror(), it sounds like there might be some weird linking problems. Does running "./configure --disable-pthreads" produce a working build? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: smart http push setup/egit win7
On Wed, Nov 05, 2014 at 07:11:29PM +, Jonathan wrote: > The client can connect to and successfully fetch the repo from the > server over https. However, when trying to push egit gives the error > "remote does not support http push." When attempting a push via bash, > I get "return code 22 - fatal: git-http-push failed." Git will not allow a push unless the client is authenticated (and the git client may fallback to trying dumb-http push-over-DAV, which you likely haven't configured; that would explain the second error message). The authentication check in http-backend checks whether $REMOTE_USER is set. I see in your config that you set it from $REDIRECT_REMOTE_USER, but I don't see any actual Auth directives. Do you need to add that somewhere? There are some Apache recipes in the git-http-backend manpage that might help. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Opinions] Integrated tickets
On Wed, Nov 05, 2014 at 01:44:29PM +0100, Fredrik Gustafsson wrote: > So my question is: > > what's your opinions on building an integrated ticket system on top of git? I think it's a nice concept, but there have been several implementations, and AFAIK none of them is incredibly popular. I do not know offhand if the problem is the concept or the implementations (I looked at them long ago but don't remember enough to provide any sort of reasonable critique). I started to assemble a list of pointers, but I realized that 4 out of 5 of the projects that I had looked at a few years ago no longer exist. ;) Here's an article from last year with a nice overview of the (non-)state and links to other sources: https://www.stationary-traveller.eu/distributed-bug-trackers.html > and (maybe mostly for Junio) > > Would such system possible be included in git.git? I am not Junio, but I would have to say: probably not. This seems like something that can very easily sit on _top_ of git and use the git plumbing. In the long-term git may want to grow features to make integration more seamless, but we'd probably want to add them in a more functionality-agnostic way (e.g., don't grow an option to attach bug information to a commit; grow an option to attach arbitrary information to a commit. We already have this part in the form of "git notes", but there are likely other opportunities for integration). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
Hi, Thanks for the input. With below command, I got new error as below: ./configure --prefix=/usr/local/git-2.1.3/ --disable-pthreads sudo gmake NO_GETTEXT=1 install Undefined first referenced symbol in file type_cas_unlock builtin/index-pack.o type_cas_lock builtin/index-pack.o ld: fatal: Symbol referencing errors. No output written to git How can I overcome this? Thanks, Victor -- View this message in context: http://git.661346.n2.nabble.com/Installed-git-2-1-3-on-sparc-8-but-got-core-dump-during-git-clone-tp7620692p7620693.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
On Wed, Nov 05, 2014 at 10:34:27PM -0800, victor wrote: > Thanks for the input. With below command, I got new error as below: > > ./configure --prefix=/usr/local/git-2.1.3/ --disable-pthreads > sudo gmake NO_GETTEXT=1 install > > Undefined first referenced > symbol in file > type_cas_unlock builtin/index-pack.o > type_cas_lock builtin/index-pack.o > ld: fatal: Symbol referencing errors. No output written to git > > How can I overcome this? The NO_PTHREADS build was broken in v2.1.2 and v2.1.3. The fix, from commit e0e2128 (index-pack: fix compilation with NO_PTHREADS, 2014-10-11) is in the current "master" branch. If you want to apply it manually, it is just: diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 792c66c..a369f55 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -185,6 +185,9 @@ static void cleanup_thread(void) #define deepest_delta_lock() #define deepest_delta_unlock() +#define type_cas_lock() +#define type_cas_unlock() + #endif -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
Hi Jeff, Thanks for your help, as your suggestion, I can compile/install git with --disable_ptheads now. While ran 'git clone', it still got core dump. Would you please have a look at it? (gdb) bt full #0 0xff0332ec in strlen () from /usr/lib/libc.so.1 No symbol table info available. #1 0xff0866b8 in _doprnt () from /usr/lib/libc.so.1 No symbol table info available. #2 0xff088ac0 in vsnprintf () from /usr/lib/libc.so.1 No symbol table info available. #3 0x00137c18 in vreportf (prefix=0x190038 "cannot create thread: %s", err=0x190038 "cannot create thread: %s", params=0xffbeec88) at usage.c:12 msg = "' for tags you want to propagate.\" >&2\n\t\t\texit 1\n\t\tfi \n\t\t;;\n\trefs/tags/*,delete)\n\t\t# delete tag\n\t\tif [ \"$allowdeleteta g\" != \"true\" ]; then\n\t\t\techo \"*** Deleting a tag is not allowed in t his repository\""... Thanks, Victor -- View this message in context: http://git.661346.n2.nabble.com/Installed-git-2-1-3-on-sparc-8-but-got-core-dump-during-git-clone-tp7620692p7620694.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] docs/credential-store: s/--store/--file/
On Thu, Oct 23, 2014 at 05:14:56PM +, Hopkins, Jesse wrote: > The man page for git-credential-store at > http://git-scm.com/docs/git-credential-store > and > https://www.kernel.org/pub/software/scm/git/docs/git-credential-store.html > > incorrectly state that the option to change the credential storage > path is '--store'. The name of the option should be '--file'. I have > noticed this running it 1.8.5.3 Thanks. Here's a fix. -- >8 -- The option name "--store" was used early in development, but never even made it into an applied patch, let alone a released version of git. I forgot to update the matching documentation at the time, though. Noticed-by: Jesse Hopkins Signed-off-by: Jeff King --- Documentation/git-credential-store.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt index 8481cae..bc97071 100644 --- a/Documentation/git-credential-store.txt +++ b/Documentation/git-credential-store.txt @@ -29,7 +29,7 @@ linkgit:gitcredentials[7] or `EXAMPLES` below. OPTIONS --- ---store=:: +--file=:: Use `` to store credentials. The file will have its filesystem permissions set to prevent other users on the system -- 2.1.2.596.g7379948 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
