On Tue, Apr 16, 2013 at 10:26:40PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > René Scharfe writes:
> >
> >> How about making split_ident_line() a bit friendlier be letting it
> >> provide the epoch as default time stamp instead of NULL?
> >
> > Two knee-jerk concerns I have w
Hi,
>> > $ ulimit -c unlimited
>>
>> Have set the git user's crash limit to 1GB in
>> /etc/security/limits.conf and still getting the same error when
>> issuing gdb to the crash file.
>
> Yep, suppsedly in Ubuntu it's not that easy to just get a plain old
> coredump file -- see below.
>
Got an p
Hello Erik,
On Tue, Apr 16, 2013 at 05:18:49PM +0200, Erik Faye-Lund wrote:
> >> >> Support determining the binaries' installation path at runtime even if
> >> >> called without any path components (i.e. via search path).
> I think the motivation for the feature in the first place is Windows,
> w
Am 4/17/2013 3:38, schrieb Tim Chase:
> I asked this on IRC and played with some of their ideas, but struck
> out with anything satisfying. I walked through [1] with the
> following setup:
>
> git init foo
> cd foo
> touch a.txt b.txt
> git add a.txt b.txt
> git commit -m "Initial check
Hi,
Thanks for review!
2013/4/16 Thomas Rast :
> Ralf Thielow writes:
>
>> msgid "You are currently reverting commit %s."
>> -msgstr "Sie sind gerade bei einer binären Suche in Zweig '%s'."
>> +msgstr "Sie kehren gerade Version '%s' um."
>
> Is revert->umkehren new? I can see it's in the gloss
Junio C Hamano writes:
> René Scharfe writes:
>
>> How about making split_ident_line() a bit friendlier be letting it
>> provide the epoch as default time stamp instead of NULL?
>
> Two knee-jerk concerns I have without going back to the callers:
>
> * Would that "0" ever be given to the appr
I checked René Scharfe's patch and it works - no more git log crash.
Also I checked a broken commits by git show and the most of them
created by me. I can confirm I never used anyting else except console
git commit or netbeans gui to commit, which is just git gui wrapper
tool. Several commits is a
Hi,
Thanks for Review!
2013/4/15 Christian Stimming :
> Thanks for the regular update! This is great work.
>
> One issue with the plural form messages, though:
>
> Am Montag, 15. April 2013, 18:27:40 schrieb Ralf Thielow:
>> #: bundle.c:186
>> -#, fuzzy, c-format
>> +#, c-format
>> msgid "The b
Phil Hord writes:
> On Mon, Apr 1, 2013 at 3:02 PM, Jens Lehmann wrote:
>> Okay, so here is the patch for that. If someone could point out
>> a portable and efficient way to check if a directory is already
>> empty I would be happy to use that to silence the "Cleaned
>> directory" message curren
On Tue, Apr 16, 2013 at 9:48 PM, Junio C Hamano wrote:
> That is a valid point. Nobody has complained that the current
> warning is too noisy, so perhaps the patch is good as-is?
Ah, hadn't realized that. Probably fine then.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the
John Keeping writes:
> Printing one message per tag also matches the current behaviour for
> --signed-tags=warn. I don't want to make the behaviour for "warn" and
> "warn-strip" different,...
That is a valid point. Nobody has complained that the current
warning is too noisy, so perhaps the patc
Phil Hord writes:
> ... Almost every time I bisect a regression
> in git.git, I find the commit message tells me exactly why the commit
> did what it did and what the expected result was. I find this to be
> amazingly useful.
> ...
> Of course, 99% of the commit messages may never be useful to
Jeff King writes:
> On Tue, Apr 16, 2013 at 04:22:25PM -0700, Junio C Hamano wrote:
>
>> +static void parse_expire_value(const char *value, unsigned long *expire)
>> +{
>> +if (!strcmp(value, "never") || !strcmp(value, "false"))
>> +*expire = 0;
>> +else if (!strcmp(value, "al
Sorry about the =3D escapes. My first attempt to submit bounced b/c it was
html and I missed
cleaning some escapes. The snippet should be:
if type_base == "symlink":
git_mode = "12"
# p4 print on a symlink contains "target\n"; remove the newline
data = ''.join(co
git-p4.py (1.8.2.1.418.gaec3f77) has at least two behaviors that
seem to be incompatible with the version of p4 that I recently
downloaded from perforce.com (P4/LINUX26X86_64/2013.1/610569).
TLDR: Is git-p4 written for an old version of p4 CLI with different
behavior? Or for a windows or mac rele
On 2013-04-16 19:29, David Aguilar wrote:
> On Tue, Apr 16, 2013 at 6:38 PM, Tim Chase
> wrote:
> > git commit -am "Long-bodied commit comment about b.txt changes"
> > # whoops, just wanted B
>
> Save the commit's ID here so that we can reuse its message later:
>
> orig_commit=$(git rev-
Looks like I missed a lot of fun I'm sleeping ;)
The current repo is a product of our core crossplatform team, working
on Linux/MacOSX/Win32 environment. The Linux environment also
separates on Ubuntu/ArchLinux distros, and probably most of repo bugs
coming from ArchLinux, since other environments
Taking a wild guess here...
On Tue, Apr 16, 2013 at 6:38 PM, Tim Chase wrote:
> I asked this on IRC and played with some of their ideas, but struck
> out with anything satisfying. I walked through [1] with the
> following setup:
>
> git init foo
> cd foo
> touch a.txt b.txt
> git add a.t
I asked this on IRC and played with some of their ideas, but struck
out with anything satisfying. I walked through [1] with the
following setup:
git init foo
cd foo
touch a.txt b.txt
git add a.txt b.txt
git commit -m "Initial checkin"
echo "Modify A" >> a.txt
git commit -am "Modifie
On Tue, Apr 16, 2013 at 05:49:41PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > [1/2]: usage: allow pluggable die-recursion checks
> > [2/2]: run-command: use thread-aware die_is_recursing routine
>
> Lovely. This doesn't solve the analagous problem for grep,
> index-pack, pack-ob
Jeff King wrote:
> [1/2]: usage: allow pluggable die-recursion checks
> [2/2]: run-command: use thread-aware die_is_recursing routine
Lovely. This doesn't solve the analagous problem for grep,
index-pack, pack-objects, preload-index, or bidirectional_transfer_loop,
but it doesn't make them w
Am 16.04.2013 19:33, schrieb Ramkumar Ramachandra:
> Firstly, great work on the series! I've just started looking into it,
> so please don't take my comments too seriously: some of them may be
> queries, and others may be minor suggestions, but I can't say I
> understand the area you're patching.
Am 16.04.2013 19:48, schrieb Ramkumar Ramachandra:
> Karsten Blees wrote:
>> 'git-status --ignored' lists ignored tracked directories without any
>> ignored files if a tracked file happens to match an exclude pattern.
>
> Here, I have:
>
> quux/
> bar
> baz/
> foo
On Tue, Apr 16, 2013 at 04:22:25PM -0700, Junio C Hamano wrote:
> +static void parse_expire_value(const char *value, unsigned long *expire)
> +{
> + if (!strcmp(value, "never") || !strcmp(value, "false"))
> + *expire = 0;
> + else if (!strcmp(value, "all") || !strcmp(value, "no
Quick incremental report on tonight's integration status.
> * jk/http-error-messages (2013-04-06) 9 commits
> (merged to 'next' on 2013-04-11 at 7a03981)
> ...
> + http: add HTTP_KEEP_ERROR option
>
> Improve error reporting from the http transfer clients.
Peff posted an update to this to fi
On Tue, Apr 16, 2013 at 5:34 PM, Phil Hord wrote:
> On Tue, Apr 16, 2013 at 3:48 PM, Felipe Contreras
> wrote:
>> Here it goes. The remote helper ref is going to be used to tell
>> fast-export which refs to negate (e.g. ^refs/testgit/origin/master),
>> so that extra commits are not generated, whi
Michael Haggerty writes:
> would be that it expires *everything*. But in fact it seems to only
> expire things that are at least one second old, which doesn't seem at
> all useful in the real world. "--expire=all" is accepted without
> complaint but doesn't do what one would hope.
Perhaps that
On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
wrote:
> On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:
>> A cursory look^W^Wreview of the messages in fc/remote-hg:
>
> [skipping irrelevant comments]
>
> I'm sorry, did you actually hit an issue that required to look at the
> commit message
On Tue, Apr 16, 2013 at 3:48 PM, Felipe Contreras
wrote:
> Here it goes. The remote helper ref is going to be used to tell
> fast-export which refs to negate (e.g. ^refs/testgit/origin/master),
> so that extra commits are not generated, which the remote helper
> should ignore anyway, because it sh
"Philip Oakley" writes:
>> int cmd_version(int argc, const char **argv, const char *prefix)
>> {
>> + /*
>> + * The format of this string should be kept stable for compatibility
>> + * with external projects that rely on the output of "git version".
>
> Shouldn't the expected format of our known
Drew Northup wrote:
> This is unobtrusive yet to the point.
I agree with the spirit.
[...]
> --- a/Documentation/gitweb.conf.txt
> +++ b/Documentation/gitweb.conf.txt
> @@ -55,7 +55,8 @@ following order:
> then fallback system-wide configuration file (defaults to
René Scharfe writes:
> How about making split_ident_line() a bit friendlier be letting it
> provide the epoch as default time stamp instead of NULL?
Two knee-jerk concerns I have without going back to the callers:
* Would that "0" ever be given to the approxidate parser, which
rejects anc
Jeff King writes:
> diff --git a/run-command.c b/run-command.c
> index 765c2ce..1b32a12 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -588,6 +588,7 @@ static pthread_key_t async_key;
> static pthread_t main_thread;
> static int main_thread_set;
> static pthread_key_t async_key;
> +st
On 04/16/2013 07:55 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> On 04/15/2013 07:38 PM, Junio C Hamano wrote:
>>> Michael Haggerty writes:
>>>
if (read_ref_full(refname, base, 1, &flag))
return -1;
- if ((flag & REF_ISPACKED)) {
+ /*
From: "David Aguilar"
Sent: Tuesday, April 16, 2013 9:33 PM
External projects have been known to parse the output of
"git version". Help prevent future authors from changing
its format by adding a comment to its implementation.
Signed-off-by: David Aguilar
---
help.c | 4
1 file changed,
Nguyễn Thái Ngọc Duy writes:
> case 'h': /* abbreviated commit hash */
> + strbuf_addstr(sb, diff_get_color(c->auto_color_next,
> DIFF_COMMIT));
> if (add_again(sb, &c->abbrev_commit_hash))
> return 1;
Doesn't this early retur
On Tue, Apr 16, 2013 at 12:45:03PM -0700, Junio C Hamano wrote:
> René Scharfe writes:
>
> > Does this patch help?
> >
> > pretty.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/pretty.c b/pretty.c
> > index d3a82d2..713eefc 100644
> > --- a/pretty.c
Nguyễn Thái Ngọc Duy writes:
> This is not simply convenient over %C(auto,xxx). Some placeholders
> (actually only one, %d) do multi coloring and we can't emit a multiple
> colors with %C(auto,xxx).
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/pretty-formats.txt | 3 ++-
> pr
On Tue, Apr 16, 2013 at 1:11 PM, Ramkumar Ramachandra
wrote:
> Brandon Casey wrote:
>> # Save another stash here
>>
>> echo bash >file
>> git add file
>> git stash save "something"
>>
>> # Now git stash show stash^{/quuxery} no longer wor
On Tue, Apr 16, 2013 at 9:45 PM, Junio C Hamano wrote:
> It still is curious how a malformed line was created in the first
> place. I wouldn't worry if a private tool used hash-object to
> create such a commit, but if it is something that is commonly used
> (e.g. "git commit"), others may suffer
From: "Junio C Hamano"
Sent: Tuesday, April 16, 2013 7:12 PM
"Philip Oakley" writes:
What kind of benefit are you envisioning out of this?
The purpose of tests is to detect mistakes and spot regressions.
A change to the 'git version X.Y.z' string would be a regression, as
I
spotted earli
First, lest I forget again: Thank you, Ivan, for the very useful
bug report!
Am 16.04.2013 21:45, schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Does this patch help?
>>
>> pretty.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/pretty.c b/pretty.c
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> I do not think anybody considered the approach to look at the commit
>> object name and making sure it appears in the reflog that implements
>> the stash. It sounds like a more robust check if done right.
>
> Actually, if you think about it,
Phil Hord wrote:
> If I follow the latter advice about 'rm -rf', who will remember that
> 'rebase' had something stashed, and what will they do with it when
> they do?
>
> What if it is weeks or months later? I would be surprised to see
> long-forgotten wip show up in my workspace all of a sudden.
Currently a "submodule deinit" run on a non-populated submodule will still
print the "Cleared directory" message even though the directory is already
empty. While that is technically correct (as the directory is removed and
created again), it is rather surprising to see this message for an empty
su
David Aguilar writes:
> External projects have been known to parse the output of
> "git version". Help prevent future authors from changing
> its format by adding a comment to its implementation.
>
> Signed-off-by: David Aguilar
> ---
> help.c | 4
> 1 file changed, 4 insertions(+)
>
> di
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> +delete_trailing_dollar() {
>> +sed 's/\$$//'
>> +}
>
> This is what we have qz_to_tab_space for, isn't it? With it, you
> can not just avoid "trailing whitespace", but also "indent with
> spaces", like this:
>
> Q message
Junio C Hamano wrote:
> Who said anything about a customer?
>
> A newcomer to a community (i.e. Matthieu's student) needs not just
> to show technical excellence with patches, but needs to make a good
> argument on a larger design decision; old timers already tried to
> achieve a concensus on it, a
Nguyễn Thái Ngọc Duy writes:
> +delete_trailing_dollar() {
> + sed 's/\$$//'
> +}
This is what we have qz_to_tab_space for, isn't it? With it, you
can not just avoid "trailing whitespace", but also "indent with
spaces", like this:
Q message thousandZ
--
To unsubscribe from th
External projects have been known to parse the output of
"git version". Help prevent future authors from changing
its format by adding a comment to its implementation.
Signed-off-by: David Aguilar
---
help.c | 4
1 file changed, 4 insertions(+)
diff --git a/help.c b/help.c
index 1dfa0b0..
Junio C Hamano wrote:
> I do not think anybody considered the approach to look at the commit
> object name and making sure it appears in the reflog that implements
> the stash. It sounds like a more robust check if done right.
Actually, if you think about it, there is really only one way to
specif
Brandon Casey wrote:
> # Save another stash here
>
> echo bash >file
> git add file
> git stash save "something"
>
> # Now git stash show stash^{/quuxery} no longer works.
Ah, yes. My stupidity. Why was I expecting ^{/quuxery} to dig
th
Junio C Hamano wrote:
> Brandon Casey writes:
>> Just a bit of advice, maybe you should think about softening your tone
>> a bit hmm? I find this last sentence to be somewhat repelling and
>> tend to refrain from responding to such.
>
> Oh, so it wasn't just me. I was about to say something simil
On Tue, Apr 16, 2013 at 12:11 PM, Junio C Hamano wrote:
> Brandon Casey writes:
>
>> The stash is implemented using the reflog. The ^{/} notation
>> searches the commit history, not the reflog. So I think it will be
>> able to match the first entry in your stash stack, but not any of the
>> oth
If we die from an async thread, we do not actually exit the
program, but just kill the thread. This confuses the static
counter in usage.c's default die_is_recursing function; it
updates the counter once for the thread death, and then when
the main program calls die() itself, it erroneously thinks
On Tue, Apr 16, 2013 at 2:19 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Sure, and where is the thinking not clear? The remote helper ref is
>> not updated, so we do update it. How is that not clear?
>
> Sure, between "leaving it untouched, keeping the stale value" and
> "updating i
When any git code calls die or die_errno, we use a counter
to detect recursion into the die functions from any of the
helper functions. However, such a simple counter is not good
enough for threaded programs, which may call die from a
sub-thread, killing only the sub-thread (but incrementing
the co
René Scharfe writes:
> Does this patch help?
>
> pretty.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/pretty.c b/pretty.c
> index d3a82d2..713eefc 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -405,8 +405,8 @@ void pp_user_info(const struct pretty_print_co
On Tue, Apr 16, 2013 at 04:13:56PM +0200, Johannes Sixt wrote:
> > I'm not clear on what you are suggesting. That we protect only the main
> > thread from recursion, or that we drop the check entirely? Or that we
> > implement thread-local storage for this case without using pthread_once?
>
> Any
Felipe Contreras writes:
> Sure, and where is the thinking not clear? The remote helper ref is
> not updated, so we do update it. How is that not clear?
Sure, between "leaving it untouched, keeping the stale value" and
"updating it to match what was pushed", everybody would know you
mean the lat
Junio C Hamano wrote:
> It is a tough topic for a newcomer developer to tackle.
Agreed. We should give these students tasks that are relatively
straightforward, and not controversial.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
Brandon Casey writes:
> The stash is implemented using the reflog. The ^{/} notation
> searches the commit history, not the reflog. So I think it will be
> able to match the first entry in your stash stack, but not any of the
> other ones.
Good point, together with...
> An extension to the re
On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:
> Felipe Contreras writes:
>
>> Clearly, that's the correct behavior. Why would anybody send a change
>> that does something other than the correct behavior?
>
> Along the same lines, why would anyone write broken code? Nobody does,
> right?
Y
David Aguilar writes:
> The "regression" is that there are scripts and tools in the wild that
> need to know the git version when deciding whether or not to use some
> new feature.
>
> e.g. "git status --ignore-submodules=dirty" did not appear until git 1.7.2.
> A script may want to use this flag
On Tue, Apr 16, 2013 at 11:09 AM, Ramkumar Ramachandra
wrote:
> While a 'git stash show stash^{/quuxery}' works just fine, a 'git
> stash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a
> stash reference'.
I don't think it is appropriate to use the ^{/} notation with stashes.
Th
Ramkumar Ramachandra writes:
> While a 'git stash show stash^{/quuxery}' works just fine, a 'git
> stash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a
> stash reference'. This confusing behavior arises from the differences
> in logic that 'show' and 'pop' internally employ to
Johannes Sixt writes:
>> I agree. I don't think we need it in maint; we don't track that branch
>> for msysGit.
>
> Yes, master is good enough.
Thanks to all those involved. Applied.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ker
On Tue, Apr 16, 2013 at 11:12 AM, Junio C Hamano wrote:
>
> "Philip Oakley" writes:
>
> >> What kind of benefit are you envisioning out of this?
> >
> > The purpose of tests is to detect mistakes and spot regressions.
> >
> > A change to the 'git version X.Y.z' string would be a regression, as I
nobody writes:
> Hello Junio,
> Hello list,
>
> On Wed, Mar 06, 2013 at 09:19:42AM +0100, Michael Weiser wrote:
>
>> > >> Support determining the binaries' installation path at runtime even if
>> > >> called without any path components (i.e. via search path).
>> > The default for any change is not
Thomas Rast writes:
> read_revisions_from_stdin() has passed pointers to its read buffer
> down to handle_revision_arg() since its inception way back in 42cabc3
> (Teach rev-list an option to read revs from the standard input.,
> 2006-09-05). Even back then, this was a bug: through
> add_pending
Ramkumar Ramachandra writes:
> Matthieu Moy wrote:
>> I tend to agree with you, but the idea has explicitly been rejected in
>> the past. The problem with an option like this is that it would also
>> disable the advices that may be added in the future. By letting people
>> disable the advices one
"Philip Oakley" writes:
>> What kind of benefit are you envisioning out of this?
>
> The purpose of tests is to detect mistakes and spot regressions.
>
> A change to the 'git version X.Y.z' string would be a regression, as I
> spotted earlier, as it conflicts with expectations of standard
> progr
While a 'git stash show stash^{/quuxery}' works just fine, a 'git
stash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a
stash reference'. This confusing behavior arises from the differences
in logic that 'show' and 'pop' internally employ to validate the
specified ref. Document t
Am 16.04.2013 18:55, schrieb Ivan Lyapunov:
> git version 1.8.2.1 crashes on my ArchLinux x86_64 on git log command
> gdb bt is attached
>
> git log | less
> does not crash in same repo
>
> I cannot share a repo for a debug purposes since it's private repo of
> my employer
> but I can perform any
Michael Haggerty writes:
> In projects where I can choose the coding standard, I like to use extra
> whitespace to help the eye pick out the range of parentheses, like
>
> if (!(
> (flags & DO_FOR_EACH_INCLUDE_BROKEN) ||
> ref_resolves_to_object(entry)
>
While a 'git stash show stash^{/quuxery}' works just fine, a 'git
stash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a
stash reference'. This confusing behavior arises from the differences
in logic that 'show' and 'pop' internally employ to validate the
specified ref. Document t
Am 16.04.2013 16:39, schrieb Erik Faye-Lund:
> On Mon, Apr 15, 2013 at 11:43 PM, Junio C Hamano wrote:
>> Erik Faye-Lund writes:
>>
>>> This is absolutely the right thing to do. However, stuff have changed
>>> a bit since the patch was written; this change now needs to go in
>>> config.mak.uname
Michael Haggerty writes:
> On 04/15/2013 07:38 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> if (read_ref_full(refname, base, 1, &flag))
>>> return -1;
>>>
>>> - if ((flag & REF_ISPACKED)) {
>>> + /*
>>> +* If the reference is packed, read its ref_entry
Karsten Blees wrote:
> 'git-status --ignored' lists ignored tracked directories without any
> ignored files if a tracked file happens to match an exclude pattern.
Here, I have:
quux/
bar
baz/
foo
So, quux is an ignored tracked directory. bar is tracked, but match
Michael Haggerty writes:
>>> ... This scenario doesn't currently occur in the code,
>>> but fix it to prevent things from breaking in a very confusing way in
>>> the future.
>>
>> Hopefully that means "in later patches in this series" ;-)
>
> I don't think that the rest of the series would have
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> If it is 0 (which means that the rebase completely successfully), pop
>> the stash before exiting as usual.
>
> And you're going to pop the stash even if no stash were triggered when
> starting the rebase.
>
> Really, think about it again:
Firstly, great work on the series! I've just started looking into it,
so please don't take my comments too seriously: some of them may be
queries, and others may be minor suggestions, but I can't say I
understand the area you're patching. I know Junio doesn't like me
mixing queries in reviews, but
Hey
> #0 0x7722b3e6 in strtoull_l_internal () from /usr/lib/libc.so.6
> #1 0x004b31d4 in pp_user_info (pp=pp@entry=0x7fffd310,
> what=what@entry=0x521379 "Author", sb=sb@entry=0x7fffd290,
>line=line@entry=0x7b3a45 "Ivan Lyapunov -
> <> 1354083115 +0400\ncommitter
Ramkumar Ramachandra writes:
> My solution fixes all these problems, and we need
> .git/modules/.git (no path-to-submodule nonsense) only as a last
> resort: #3 (ref: my email to Peff).
Have you noticed that there are distinction between submodule path
and submodule name already in the current s
Jeff King writes:
> The solution is simple: now that FAILONERROR is a
> per-request setting, we move it to get_active_slot to make
> sure it is reset for each request.
>
> Signed-off-by: Jeff King
> ---
> Hmph. I have no idea how this ever passed the tests, so I can only
> assume that I screwed
On Tue, Apr 16, 2013 at 5:20 AM, Ramkumar Ramachandra
wrote:
> Matthieu Moy wrote:
> No. Ultimately, the entry point of all these invocations is
> git-rebase.sh. The plan is to refactor calls from git-rebase.sh to
> git-rebase--*.sh scripts so that those scripts return control to
> git-rebase.sh
On 13-04-16 04:21 AM, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> It does not relieve "git add" (or "git submodulea add") from the
>> responsibility of moving .git directory. It only reduces the need
>> to do so.
>>
>> When the user says "add" and the repository has .git directory in
>>
On 13-04-16 04:17 AM, Ramkumar Ramachandra wrote:
> Marc Branchaud wrote:
>> If "git add" is all about specifying what lives under paths in the worktree,
>> what's wrong with letting "git add" go beyond specifying just files?
>>
>> Syntax aside for the moment, I think a command like
>> git
On 13-04-16 04:13 AM, Ramkumar Ramachandra wrote:
> Jeff King wrote:
>> So there is some information that is per-clone (the objects, the remote
>> tips), but there is some information that is per-submodule (where our
>> local branches are, the index, the worktree). I can see why it is
>> advantageo
On Wed, Mar 6, 2013 at 9:19 AM, Michael Weiser
wrote:
> Hello Junio,
>
> On Tue, Mar 05, 2013 at 08:13:50AM -0800, Junio C Hamano wrote:
>
>> >> Support determining the binaries' installation path at runtime even if
>> >> called without any path components (i.e. via search path).
>
>> The default
Hello Junio,
Hello list,
On Wed, Mar 06, 2013 at 09:19:42AM +0100, Michael Weiser wrote:
> > >> Support determining the binaries' installation path at runtime even if
> > >> called without any path components (i.e. via search path).
> > The default for any change is not to include it. Is there a
The short version:
all applied, compiled and test OK.
Possible minor nits from apply:
applying: pretty: support padding placeholders, %< %> and %><
/Users/tb/projects/git/tb.duy/.git/rebase-apply/patch:253: indent with spaces.
message two$
/Users/tb/projects/git/tb.duy
On Mon, Apr 15, 2013 at 11:43 PM, Junio C Hamano wrote:
> Erik Faye-Lund writes:
>
>> This is absolutely the right thing to do. However, stuff have changed
>> a bit since the patch was written; this change now needs to go in
>> config.mak.uname instead of config.mak.
>
> Thanks for a quick respon
On 04/15/2013 09:12 PM, Junio C Hamano wrote:
> The paths given to handle_refs() may also have to be copied before
> saved, depending on how ref iteration is implemented, details of
> which may change as Michael seems to be updating the area again.
> I think we let the callback peek ref_entry->name
On 04/15/2013 07:39 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> How can I get rid of the sleeps in these tests?
>
> Would test-chmtime help?
Maybe I should take a step back and ask why it isn't easier to expire
things regardless of age, which is sometimes a reasonable thing to do
eve
Am 4/16/2013 15:01, schrieb Jeff King:
> On Tue, Apr 16, 2013 at 09:18:46AM +0200, Johannes Sixt wrote:
>
>>> Yeah, that seems sane; my biggest worry was that it would create
>>> headaches for Windows folks, who would have to emulate pthread_key. But
>>> it seems like we already added support in 9
On Mon, Apr 1, 2013 at 3:02 PM, Jens Lehmann wrote:
> Okay, so here is the patch for that. If someone could point out
> a portable and efficient way to check if a directory is already
> empty I would be happy to use that to silence the "Cleaned
> directory" message currently printed also when dein
On 04/15/2013 07:38 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> [...] But more
>> importantly, this change prevents peel_ref() from returning invalid
>> results in the following scenario:
>>
>> When iterating via the external API, the iteration always includes
>> both packed and loose
On 04/15/2013 07:38 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> if (read_ref_full(refname, base, 1, &flag))
>> return -1;
>>
>> -if ((flag & REF_ISPACKED)) {
>> +/*
>> + * If the reference is packed, read its ref_entry from the
>> + * cache in the
On Tue, Apr 16, 2013 at 09:18:46AM +0200, Johannes Sixt wrote:
> > Yeah, that seems sane; my biggest worry was that it would create
> > headaches for Windows folks, who would have to emulate pthread_key. But
> > it seems like we already added support in 9ba604a.
>
> pthread_key is not a problem,
1 - 100 of 142 matches
Mail list logo
