Am 03.10.2014 um 22:32 schrieb Jeff King:
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
Am 03.10.2014 um 22:41 schrieb Jeff King:
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
Am 05.10.2014 um 00:22 schrieb Junio C Hamano:
Jeff King p...@peff.net writes:
There's quite a lot of patches here, but most of them are preparatory
cleanups. The meat is in patches 13, 15, and 16.
[01/16]: foreach_alt_odb: propagate return value from callback
[02/16]: isxdigit: cast
On 05/10/14 09:15, René Scharfe wrote:
Am 03.10.2014 um 22:32 schrieb Jeff King:
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
Hi all,
I've just found that:
- given you have an empty staging area
- and you have only untracked files in your working dir
- when you do `git stash --untracked`
- then `git stash show` gives you an empty output = stash looks empty
My first thought was oh god, my files are lost!
Second thought:
We have a private donation for you
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
I think gitk is great, but I have a small annoyance with it.
As it starts up the three history panels in the top half of the screen
have the same width.
After maximizing the window they all get wider and still have the same
width as each other (scaled up proportionally, which makes sense).
I also like the feature of being able to fetch commits by SHA-1. My
problem is that it is not clear to end users whether they can fetch
SHA-1 from a specific server or not. For exactly the same server a
git fetch origin id-of-commit-x first doesn't work and all of the
sudden that command works and
René Scharfe wrote:
Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off
and use skip_prefix() in more places for determining the lengths of prefix
strings to avoid using dependent constants and other indirect methods.
Sounds promising.
[...]
--- a/builtin/branch.c
+++
On Sun, Oct 05, 2014 at 03:49:19PM -0700, Jonathan Nieder wrote:
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -81,14 +81,16 @@ static int parse_branch_color_slot(const char *var, int
ofs)
static int git_branch_config(const char *var, const char *value, void *cb)
{
+
On Sat, Oct 04, 2014 at 08:54:50PM +0200, René Scharfe wrote:
Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off
and use skip_prefix() in more places for determining the lengths of prefix
strings to avoid using dependent constants and other indirect methods.
Thanks,
On Sat, Oct 04, 2014 at 03:22:10PM -0700, Junio C Hamano wrote:
This applied on top of 'maint' (which does have c40fdd01) makes the
test #9 (prune: do not prune detached HEAD with no reflog) fail.
I'll fix the bone-headed error returns that René noticed and double
check that they were the
On Tue, Sep 30, 2014 at 11:02:29AM +0400, Marat Radchenko wrote:
This patch series fixes building on modern MinGW and MinGW-W64 (including
x86_64!).
Junio, ping?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
13 matches
Mail list logo
