Jeff King writes:
> On Fri, Oct 03, 2014 at 02:47:57PM -0700, Junio C Hamano wrote:
>
>> With this patch applied, the system will not prune unreachable old
>> objects that are reachable from a recent object (the recent object
>> itself may or may not be reachable but that does not make any
>> dif
On Sat, Oct 04, 2014 at 12:55:13AM +0200, René Scharfe wrote:
> >-void foreach_alt_odb(alt_odb_fn fn, void *cb)
> >+int foreach_alt_odb(alt_odb_fn fn, void *cb)
> > {
> > struct alternate_object_database *ent;
> >+int r = 0;
> >
> > prepare_alt_odb();
> >-for (ent = alt_odb_list;
On Fri, Oct 03, 2014 at 02:47:57PM -0700, Junio C Hamano wrote:
> With this patch applied, the system will not prune unreachable old
> objects that are reachable from a recent object (the recent object
> itself may or may not be reachable but that does not make any
> difference). And that is suff
On Fri, Oct 03, 2014 at 03:19:29PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Prune has to walk $GIT_DIR/objects/?? in order to find the
> > set of loose objects to prune. Other parts of the code
> > (e.g., count-objects) want to do the same. Let's factor it
> > out into a reusable f
On Fri, Oct 03, 2014 at 03:17:18PM -0700, Junio C Hamano wrote:
> > That's a bit verbose. We could hide it behind something like test_eq,
> > too, but it introduces several extra new processes.
>
> What do you mean by "extra new processes"? Whether open coded in a
> verbose way, or wrapped insid
On Fri, Oct 03, 2014 at 02:47:57PM -0700, Junio C Hamano wrote:
> Sorry but this part is beyond a simple panda brain.
I probably didn't explain it very well. I found it rather confusing to
reason about. Let's see if we can go through it together.
> I can understand this
>
> If we have an
On Fri, Oct 03, 2014 at 02:29:58PM -0700, Junio C Hamano wrote:
> > We can solve this by "freshening" objects that we avoid
> > writing by updating their mtime. The algorithm for doing so
> > is essentially the same as that of has_sha1_file. Therefore
> > we provide a new (static) interface "check
René Scharfe wrote:
> --- a/bundle.c
> +++ b/bundle.c
> @@ -211,24 +211,28 @@ static int is_tag_in_date_range(struct object *tag,
> struct rev_info *revs)
> enum object_type type;
> char *buf, *line, *lineend;
If buf is initialized to NULL, there is no need for separate out and
out_f
Am 03.10.2014 um 22:21 schrieb Jeff King:
We check the return value of the callback and stop iterating
if it is non-zero. However, we do not make the non-zero
return value available to the caller, so they have no way of
knowing whether the operation succeeded or not (technically
they can keep the
Free the buffer returned by read_sha1_file() even if no valid tagger
line is found.
Signed-off-by: Rene Scharfe
---
bundle.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/bundle.c b/bundle.c
index b2b89fe..9ed865c 100644
--- a/bundle.c
+++ b/bundle.c
@@ -2
Jeff King writes:
> ... The objects are removed by prune, which doesn't realize
> that they are part of an ongoing operation. Prune uses the filesystem
> mtime to determine this, but we are not very thorough in making sure
> that is kept up to date.
The whole series looked quite sensible. Thank
Jeff King writes:
> Prune has to walk $GIT_DIR/objects/?? in order to find the
> set of loose objects to prune. Other parts of the code
> (e.g., count-objects) want to do the same. Let's factor it
> out into a reusable for_each-style function.
Doesn't fsck also look at these as well? I recall t
Jeff King writes:
> For small outputs, we sometimes use:
>
> test "$(some_cmd)" = "something we expect"
>
> instead of a full test_cmp. The downside of this is that
> when it fails, there is no output at all from the script.
> Let's introduce a small helper to make tests easier to
> debug.
>
>
Jeff King writes:
> This is slightly more robust (checking "! test -f" would not
> notice a directory of the same name, though that is not
> likely to happen here). It also makes debugging easier, as
> the test script will output a message on failure.
>
> Signed-off-by: Jeff King
> ---
> This pa
Jeff King writes:
> Instead, this patch pushes the extra work onto prune, which
> runs less frequently (and has to look at the whole object
> graph anyway). It creates a new category of objects: objects
> which are not recent, but which are reachable from a recent
> object. We do not prune these
From: Ronnie Sahlberg
Date: Thu, 1 May 2014 11:16:07 -0700
commit 23acf975d74825789112a3a7ba97dbbdc76904f4 upstream.
Change is_refname_available to take a list of strings to exclude when
checking for conflicts instead of just one single name. We can already
exclude a single name for the sake of
Jeff King writes:
> When we try to write a loose object file, we first check
> whether that object already exists. If so, we skip the
> write as an optimization. However, this can interfere with
> prune's strategy of using mtimes to mark files in progress.
>
> For example, if a branch contains a
When we try to write a loose object file, we first check
whether that object already exists. If so, we skip the
write as an optimization. However, this can interfere with
prune's strategy of using mtimes to mark files in progress.
For example, if a branch contains a particular tree object
and is d
Ronnie Sahlberg writes:
> On Thu, Oct 2, 2014 at 11:55 AM, Junio C Hamano wrote:
> ...
>> Thanks. We originally threw all the different kind of breakages
>> into ISBROKEN, but a ref can have a malformed name or can contain a
>> bad/non value and allowing us to tell them apart is a good directio
When we are loosening unreachable packed objects, we do not
bother to process objects that would simply be pruned
immediately anyway. The "would be pruned" check is a simple
comparison, but is about to get more complicated. Let's pull
it out into a separate function.
Note that this is slightly les
Our current strategy with prune is that an object falls into
one of three categories:
1. Reachable (from ref tips, reflogs, index, etc).
2. Not reachable, but recent (based on the --expire time
and the file's mtime).
3. Not reachable and not recent.
We keep objects from (1) and (2),
A recent commit taught git-prune to keep non-recent objects
that are reachable from recent ones. However, pack-objects,
when loosening unreachable objects, tries to optimize out
the write in the case that the object will be immediately
pruned. It now gets this wrong, since its rule does not
reflect
We typically iterate over the reachable objects in a
repository by starting at the tips and walking the graph.
There's no easy way to iterate over all of the objects,
including unreachable ones. Let's provide a way of doing so.
Signed-off-by: Jeff King
---
cache.h | 11 +++
sha1_file
On Fri, Oct 3, 2014 at 1:25 PM, Ronnie Sahlberg wrote:
> On Thu, Oct 2, 2014 at 11:55 AM, Junio C Hamano wrote:
>> Jonathan Nieder writes:
>>
>>> From: Ronnie Sahlberg
>>> ...
>>> In resolving functions, refuse to resolve refs that don't pass the
>>> check-ref-format(1) check unless the new RES
This drops our line count considerably, and should make
things more readable by keeping the counting logic separate
from the traversal.
Signed-off-by: Jeff King
---
builtin/count-objects.c | 101 ++--
1 file changed, 30 insertions(+), 71 deletions(-)
The point of xsize_t is to safely cast an off_t into a size_t
(because we are about to mmap). But in count-objects, we are
summing the sizes in an off_t. Using xsize_t means that
count-objects could fail on a 32-bit system with a 4G
object (not likely, as other parts of git would fail, but
we shoul
Prune has to walk $GIT_DIR/objects/?? in order to find the
set of loose objects to prune. Other parts of the code
(e.g., count-objects) want to do the same. Let's factor it
out into a reusable for_each-style function.
Note that this is not quite a straight code movement. There
are two differences:
For small outputs, we sometimes use:
test "$(some_cmd)" = "something we expect"
instead of a full test_cmp. The downside of this is that
when it fails, there is no output at all from the script.
Let's introduce a small helper to make tests easier to
debug.
Signed-off-by: Jeff King
---
This is
This is slightly more robust (checking "! test -f" would not
notice a directory of the same name, though that is not
likely to happen here). It also makes debugging easier, as
the test script will output a message on failure.
Signed-off-by: Jeff King
---
This patch is totally optional. I did it w
On Thu, Oct 2, 2014 at 11:55 AM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> From: Ronnie Sahlberg
>> ...
>> In resolving functions, refuse to resolve refs that don't pass the
>> check-ref-format(1) check unless the new RESOLVE_REF_ALLOW_BAD_NAME
>> flag is passed. Even with RESOLVE_RE
We add a number of objects to our "pending" array, and then
process it with a combination of get_revision and walking
the pending array ourselves (to catch any non-commits). The
commits in the pending array are cleaned up automatically by
prepare_revision_walk, but we essentially leak any other
obj
When we enter prepare_revision_walk, we have zero or more
entries in our "pending" array. We disconnect that array
from the rev_info, and then process each entry:
1. If the entry is a commit and the --source option is in
effect, we keep a pointer to the object name.
2. Otherwise, we re-a
There's currently no easy way to free the memory associated
with an object_array (and in most cases, we simply leak the
memory in a rev_info's pending array). Let's provide a
helper to make this easier to handle.
We can make use of it in list-objects.c, which does the same
thing by hand (but fails
This is not a lot of code, but it's a logical construct that
should not need to be repeated (and we are about to add a
third repetition).
Signed-off-by: Jeff King
---
object.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/object.c b/object.c
index ca9d790..1423
Otherwise, callers must do so or risk triggering
-Wchar-subscript (and rightfully so; a signed char might
cause us to use a bogus negative index into the
hexval_table).
While we are dropping the now-unnecessary casts from the
caller in urlmatch.c, we can get rid of similar casts in
actually parsin
We check the return value of the callback and stop iterating
if it is non-zero. However, we do not make the non-zero
return value available to the caller, so they have no way of
knowing whether the operation succeeded or not (technically
they can keep their own error flag in the callback data, but
At GitHub we've occasionally run across repos getting corrupted by trees
and blobs near the tip going missing. We do a lot of "test merges"
between branches and HEAD (this is what feeds the "OK to merge" button
on the web interface), and the objects are almost always related to
these merges. The ob
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> The "git config [--add] section.var value" UI, [...] finds the "var = value"
>> definition at the end (or adds a "section" at the end and then adds
>> [...]
>>
>> It is fine for single-valued ones that follow "the last one wins"
>> semantics; "g
Junio C Hamano writes:
> The "git config [--add] section.var value" UI, [...] finds the "var = value"
> definition at the end (or adds a "section" at the end and then adds
> [...]
>
> It is fine for single-valued ones that follow "the last one wins"
> semantics; "git config" would add the new def
Nazri Ramliy writes:
> When rebasing these upwards of 40+ commits, it is helpful if the
> rebase instruction sheet shows me the actual files that the commits
> affect so I made this patch (sorry I couldn't attach it inline since
> gmail eats all the tabs) that adds the "--show-files" option to
>
Jonathan Nieder writes:
> Junio C Hamano wrote:
> ...
>> As cbe73331 (refs: speed up is_refname_available, 2014-09-10)
>> touches the same area and is now in 'master', the logic around here
>> in this series needs to be reworked.
>
> Thanks for the heads up. (I hadn't realized the ref-transactio
Junio C Hamano writes:
> Even though I did allude to ../project.gitconfig in the original message, I
> think there should probably be an explicit syntax to name a path that is
> relative to the root level of the working tree. People do funky things using
> $GIT_DIR and $GIT_WORK_TREE to break the
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> diff --git a/refs.c b/refs.c
>> index f124c2b..6820c93 100644
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -801,14 +801,16 @@ static int names_conflict(const char *refname1, const
>> char *refname2)
>>
>> struct name_conflict_cb {
>> const char
Junio C Hamano writes:
> That is why I said "unset.variable" is unworkable with existing "git
> config" command line. Always appending at the end is usable for
> ordinary variables, but for unset.variable, it is most likely the
> least useful thing to do. You can explain "among 47 different
> t
Matthieu Moy writes:
> Junio C Hamano writes:
> ...
>> Off the top of my head, from an end-user's point of view, something
>> like this would give a behaviour that is at least understandable:
Let's make sure we have the same starting point (i.e. understanding
of the limitation of the current co
Torsten Bögershausen writes:
>> The first sentence says what happens, as it should.
>>
>> But it is not directly clear what makes the executable bit differ
>> and when it is a useful thing to ignore the differences, so the
>> second sentence that says "This may be useful" does not give the
>> re
On 2014-10-02 19.02, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> On 2014-10-01 19.10, Junio C Hamano wrote:
>>> Hilco Wijbenga writes:
>>>
Perhaps I completely misunderstand the meaning of core.filemode but I
thought it determined whether Git cared about changes in file
>
I really like the way Git officializes the relation between branches via
the notion of "tracking". I can see which local branch tracks which
remote branch easily, and that's very helpful.
But when I find a Git repository on the Web, I often have no idea about
the relationship between its branches
On Fri, Oct 03 2014, Jens Lehmann wrote:
> Am 30.09.2014 um 15:25 schrieb Michal Sojka:
>> I'd like to shorten the time needed by our continuous integration (CI)
>> tool to clone the source repositories. Currently the full clone takes
>> about 10 minutes (even from local server). Our main repositor
Am 30.09.2014 um 15:25 schrieb Michal Sojka:
I'd like to shorten the time needed by our continuous integration (CI)
tool to clone the source repositories. Currently the full clone takes
about 10 minutes (even from local server). Our main repository has
several submodules so the CI tool runs "git
* Works with Apple clang
* Works with FSF GCC and NO_APPLE_COMMON_CRYPTO=yes.
* Fails with FSF GCC, see below
* FWIW, git-1.8.4.4 can be compiled with FSF GCC
$ gcc --version
gcc (GCC) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditi
Hi,
On Fri, Oct 3, 2014 at 5:42 PM, Nazri Ramliy wrote:
> Hi,
>
> When working on a "new feature branch" that touches a lot of files I
> tend to make commits that affect only single files, and for very small
> changes. Since at this stage I'm experimentating a lot - trying out
> ideas, etc. - the
Junio C Hamano writes:
> Tanay Abhra writes:
>
>> I can think of two solutions, one leave it as it is and advertise it to be
>> explicitly typed in the config files at the appropriate position or to change
>> the behavior of unset.variable to unset all matching variables in that file,
>> before
53 matches
Mail list logo
