On Thursday 2014-02-20 00:40, Junio C Hamano wrote:
On Wed, Feb 19, 2014 at 2:58 PM, Jan Engelhardt jeng...@inai.de wrote:
Looking at it from one more angle, `git fetch r --tags` and
`git push r --tags` is now no longer symmetric :(
I would have loved to hear such comments _during_ the
On 02/19/2014 11:58 PM, Jan Engelhardt wrote:
On Wednesday 2014-02-19 21:01, Junio C Hamano wrote:
Jan Engelhardt jeng...@inai.de writes:
The release notes for 1.9.0 read:
* The --tags option to git fetch no longer tells the command to
fetch _only_ the tags. It instead fetches tags _in
On Thu, Feb 20, 2014 at 3:17 AM, Junio C Hamano gits...@pobox.com wrote:
+ strbuf_setlen(sb, len);
+ strbuf_add(sb, s, strlen(s));
I am not sure addstr_at() gives us a good abstraction, or at least
the name conveys what it does well not to confuse readers.
At first after only seeing
Hi Semyon,
Am 18.02.2014 18:49, schrieb Semyon Perepelitsa:
I noticed the option in the man-page but there is still no configuration
option available. Did you forget to add it after all?
Nope, we just didn't implement it yet. ;-)
It's one of the topics on my submodule ToDo list:
On Thu, Feb 20, 2014 at 3:32 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
(Only nitpicks during this round of review).
+ if (get_device_or_die(path) != get_device_or_die(get_git_dir())) {
+ strbuf_reset(sb);
+
On Thu, Feb 20, 2014 at 5:08 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
+static dev_t get_device_or_die(const char *path)
+{
+ struct stat buf;
+ if (stat(path, buf))
+ die_errno(failed to stat '%s', path);
+ /* Ah Windows! Make different drives
Hello,
I started playing around with sharing git notes and so was happy to see
that git-notes learned about merging since I last tried.
My first try looked as follows (using git 1:1.9.0-1 from Debian):
$ git fetch $someremote refs/notes/commits
...
$ git notes merge
Duy Nguyen pclo...@gmail.com writes:
I can think of two improvements we could make, either increase cache
size dynamically (within limits) or make it configurable. If we have N
entries in worktree (both trees and blobs) and depth M, then we might
need to cache N*M objects for it to be
David Kastrup d...@gnu.org writes:
Duy Nguyen pclo...@gmail.com writes:
I can think of two improvements we could make, either increase cache
size dynamically (within limits) or make it configurable. If we have N
entries in worktree (both trees and blobs) and depth M, then we might
need to
On Thu, 20 Feb 2014 12:06:17, Michael Haggerty wrote:
On 02/19/2014 11:58 PM, Jan Engelhardt wrote:
Looking at it from one more angle, `git fetch r --tags` and
`git push r --tags` is now no longer symmetric :(
I'm glad you brought this up, because I didn't really think about
whether git push
Michael Haggerty mhag...@alum.mit.edu writes:
I wonder whether we could give a way to specify a reference in an
unambiguous, canonical fashion like I expected, for example by using a
leading slash: /refs/heads/mybranch. This could be a way for the user
to ask for DWIMming to be turned off
Duy Nguyen pclo...@gmail.com writes:
OK so your question was if there was a git_path() or mkpath() call
earlier in update_refs_for_switch() and the result was expected to
remain stable till the end of update_refs_for_switch(), then this
conversion could ruin it, correct? I didn't think about
On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:
* fc/transport-helper-fixes (2013-12-09) 6 commits
- remote-bzr: support the new 'force' option
- test-hg.sh: tests are now expected to pass
- transport-helper: check for 'forced update' message
- transport-helper: add 'force'
Duy Nguyen pclo...@gmail.com writes:
On Thu, Feb 20, 2014 at 3:17 AM, Junio C Hamano gits...@pobox.com wrote:
+ strbuf_setlen(sb, len);
+ strbuf_add(sb, s, strlen(s));
I am not sure addstr_at() gives us a good abstraction, or at least
the name conveys what it does well not to
Max Horn m...@quendi.de writes:
On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:
* fc/transport-helper-fixes (2013-12-09) 6 commits
- remote-bzr: support the new 'force' option
- test-hg.sh: tests are now expected to pass
- transport-helper: check for 'forced update' message
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
On Thu, Feb 20, 2014 at 3:17 AM, Junio C Hamano gits...@pobox.com wrote:
+ strbuf_setlen(sb, len);
+ strbuf_add(sb, s, strlen(s));
I am not sure addstr_at() gives us a good abstraction, or at least
the
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
@@ -2717,17 +2729,19 @@ static int copy_msg(char *buf, const char *msg)
return cp - buf;
}
-int log_ref_setup(const char *refname, char *logfile, int bufsize)
+int log_ref_setup(const char *refname, struct strbuf *sb_logfile)
{
Duy Nguyen pclo...@gmail.com writes:
But why is it OK to fail in the first place? If we couldn't link,
don't you want to fall back to the lock codepath? After all, the
are we on the same device? check is to cope with the case where
we cannot link and that alternate codepath is supposed to
On Wed, Feb 19, 2014 at 09:19:24PM +0700, Duy Nguyen wrote:
We don't need to do any of that immediately. This is mostly just me
thinking aloud, to make sure we do not paint ourselves into a corner
compatibility-wise.
Good thinking. If you plan to use the exact same sort syntax f-e-r
Hello,
I'm playing around with git-notes and want to share some of my notes
with my co-workers. We have a central repository for our various topic
branches and want to track upstream inclusion in git-notes. So we have
to share our notes branch somehow.
The workflow I think makes sense here is
Sorry for the late reply, but here we go ...
Am 10.02.2014 07:33, schrieb Gábor Lipták:
Hi Jens,
So git status says:
liptak@liptak-kubuntu:~/Projects/MAIN_MODULE/platform/SUBMODULE
[master]$ git status
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes
On Thu, Feb 20, 2014 at 1:03 PM, Jens Lehmann jens.lehm...@web.de wrote:
Sorry for the late reply, but here we go ...
Am 10.02.2014 07:33, schrieb Gábor Lipták:
Hi Jens,
So git status says:
liptak@liptak-kubuntu:~/Projects/MAIN_MODULE/platform/SUBMODULE
[master]$ git status
# On branch
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
Duy Nguyen pclo...@gmail.com writes:
Something's _really_ fishy about that cache behavior. Note that the
_system_ time goes up considerably, not just user time. Since the
packs are zlib-packed, it's reasonable that
On Thu, Feb 20, 2014 at 1:59 AM, Junio C Hamano gits...@pobox.com wrote:
Philippe Vaucher philippe.vauc...@gmail.com writes:
fwiw this is the thread that added --depth=250
http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
This post is quite interesting:
This delta_stack array can grow to any length depending on the actual
delta chain, but we forget to free it. Normally it does not matter
because we use small_delta_stack[] from stack and small_delta_stack
can hold 64-delta chains, more than standard --depth=50 in pack-objects.
Signed-off-by:
On 19 February 2014 00:14, Junio C Hamano gits...@pobox.com wrote:
[...]
The patch was whitespace damaged, by the way. It was easy to hand
tweak so there is no need to resend this particular patch, but if
you are planning to send more patches, please check your MUA and
tell it not to.
Suits
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
What is the right mental model the end-user needs to form when
understanding these? Conditions on keys go on the left, and any
other random conditions can come as a modifier after action
e.g.
2014-02-20 23:35 GMT+00:00 Duy Nguyen pclo...@gmail.com:
does it make sense to apply
--depth=250 for old commits only
Just wondering: would it be difficult to fix the problems that lead to
worse than linear slowdown with the --depth? (I.e. adaptive cache/hash
table size.) If the performance
On Tue, Feb 18, 2014 at 8:40 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
index 73e80ce..aec9fdb 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -116,6 +116,10 @@ extern void strbuf_add(struct strbuf *, const void *,
size_t);
static
On Fri, Feb 21, 2014 at 06:35:06AM +0700, Duy Nguyen wrote:
On the other hand, the size reduction is really nice (320MB vs 500MB).
I don't know if we can do this, but does it make sense to apply
--depth=250 for old commits only and shallow depth for recent commits?
For old projects, commits
On Fri, Feb 21, 2014 at 06:47:47AM +0700, Nguyễn Thái Ngọc Duy wrote:
This delta_stack array can grow to any length depending on the actual
delta chain, but we forget to free it. Normally it does not matter
because we use small_delta_stack[] from stack and small_delta_stack
can hold 64-delta
31 matches
Mail list logo
