On Sat, Jul 12, 2014 at 02:05:39PM -0400, Jeff King wrote:
I don't particularly like 'flag' here. (not a massive dislike, mind you:)
Perhaps: flag-object_type, type-node_type?
Or, if that's too verbose, maybe just: flag-type, type-node?
Me either, but as you noticed, type was taken.
From: Ramsay Jones ram...@ramsay1.demon.co.uk
In order to encapsulate the setting of the unique commit index, commit
969eba63 (commit: push commit_index update into alloc_commit_node,
10-06-2014) introduced a (logically private) intermediary allocator
function. However, this function
Because the allocator functions for tree, blobs, etc are all
very similar, we originally used a macro to avoid repeating
ourselves. Since the prior commit, though, the heavy lifting
is done by an inline helper function. The macro does still
save us a few lines, but at some readability cost. It
The only way that obj can be non-NULL is if it came from
one of the lookup_* functions. These functions always ensure
that the object has the expected type (and return NULL
otherwise), so there is no need for us to set the type.
Signed-off-by: Jeff King p...@peff.net
---
object.c | 2 --
1 file
When we call lookup_commit, lookup_tree, etc, the logic goes
something like:
1. Look for an existing object struct. If we don't have
one, allocate and return a new one.
2. Double check that any object we have is the expected
type (and complain and return NULL otherwise).
3.
We keep a static counter to set the commit index on newly
allocated objects. However, since we also need to set the
index on any_objects which are converted to commits, let's
make the counter available as a public function.
While we're moving it, let's make sure the counter is
allocated as an
The struct object type implements basic object
polymorphism. Individual instances are allocated as
concrete types (or as a union type that can store any
object), and a struct object * can be cast into its real
type after examining its type enum. This means it is
dangerous to have a type field
We generally want to avoid lookup_unknown_object, because it
results in allocating more memory for the object than may be
strictly necessary.
In this case, it is used to check whether we have an
already-parsed object before calling parse_object, to save
us from reading the object from disk. Using
The point of the index field of struct commit is that
every allocated commit would have one. It is supposed to be
an invariant that whenever object-type is set to
OBJ_COMMIT, we have a unique index.
Commit 969eba6 (commit: push commit_index update into
alloc_commit_node, 2014-06-10) covered this
2014-07-13 13:26 GMT+09:00 Eric Sunshine sunsh...@sunshineco.com:
+ /* Decide the precision for q-factor on number of preferred
languages. */
+ if (num_langs + 1 100) { /* +1 is for '*' */
+ q_precision = 0.001;
+ q_format = ; q=%.3f;
+ } else
Am 11.07.14 18:01, schrieb Junio C Hamano:
Ephrim Khong dr.kh...@gmail.com writes:
git seems to have issues with alternates when cycles are present (repo
A has B/objects as alternates, B has A/objects as alternates).
Yeah, don't do that. A thinks eh, the other guy must have it and
B thinks
Hi Junio,
Junio C Hamano writes:
Fabian Ruch baf...@gmail.com writes:
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. This happens in two
steps. Firstly, the named commit is cherry-picked. Secondly, the
commit created in the
David Turner dtur...@twopensource.com writes:
On Fri, 2014-07-11 at 08:40 -0700, Junio C Hamano wrote:
In the ideal world, I think whoever tries to compare two cache-trees
(i.e. test-dump-cache-tree) should *not* care, because we are merely
trying to show what the correct tree object name
Yi, EungJun semtlen...@gmail.com writes:
I think it is possible like this:
num_langs += 1; /* for '*' */
decimal_places = 1 + (num_langs 10) + (num_langs 100);
snprintf(q_format, sizeof(q_format), ; q=%%.%df, decimal_places);
for (q_precision = 1.0; decimal_places-- 0;)
Jeff King p...@peff.net writes:
On Fri, Jul 11, 2014 at 02:54:25PM -0700, Junio C Hamano wrote:
Yeah, we're quite inconsistent there. In some cases we silently ignore
something unknown (e.g., a color.diff.* slot that we do not understand),
but in most cases if it is a config key we
Eric Sunshine sunsh...@sunshineco.com writes:
Made parse_sort_string take a var parameter, and if given will only warn
about invalid parameter, instead of error.
This seems unnecessarily ugly since it's hard-coding specialized
knowledge of the callers' error-reporting requirements into what
Eric Sunshine sunsh...@sunshineco.com writes:
+ (echo p; echo 1; echo; echo s; echo n; echo y; echo q) | git commit
--interactive -m foo
Broken -chain.
Would a printf make this more readable?
printf p\n1\n\ns\nn\ny\nq\n | git commt ...
Perhaps not.
But
printf %s\n
On Sun, Jul 13, 2014 at 10:10:27AM -0700, Junio C Hamano wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
Made parse_sort_string take a var parameter, and if given will only warn
about invalid parameter, instead of error.
This seems unnecessarily ugly since it's hard-coding
On Sun, Jul 13, 2014 at 01:33:56PM -0400, Jeff King wrote:
I realize that I am reinventing the error-reporting wheel on a sleepy
Sunday afternoon without having thought about it much, so there is
probably some gotcha or case that makes this ugly, or perhaps it just
ends up verbose in
On Sun, Jul 13, 2014 at 1:22 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
+ (echo p; echo 1; echo; echo s; echo n; echo y; echo q) | git commit
--interactive -m foo
Broken -chain.
Would a printf make this more readable?
printf
On 13/07/14 07:41, Jeff King wrote:
On Sat, Jul 12, 2014 at 02:05:39PM -0400, Jeff King wrote:
I don't particularly like 'flag' here. (not a massive dislike, mind you:)
Perhaps: flag-object_type, type-node_type?
Or, if that's too verbose, maybe just: flag-type, type-node?
Me either, but
From: David Turner dtur...@twopensource.com
Do not treat known-invalid trees as errors even when their subtree_nr is
incorrect. Because git already knows that these trees are invalid,
an incorrect subtree_nr will not cause problems.
Add a couple of comments.
Signed-off-by: David Turner
From: David Turner dtur...@twopensource.com
When git checkout checks out a branch, create or update the
cache-tree so that subsequent operations are faster.
update_main_cache_tree learned a new flag, WRITE_TREE_REPAIR. When
WRITE_TREE_REPAIR is set, portions of the cache-tree which do not
From: David Turner dtur...@twopensource.com
During the commit process, update the cache-tree. Write this updated
cache-tree so that it's ready for subsequent commands.
Add test code which demonstrates that git commit now writes the cache
tree. Make all tests test the entire cache-tree, not just
From: David Turner dtur...@twopensource.com
Add tests to confirm that invalidation of subdirectories neither over-
nor under-invalidates.
Signed-off-by: David Turner dtur...@twitter.com
---
t/t0090-cache-tree.sh | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
2014-07-14 1:57 GMT+09:00 Junio C Hamano gits...@pobox.com:
If you do not want floating point (and I think we tend to avoid it
when we do not need it), you can realize that in your use of 0.1
and 0.01 and 0.001 there is nothing fundamentally floating-point;
you can measure how many digits
Jens Lehmann jens.lehm...@web.de writes:
Perhaps squashing this to 7e8e5af9 instead?
Yes please, this is much better than my first attempt.
One thing that I found troubling is the ../../../ three levels up
is hardcoded. Would it be always true for any value of $1? If
the submodule is bound
My name is Carlos Ramirez, I am lawyer here in Madrid Spain. I want to
transfer an abandoned sum of 13.5 Millions USD to your account.50%
will be for you. No risk involved. Contact me for more details.
Kindly reply me back to my alternative email address ( carlos...@aol.com )
Regards
On 07/02/2014 07:10 PM, Alex Vandiver wrote:
On 07/02/2014 06:20 PM, Junio C Hamano wrote:
Alex Vandiver a...@chmrr.net writes:
[remote github]
url = g...@github.com:bestpractical/rt.git
fetch = +refs/*:refs/*
mirror = yes
git push github master^:master must
Duy Nguyen pclo...@gmail.com writes:
[01/20] dir.c: coding style fix
[02/20] dir.h: move struct exclude declaration to top level
[03/20] prep_exclude: remove the artificial PATH_MAX limit
...perhaps with s/if (!dir-basebuf.alloc)/if (!dir-basebuf.buf)/
@Duy any reason for not signing off
My name is Carlos Ramirez, I am lawyer here in Madrid Spain. I want to
transfer an abandoned sum of 13.5 Millions USD to your account.50%
will be for you. No risk involved. Contact me for more details.
Kindly reply me back to my alternative email address ( carlos...@aol.com )
Regards
On Wed, Jul 9, 2014 at 2:47 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Jul 9, 2014 at 3:33 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com
wrote:
Yet, there is a space after the opening '{'. So, this is now
inconsistently formatted as:
{ foo, bar}
So, if we drop the other
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
fd = open(git_path(repos/%s/gitdir, id), O_RDONLY);
...
- while (path[len - 1] == '\n' || path[len - 1] == '\r')
+ while (len (path[len - 1] == '\n' || path[len - 1] == '\r'))
len--;
Do we anticipate (or even
As Junio and I discussed earlier in [1], this series makes the
prio_queue struct stable with respect to object insertion (which in turn
means we can use it to replace commit_list in more places).
I think everything here is correct, but the second commit fails the
final test in t5539. I think the
When manipulating the priority queue's heap, we frequently
have to compare and swap heap entries. As we are storing
only void pointers right now, this is quite easy to do
inline in a few lines. However, when we start using a more
complicated heap entry in a future patch, that will get
longer.
If two items are added to a prio_queue and compare equal,
they currently come out in an apparently random order (this
order is deterministic for a particular sequence of
insertions and removals, but does not necessarily match the
insertion order). This makes it unlike using a date-ordered
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
On Sun, Jul 13, 2014 at 08:27:51PM +0100, Ramsay Jones wrote:
Thinking on this more, writing out the definitions is the only sane
thing to do here, now that alloc_commit_node does not use the macro.
Otherwise you are inviting people to modify the macro, but fail to
notice that the commit
38 matches
Mail list logo
