Re: [PATCH v1 4/4] hashmap: add string interning API
Karsten Blees karsten.bl...@gmail.com writes: --- a/t/t0011-hashmap.sh +++ b/t/t0011-hashmap.sh @@ -237,4 +237,17 @@ test_expect_success 'grow / shrink' ' ' +test_expect_success 'string interning' ' + +test_hashmap intern value1 +intern Value1 +intern value2 +intern value2 + value1 +Value1 +value2 +value2 + +' Indentation is broken here, but it's consistant with the current style of the file. You may want a modernize style patch before yours and then indent properly, but that shouldn't block inclusion. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 v1 0/4] hashmap improvements
Karsten Blees karsten.bl...@gmail.com writes: Here are a few small hashmap improvements, partly resulting from recent discussion of the config-cache topic. Karsten Blees (4): hashmap: factor out getting an int hash code from a SHA1 hashmap: improve struct hashmap member documentation hashmap: add simplified hashmap_get_from_hash() API hashmap: add string interning API The patch series look good to me (but that's not a detailed review, just a moderately quick look). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 RFC v2 00/19] Enable options --signoff, --reset-author for pick, reword
On 07/02/2014 07:47 PM, Fabian Ruch wrote: [...] 2. Add user options to main commands Enable options --signoff, --reset-author for pick, reword (19/19) The last stage was added in this reroll. It enables the parsing of line options for to-do list commands, which is still restricted to options without arguments because it is unclear how spaces can be parsed as characters rather than separators where needed. For instance, if we were to support pick --author=A U Thor fa1afe1 Some changes then read(1) would hand us the tokens `--author=A`, `U` and `Thor` instead of `--author=A U Thor`, which we would want to relay to `do_pick`. Interpreting the shell quoting would help. However, eval(1) seems to disqualify itself as an interpreter because the to-do list entry could potentially contain any shell command line. This could be both a security and a usability issue. For this reason, the patch series still hasn't graduated from being RFC. [...] It is not required that a patch series solves all of the problems in the universe. If these patches implements some useful features robustly, and if there is no reason to expect that future enhancements will require the user interface to be changed in a backwards-compatible way, then there is no reason that this patch series has to be held as an RFC hostage to some hypothetical future. 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
Re: [PATCH v5 2/7] replace: add test for --graft
On Wed, Jul 2, 2014 at 10:49 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t6050-replace.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 68b3cb2..ca45a84 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -351,4 +351,16 @@ test_expect_success 'replace ref cleanup' '
test -z $(git replace)
'
+test_expect_success '--graft with and without already replaced object' '
+ test $(git log --oneline | wc -l) = 7
+ git replace --graft $HASH5
+ test $(git log --oneline | wc -l) = 3
+ git cat-file -p $HASH5 | test_must_fail grep parent
Please do not run non-git command under test_must_fail.
Ok, I think I will just use the following then:
test_must_fail git rev-parse $HASH5^1
+ test_must_fail git replace --graft $HASH5 $HASH4 $HASH3
+ git replace --force -g $HASH5 $HASH4 $HASH3
+ git cat-file -p $HASH5 | grep parent $HASH4
+ git cat-file -p $HASH5 | grep parent $HASH3
+ git replace -d $HASH5
+'
+
test_done
For all these git cat-file -p $commit | grep ..., I would think
you should add commit_has_parents helper function to allow a bit
more careful testing. As written, the test will mistake a commit
with string parent $HASHx anywhere, not in the header part, and
the test does not ensure that $HASH{3,4} is the {first,second}
parent.
commit_has_parents $HASH5 $HASH4 $HASH3
would then may be implemented like:
commit_has_parents () {
git cat-file commit $1 payload
sed -n -e '/^$/q' -e 's/^parent //p' payload actual
shift
printf 'parent %s\n' $@ expect
test_cmp expect actual
}
I think I'll rather use something like:
test $(git rev-parse $HASH5^1) = $HASH4
test $(git rev-parse $HASH5^2) = $HASH3
...
Thanks,
Christian.
--
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 5/7] replace: refactor replacing parents
On Wed, Jul 2, 2014 at 11:05 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder chrisc...@tuxfamily.org writes: Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- builtin/replace.c | 42 +- 1 file changed, 25 insertions(+), 17 deletions(-) diff --git a/builtin/replace.c b/builtin/replace.c index 3515979..ad47237 100644 --- a/builtin/replace.c +++ b/builtin/replace.c @@ -295,27 +295,14 @@ static int edit_and_replace(const char *object_ref, int force) return replace_object_sha1(object_ref, old, replacement, new, force); } -static int create_graft(int argc, const char **argv, int force) +static void replace_parents(struct strbuf *buf, int argc, const char **argv) It is somewhat strange to see that a new function introduced earlier in the series is rewritten with a refactoring. Shouldn't the new function have been done right from the beginning instead? Yeah, I will do it right from the beginning in the next patch series. -- 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] git-am: add option to extract email Message-Id: tag into commit log
On 07/02/2014 08:17 PM, Junio C Hamano wrote: Avi Kivity a...@cloudius-systems.com writes: + if test 't' == $message_id + then + grep ^Message-Id: $dotest/info || true + fi if test '' != $ADD_SIGNOFF then echo $ADD_SIGNOFF Seeing how existing code carefully makes sure that ADD_SIGNOFF has an empty line before it when and only when necessary to ensure that there is a blank after the existing log message, I would suspect that this patch that blindly inserts a line is doubly wrong. The output from grep may be appended without adding a blank when necessary, and appending of ADD_SIGNOFF may end up adding an extra blank after Message-Id. Am I reading the patch wrong? Yes, you're right. Will have to redo the logic for deciding whether we already have a tag stanza or not. -- 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 6/7] replace: remove signature when using --graft
On Wed, Jul 2, 2014 at 11:19 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
It could be misleading to keep a signature in a
replacement commit, so let's remove it.
Note that there should probably be a way to sign
the replacement commit created when using --graft,
but this can be dealt with in another commit or
patch series.
Both paragraphs read very sensibly.
Thanks.
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -344,6 +344,11 @@ static int create_graft(int argc, const char **argv,
int force)
replace_parents(buf, argc, argv);
+ if (remove_signature(buf))
+ warning(_(the original commit '%s' has a gpg signature.\n
+ It will be removed in the replacement commit!),
Hmmm... does the second line of this message start with the usual
warning: prefix?
Ok, I will use following:
if (remove_signature(buf)) {
warning(_(the original commit '%s' has a gpg signature.), old_ref);
warning(_(the signature will be removed in the replacement commit!));
}
diff --git a/commit.c b/commit.c
index fb7897c..54e157d 100644
--- a/commit.c
+++ b/commit.c
@@ -1177,6 +1177,40 @@ int parse_signed_commit(const struct commit *commit,
return saw_signature;
}
+int remove_signature(struct strbuf *buf)
+{
+ const char *line = buf-buf;
+ const char *tail = buf-buf + buf-len;
+ int in_signature = 0;
+ const char *sig_start = NULL;
+ const char *sig_end = NULL;
+
+ while (line tail) {
+ const char *next = memchr(line, '\n', tail - line);
+ next = next ? next + 1 : tail;
This almost makes me wonder if we want something similar to
strchrnul() we use for NUL-terminated strings, and I suspect that
you would find more instances by running git grep -A2 memchr.
I don't know what such a helper function should be named, though.
Certainly not memchrnul().
I can add this to a GSoC microproject page for next year.
+ if (in_signature line[0] == ' ')
+ sig_end = next;
+ else if (starts_with(line, gpg_sig_header)
+ line[gpg_sig_header_len] == ' ') {
+ sig_start = line;
+ sig_end = next;
+ in_signature = 1;
+ } else {
+ if (*line == '\n')
+ /* dump the whole remainder of the buffer */
+ next = tail;
+ in_signature = 0;
+ }
+ line = next;
+ }
+
+ if (sig_start)
+ strbuf_remove(buf, sig_start - buf-buf, sig_end - sig_start);
If there are two instances of gpg_sig, this will remove only the
last one, but there is no chance both signatures of such a commit
can validate OK, and we won't be losing something in between anyway,
so it should be fine.
Ok.
Thanks,
Christian.
--
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 7/7] replace: add test for --graft with signed commit
On Wed, Jul 2, 2014 at 11:22 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder chrisc...@tuxfamily.org writes: +test_expect_success GPG 'set up a signed commit' ' + echo line 17 hello + echo line 18 hello Style? Yeah, I will change it to: echo line 17 hello echo line 18 hello + git add hello + test_tick + git commit --quiet -S -m hello: 2 more lines in a signed commit + HASH8=$(git rev-parse --verify HEAD) + git verify-commit $HASH8 +' + +test_expect_success GPG '--graft with a signed commit' ' + git cat-file commit $HASH8 orig + git replace --graft $HASH8 + git cat-file commit $HASH8 repl + test_must_fail grep gpgsig repl + diff -u orig repl | grep ^-parent $HASH7 + diff -u orig repl | grep ^-gpgsig -BEGIN PGP SIGNATURE- Almost the same comment as the one for 2/7 applies here. Ok, I will find a way to make it better. Thanks, Christian. -- 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: Show containing branches in log?
Robert Dailey: Is there a way to graphically see what is the nearest named ref to the specified commit in the logs? git log --graph --decorate commit.. will display all the commits that happened after the commit commit, with the branch names indicated, with lines indicating the ancestry. That's the closest I can come to think of. -- \\// Peter - http://www.softwolves.pp.se/ -- 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
Git for Windows no longer on Google Code
Dear friends of Git, the Git for Windows team, myself included, tried quite a couple of times to mark the old home of Git for Windows on Google Code as obsolete. Unfortunately, it is not possible to disable issue trackers nor downloads (and Google Search helpfully insists on listing them as top hits, still). It is not even possible to forward to a new project home: we tried literally twenty times to hit the Project moved button with the new URL -- http://msysgit.github.io/ -- but all it did was reset the URL to http://; and give a 500. That's an error. when browsing the old URL. The link supposedly allowing to report the error leads to a read-only knowledge base with no way to inform any responsible developer of the bug. The only way was to delete the old project home, with no automatic redirection and no hint for users where to look instead. Therefore it is with great sadness that I have to resort to sending this mail and hoping that it reaches at least a part of the people who are from now on undoubtedly surprised to see a Google. One account. All of Google. page instead of being forwarded to http://msysgit.github.io/. I am seriously sorry about the inconvenience, wishing there was anything I could do about this, Johannes -- 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
[BUG] rebase no longer omits local commits
Starting with git 1.9.0, rebase no longer omits local commits that appear in both the upstream and local branches. I've bisected this down to commit bb3f458: rebase: fix fork-point with zero arguments. The attached script reproduces the problem. Reverting the aforementioned commit fixes the problem. A failed run of this script will result in conflicts. A successful run against master with bb3f458 reverted ends as follows: From /tmp/rebase-issue/maint fe401cd..955af04 master - origin/master fatal: Not a valid object name: '' First, rewinding head to replay your work on top of it... Applying: Third change (I'm not sure if that fatal: Not a valid object name: '' is of any concern. It started appearing for me at some point during the bisect.) Let me know if there's more I can do to help. #!/bin/bash # git-rebase is supposed to drop commits that it finds in both the # local and upstream branches. As of 1.9.0, this isn't happening. # This script reproduces the problem. # I've bisected the issue down to commit bb3f458. Reverting that commit # solves the problem. # Run this in a directory where you have create privs. # At the end, if there are conflicts, then the test has failed. # Create a repo. mkdir rebase-issue cd rebase-issue mkdir maint cd maint git init # Create a README file and put some text in it echo Hi there! README git add README git commit -a -m Initial commit # Clone the repo for dev cd .. git clone maint dev # Dev makes *two* changes to the *same* area. cd dev # edit something, make some typos echo Freekwently Mispeled Werdz README git commit -a -m First change # edit same thing, fix those typos echo Frequently Misspelled Words README git commit -a -m Second change # Create patches to send to maintainer... git format-patch -M origin/master mv *.patch ../maint # Add a third change that should make it through for completeness. echo Frequently Misspelled Words version 2 README git commit -a -m Third change # We have to sleep (to make sure the times do not match?). # If we don't, this script will succeed on fast machines. # This can probably be reduced to 2 which should guarantee that # the seconds will turn over on the clock. echo echo Waiting 5 seconds to make sure apply time is different from patch time... sleep 5 echo echo Maint applies patches... cd ../maint git am -3 *.patch echo echo Dev does the fetch/rebase... cd ../dev git fetch git rebase echo git --version
bug in os x - deleted file on clone
Hello, When I clone a repository using git on osx this happens : grandmesse:code dubbed$ git clone ssh://git@[snip]/puppet.git Cloning into 'puppet'... remote: Counting objects: 5313, done. remote: Compressing objects: 100% (4086/4086), done. remote: Total 5313 (delta 2200), reused 2996 (delta 841) Receiving objects: 100% (5313/5313), 2.07 MiB | 0 bytes/s, done. Resolving deltas: 100% (2200/2200), done. Checking connectivity... done. grandmesse:code dubbed$ cd puppet grandmesse:puppet dubbed$ git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use git add/rm file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) deleted:modules/areversat-nidautoprov/files/dhcp/staticDHCPd/staticDHCPd no changes added to commit (use git add and/or git commit -a) - This does not happen under linux so the repository isn't the issue. Thanks, D -- David Salib Spécialiste systèmes / Systems specialist Fibrenoire - www.fibrenoire.ca A: 550 ave Beaumont, suite 320, Montreal, Qc, H3N 1V1 T. 514 907-3002 x133 -- 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 os x - deleted file on clone
On Thu, Jul 03, 2014 at 11:53:28AM -0400, David Salib wrote: When I clone a repository using git on osx this happens : [...] deleted:modules/areversat-nidautoprov/files/dhcp/staticDHCPd/staticDHCPd [...] This does not happen under linux so the repository isn't the issue. Does the repository have similar paths distinguished only by case? Try looking at the output of: git ls-tree HEAD If your file system is case-insensitive, then it might not be possible to represent the repository contents on disk (git has some workarounds to handle case-insensitivty, but fundamentally such filesystems cannot represent FOO and foo with different contents, and you are best off not trying to store that in your repository). -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: [PATCH v4 1/2] add `config_set` API for caching config files
On 7/2/2014 10:30 PM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
diff --git a/Documentation/technical/api-config.txt
b/Documentation/technical/api-config.txt
index 230b3a0..2c02fee 100644
--- a/Documentation/technical/api-config.txt
+++ b/Documentation/technical/api-config.txt
@@ -77,6 +77,75 @@ To read a specific file in git-config format, use
+`git_config_get_value` returns 0 on success, or -1 for no value found.
+
+`git_config_get_value_multi` allocates and returns a `string_list`
+containing all the values for the key passed as parameter, sorted in order
+of increasing priority (Note: caller has to call `string_list_clear` on
+the returned pointer and then free it).
+
+`git_config_get_value_multi` returns NULL for no value found.
+
+`git_config_clear` is provided for resetting and invalidating the cache.
+
+`git_config_iter` gives a way to iterate over the keys in cache. Existing
+`git_config` callback function signature is used for iterating.
Instead of doing prose above and then enumeration below,
consistently using the enumeration-style would make the descriptions
of API functions easier to find and read. Also show what parameters
each function takes. E.g.
Noted.
A few random thoughts.
- Are a value for the variable is found and no value for the
variable is found the only possible outcome? Should somebody
(not necessarily the calling code) be notified of an error---for
example, if you opened a config file successfully but later found
that the file could not be parsed due to a syntax error or an I/O
error, is it possible the caller of this function to tell, or are
these just some special cases of variable not found?
The syntactical errors when parsing the file are shown when it fails to
construct the hashmap. Whenever a caller calls for a value for the first
time, the file is read and parsed and if it fails during parsing it dies
raising a error specifying the lineno and filename.
Variable not found means that the variable is not present in the file,
nothing more. Note: the hashmap code uses git_config() parsing stack
so whatever error it raises in normal git_config() invocation, it
would be raised here too.
- The same goes for the multi variant but it is a bit more grave,
as a function that returns an int can later be updated to
return different negative values to signal different kinds of
errors, but a function that returns a pointer to string-list can
only return one kind of NULL ;-)
Null pointer just means no variable found in the files. What other kind
of errors may arise?
- For the purpose of git_config_get_value(), what is the value
returned for core.filemode when the configuration file says
[core] filemode\n, i.e. when git_config() callback would get a
NULL for value to signal a boolean true?
NULL in value pointer with 0 return value denoting variable found.
- Is there a reason why you need a separate and new config_iter?
What does it do differently from the good-old git_config() and
how? It does not belong to Querying for Specific Variables
anyway.
You mentioned previously in the list for a analogue to git_config()
which supports iterating over the keys.
The link is [1] I think, gmane is not working for me currently.
http://thread.gmane.org/gmane.comp.version-control.git/252567
+The config API also provides type specific API functions which do conversion
+as well as retrieval for the queried variable, including:
+
+`git_config_get_int`::
+Parse the retrieved value to an integer, including unit factors. Dies on
+error; otherwise, allocates and copies the integer into the dest parameter.
+Returns 0 on success, or 1 if no value was found.
allocates and copies Is a caller forced to do something like
this?
int *val;
if (!git_config_get_int(int.one, val)) {
use(*val);
free(val);
}
I'd expect it to be more like:
int val;
if (!git_config_get_int(int.one, val))
use(val);
Yup, you are right, my fault.
Also, is there a reason why the not found signal is 1 (as
opposed to -1 for the lower-level get_value() API)?
Many of the type specific functions return -1 for wrongful parsing
like git_config_get_string and git_config_get_maybe_bool, that is
why I changed the return value for such functions.
+Custom Configsets
+-
+
+A `config_set` points at an ordered set of config files, each of
+which represents what was read and cached in-core from a file.
This over-specifies the implementation. Judging from the list of
API functions below, an implementation is possible without having to
keep track of what source files were fed in what order (i.e. it can
just keep a single hash-table of read values and incrementally parse
the new contents given via configset-add-file into it, without even
recording the origins,
Re: Show containing branches in log?
On Thu, Jul 03, 2014 at 03:18:42PM +0100, Peter Krefting wrote:
Robert Dailey:
Is there a way to graphically see what is the nearest named ref to the
specified commit in the logs?
git log --graph --decorate commit..
will display all the commits that happened after the commit commit, with
the branch names indicated, with lines indicating the ancestry. That's the
closest I can come to think of.
The trouble with --decorate is that you have to manually find the
decorated commit that is closest. That can be hard if you have a lot of
commits.
There is also --source, which will transmit the source name down
from parent to child. So if you do:
git log --all --source
each tip will be painted with its ref name, and will pass that to its
ancestors as we walk the graph. Of course ancestors that have multiple
children (e.g., something that got merged) will only show one source,
but that painting will never cross an actual branch boundary (so if
branch A merged branch B, the commits that are in B will still get
painted as B).
The big downside is that you are now traversing _all_ refs, instead of
just the ones you wanted. We could fix that by letting you specify a set
of refs to paint. For example, with the patch below, you can do:
git log --source=refs/heads
and see only commits in HEAD, but painted by their source in
refs/heads/*. I'm not planning to work on it further anytime soon, but
if somebody wants to pick it up and run with it, feel free. I think
before inclusion one would want to consider:
1. Calling it --contains instead of --source, since it is not
really about the source anymore.
2. Moving the storage out of commit-util into a commit-slab. This
would prevent it from conflicting with --source (for that matter,
it would be nice if --source used a slab, too).
3. Rather than showing one arbitrary way of getting to the commit,
keep track of _all_ of them. Unfortunately this is not quite a true
list of which refs contain the commit, as we might show the commit
before its parent paints down to it (this can happen if the commit
timestamps are out of order, I think). We could get around that by
using --topo-order.
4. Make the output less ugly (probably more like --decorate, with
colors and parentheses).
---
diff --git a/builtin/log.c b/builtin/log.c
index a7ba211..8ad7b46 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -25,6 +25,7 @@
#include version.h
#include mailmap.h
#include gpg-interface.h
+#include refs.h
/* Set a default date-time format for git log (log.date config variable) */
static const char *default_date_mode = NULL;
@@ -116,16 +117,61 @@ static void cmd_log_init_defaults(struct rev_info *rev)
rev-diffopt.touched_flags = 0;
}
+struct source_opt {
+ struct string_list refs;
+ int enabled;
+};
+
+static int parse_opt_source(const struct option *opt, const char *arg, int
unset)
+{
+ struct source_opt *source = opt-value;
+
+ if (unset) {
+ source-enabled = 0;
+ string_list_clear(source-refs, 0);
+ } else {
+ source-enabled = 1;
+ if (arg)
+ string_list_append(source-refs, arg);
+ }
+
+ return 0;
+}
+
+static int paint_source_ref(const char *refname, const unsigned char *sha1,
+ int flags, void *data)
+{
+ const char *prefix = data;
+ struct commit *c = lookup_commit_reference_gently(sha1, 1);
+
+ if (c !c-util) {
+ struct strbuf buf = STRBUF_INIT;
+ strbuf_addstr(buf, prefix);
+ strbuf_addstr(buf, refname);
+ c-util = strbuf_detach(buf, NULL);
+ }
+ return 0;
+}
+
+static int paint_source_refs_in(struct string_list_item *it, void *data)
+{
+ for_each_ref_in(it-string, paint_source_ref, it-string);
+ return 0;
+}
+
+
static void cmd_log_init_finish(int argc, const char **argv, const char
*prefix,
struct rev_info *rev, struct setup_revision_opt *opt)
{
struct userformat_want w;
- int quiet = 0, source = 0, mailmap = 0;
+ struct source_opt source = { STRING_LIST_INIT_DUP, 0 };
+ int quiet = 0, mailmap = 0;
static struct line_opt_callback_data line_cb = {NULL, NULL,
STRING_LIST_INIT_DUP};
const struct option builtin_log_options[] = {
OPT__QUIET(quiet, N_(suppress diff output)),
- OPT_BOOL(0, source, source, N_(show source)),
+ { OPTION_CALLBACK, 0, source, source, N_(refs), N_(show
source),
+ PARSE_OPT_OPTARG, parse_opt_source },
OPT_BOOL(0, use-mailmap, mailmap, N_(Use mail map file)),
{ OPTION_CALLBACK, 0, decorate, NULL, NULL, N_(decorate
options),
PARSE_OPT_OPTARG, decorate_callback},
@@ -164,8 +210,10 @@ static void cmd_log_init_finish(int argc, const char
**argv, const char
Re: Support for EBCDIC
On Wed, Jul 02, 2014 at 07:39:12PM -0700, Scott McKellar wrote: Is Git supposed to be usable in an environment where the execution character set is EBCDIC? Not really. In addition to the cases you found (and I would be surprised if there are not more, such as our reimplementation of ctype.h), we assume: - we can intermingle ASCII from string literals with user data to form diffs, commit objects, network protocols, etc. This is actually a problem not just for EBCDIC, but for any encoding which is not an ASCII-superset (like UTF-16). - many outputs from git should be ASCII in order to interoperate with the outside world (object headers, network protocols, etc). So I'd be surprised if things worked well in an EBCDIC environment (but I have never worked with one, so maybe I do not understand all of the implications). -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
Wish bug report: Comments to the state group may be inconsistent with real state
Hello to the community! I noticed when HEAD is changed outside the Wish (for example in console) while Amend Last Commit option in the GUI is chosen, committing state becomes inconsistent. Staged files list and commit description looks like New Commit is chosen, but options group still points to Amend Last Commit. I consides that this is a bug. My Wish version is 0.19. --- Oleg Yarigin arha...@gmail.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 v5 2/7] replace: add test for --graft
Christian Couder christian.cou...@gmail.com writes:
On Wed, Jul 2, 2014 at 10:49 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t6050-replace.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 68b3cb2..ca45a84 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -351,4 +351,16 @@ test_expect_success 'replace ref cleanup' '
test -z $(git replace)
'
+test_expect_success '--graft with and without already replaced object' '
+ test $(git log --oneline | wc -l) = 7
+ git replace --graft $HASH5
+ test $(git log --oneline | wc -l) = 3
+ git cat-file -p $HASH5 | test_must_fail grep parent
Please do not run non-git command under test_must_fail.
Ok, I think I will just use the following then:
test_must_fail git rev-parse $HASH5^1
...
See below.
+ test_must_fail git replace --graft $HASH5 $HASH4 $HASH3
+ git replace --force -g $HASH5 $HASH4 $HASH3
+ git cat-file -p $HASH5 | grep parent $HASH4
+ git cat-file -p $HASH5 | grep parent $HASH3
+ git replace -d $HASH5
+'
+
test_done
For all these git cat-file -p $commit | grep ..., I would think
you should add commit_has_parents helper function to allow a bit
more careful testing. As written, the test will mistake a commit
with string parent $HASHx anywhere, not in the header part, and
the test does not ensure that $HASH{3,4} is the {first,second}
parent.
commit_has_parents $HASH5 $HASH4 $HASH3
would then may be implemented like:
commit_has_parents () {
git cat-file commit $1 payload
sed -n -e '/^$/q' -e 's/^parent //p' payload actual
shift
printf 'parent %s\n' $@ expect
test_cmp expect actual
}
I think I'll rather use something like:
test $(git rev-parse $HASH5^1) = $HASH4
test $(git rev-parse $HASH5^2) = $HASH3
...
Even in that case, I'd suggest using the same commit_has_parents
abstraction, which you will also be using to check the replaced to
be a new root case in the earlier part of this test.
In case you do not get what I mean by in that case, you are saying
that you will now be testing a different thing. You can test what
your new code produces at the bit level by directly obtaining the
resulting object via cat-file and that lets you not to depend on
the rest of the system (i.e. the part that allows you to pretend an
existing object you have a corresponding replace ref for has contents
of a totally different object) working correctly. Or you can choose
to test the system as a whole (i.e. not just the git replace produced
a new object with contents you planned to fabricate, but also by
having a replace ref, you can let the rest of the system use th
contents of that object when asked for the replaced object).
The implementation suggested in my previous message was in line with
the former, because your use of cat-file seemed to indicate that
you wanted to avoid depending on the rest of the system to test this
new feature in your new tests. You seem to be saying that you now
want to take the other approach of testing both at the same time.
I am fine with either approach, but I want to make sure that you are
aware of the distinction. The last thing I want to see is to flip
the approach you take to test not because testing as a whole is
better than testing one thing without getting interfered by
potential breakage in other parts but because testing as a whole
is easier.
The implementation of commit_has_parents that tests the system as a
whole may look like
commit=$1 parent_number=1
shift
for parent
do
test $(git rev-parse --verify $commit^$parent_number) =
$parent ||
return 1
parent_number=$(( $parent_number + 1 ))
done
test_must_fail git rev-parse $commit^$parent_number
and you would still use it like this:
commit_has_parents $HASH5 ;# must have no parent
commit_has_parents $HASH5 $HASH4 $HASH3 ;# must have these parents
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: [BUG] rebase no longer omits local commits
On Thu, Jul 03, 2014 at 11:14:26AM -0400, Ted Felix wrote:
Starting with git 1.9.0, rebase no longer omits local commits that
appear in both the upstream and local branches.
I've bisected this down to commit bb3f458: rebase: fix fork-point with
zero arguments. The attached script reproduces the problem. Reverting
the aforementioned commit fixes the problem.
A failed run of this script will result in conflicts. A successful run
against master with bb3f458 reverted ends as follows:
From /tmp/rebase-issue/maint
fe401cd..955af04 master - origin/master
fatal: Not a valid object name: ''
First, rewinding head to replay your work on top of it...
Applying: Third change
(I'm not sure if that fatal: Not a valid object name: '' is of any
concern. It started appearing for me at some point during the bisect.)
It is the problem that bb3f458 fixes. The change in behaviour is
actually introduced by ad8261d (rebase: use reflog to find common base
with upstream).
In your example, I think this is working as designed. You can restore
the previous behaviour either with `git rebase --no-fork-point` or with
`git rebase @{u}`.
The change is designed to help users recover from an upstream rebase, as
described in the DISCUSSION ON FORK-POINT MODE section of
git-merge-base(1) and makes `git rebase` match the behaviour of
`git pull --rebase` so that:
git fetch
git rebase
really is equivalent to:
git pull --rebase
--
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: Show containing branches in log?
On 2 July 2014 16:50, Robert Dailey rcdailey.li...@gmail.com wrote: I know that with the `git branch` command I can determine which branches contain a commit. Is there a way to represent this graphically with `git log`? Sometimes I just have a commit, and I need to find out what branch contains that commit. The reason why `git branch --contains` doesn't solve this problem for me is that it names almost all branches because of merge commits. Too much ancestry has been built since this commit, so there is no way to find the closest branch that contains that commit. Is there a way to graphically see what is the nearest named ref to the specified commit in the logs? I have created a script for just this functionality which I use very often, and have created a gist with the files at https://gist.github.com/sunny256/2eb583f21e0ffcfe994f, I think it should solve your problem. It contains these files: git-wn wn means What's New and will create a visual graph of all commits which has a specified ref as ancestor. It also needs the following script, just put it into your $PATH somewhere: git-lc lc means List branches Containing this commit and generates a list of all branches containing a specified ref. The files originates from https://github.com/sunny256/utils, but I've modified them in the gist to make your life easier. :) Hope that helps, Øyvind -- 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: Support for EBCDIC
-Original Message-
From: Jeff King
Sent: Thursday, July 03, 2014 13:34
On Wed, Jul 02, 2014 at 07:39:12PM -0700, Scott McKellar wrote:
Is Git supposed to be usable in an environment where the
execution character set is EBCDIC?
Not really.
If the core uses specific 8bit values for the internals then there is a hope and
prayer.
E.g. blob would need to be char _BLOB={0x62,0x6c,0x6f,0x62} because the hash
calculation would be wrong if were {0x82,0x93,0x96,0x82} ensuring the compiler
does not change that binary data value.
In addition to the cases you found (and I would be surprised if there
are not more, such as our reimplementation of ctype.h), we assume:
- we can intermingle ASCII from string literals with user
data to form
diffs, commit objects, network protocols, etc. This is actually a
problem not just for EBCDIC, but for any encoding which is not an
ASCII-superset (like UTF-16).
And then all output would require code-page aware translation, but fix the above
first.
- many outputs from git should be ASCII in order to
interoperate with
the outside world (object headers, network protocols, etc).
So I'd be surprised if things worked well in an EBCDIC
environment (but
I have never worked with one, so maybe I do not understand all of the
implications).
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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
Git diff cr+lf inconsistency observations
(I am on the list cc not needed) jpyeron@black /projects/cipherShed $ git --version uname -a git version 1.8.4.21.g992c386 CYGWIN_NT-5.2-WOW64 black 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin jpyeron@black /projects/cipherShed $ git diff src/Format/Format.vcproj diff --git a/src/Format/Format.vcproj b/src/Format/Format.vcproj index 41081b5..e78f153 100644 --- a/src/Format/Format.vcproj +++ b/src/Format/Format.vcproj @@ -505,6 +505,10 @@ /File File + RelativePath=..\Common\snprintf.h^M + ^M + /File^M + File^M RelativePath=..\Common\Tcdefs.h /File jpyeron@black /projects/cipherShed $ hexdump.exe -C src/Format/Format.vcproj | less 29c0 09 09 3c 2f 46 69 6c 65 3e 0d 0a 09 09 09 3c 46 |../File.F| 29d0 69 6c 65 0d 0a 09 09 09 09 52 65 6c 61 74 69 76 |ile..Relativ| 29e0 65 50 61 74 68 3d 22 2e 2e 5c 43 6f 6d 6d 6f 6e |ePath=..\Common| 29f0 5c 53 65 63 75 72 69 74 79 54 6f 6b 65 6e 2e 68 |\SecurityToken.h| 2a00 22 0d 0a 09 09 09 09 3e 0d 0a 09 09 09 3c 2f 46 |.../F| 2a10 69 6c 65 3e 0d 0a 09 09 09 3c 46 69 6c 65 0d 0a |ile.File..| --^^-^^--- Why does git diff output not show these as CTRL-M? 2a20 09 09 09 09 52 65 6c 61 74 69 76 65 50 61 74 68 |RelativePath| 2a30 3d 22 2e 2e 5c 43 6f 6d 6d 6f 6e 5c 73 6e 70 72 |=..\Common\snpr| 2a40 69 6e 74 66 2e 68 22 0d 0a 09 09 09 09 3e 0d 0a |intf.h| ---^^^^--- When it shows these, 2a50 09 09 09 3c 2f 46 69 6c 65 3e 0d 0a 09 09 09 3c |.../File.| -^^--- these, 2a60 46 69 6c 65 0d 0a 09 09 09 09 52 65 6c 61 74 69 |File..Relati| --^^-- and these. 2a70 76 65 50 61 74 68 3d 22 2e 2e 5c 43 6f 6d 6d 6f |vePath=..\Commo| 2a80 6e 5c 54 63 64 65 66 73 2e 68 22 0d 0a 09 09 09 |n\Tcdefs.h.| 2a90 09 3e 0d 0a 09 09 09 3c 2f 46 69 6c 65 3e 0d 0a |../File..| -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Compile Error on Git 2.0.1 on Redhat 5.9 with Fix
Thanks for the tip Jeff. config.mak.autogen is created in the git compile only when you do a ./configure. Mine had the bad reference to gar in it due to the following. It was caused because my path had a reference to a non-related gar executable (some internal command). I saw the compile trying to execute it and removed it from my path. Doing a make clean afterwards didn't remove the config.mak.autogen which had mistakenly thought that I was using gar and not ar. When I fixed my path to not include the company specific gar and started with a fresh untar it worked perfectly. It also didn't make a config.mak.autogen since that isn't what is recommended to do in the git docs for install. This is closed due to my own user error. config.mak.autogen # git Makefile configuration, included in main Makefile # config.mak.autogen. Generated from config.mak.in by configure. CC = cc CFLAGS = -g -O2 CPPFLAGS = LDFLAGS = AR = gar TAR = gtar Eldon Nelson eldon_nel...@ieee.org -- 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 00/14] Add submodule test harness
Am 03.07.2014 07:56, schrieb Torsten Bögershausen:
On 07/02/2014 09:57 PM, Jens Lehmann wrote:
Am 02.07.2014 16:54, schrieb Torsten Bögershausen:
(Not sure if this is the right thread)
(I haven't checked if this is fixed in your latest version)
Yes, this is the right thread and no, it isn't fixed yet.
On what I have on pu 7a0da7902cbbc9a876b90c9, Tue Jul 1 14:51:53 2014 -0700
Many submodule tests are broken.
One problem is here:
lib-submodule-update.sh:264: possible problem: echo -n is not portable
(please use printf): echo -n sub1
lib-submodule-update.sh:507: possible problem: echo -n is not portable
(please use printf): echo -n sub1
You can remove the empty echo -n to create an empty file:
sub1
Thanks for spotting and diagnosing this. Running make lint in the
test directory only feeds the tests to check-non-portable-shell.pl,
but not the *lib*.sh helper scripts, which made me miss this one.
The following diff should fix it for you. Am I understanding you
correctly that you are experiencing other failures too? I see no
other incompatibilities when running ./check-non-portable-shell.pl
on all the shell scripts in the repo.
The longer story is that I run the test suite once a week or so.
Most often under Mac OS, sometimes cygwin or Linux.
Whenever there is a breakage under Mac OS which I can not
debug within some minutes, I run it under Linux to see if there
is the same breakage.
Thanks, that really helps a lot and is more than I could ask for.
The ./check-non-portable-shell.pl can sometimes give an indication
why some test fail.
You can run it from command line:
./check-non-portable-shell.pl *.sh
and it will find the echo -n which I reported.
On the longer run it could probably check all *.sh files,
not only the ones under t/
That is exactly what I thought when I tried to find out why I missed
this. Will cook up a patch to at least check the test helpers too.
I do not have the time to test the snipped patch below, but I can check pu
when the next round of your patch is in and give you some more info.
That'd be great!
Junio, do you want me to resend 02/14 without the non-portable echo -n
or could you just squash the following diff in?
-8
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
index 24c9fd7..3584755 100755
--- a/t/lib-submodule-update.sh
+++ b/t/lib-submodule-update.sh
@@ -304,7 +304,7 @@ test_submodule_switch () {
(
cd submodule_update
git branch -t add_sub1 origin/add_sub1
- echo -n sub1
+ sub1
test_must_fail $command add_sub1
test_superproject_content origin/no_submodule
test_must_be_empty sub1
@@ -547,7 +547,7 @@ test_submodule_forced_switch () {
(
cd submodule_update
git branch -t add_sub1 origin/add_sub1
- echo -n sub1
+ sub1
$command add_sub1
test_superproject_content origin/add_sub1
test_dir_is_empty sub1
-- 2.0.1.458.gf680257.dirty
--
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
t5150-request-pull.sh fails on newest master in Debian
When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5
(64-bit), t5150-request-pull.sh fails when compiling with
$ make configure
$ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
$ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
$ make
$ cd t
$ ./t5150-request-pull.sh
I have attached the output of t5150-request-pull.sh, but in case the
attachment doesn't go through, I've also pasted it at
https://gist.github.com/sunny256/0f6ff7ffee26224dbe12. This happened
on two virtual servers (64 bit) hosted on Linode, with this
configuration:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 7.5 (wheezy)
Release:7.5
Codename: wheezy
$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Both servers are (of course) updated with new packages from apt-get.
The test worked on my laptop which runs Ubuntu Studio 13.10. Have tried
recompiling several times, and it fails on Debian every time.
git bisect says the bad commit is 6f92e5ff3 (Merge branch
'dt/refs-check-refname-component-sse, 2014-07-02 12:53:07 -0700), but
that's a merge. Both parent commits works, so could this be an evil
merge?
When compiling parent commit 745224e test 6 is disabled, could that be
the reason?
Parent commit a02ad88 passes all 7 tests.
Cheers,
Øyvind
*** t5150-request-pull.sh ***
not ok 1 - setup
#
#
# git init --bare upstream.git
# git init --bare downstream.git
# git clone upstream.git upstream-private
# git clone downstream.git local
#
# trash_url=file://$TRASH_DIRECTORY
# downstream_url=$trash_url/downstream.git/
# upstream_url=$trash_url/upstream.git/
#
# (
# cd upstream-private
# cat -\EOT mnemonic.txt
# Thirtey days hath November,
# Aprile, June, and September:
# EOT
# git add mnemonic.txt
# test_tick
# git commit -m \Thirty days\, a reminder of month
lengths
# git tag -m version 1 -a initial
# git push --tags origin master
# )
# (
# cd local
# git remote add upstream $trash_url/upstream.git
# git fetch upstream
# git pull upstream master
# cat -\EOT mnemonic.txt
# Of twyecescore-eightt is but eine,
# And all the remnante be thrycescore-eine.
# O’course Leap yare comes an’pynes,
# Ev’rie foure yares, gote it ryghth.
# An’twyecescore-eight is but twyecescore-nyne.
# EOT
# git add mnemonic.txt
# test_tick
# git commit -m More detail
# git tag -m version 2 -a full
# git checkout -b simplify HEAD^
# mv mnemonic.txt mnemonic.standard
# cat -\EOT mnemonic.clarified
# Thirty days has September,
# All the rest I can’t remember.
# EOT
# git add -N mnemonic.standard mnemonic.clarified
# git commit -a -m Adapt to use modern, simpler English
#
# But keep the old version, too, in case some people prefer it.
# git checkout master
# )
#
#
ok 2 - setup: two scripts for reading pull requests
not ok 3 - pull request when forgot to push
#
#
# rm -fr downstream.git
# git init --bare downstream.git
# (
# cd local
# git checkout initial
# git merge --ff-only master
# test_must_fail git request-pull initial
$downstream_url \
# 2../err
# )
# grep No match for commit .* err
# grep Are you sure you pushed err
#
#
not ok 4 - pull request after push
#
#
# rm -fr downstream.git
# git init --bare downstream.git
# (
# cd local
# git checkout initial
# git merge --ff-only master
# git push origin master:for-upstream
# git request-pull initial origin master:for-upstream
../request
# )
# sed -nf read-request.sed request digest
# cat digest
# {
# read task
# read repository
# read branch
# } digest
# (
# cd
Re: t5150-request-pull.sh fails on newest master in Debian
Interesting! I wonder if the problem is with the compiler or with my code. I don't happen to have a Debian box handy; would it be possible for you to compile refs.c to assembly language (gcc -S) and send me the output? That would help me track down the problem. On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote: When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5 (64-bit), t5150-request-pull.sh fails when compiling with $ make configure $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make $ cd t $ ./t5150-request-pull.sh I have attached the output of t5150-request-pull.sh, but in case the attachment doesn't go through, I've also pasted it at https://gist.github.com/sunny256/0f6ff7ffee26224dbe12. This happened on two virtual servers (64 bit) hosted on Linode, with this configuration: $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 7.5 (wheezy) Release:7.5 Codename: wheezy $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 Both servers are (of course) updated with new packages from apt-get. The test worked on my laptop which runs Ubuntu Studio 13.10. Have tried recompiling several times, and it fails on Debian every time. git bisect says the bad commit is 6f92e5ff3 (Merge branch 'dt/refs-check-refname-component-sse, 2014-07-02 12:53:07 -0700), but that's a merge. Both parent commits works, so could this be an evil merge? When compiling parent commit 745224e test 6 is disabled, could that be the reason? Parent commit a02ad88 passes all 7 tests. Cheers, Øyvind -- 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: t5150-request-pull.sh fails on newest master in Debian
On 3 July 2014 23:55, Øyvind A. Holm su...@sunbase.org wrote: When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5 (64-bit), t5150-request-pull.sh fails when compiling with $ make configure $ ./configure --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f $ make $ cd t $ ./t5150-request-pull.sh That's a copy+paste error, ignore the second make. :-P Cheers, Øyvind -- 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 0/2] always run all lint targets when running the test suite
I recently accidentally added a non-portable echo -n to a test suite helper which make test didn't show. This series attempts to detect such problems early when running the test suite. The first patch includes the helper scripts to be tested too when running make test-lint (and thus the test-lint-shell-syntax target) in the test directory. The second patch then uses all lint tests in the test run. Jens Lehmann (2): t/Makefile: check helper scripts for non-portable shell commands too t/Makefile: always test all lint targets when running tests t/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.0.1.474.g5b85b58 -- 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 1/2] t/Makefile: check helper scripts for non-portable shell commands too
Currently only the t[0-9][0-9][0-9][0-9]-*.sh scripts are tested for shell incompatibilities using the check-non-portable-shell.pl script. This makes it easy to miss non-POSIX constructs added to one of the t/*lib*.sh helper scripts, as they aren't automatically detected. Fix that by adding a THELPERS variable containing all shell scripts that aren't tests and add these to the test-lint-shell-syntax target too. --- t/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/Makefile b/t/Makefile index 8fd1a72..7fa6692 100644 --- a/t/Makefile +++ b/t/Makefile @@ -29,6 +29,7 @@ TEST_RESULTS_DIRECTORY_SQ = $(subst ','\'',$(TEST_RESULTS_DIRECTORY)) T = $(sort $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)) TSVN = $(sort $(wildcard t91[0-9][0-9]-*.sh)) TGITWEB = $(sort $(wildcard t95[0-9][0-9]-*.sh)) +THELPERS = $(sort $(filter-out $(T),$(wildcard *.sh))) all: $(DEFAULT_TEST_TARGET) @@ -65,7 +66,7 @@ test-lint-executable: echo 2 non-executable tests: $$bad; exit 1; } test-lint-shell-syntax: - @'$(PERL_PATH_SQ)' check-non-portable-shell.pl $(T) + @'$(PERL_PATH_SQ)' check-non-portable-shell.pl $(T) $(THELPERS) aggregate-results-and-cleanup: $(T) $(MAKE) aggregate-results -- 2.0.1.474.g5b85b58 -- 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 2/2] t/Makefile: always test all lint targets when running tests
Only the two targets test-lint-duplicates and test-lint-executable are currently executed when running the test target. This was done on purpose when the TEST_LINT variable was added in 81127d74. But as this does not include the test-lint-shell-syntax target added the same day in commit c7ce70ac, it is easy to accidentally add non portable shell constructs without noticing that when running the test suite. Fix that by always running all lint tests unless the TEST_LINT variable is overridden. If we add less accurate or slow tests later we could still fall back to exclude them like 81127d74 proposed. But for now it is better to include all lint tests until proven otherwise. --- t/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/Makefile b/t/Makefile index 7fa6692..43b15e3 100644 --- a/t/Makefile +++ b/t/Makefile @@ -13,7 +13,7 @@ TAR ?= $(TAR) RM ?= rm -f PROVE ?= prove DEFAULT_TEST_TARGET ?= test -TEST_LINT ?= test-lint-duplicates test-lint-executable +TEST_LINT ?= test-lint ifdef TEST_OUTPUT_DIRECTORY TEST_RESULTS_DIRECTORY = $(TEST_OUTPUT_DIRECTORY)/test-results -- 2.0.1.474.g5b85b58 -- 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] rebase no longer omits local commits
On Thu, Jul 03, 2014 at 08:09:17PM +0100, John Keeping wrote:
On Thu, Jul 03, 2014 at 11:14:26AM -0400, Ted Felix wrote:
Starting with git 1.9.0, rebase no longer omits local commits that
appear in both the upstream and local branches.
It is the problem that bb3f458 fixes. The change in behaviour is
actually introduced by ad8261d (rebase: use reflog to find common base
with upstream).
In your example, I think this is working as designed. You can restore
the previous behaviour either with `git rebase --no-fork-point` or with
`git rebase @{u}`.
The change is designed to help users recover from an upstream rebase, as
described in the DISCUSSION ON FORK-POINT MODE section of
git-merge-base(1).
Having thought about this a bit more, I think the case you've identified
is an unexpected side effect of that commit.
Perhaps we shuld do something like this (which passes the test suite):
-- 8 --
diff --git a/git-rebase.sh b/git-rebase.sh
index 06c810b..0c6c5d3 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -544,7 +544,8 @@ if test $fork_point = t
then
new_upstream=$(git merge-base --fork-point $upstream_name \
${switch_to:-HEAD})
- if test -n $new_upstream
+ if test -n $new_upstream
+ ! git merge-base --is-ancestor $new_upstream $upstream_name
then
upstream=$new_upstream
fi
-- 8 --
Since the intent of `--fork-point` is to find the best starting point
for the $upstream...$orig_head range, if the fork point is behind the
new location of the upstream then should we leave the upstream as it
was?
I haven't thought through this completely, but it seems like we should
be doing a check like the above, at least when we're in
$fork_point=auto mode.
--
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] trace.h: suppress some sparse warnings and errors
Commit 07896a5c (trace: improve trace performance, 02-07-2014) added
a 'trace_key' structure to the trace.h header file which provokes sparse
to issue numerous (837) warnings and errors, like so:
SP abspath.c
trace.h:8:26: warning: duplicate const
trace.h:10:29: error: dubious one-bit signed bitfield
trace.h:11:28: error: dubious one-bit signed bitfield
In order to suppress the warning, we simply remove the redundant
'const' keyword in the declaration of the key field.
The bit-field errors are addressed by changing the declaration to
use an 'unsigned int' type for each bit-field. Note that the C
standard says that using anything other than _Bool, signed int
and unsigned int for the type of a bit-field is implementation
defined. (In addition, the signed-ness of the 'char' type is also
implementation defined).
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Karsten,
If you need to re-roll your 'kb/perf-trace' branch, could you
please squash this (or something like it) into the patch which
corresponds to commit 07896a5c. Thanks!
Note that, if you had intended to declare the key field as a
'constant pointer to const char', then that would be spelt
like: 'const char *const key;' instead.
I suspect that most (but maybe not all) compilers support
'unsigned char' bit-field types, which _may_ result in using
a byte-sized storage unit for the two bit-fields combined.
However, because of the alignment requirements of the other
fields, the sizeof(struct trace_key) is 12 for both versions
of the struct ('unsigned int' vs 'unsigned char') on 32-bit
Linux (for both gcc and clang).
If you turn up the compiler warning levels (-Wall -Wextra)
then both gcc and clang complain about missing initialisers
for the trailing structure fields. These fields will be
default initialised to zero anyway, but it also doesn't
hurt to be more explicit.
So, an alternative patch may look like this:
|diff --git a/trace.h b/trace.h
|index 74d7396..1a193bf 100644
|--- a/trace.h
|+++ b/trace.h
|@@ -5,13 +5,13 @@
| #include strbuf.h
|
| struct trace_key {
|-const char const *key;
|+const char *const key;
| int fd;
|-char initialized : 1;
|-char need_close : 1;
|+unsigned int initialized : 1;
|+unsigned int need_close : 1;
| };
|
|-#define TRACE_KEY_INIT(name) { GIT_TRACE_ #name }
|+#define TRACE_KEY_INIT(name) { GIT_TRACE_ #name, 0, 0, 0 }
|
| extern void trace_repo_setup(const char *prefix);
| extern int trace_want(struct trace_key *key);
ATB,
Ramsay Jones
trace.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/trace.h b/trace.h
index 74d7396..1bbb341 100644
--- a/trace.h
+++ b/trace.h
@@ -5,10 +5,10 @@
#include strbuf.h
struct trace_key {
- const char const *key;
+ const char *key;
int fd;
- char initialized : 1;
- char need_close : 1;
+ unsigned int initialized : 1;
+ unsigned int need_close : 1;
};
#define TRACE_KEY_INIT(name) { GIT_TRACE_ #name }
--
2.0.0
--
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: t5150-request-pull.sh fails on newest master in Debian
On 4 July 2014 00:34, Øyvind A. Holm su...@sunbase.org wrote: On 4 July 2014 00:16, David Turner dtur...@twopensource.com wrote: On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote: When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5 (64-bit), t5150-request-pull.sh fails when compiling with [...] Interesting! I wonder if the problem is with the compiler or with my code. I don't happen to have a Debian box handy; would it be possible for you to compile refs.c to assembly language (gcc -S) and send me the output? That would help me track down the problem. Sure! I have attached refs.s from v2.0.1-472-g6f92e5f . If someone else is interested in the assembly output, it's available from http://sunbase.org/t5150-fail/refs.s.gz. Didn't send it to the list, it's 128KB. Cheers again, Øyvind -- 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 v4 1/2] add `config_set` API for caching config files
Hi,
I have cooked up a single hashmap implementation. What are your
thoughts about it? I must say it is much cleaner than the
previous attempt and it passes all the tests.
I will send the revised patch tomorrow with the corrected
documentation, till then please say so if you prefer this one
or the multi hashmap one.
Cheers,
Tanay Abhra.
-- 8 --
diff --git a/Makefile b/Makefile
index 07ea105..d503f78 100644
--- a/Makefile
+++ b/Makefile
@@ -777,6 +777,7 @@ LIB_OBJS += commit.o
LIB_OBJS += compat/obstack.o
LIB_OBJS += compat/terminal.o
LIB_OBJS += config.o
+LIB_OBJS += config-hash.o
LIB_OBJS += connect.o
LIB_OBJS += connected.o
LIB_OBJS += convert.o
diff --git a/cache.h b/cache.h
index df65231..2a675f6 100644
--- a/cache.h
+++ b/cache.h
@@ -7,6 +7,7 @@
#include advice.h
#include gettext.h
#include convert.h
+#include string-list.h
#include SHA1_HEADER
#ifndef git_SHA_CTX
@@ -1325,6 +1326,41 @@ extern int parse_config_key(const char *var,
const char **subsection, int *subsection_len,
const char **key);
+/* config-hash.c */
+
+struct config_set {
+ struct hashmap config_hash;
+ int hash_initialized;
+};
+
+extern struct config_set *git_configset_init(void);
+extern int git_configset_add_file(struct config_set *cs, const char *filename);
+extern int git_configset_get_value(struct config_set *cs, const char *key,
const char **value);
+extern const struct string_list *git_configset_get_value_multi(struct
config_set *cs, const char *key);
+extern void git_configset_clear(struct config_set *cs);
+extern void git_configset_iter(struct config_set *cs, config_fn_t fn, void
*data);
+extern int git_configset_get_string(struct config_set *cs, const char *key,
const char **dest);
+extern int git_configset_get_int(struct config_set *cs, const char *key, int
*dest);
+extern int git_configset_get_ulong(struct config_set *cs, const char *key,
unsigned long *dest);
+extern int git_configset_get_bool(struct config_set *cs, const char *key, int
*dest);
+extern int git_configset_get_bool_or_int(struct config_set *cs, const char
*key, int *is_bool, int *dest);
+extern int git_configset_get_maybe_bool(struct config_set *cs, const char
*key, int *dest);
+extern int git_configset_get_pathname(struct config_set *cs, const char *key,
const char **dest);
+
+extern int git_config_get_value(const char *key, const char **value);
+extern const struct string_list *git_config_get_value_multi(const char *key);
+extern void git_config_clear(void);
+extern void git_config_iter(config_fn_t fn, void *data);
+extern int git_config_get_string(const char *key, const char **dest);
+extern int git_config_get_int(const char *key, int *dest);
+extern int git_config_get_ulong(const char *key, unsigned long *dest);
+extern int git_config_get_bool(const char *key, int *dest);
+extern int git_config_get_bool_or_int(const char *key, int *is_bool, int
*dest);
+extern int git_config_get_maybe_bool(const char *key, int *dest);
+extern int git_config_get_pathname(const char *key, const char **dest);
+
+
extern int committer_ident_sufficiently_given(void);
extern int author_ident_sufficiently_given(void);
diff --git a/config-hash.c b/config-hash.c
new file mode 100644
index 000..e12bf57
--- /dev/null
+++ b/config-hash.c
@@ -0,0 +1,325 @@
+#include cache.h
+#include hashmap.h
+#include string-list.h
+
+
+/*
+ * Default config_set that contains key-value pairs from the usual set of
config
+ * config files (i.e repo specific .git/config, user wide ~/.gitconfig and the
+ * global /etc/gitconfig)
+ */
+static struct config_set the_config_set;
+
+struct config_hash_entry {
+ struct hashmap_entry ent;
+ char *key;
+ struct string_list value_list;
+};
+
+static int config_hash_add_value(const char *, const char *, struct hashmap *);
+
+static int config_hash_entry_cmp(const struct config_hash_entry *e1,
+const struct config_hash_entry *e2, const void
*unused)
+{
+ return strcmp(e1-key, e2-key);
+}
+
+static void config_hash_init(struct hashmap *config_hash)
+{
+ hashmap_init(config_hash, (hashmap_cmp_fn)config_hash_entry_cmp, 0);
+}
+
+static int config_hash_callback(const char *key, const char *value, void *cb)
+{
+ struct config_set *cs = cb;
+ config_hash_add_value(key, value, cs-config_hash);
+ return 0;
+}
+
+static int add_configset_hash(const char *filename, struct config_set *cs)
+{
+ int ret = 0;
+ if (!cs-hash_initialized)
+ config_hash_init(cs-config_hash);
+ cs-hash_initialized = 1;
+ ret = git_config_from_file(config_hash_callback, filename, cs);
+ if (!ret)
+ return 0;
+ else {
+ hashmap_free(cs-config_hash, 1);
+ cs-hash_initialized = 0;
+ return -1;
+ }
+}
+
+static struct config_hash_entry *config_hash_find_entry(const char *key,
+
