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 majord
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 com
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, t
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)
> >
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
>
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 " first doesn't work and all of the
sudden that command works and updates e.g.
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).
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 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 though
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 pro
Am 05.10.2014 um 00:22 schrieb Junio C Hamano:
Jeff King 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 input to unsigne
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 branc
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
13 matches
Mail list logo