On 6/24/2014 4:55 AM, Junio C Hamano wrote:
Ramsay Jones writes:
+static struct hashmap *get_config_cache(void)
+{
+ static struct hashmap config_cache;
+ if (!hashmap_initialized) {
+ config_cache_init(&config_cache);
+ hashmap_initialized = 1;
+
On 6/24/2014 4:55 AM, Junio C Hamano wrote:
Ramsay Jones writes:
+static struct hashmap *get_config_cache(void)
+{
+ static struct hashmap config_cache;
+ if (!hashmap_initialized) {
+ config_cache_init(&config_cache);
+ hashmap_initialized = 1;
+
On 2014-06-23 07:42 PM, Junio C Hamano wrote:
Noel Grandin writes:
It looks like the perl regular expression multiline mode does not work with
'git grep'
Yes, and deliberately so, to avoid having to think about things like
"how would a multi-line match interact with 'grep -n'?"
Ah, that
I tried to use "git replace --edit" today to repair a corrupted tree
that had an empty filename:
$ git replace --edit HEAD^{tree}
fatal: empty filename in tree entry
fatal: cat-file reported failure
Oops. One of the major purposes of the command is to repair broken
objects. This series intr
This matches our usual style and the surrounding code.
Signed-off-by: Jeff King
---
builtin/replace.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index 1bb491d..8507835 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -
This is a little more verbose, but will make it easier to
make parts of our command-line conditional (without
resorting to magic numbers or lots of NULLs to get an
appropriately sized argv array).
Signed-off-by: Jeff King
---
builtin/replace.c | 8 +---
1 file changed, 5 insertions(+), 3 del
When a file descriptor is given to run_command via the
"in", "out", or "err" parameters, run_command takes
ownership. The descriptor will be closed in the parent
process whether the process is spawned successfully or not,
and closing it again is wrong.
In practice this has not caused problems, bec
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-walker, in which case our
pretty
Jens Lehmann wrote:
> Am 23.06.2014 20:24, schrieb Stephen Kelly:
>> Stephen Kelly wrote:
>>
>>> I see that gitk is showing the output of git diff --submodule, similar
>>> to git submodule summary.
>
> Right, and for your use case --submodule would have to learn a
> different value in addition t
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
> The Illumos repo, like OpenSolaris before it, and Solaris itself at
> Sun (and now at Oracle) requires that fixes be broken down into small
> commits, with related fixes, tests, and docs changes all typically in
> separate commits, bu
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
>
> Now, suppose that branches were objects. Then at push time one might
> push with a message about the set of commits being pushed, and this
> message (and time of push, and pusher ID) would get recorded in the
> branch object. At
fsck is a tool that error() is more preferred than die(), but many
functions embed die() inside beyond fsck's control.
unpack_compressed_entry()'s using xmallocz is such a function,
triggered from verify_packfile() -> unpack_entry(). Make it use
xmallocz_gentle() instead.
Noticed-by: Dale R. Worle
Signed-off-by: Nguyễn Thái Ngọc Duy
---
git-compat-util.h | 1 +
wrapper.c | 68 ++-
2 files changed, 53 insertions(+), 16 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index b6f03b3..7eee0f2 100644
--- a/git-compat-u
Signed-off-by: Nguyễn Thái Ngọc Duy
---
diff.c| 13 +++--
diffcore-rename.c | 6 --
diffcore.h| 3 ++-
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/diff.c b/diff.c
index bba9a55..a489540 100644
--- a/diff.c
+++ b/diff.c
@@ -373,7 +373,7 @@ stat
Too large files may lead to failure to allocate memory. If it happens
here, it could impact quite a few commands that involve
diff. Moreover, too large files are inefficient to compare anyway (and
most likely non-text), so mark them binary and skip looking at their
content.
Noticed-by: Dale R. Wor
On Tue, Jun 24, 2014 at 2:03 AM, Junio C Hamano wrote:
> Since its inception at 7e29b825 (Add column layout skeleton and
> git-column, 2012-04-21), it seems that git_column_config() asked for
> a specific $command did not give "column.$command.*" any precedence
> over the fallback value defined fo
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 "... is an 'int *' pointing to the value 1".
And actually,
On 6/24/2014 4:44 AM, Junio C Hamano wrote:
Tanay Abhra writes:
+static int hashmap_initialized;
+ ...
+static struct hashmap *get_config_cache(void)
+{
+ static struct hashmap config_cache;
+ if (!hashmap_initialized) {
+ config_cache_init(&config_cache);
+
I discovered an issue while trying to clone a git repo over an IPv6 link-local
address:
[vb@nerenyi ~/code/ocaml-llnet]% LANG=C git clone
"http://[fe80::226:c6ff:fe50:efa0%wlan0]:33075/repo";
Cloning into 'repo'...
fatal: unable to access 'http://[fe80::226:c6ff:fe50:efa0%wlan0]:33075/repo/':
On Mon, Jun 23, 2014 at 5:21 PM, Eric Sunshine wrote:
> On Thu, Jun 19, 2014 at 5:28 PM, Jeff King wrote:
>> This is shorter, harder to get wrong, and more clearly
>> captures the intent.
>>
>> Signed-off-by: Jeff King
>> ---
>> I wondered if there was a reason to avoid this (because we are in
>
On 06/24/2014 02:47 PM, Vincent B. wrote:
I discovered an issue while trying to clone a git repo over an IPv6 link-local
address:
[vb@nerenyi ~/code/ocaml-llnet]% LANG=C git clone
"http://[fe80::226:c6ff:fe50:efa0%wlan0]:33075/repo";
Cloning into 'repo'...
fatal: unable to access 'http://[fe8
On 24/06/2014 15:15, Torsten Bögershausen wrote:
> Which OS are you using ?
>
> what does
> git --version
> give?
>
> And what does this do ?
>
> GIT_CURL_VERBOSE=1 LANG=C git clone
> "http://[fe80::226:c6ff:fe50:efa0%wlan0]:33075/repo";
>
My mistake, actually:
As per RFC6874, IPv6 URI with
While it's about malloc..
On Fri, Jun 20, 2014 at 4:28 AM, Jeff King wrote:
> diff --git a/environment.c b/environment.c
> index 4dac5e9..4de7b81 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -135,15 +135,11 @@ static void setup_git_env(void)
> gitfile = read_gitfile(git_dir);
>
On 23/06/14 17:20, Tanay Abhra wrote:
> On 06/23/2014 07:57 AM, Ramsay Jones wrote:
>> On 23/06/14 11:11, Tanay Abhra wrote:
[snip]
>>> +static struct hashmap *get_config_cache(void)
>>> +{
>>> + static struct hashmap config_cache;
>>> + if (!hashmap_initialized) {
>>> + config_cache
On 24/06/14 00:25, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>>> +static struct hashmap *get_config_cache(void)
>>> +{
>>> + static struct hashmap config_cache;
>>> + if (!hashmap_initialized) {
>>> + config_cache_init(&config_cache);
>>> + hashmap_initialized = 1;
>>
Changes vs v1:
* Rebase to latest gitk master
* Fix typos in commments
* Switch to patch mode at showing the found change
Max Kirillov (4):
gitk: use single blamestuff for all show_line_source{} calls
gitk: refactor: separate generic hunk parsing out of
find_hunk_blamespecs{}
gi
There seems to be no point to search for several origins at once.
Probably is is not even fully working (because there is one blameinst),
but blamestuff for some reason is an array. Also, it is not cleaned
after blame is completed.
Signed-off-by: Max Kirillov
---
gitk | 13 -
1 file
For requesting a region blame, it is necessary to parse a hunk and
find the region in the parent file corresponding to the selected region.
There is already hunk parsing functionality in find_hunk_blamespec{},
but it returns only information for a single line.
The new function, resolve_hunk_lines{
The pattern of maintaining blame command and collecting output
can be reused for searching of latest change to region.
It still can use the blame's global variables, because the two
search commands should not run concurrently as well as two instances
of blame.
Signed-off-by: Max Kirillov
---
git
On Mon, Feb 03, 2014 at 06:20:36PM -0500, Eric Sunshine wrote:
> On Mon, Feb 3, 2014 at 5:41 PM, Max Kirillov wrote:
>> For requesting a region blame, it is necessary to parse a hunk and
>> find the region in the parent file corresponding to the selected region.
>> There is already hunk parsin fun
Add a new command to the diffmenu, "Show the latest change of selected
region". The menu command picks selection, and if it exists and covers
a single hunk, locates the latest change which has been made to the
selected lines in the file.
The menu command is disabled if the region blame is impossi
Hi all-
I work on the education team at GitHub and do a fair number of Git
workshops. One thing that I've always found difficult to explain to
newbies is how the staging area works, and why it's useful. As a
hand-wave to simplify things, I usually have them use
git add -A
git commit -m "..."
to
So, I've got a gitconfig template for new people (also what link to as
my ~/.gitconfig) so I have a smudge/clean:
[filter "gitconfig-rmuser"]
clean = sed -e \"s/^\\( *email =\\).*/\\1 /\" -e
\"s/^\\( *name =\\).*/\\1 /\" -e \"s/^\\( *signingkey
=\\).*/\\1 /\"
smudge = egrep \"^ *(email|name|si
On Tue, Jun 24, 2014 at 08:30:26PM +0700, Duy Nguyen wrote:
> On Fri, Jun 20, 2014 at 4:28 AM, Jeff King wrote:
> > diff --git a/environment.c b/environment.c
> > index 4dac5e9..4de7b81 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -135,15 +135,11 @@ static void setup_git_env(void
Putting the new trace_performance functions to good use, here are a few
observations about git-status performance.
Comes with three patches (mostly independent, not a patch series!):
* [PATCH] preload-index: optimize for sequential IO
Improves preload-index performance, should apply anywhere
Enabling core.preloadIndex on a real HD reduces cold cache performance by
~5%. This is because the threads read from up to 20 different locations on
disk.
Additionally, some threads finish early (each thread is assigned a fixed
number of cache entries to process in advance), i.e. preloading is not
Make the amount of IO parallelism configurable (i.e. number of separate
index sections to be processed in parallel).
Defining PARALLEL_IO = 20 restores approximately the IO pattern of the
original preload_index() implementation. Best performance is achieved with
PARALLEL_IO = 1 (i.e. sequential IO
Add trace_performance output to functions involved in git-status.
Signed-off-by: Karsten Blees
---
Applies on top of performance-tracing topic.
builtin/commit.c | 8
preload-index.c | 4
read-cache.c | 2 ++
wt-status.c | 11 +++
4 files changed, 25 insertion
On Wed, 2014-06-25 at 00:52 +0200, Karsten Blees wrote:
> Even more time is spent unpacking the HEAD tree, even with hot cache
> (repacking with depth 10 reduces this to ~250ms, on SSD its just 7ms).
> Perhaps caching the HEAD tree in an index extension could help here?
This is approximately wha
Am 25.06.2014 01:12, schrieb David Turner:
> On Wed, 2014-06-25 at 00:52 +0200, Karsten Blees wrote:
>> Even more time is spent unpacking the HEAD tree, even with hot cache
>> (repacking with depth 10 reduces this to ~250ms, on SSD its just 7ms).
>> Perhaps caching the HEAD tree in an index exten
On Tue, 2014-06-24 at 15:01 -0400, Aidan Feldman wrote:
> Hi all-
> I work on the education team at GitHub and do a fair number of Git
> workshops. One thing that I've always found difficult to explain to
> newbies is how the staging area works, and why it's useful. As a
> hand-wave to simplify t
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: http://svy.mk/1irgfmt
By completing this survey, you will be entered to win a $25 Amazon gift card
(submit by 07/11/14, 50 winners will
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: http://svy.mk/1irgfmt
By completing this survey, you will be entered to win a $25 Amazon gift card.
50 winners will be chosen at random f
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
> easier to work with than the raw binary data. However, some
> forms
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
> ---
> alias.c | 28 ++--
> 1 file changed, 10 ins
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
> ---
> pager.c | 44 +++-
> 1 file
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
> ---
> branch.c | 24
> 1 file changed, 8 inserti
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:
>
> On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
> >
> > Now, suppose that branches were objects. Then at push time one might
> > push with a message about the set of commits being pushed, and this
> > message (and time of pu
48 matches
Mail list logo