On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra wrote:
> Use git_config_get_string instead of git_config to take advantage of
> the config hash-table api which provides a cleaner control flow.
You may want to mention as a side-note the slight behavior change
introduced by this patch. The original co
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra wrote:
> Use git_config_get_string instead of git_config to take advantage of
> the config hash-table api which provides a cleaner control flow.
>
> Signed-off-by: Tanay Abhra
> ---
> notes-utils.c | 31 +++
> 1 file change
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra wrote:
> Use git_config_get_string instead of git_config to take advantage of
> the config hash-table api which provides a cleaner control flow.
>
> Signed-off-by: Tanay Abhra
> ---
> notes.c | 20 ++--
> 1 file changed, 6 insertions(+
Hello,
I have git from Debian's 2.0.0-2 package:
$ git version
git version 2.0.0
git request-pull is broken for me:
$ git rev-parse HEAD
9e065e4a5a58308f1a0da4bb80b830929dfa90b3
$ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
On Tue, Jun 24, 2014 at 09:40:09PM -0400, Eric Sunshine wrote:
> On Tue, Jun 24, 2014 at 5:46 AM, Jeff King wrote:
> > One of the purposes of "git replace --edit" is to help a
> > user repair objects which are malformed or corrupted.
> > Usually we pretty-print trees with "ls-tree", which is much
On Mon, Jun 23, 2014 at 6:11 AM, Tanay Abhra wrote:
> Add different usage examples for 'git_config_get_string' and
> `git_config_get_string_multi`. They will serve as documentation
> on how to query for config values in a non-callback manner.
This is a good start, but it's not fully what Matthieu
On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König
wrote:
>
> $ git rev-parse HEAD
> 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
> $ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
> 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
> refs/heads/ukl/
On Wed, Jun 25, 2014 at 3:58 AM, Jeff King wrote:
> Here's a replacement patch that handles this (and just drops the ugly
> mallocs as a side effect).
Shortly after I wrote my email, I thought about getenvdup() and look
for similar getenv/xstrdup patterns. But I saw only one in config.c.
So let's
Hello Linus,
On Wed, Jun 25, 2014 at 05:05:51AM -0700, Linus Torvalds wrote:
> On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König
> wrote:
> >
> > $ git rev-parse HEAD
> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
> > $ git ls-remote origin | grep
> > 9e065e4a5a58308f1a0da4
On Wed, Jun 11, 2014 at 2:55 PM, Karsten Blees wrote:
> Here's v5 of the performance tracing patch series, now including a bunch of
> cleanups and adding timestamp, file and line to all trace output.
>
> I'm particularly interested in feedback for the output format. As file names
> have differen
Your fund of US$10.5 Million Dollars is ready to deliver to you through ATM
Card, please reconfirm to me your Information. Reply to rev_peteradams001@live.
com
Thanks
Rev. Peter Adams
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
Am 25.06.2014 16:28, schrieb Duy Nguyen:
> On Wed, Jun 11, 2014 at 2:55 PM, Karsten Blees
> wrote:
>> Here's v5 of the performance tracing patch series, now including a bunch of
>> cleanups and adding timestamp, file and line to all trace output.
>>
>> I'm particularly interested in feedback for
** The previous survey link was incorrect, please use the one below
We'd like to hear from people using Git to manage software projects.
Taking this short 5 minute survey helps us create better Git tools.
Take the survey here: https://www.surveymonkey.com/s/5X97XMM
By completing this survey, yo
Jeff King writes:
> Here's a replacement patch that handles this (and just drops the ugly
> mallocs as a side effect).
>
> -- >8 --
> Subject: [PATCH] setup_git_env: copy getenv return value
>
> The return value of getenv is not guaranteed to survive
> across further invocations of setenv or even
On Wed, Jun 25, 2014 at 10:20:13AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Here's a replacement patch that handles this (and just drops the ugly
> > mallocs as a side effect).
> >
> > -- >8 --
> > Subject: [PATCH] setup_git_env: copy getenv return value
> >
> > The return value of
Mark Ferrell writes:
> push repository, but our use case relies on the pull branch being
> different than the push branch. It would seem that git would need a
> branch..push directive for this to work out.
I thought that you can tell recent versions of Git to pay attention
to the remote.*.push
Nico Williams writes:
> On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:
> ...
>> This seems pretty close to what we have with signed tags. When I send
>> a pull request to Linus, I create a signed tag which createscontains a
>> message about a set of commits, and this message is automatic
Ramsay Jones writes:
> On 24/06/14 00:25, Junio C Hamano wrote:
> ...
>> Yup, that is a very good point. There needs an infrastructure to
>> tie a set of files (i.e. the standard one being the chain of
>> system-global /etc/gitconfig to repo-specific .git/config, and any
>> custom one that can b
Tanay Abhra writes:
> What changes should I implement in this series? Should I add new
> user facing API adding to the singleton callers which are already in
> this series.
I think the underlying data structures that represent what the
entire set of config data is needs to be refined.
We did th
Jeff King writes:
> On Wed, Jun 25, 2014 at 10:20:13AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Here's a replacement patch that handles this (and just drops the ugly
>> > mallocs as a side effect).
>> >
>> > -- >8 --
>> > Subject: [PATCH] setup_git_env: copy getenv return val
Am 25.06.2014 20:13, schrieb Junio C Hamano:
> Ramsay Jones writes:
>
>> On 24/06/14 00:25, Junio C Hamano wrote:
>> ...
>>> Yup, that is a very good point. There needs an infrastructure to
>>> tie a set of files (i.e. the standard one being the chain of
>>> system-global /etc/gitconfig to repo-
Am 24.06.2014 14:06, schrieb Tanay Abhra:
> On 6/23/2014 5:25 PM, Matthieu Moy wrote:
>> Tanay Abhra writes:
>>
>>> +/* for NULL values, 'util' for each `string_list_item` is flagged as 1 */
>>
>> It's a void *, so just saying that it is flagged as 1 does not say how
>> it's encoded. How about "..
Hi dear,
I am Ms. Lo King Yong, A Private Investment Manager in Hong Kong; I have a
lucrative business proposal of mutual interest to share with you. If you
are interested in working with me, contact me urgently through my private
email; (lo.kingy...@aol.co.uk) for further details.
Sincerely,
Uwe Kleine-König writes:
> Hello Linus,
>
> On Wed, Jun 25, 2014 at 05:05:51AM -0700, Linus Torvalds wrote:
>> On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König
>> wrote:
>> >
>> > $ git rev-parse HEAD
>> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
>> > $ git ls-remote or
Karsten Blees writes:
> Am 25.06.2014 20:13, schrieb Junio C Hamano:
>> Ramsay Jones writes:
>>> I had expected to see one hash table per file/blob, with the three
>>> standard config hash tables linked together to implement the scope/
>>> priority rules. (Well, these could be merged into one, a
Brian Gernhardt writes:
> Since the setup requires the GPG prerequisite, it doesn't make much
> sense to try and run any tests without it. So rather than using a
> prereq on each individual test and possibly forgetting it on new ones
> (as just happened), skip the entire file if GPG isn't found.
Jeff King writes:
> For a while some people were compiling git with pretty antique
> compilers, but I do not know if that is the case any more (Junio noted
> recently that we have had trailing commas on arrays and enums in
> builtin/clean.c for the past year, and nobody has complained).
IIRC, th
Jeremiah Mahler writes:
> We often represent our strings as a counted string, i.e. a pair of the
> pointer to the beginning of the string and its length, and the string
> may not be NUL terminated to that length.
>
> To compare a pair of such counted strings, unpack-trees.c and
> read-cache.c imp
Jeremiah Mahler writes:
> When cache_name_compare() is used on counted strings of the same
> length, it is equivalent to a memcmp(). Since the one use of
> cache_name_compare() in name-hash.c requires that the lengths are
> equal, just replace it with memcmp().
I do not think it is not "require
Jens Lehmann writes:
> + rm -rf sub1 &&
> + git checkout -f "$1" &&
> + git status -u -s >actual &&
> + test_must_be_empty actual &&
> + sha1=$(git rev-parse HEAD:sub1 || true) &&
$ xx=; xx=$(git rev-parse HEAD:no-such-path || t
Git v2.0.1, the first maintenance release for Git v2.0, is now
available at the usual places. This contains most of the fixes
already merged on the 'master' front in preparation for the v2.1
release.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following publi
On Wed, Jun 25, 2014 at 02:16:55PM -0700, Junio C Hamano wrote:
> Brian Gernhardt writes:
>
> > Since the setup requires the GPG prerequisite, it doesn't make much
> > sense to try and run any tests without it. So rather than using a
> > prereq on each individual test and possibly forgetting it
Am 23.06.2014 12:11, schrieb Tanay Abhra:
[...]
> +
> +static struct config_cache_entry *config_cache_find_entry(const char *key)
> +{
> + struct hashmap *config_cache;
> + struct config_cache_entry k;
> + struct config_cache_entry *found_entry;
> + char *normalized_key;
> + i
Jeff King writes:
> ...
> I think it may make more sense to just configure gpg.program to "false"
> for the NOGPG case. Then you get coverage both on systems with it
> installed, and without (you could also just test it on GPG systems, and
> drop the "ship commits in fast-import form" part of the
Jeff King writes:
> One of the purposes of "git replace --edit" is to help a
> user repair objects which are malformed or corrupted.
> Usually we pretty-print trees with "ls-tree", which is much
> easier to work with than the raw binary data. However, some
> forms of corruption break the tree-wa
On Wed, Jun 25, 2014 at 10:42:49AM -0700, Junio C Hamano wrote:
> Nico Williams writes:
>
> > On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:
> > ...
> >> This seems pretty close to what we have with signed tags. When I send
> >> a pull request to Linus, I create a signed tag which create
Once upon a time we checked "tag --contains" by doing N merge-base
traversals, one per tag. That turned out to be really slow.
Later, I added a single traversal in ffc4b80 (tag: speed up --contains
calculation, 2011-06-11) that works in a depth-first way. That's fast
for the common case of tags sp
When we are listing tags, we print each one as it is
processed by for_each_ref. We can't do that with --sort, of
course, as we need to see the whole list to sort. For the
--sort code path, we store each tag in a string_list, and
then print them all at the end.
This interacts badly with "-n", which
Right now we stream tags if we are not sorting. If we are
sorting, we save them in a list and print them at the end.
Let's abstract this decision into a function to make it
easier to add more cases where we use the list.
Signed-off-by: Jeff King
---
builtin/tag.c | 15 ++-
1 file cha
We already have a nice-to-use bitmap implementation in
ewah/bitmap.c. It pretends to be infinitely long when asking
for a bit (and just returns 0 for bits that haven't been
allocated or set), and dynamically resizes as appropriate
when you set bits.
The cost to this is that each bitmap must store
When we are traversing to find merge bases, we keep our
usual commit_list of commits to process, sorted by their
commit timestamp. As we add each parent to the list, we have
to spend "O(width of history)" to do the insertion, where
the width of history is the number of simultaneous lines of
develop
When we are running a string-list foreach or filter, the
callback function sees only the string_list_item, along with
a void* data pointer provided by the caller. This is
sufficient for most purposes.
However, it can also be useful to know the position of the
item within the string (for example, i
When commands like "git branch --contains" want to know
which branches contain a particular commit, they run a
series of merge-base calculations, one per branch. This can
be very slow if you have a large number of branches.
We made "tag --contains" faster in ffc4b80 (tag: speed up
--contains calcu
The newly added commit_contains function should do a better
job than our custom depth-first traversal. It should be the
same speed when going close to the roots, but much faster
when all tags are close to the searched-for commit (this
usually isn't the case, but could be if you limit the tags
with
These tests can demonstrate the changes in "tag --contains"
speed over time. The interesting points in history are:
- pre-ffc4b80, where we used a series of N merge-base
traversals
- ffc4b80 up to the current master, where we moved to a
single depth-first traversal
- the previous c
On Wed, Jun 25, 2014 at 07:53:35PM -0400, Jeff King wrote:
> There are still two things about the timings that puzzle me a bit.
This certainly isn't helping:
> +test_expect_success 'find reference points' '
> + recent=$(git rev-parse HEAD~100) &&
> + old=$(git rev-parse HEAD~5000) &&
>
On Wed, Jun 25, 2014 at 08:01:29PM -0400, Jeff King wrote:
> I get:
>
> Test ffc4b80^ origin/master
> HEAD
>
>
> 7000.3:
On Wed, Jun 25, 2014 at 9:49 PM, Karsten Blees wrote:
> Am 25.06.2014 16:28, schrieb Duy Nguyen:
>> On Wed, Jun 11, 2014 at 2:55 PM, Karsten Blees
>> wrote:
>>> Here's v5 of the performance tracing patch series, now including a bunch of
>>> cleanups and adding timestamp, file and line to all tr
My only complaint against Kitcheń Design Lancashire Reviews is that they
don't sell bathrooms.
--
View this message in context:
http://git.661346.n2.nabble.com/Kitche-Design-Lancashire-Reviews-tp7614066.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list:
Dear sir/madam,
How are you!
This is cindy from Hangzhou yirun textile company.
Hangzhou Yirun Textile Co., Ltd. founded in 1999, located in Yuhang District,
Zhejiang Province, China. We are a professional enterprise engaged in the
manufacture and sales of polyester fabrics, oxford fabrics, ba
On 2014-06-26 01.40, Jeff King wrote:
[]
> + */
> +static inline int bitset_sizeof(int num_bits)
> +{
> + return (num_bits + CHAR_BIT - 1) / CHAR_BIT;
> +}
Just a general question about the usage of "int" here (and at other places):
Is there a special reason for new code to allow num_bits to b
51 matches
Mail list logo
