On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra tanay...@gmail.com 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
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra tanay...@gmail.com 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 tanay...@gmail.com
---
notes-utils.c | 31
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra tanay...@gmail.com 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 tanay...@gmail.com
---
notes.c | 20 ++--
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 p...@peff.net 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
On Mon, Jun 23, 2014 at 6:11 AM, Tanay Abhra tanay...@gmail.com 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
On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König
u.kleine-koe...@pengutronix.de wrote:
$ git rev-parse HEAD
9e065e4a5a58308f1a0da4bb80b830929dfa90b3
$ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3
9e065e4a5a58308f1a0da4bb80b830929dfa90b3
On Wed, Jun 25, 2014 at 3:58 AM, Jeff King p...@peff.net 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
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
u.kleine-koe...@pengutronix.de wrote:
$ git rev-parse HEAD
9e065e4a5a58308f1a0da4bb80b830929dfa90b3
$ git ls-remote origin | grep
On Wed, Jun 11, 2014 at 2:55 PM, Karsten Blees karsten.bl...@gmail.com 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
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
Am 25.06.2014 16:28, schrieb Duy Nguyen:
On Wed, Jun 11, 2014 at 2:55 PM, Karsten Blees karsten.bl...@gmail.com
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
** 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,
Jeff King p...@peff.net 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
On Wed, Jun 25, 2014 at 10:20:13AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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 ma...@homeonderanged.org 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.name.push directive for this to work out.
I thought that you can tell recent versions of Git to pay
Nico Williams n...@cryptonector.com writes:
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu 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,
Ramsay Jones ram...@ramsay1.demon.co.uk 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
Tanay Abhra tanay...@gmail.com 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
Jeff King p...@peff.net writes:
On Wed, Jun 25, 2014 at 10:20:13AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Am 25.06.2014 20:13, schrieb Junio C Hamano:
Ramsay Jones ram...@ramsay1.demon.co.uk 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
Am 24.06.2014 14:06, schrieb Tanay Abhra:
On 6/23/2014 5:25 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com 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
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 u.kleine-koe...@pengutronix.de 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
u.kleine-koe...@pengutronix.de wrote:
$ git rev-parse HEAD
Karsten Blees karsten.bl...@gmail.com writes:
Am 25.06.2014 20:13, schrieb Junio C Hamano:
Ramsay Jones ram...@ramsay1.demon.co.uk 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.
Brian Gernhardt br...@gernhardtsoftware.com 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
Jeff King p...@peff.net 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).
Jeremiah Mahler jmmah...@gmail.com 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
Jeremiah Mahler jmmah...@gmail.com 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
Jens Lehmann jens.lehm...@web.de 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 ||
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
On Wed, Jun 25, 2014 at 02:16:55PM -0700, Junio C Hamano wrote:
Brian Gernhardt br...@gernhardtsoftware.com 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
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;
+ int ret;
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
On Wed, Jun 25, 2014 at 10:42:49AM -0700, Junio C Hamano wrote:
Nico Williams n...@cryptonector.com writes:
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu wrote:
...
This seems pretty close to what we have with signed tags. When I send
a pull request to Linus, I create a
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
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 p...@peff.net
---
builtin/tag.c | 15
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
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,
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
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
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.
forehead-palm
This certainly isn't helping:
+test_expect_success 'find reference points' '
+ recent=$(git rev-parse HEAD~100)
+ old=$(git rev-parse
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 karsten.bl...@gmail.com wrote:
Am 25.06.2014 16:28, schrieb Duy Nguyen:
On Wed, Jun 11, 2014 at 2:55 PM, Karsten Blees karsten.bl...@gmail.com
wrote:
Here's v5 of the performance tracing patch series, now including a bunch of
cleanups and
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
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,
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 be
51 matches
Mail list logo
