Re: [PATCH v1 4/4] hashmap: add string interning API

[Matthieu Moy]

Karsten Blees  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

[Matthieu Moy]

Karsten Blees  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

[Michael Haggerty]

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

[Christian Couder]

On Wed, Jul 2, 2014 at 10:49 PM, Junio C Hamano  wrote:
> Christian Couder  writes:
>
>> Signed-off-by: Christian Couder 
>> Signed-off-by: Junio C Hamano 
>> ---
>>  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' 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

[Christian Couder]

On Wed, Jul 2, 2014 at 11:05 PM, Junio C Hamano  wrote:
> Christian Couder  writes:
>
>> Signed-off-by: Christian Couder 
>> ---
>>  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

[Avi Kivity]

On 07/02/2014 08:17 PM, Junio C Hamano wrote:

Avi Kivity  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

[Christian Couder]

On Wed, Jul 2, 2014 at 11:19 PM, Junio C Hamano  wrote:
> Christian Couder  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

[Christian Couder]

On Wed, Jul 2, 2014 at 11:22 PM, Junio C Hamano  wrote:
> Christian Couder  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?

[Peter Krefting]

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

[Johannes Schindelin]

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

[Ted Felix]

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

[David Salib]

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 ..." to update what will be committed)
  (use "git checkout -- ..." 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

[Jeff King]

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

[Tanay Abhra]

On 7/2/2014 10:30 PM, Junio C Hamano wrote:
> Tanay Abhra  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

Re: Show containing branches in log?

[Jeff King]

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

Re: Support for EBCDIC

[Jeff King]

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 .
--
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

[Junio C Hamano]

Christian Couder  writes:

> On Wed, Jul 2, 2014 at 10:49 PM, Junio C Hamano  wrote:
>> Christian Couder  writes:
>>
>>> Signed-off-by: Christian Couder 
>>> Signed-off-by: Junio C Hamano 
>>> ---
>>>  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' 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

[John Keeping]

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?

[Øyvind A . Holm]

On 2 July 2014 16:50, Robert Dailey  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
, 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 , 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

[Jason Pyeron]

> -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

[Jason Pyeron]

(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 @@
>

^M
+   ^M
+   


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  |...|
---^^^^---
When it shows these,
2a50  09 09 09 3c 2f 46 69 6c  65 3e 0d 0a 09 09 09 3c  |<|
-^^---
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  |.>...|

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- 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

[Eldon Nelson]

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

[Jens Lehmann]

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

[Øyvind A . Holm]

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
. 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 digest &&
#   cat digest &&
#   {
#   read task &&
#   rea

Re: t5150-request-pull.sh fails on newest master in Debian

[David Turner]

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
> . 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

[Øyvind A . Holm]

On 3 July 2014 23:55, Ø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

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

[Jens Lehmann]

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

[Jens Lehmann]

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

[Jens Lehmann]

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

[John Keeping]

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

[Ramsay Jones]

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 
---

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

[Øyvind A . Holm]

On 4 July 2014 00:34, Øyvind A. Holm  wrote:
> On 4 July 2014 00:16, David Turner  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 . 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

[Tanay Abhra]

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,
+