Junio C Hamano gits...@pobox.com writes:
Tanay Abhra tanay...@gmail.com 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
Hi,
On Fri, Oct 3, 2014 at 5:42 PM, Nazri Ramliy ayieh...@gmail.com 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,
* 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
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
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 repository has
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 2014-10-02 19.02, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
On 2014-10-01 19.10, Junio C Hamano wrote:
Hilco Wijbenga hilco.wijbe...@gmail.com writes:
Perhaps I completely misunderstand the meaning of core.filemode but I
thought it determined whether Git cared
Torsten Bögershausen tbo...@web.de 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com 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.
Junio C Hamano gits...@pobox.com 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
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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 gits...@pobox.com 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
Jonathan Nieder jrnie...@gmail.com 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
Nazri Ramliy ayieh...@gmail.com 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
Junio C Hamano gits...@pobox.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com 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
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
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 p...@peff.net
---
object.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/object.c b/object.c
index
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
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
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
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
On Thu, Oct 2, 2014 at 11:55 AM, Junio C Hamano gits...@pobox.com wrote:
Jonathan Nieder jrnie...@gmail.com writes:
From: Ronnie Sahlberg sahlb...@google.com
...
In resolving functions, refuse to resolve refs that don't pass the
check-ref-format(1) check unless the new
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 p...@peff.net
---
This patch is totally
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 p...@peff.net
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
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
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 p...@peff.net
---
builtin/count-objects.c | 101 ++--
1 file changed, 30 insertions(+), 71
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 p...@peff.net
---
cache.h | 11
On Fri, Oct 3, 2014 at 1:25 PM, Ronnie Sahlberg sahlb...@google.com wrote:
On Thu, Oct 2, 2014 at 11:55 AM, Junio C Hamano gits...@pobox.com wrote:
Jonathan Nieder jrnie...@gmail.com writes:
From: Ronnie Sahlberg sahlb...@google.com
...
In resolving functions, refuse to resolve refs that
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
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 less
Ronnie Sahlberg sahlb...@google.com writes:
On Thu, Oct 2, 2014 at 11:55 AM, Junio C Hamano gits...@pobox.com 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
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),
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
Jeff King p...@peff.net 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
From: Ronnie Sahlberg sahlb...@google.com
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
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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 p...@peff.net 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?
Jeff King p...@peff.net 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
Free the buffer returned by read_sha1_file() even if no valid tagger
line is found.
Signed-off-by: Rene Scharfe l@web.de
---
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
+++
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
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_free
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
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 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 inside a
On Fri, Oct 03, 2014 at 03:19:29PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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
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; ent; ent =
Jeff King p...@peff.net 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
53 matches
Mail list logo
