2013/1/16 Junio C Hamano :
>>> diff --git a/git-submodule.sh b/git-submodule.sh
>>> index 22ec5b6..1b8d95f 100755
>>> --- a/git-submodule.sh
>>> +++ b/git-submodule.sh
>>> @@ -975,13 +975,19 @@ cmd_summary() {
>>> echo
>>> done |
>>> if test -n "$for_status"; then
>>> +
On 01/15/2013 09:32 PM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
>> -else if ((arg1 = next_arg(&cmd))) {
>> -if (!strcmp("EXISTS", arg1))
>> -ctx->gen.count = atoi(arg);
>> -el
On 01/15/2013 07:51 PM, Matt Kraai wrote:
> On Tue, Jan 15, 2013 at 09:06:25AM +0100, Michael Haggerty wrote:
>> -static struct imap_list *parse_imap_list(struct imap *imap, char **sp)
>> +static struct imap_list *parse_list(char **sp)
>
> The commit subject refers to imap_parse_list and imap_list
Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
> Michael J Gruber writes:
>
>> Also there is a conceptual confusion: pushurl is meant to push to the
>> same repo using a different url, e.g. something authenticated
>> (https/ssh) for push and something faster/easier for fetch.
>
> That is n
On Tue, Jan 15, 2013 at 07:03:16PM -0500, Pete Wyckoff wrote:
> j...@keeping.me.uk wrote on Tue, 15 Jan 2013 22:40 +:
>> This is what keeping the refs as byte strings looks like.
>
> As John knows, it is not possible to interpret text from a byte
> string without talking about the character en
The current output of "git remote -v" does not distinguish between
explicitly configured push URLs and those coming from fetch lines.
Revise the output so so that URLs are distinguished by their labels:
(fetch): fetch config used for fetching only
(fetch/push): fetch config used for fetching and
These variables are user parameters to control how to run the perf
tests. Allow users to do so.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
PERF -> PERF_
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..bf4cf71 100644
--
Michael J Gruber venit, vidit, dixit 16.01.2013 11:14:
> The current output of "git remote -v" does not distinguish between
> explicitly configured push URLs and those coming from fetch lines.
>
> Revise the output so so that URLs are distinguished by their labels:
>
> (fetch): fetch config used
On Wed, Jan 16, 2013 at 1:53 AM, Chris Rorvick wrote:
> On Tue, Jan 15, 2013 at 5:10 PM, Ben Walton wrote:
>> Neither %s or %z are portable strftime format specifiers. There is no
>> need for %s in git-cvsimport as the supplied time is already in
>> seconds since the epoch. For %z, use the func
On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
> The current output of "git remote -v" does not distinguish between
> explicitly configured push URLs and those coming from fetch lines.
>
> Revise the output so so that URLs are distinguished by their labels:
>
> (fetch): fetch c
On Wed, Jan 16, 2013 at 2:37 AM, Junio C Hamano wrote:
> Adam Spiers writes:
>
>> On Mon, Jan 14, 2013 at 10:23 PM, Junio C Hamano wrote:
>>> * as/check-ignore (2013-01-10) 12 commits
>>> (merged to 'next' on 2013-01-14 at 9df2afc)
>>> + t0008: avoid brace expansion
>>> + add git-check-ignor
Jan Engelhardt wrote:
On Tuesday 2012-10-02 10:26, Johannes Sixt wrote:
Note that git commit -m A --allow-empty *DID* create a commit. Only,
that it received the same name (SHA1) as the commit you created
before it because it had the exact same contents (files, parents,
author, committer, and t
John Keeping venit, vidit, dixit 16.01.2013 11:42:
> On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
>> The current output of "git remote -v" does not distinguish between
>> explicitly configured push URLs and those coming from fetch lines.
>>
>> Revise the output so so that URLs
On Wed, Jan 16, 2013 at 01:45:36PM +0100, Michael J Gruber wrote:
> John Keeping venit, vidit, dixit 16.01.2013 11:42:
>> On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
>>> The current output of "git remote -v" does not distinguish between
>>> explicitly configured push URLs and
A short string is appended after the path name in diffstat:
- "(new)" for new 0644 files
- "(new +x)" for new 0755 files
- "(new +l)" for new symlinks
- "(gone)"for deleted files
- "(mode +x)" for files gaining executable permission
- "(mode -x)" for files losing executable permission
T
Consumers of the dir.c traversal API should avoid assuming knowledge
of the internal implementation of exclude_list_groups. Therefore
when adding items to an exclude list, it should be accessed via the
pointer returned from add_exclude_list(), rather than by referencing
a location within dir.exclu
Hi there,
I was just working on improving git-remote-helper.txt by documenting how remote
helper can signal error conditions to git. This lead me to notice a (to me)
surprising change in behavior between master and next that I traced back to
this patch series.
Specifically:
On 30.11.2012, at
Signed-off-by: Max Horn
---
cache.h | 2 +-
git-compat-util.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index c257953..5c8440b 100644
--- a/cache.h
+++ b/cache.h
@@ -1148,7 +1148,7 @@ extern int check_repository_format_version(const char
On Tue, Jan 15, 2013 at 10:26:06PM -0500, Theodore Ts'o wrote:
> On Tue, Jan 15, 2013 at 06:26:06PM -0800, Jonathan Nieder wrote:
> > Hi Jeff and other guilty parties,
> >
> > I collected all the guilt patches I could find on-list and added one
> > of my own. Completely untested, except for runni
Michael Haggerty writes:
> On 01/15/2013 07:51 PM, Matt Kraai wrote:
>> On Tue, Jan 15, 2013 at 09:06:25AM +0100, Michael Haggerty wrote:
>>> -static struct imap_list *parse_imap_list(struct imap *imap, char **sp)
>>> +static struct imap_list *parse_list(char **sp)
>>
>> The commit subject refer
Ben Walton writes:
> +sub get_tz_offset {
> + # some systmes don't handle or mishandle %z, so be creative.
Hmph. I wonder if we can use %z if it is handled correctly and fall
back to this code only on platforms that are broken?
--
To unsubscribe from this list: send the line "unsubscribe gi
gree...@obbligato.org writes:
> Are you incorporating the other patches? Should I drop them
> from my list?
I actually was planning to accept patches to this subdirectory only
through you, hopefully as messages that forward others' changes with
your Acked-by: tagline. That frees me from having
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
> ...
>> * When there are more than one URLs, and there is no pushURL, then
>>show the first URL as (fetch/push), and the remainder in a
>>notation that says it is used only for push, but it shouldn't be
>>
On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano wrote:
> Michael J Gruber writes:
>
>> That being said, I don't mind changing the behaviour of set-url.
>
> I do not think we want to change the behaviour of set-url.
I agree with Michael that changing the set-url behavior would be
appropriate her
Junio C Hamano venit, vidit, dixit 16.01.2013 16:50:
> Michael J Gruber writes:
>
>> Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
>> ...
>>> * When there are more than one URLs, and there is no pushURL, then
>>>show the first URL as (fetch/push), and the remainder in a
>>>notatio
Phil Hord venit, vidit, dixit 16.01.2013 17:15:
> On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano wrote:
>> Michael J Gruber writes:
>>
>>> That being said, I don't mind changing the behaviour of set-url.
>>
>> I do not think we want to change the behaviour of set-url.
>
> I agree with Michael
Max Horn writes:
> But with next, I get this:
>
>
> ! [rejected]master -> master (already exists)
> error: failed to push some refs to '/Users/mhorn/Proje...o_orig'
> hint: Updates were rejected because the destination reference already exists
> hint: in the remote.
>
> This looks like a
On Wed, Jan 16, 2013 at 03:53:23PM +0100, Max Horn wrote:
> -#ifdef __GNUC__
> +#if defined(__GNUC__) && ! defined(__clang__)
> #define config_error_nonbool(s) (config_error_nonbool(s), -1)
> #endif
You don't say what the warning is, but I'm guessing it's complaining
about throwing away the ret
Junio C Hamano writes:
> Max Horn writes:
>
>> But with next, I get this:
>>
>> ! [rejected]master -> master (already exists)
>> error: failed to push some refs to '/Users/mhorn/Proje...o_orig'
>> hint: Updates were rejected because the destination reference already exists
>> hint: in t
Jeff King writes:
> On Wed, Jan 16, 2013 at 03:53:23PM +0100, Max Horn wrote:
>
>> -#ifdef __GNUC__
>> +#if defined(__GNUC__) && ! defined(__clang__)
>> #define config_error_nonbool(s) (config_error_nonbool(s), -1)
>> #endif
>
> You don't say what the warning is, but I'm guessing it's complaini
On Wed, Jan 16, 2013 at 02:32:03PM +0100, Max Horn wrote:
> With git 1.8.1, I get this message:
>
> ! [rejected]master -> master (non-fast-forward)
> [...]
> But with next, I get this:
>
> ! [rejected]master -> master (already exists)
Thanks for the detailed report. I was able
Max Horn writes:
> But with next, I get this:
>
> ! [rejected]master -> master (already exists)
> error: failed to push some refs to
> '/Users/mhorn/Projekte/foreign/gitifyhg/bugs/git-push-conflict/repo_orig'
> hint: Updates were rejected because the destination reference already exists
Jeff King writes:
> I.e., we trigger the "!o" branch after the parse_object in your example.
Heh, I didn't see this message until now (gmane seems to be lagging
a bit).
I am very tempted to do this.
* Remove unnecessary not_forwardable from "struct ref"; it is only
used inside set_ref_stat
FWIW, I also happen to have the warning:
advice.c:69:2: warning: expression result unused [-Wunused-value]
error("'%s' is not possible because you have unmerged files.", me);
^~
./git-compat-util.h:314:55: note: expand
On Wed, Jan 16, 2013 at 06:12:57PM +0100, Antoine Pelisse wrote:
> FWIW, I also happen to have the warning:
>
> advice.c:69:2: warning: expression result unused [-Wunused-value]
> error("'%s' is not possible because you have unmerged files.", me);
> ^~~~
On 16.01.2013, at 18:18, John Keeping wrote:
> On Wed, Jan 16, 2013 at 06:12:57PM +0100, Antoine Pelisse wrote:
>> FWIW, I also happen to have the warning:
>>
>> advice.c:69:2: warning: expression result unused [-Wunused-value]
>>error("'%s' is not possible because you have unmerged file
Andy, do you have any thoughts on adding this email header to
contrib/hooks/post-receive-email? This patch shouldn't cause problems for anyone
with a sanely configured mail delivery agent, and the additional header is very
useful in toggling auto responses.
This conforms to RFC3834 and is useful
Will replace the one in 'pu' with this round. Looking good.
Thanks.
--
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
On Wed, Jan 16, 2013 at 09:10:10AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I.e., we trigger the "!o" branch after the parse_object in your example.
>
> Heh, I didn't see this message until now (gmane seems to be lagging
> a bit).
I think it is vger lagging, actually.
> I am ver
Adam Spiers writes:
> Consumers of the dir.c traversal API should avoid assuming knowledge
> of the internal implementation of exclude_list_groups. Therefore
> when adding items to an exclude list, it should be accessed via the
> pointer returned from add_exclude_list(), rather than by referenci
Hello,
We're just in the process of investigating a versioning tool and are very
interesting in git. We have one question we're hoping someone can answer. In
regards to the repositories, I think I understand correctly that each developer
will have a local repository that they will work from, an
On Wed, Jan 16, 2013 at 06:26:35PM +0100, Max Horn wrote:
> > On Wed, Jan 16, 2013 at 06:12:57PM +0100, Antoine Pelisse wrote:
> >> FWIW, I also happen to have the warning:
> >>
> >> advice.c:69:2: warning: expression result unused [-Wunused-value]
> >>error("'%s' is not possible because
On Wed, Jan 16, 2013 at 09:50:57AM -0800, Jeff King wrote:
> I'm confused, though, why your patch does not have a matching update to
> the opterror macro in parse-options.h. It uses exactly the same
> technique. Does it not generate a warning?
Ah, I think I see why not.
It is not about the macro
---
Sorry, I forgot the documentation updates. I hope this looks ok. Can
you squash this in, Junio? Thanks.
I don't think any documentation update is necessary for the "reset on
unborn branch" patch. Let me know if you think differently.
Documentation/git-reset.txt | 18 +-
bui
On Wed, 16 Jan 2013 09:50:57 -0800, Jeff King wrote:
> However, clang also defines __GNUC__, [...]
http://sourceforge.net/p/predef/wiki/Compilers/
Notice that the meaning of the __GNUC__ macro has changed subtly over the
years, from identifying the GNU C/C++ compiler to identifying any
On Wed, 16 Jan 2013 17:49:09 +
"Lang, David" wrote:
> We're just in the process of investigating a versioning tool and are
> very interesting in git. We have one question we're hoping someone
> can answer. In regards to the repositories, I think I understand
> correctly that each developer wi
On Wed, Jan 16, 2013 at 10:00 AM, Martin von Zweigbergk
wrote:
> ---
>
> Sorry, I forgot the documentation updates. I hope this looks ok. Can
> you squash this in, Junio? Thanks.
I see the series just entered 'next', so I guess it would have to go
on top then. Perhaps with a commit message like a
On Wed, Jan 16, 2013 at 10:00:42AM -0800, Jeff King wrote:
> So opterror does not happen to generate any warnings, because we do not
> ever use it in a void context. It should probably be marked the same
> way, though, as future-proofing.
> [...]
> So a more accurate description would be:
Here it
On Wed, Jan 16, 2013 at 10:00:42AM -0800, Jeff King wrote:
> It is not about the macro itself, but rather the callsites that do not
> return error, but call it for its printing side effect. It seems that
> clang -Wunused-value is OK with unused values from functions being
> discarded, but not with
Jeff King writes:
> It seems a little weird to me that clang defines __GNUC__, but I
> assume there are good reasons for it.
The reason is essentially that clang targets compatibility with GCC
(implementing the same extensions & cie), in the sense "drop in
replacement that should be able to comp
On Wed, Jan 16, 2013 at 06:12:03PM +, John Keeping wrote:
> On Wed, Jan 16, 2013 at 10:00:42AM -0800, Jeff King wrote:
> > It is not about the macro itself, but rather the callsites that do not
> > return error, but call it for its printing side effect. It seems that
> > clang -Wunused-value i
> Is it worth applying this at all, then? Or should we apply it but limit
> it with a clang version macro (they mention r163034, but I do not know
> if it is in a released version yet, nor what macros are available to
> inspect the version)?
Please also note that building with clang is not warning
On Wed, Jan 16, 2013 at 10:06:15PM +0400, Konstantin Khomoutov wrote:
> > In regards to the repositories, I think I understand correctly that
> > each developer will have a local repository that they will work
> > from, and that there will also be a remote repository (origin) that
> > will hold th
On Wed, Jan 16, 2013 at 10:15:58AM -0800, Jeff King wrote:
> On Wed, Jan 16, 2013 at 06:12:03PM +, John Keeping wrote:
>
> > On Wed, Jan 16, 2013 at 10:00:42AM -0800, Jeff King wrote:
> > > It is not about the macro itself, but rather the callsites that do not
> > > return error, but call it f
On Wed, Jan 16, 2013 at 06:22:40PM +, John Keeping wrote:
> > > [1] http://llvm.org/bugs/show_bug.cgi?id=13747
> >
> > Yeah, I think it is exactly the same issue, and the fix they mention
> > there would apply to us, too.
> >
> > Is it worth applying this at all, then? Or should we apply it
Am 16.01.2013 06:45, schrieb 乙酸鋰:
> With git pull or git fetch without specifying --recurse-submodules,
> what is the default action?
on-demand fetch (unless something else is configured).
> It seems git fetches submodules wtihout specifying --recurse-submodules.
> If this is not clear, please up
Nguyễn Thái Ngọc Duy wrote:
> These variables are user parameters to control how to run the perf
> tests. Allow users to do so.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
FWIW, of the three versions proposed, this one makes the most sense to
me. Looks good.
--
To unsubscribe from this list: send t
On Wed, Jan 16, 2013 at 10:24:49AM -0800, Jeff King wrote:
> On Wed, Jan 16, 2013 at 06:22:40PM +, John Keeping wrote:
>
> > > > [1] http://llvm.org/bugs/show_bug.cgi?id=13747
> > >
> > > Yeah, I think it is exactly the same issue, and the fix they mention
> > > there would apply to us, too.
Duy Nguyen writes:
> OK I get your point now. Something like this?
>
> -- 8< --
> Subject: [PATCH] attr: avoid calling find_basename() twice per path
>
> find_basename() is only used inside collect_all_attrs(), called once
> in prepare_attr_stack, then again after prepare_attr_stack()
> returns.
From: Junio C Hamano
Some users do want to write a line that begin with a pound sign, #,
in their commit log message. Many tracking system recognise
a token of # form, for example.
The support we offer these use cases is not very friendly to the end
users. They have a choice between
- Don't
Michael J Gruber writes:
> In short, the separate listing is correct, but in this case there's no
> improvement in readability.
Yes, I think the "insteadOf" rewrite is a related but a separate
issue.
Is "remote -v" meant for diagnosing remote.origin.{url,pushurl} that
are misconfigured?
If not
Junio C Hamano writes:
> I actually think my earlier "it shouldn't be the same (push)" is not
> needed and probably is actively wrong. Just like you can tell
> between
>
> (only one .url) (both .url and .pushurl)
>
> origin there (fetch/push) origin there (f
On Wed, 16 Jan 2013 10:21:56 -0800
Jeff King wrote:
Thanks for elaborating on the "origin" -- I intended to write up on its
special status but got distracted and sent my message missing that
bit ;-)
[...]
> > > Ideally we'd prefer to simply create our remote repository on a
> > > drive of one of
Andreas Schwab writes:
> Junio C Hamano writes:
>
>> I actually think my earlier "it shouldn't be the same (push)" is not
>> needed and probably is actively wrong. Just like you can tell
>> between
>>
>> (only one .url) (both .url and .pushurl)
>>
>> origin there (fe
Hi David, now we are going to have some confusion here, two David Langs on the
list :-)
On Wed, 16 Jan 2013, Lang, David wrote:
We're just in the process of investigating a versioning tool and are very
interesting in git. We have one question we're hoping someone can answer. In
regards to the
Junio C Hamano wrote:
> Robin Rosenberg writes:
> That configurability is a slipperly slope to drag us into giving users
> more complexity that does not help them very much, I suspect.
>
> Earlier somebody mentioned "size and mtime is often enough", so I
> think a single option core.looseStatInf
On Wed, Jan 16, 2013 at 3:37 PM, Junio C Hamano wrote:
> Ben Walton writes:
>
>> +sub get_tz_offset {
>> + # some systmes don't handle or mishandle %z, so be creative.
>
> Hmph. I wonder if we can use %z if it is handled correctly and fall
> back to this code only on platforms that are broke
Ralf Thielow writes:
> From: Junio C Hamano
>
> Some users do want to write a line that begin with a pound sign, #,
> in their commit log message. Many tracking system recognise
> a token of # form, for example.
>
> The support we offer these use cases is not very friendly to the end
> users.
Ben Walton writes:
> On Wed, Jan 16, 2013 at 3:37 PM, Junio C Hamano wrote:
>> Ben Walton writes:
>>
>>> +sub get_tz_offset {
>>> + # some systmes don't handle or mishandle %z, so be creative.
>>
>> Hmph. I wonder if we can use %z if it is handled correctly and fall
>> back to this code on
Jeff King writes:
> I see what you are saying, but I think the ship has already sailed to
> some degree. We already implement the non-fast-forward check everywhere,
> and I cannot have a "refs/tested" hierarchy that pushes arbitrary
> commits without regard to their history. If I have such a hier
Am 16.01.2013 20:18, schrieb Ralf Thielow:
> From: Junio C Hamano
>
> Some users do want to write a line that begin with a pound sign, #,
> in their commit log message. Many tracking system recognise
> a token of # form, for example.
>
> The support we offer these use cases is not very friendly
"Konstantin Khomoutov" wrote in message
news:<20130116233744.7d0775eaec98ce154a9de...@domain007.com>...
> On Wed, 16 Jan 2013 10:21:56 -0800
> Jeff King wrote:
> >
> > I agree that performance is not ideal (although if you are on a fast
> > LAN, it probably would not matter much), but I do not
Junio C Hamano writes:
> Will replace the one in 'pu' with this round. Looking good.
>
> Thanks.
By the way, wouldn't we want some tests to protect this feature from
future breakages?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
Adam Spiers writes:
> Consumers of the dir.c traversal API should avoid assuming knowledge
> of the internal implementation of exclude_list_groups. Therefore
> when adding items to an exclude list, it should be accessed via the
> pointer returned from add_exclude_list(), rather than by referenci
clang incorrectly reports a constant conversion warning (implicit
truncation to bit field) when using the "flag &= ~FLAG" form, because
~FLAG needs to be truncated.
Convert this form to "flag = flag & ~FLAG" fixes the issue as
the right operand now fits into the bit field.
Signed-off-by: Antoine
Create a GREP_HEADER_FIELD_MIN so we can check that the field value is
sane and silent the clang warning.
Clang warning happens because the enum is unsigned (this is
implementation-defined, and there is no negative fields) and the check
is then tautological.
Signed-off-by: Antoine Pelisse
---
I
Ideally we'd prefer to simply create our remote repository on a
drive of one of our local network servers. Is this possible?
>>>
>>> Yes, this is possible, but it's not advised to keep such a
>>> "reference" repository on an exported networked drive for a number
>>> of reasons (both per
On Wed, 16 Jan 2013, Stephen Smith wrote:
Ideally we'd prefer to simply create our remote repository on a
drive of one of our local network servers. Is this possible?
Yes, this is possible, but it's not advised to keep such a
"reference" repository on an exported networked drive for a number
o
On Wed, Jan 16, 2013 at 11:47:22PM +0100, Antoine Pelisse wrote:
> clang incorrectly reports a constant conversion warning (implicit
> truncation to bit field) when using the "flag &= ~FLAG" form, because
> ~FLAG needs to be truncated.
>
> Convert this form to "flag = flag & ~FLAG" fixes the issue
On Thu, Jan 17, 2013 at 12:08 AM, John Keeping wrote:
> On Wed, Jan 16, 2013 at 11:47:22PM +0100, Antoine Pelisse wrote:
>> clang incorrectly reports a constant conversion warning (implicit
>> truncation to bit field) when using the "flag &= ~FLAG" form, because
>> ~FLAG needs to be truncated.
> W
> With these two patches and the patch from Max Horne,
I'm deeply sorry for this typo Max
--
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
So I guess we should drop this patch, it's probably not worth it,
especially if it's been fixed already by clang.
On Thu, Jan 17, 2013 at 12:09 AM, Antoine Pelisse wrote:
> On Thu, Jan 17, 2013 at 12:08 AM, John Keeping wrote:
>> On Wed, Jan 16, 2013 at 11:47:22PM +0100, Antoine Pelisse wrote:
>
"David Lang" wrote in message
news:...
> But if you try to have one filesystem, with multiple people running git on
> their
> machines against that shared filesystem, I would expect you to have all sorts
> of
> problems.
What leads you to think you will have problems?
Why would there be mor
Antoine Pelisse writes:
> clang incorrectly reports a constant conversion warning (implicit
> truncation to bit field) when using the "flag &= ~FLAG" form, because
> ~FLAG needs to be truncated.
>
> Convert this form to "flag = flag & ~FLAG" fixes the issue as
> the right operand now fits into th
Junio C Hamano writes:
> Antoine Pelisse writes:
>
>> clang incorrectly reports a constant conversion warning (implicit
>> truncation to bit field) when using the "flag &= ~FLAG" form, because
>> ~FLAG needs to be truncated.
>>
>> Convert this form to "flag = flag & ~FLAG" fixes the issue as
>>
On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote:
"David Lang" wrote in message
news:...
But if you try to have one filesystem, with multiple people running git on their
machines against that shared filesystem, I would expect you to have all sorts of
problems.
What leads you to think you wi
j...@keeping.me.uk wrote on Tue, 15 Jan 2013 22:58 +:
> For reference, putting the version check in setup.py looks like this:
>
> -- >8 --
>
> diff --git a/git_remote_helpers/setup.py b/git_remote_helpers/setup.py
> index 6de41de..2c21eb5 100644
> --- a/git_remote_helpers/setup.py
> +++ b/git
j...@keeping.me.uk wrote on Wed, 16 Jan 2013 09:45 +:
> On Tue, Jan 15, 2013 at 07:03:16PM -0500, Pete Wyckoff wrote:
> > I'd suggest for this Python conundrum using byte-string literals, e.g.:
> >
> > lines = check_output(args).strip().split(b'\n')
> > value, name = line.split(b'
Hi Chris,
Chris Hiestand wrote:
> Andy, do you have any thoughts on adding this email header to
> contrib/hooks/post-receive-email? This patch shouldn't cause problems for
> anyone
> with a sanely configured mail delivery agent, and the additional header is
> very
> useful in toggling auto resp
> From: David Lang [mailto:da...@lang.hm]
>
> On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote:
>
> > Linus seemed to think it should work:
> >
> > http://permalink.gmane.org/gmane.comp.version-control.git/122670
>
> In the link you point at, he says that you can have problems with some
> types
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
From: David Lang [mailto:da...@lang.hm]
On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote:
Linus seemed to think it should work:
http://permalink.gmane.org/gmane.comp.version-control.git/122670
In the link you point at, he says that you can
> From: David Lang [mailto:da...@lang.hm]
>
> Linus says that git does not have "proper locking", so think about it,
> what do
> you think will happen if person A does git add a/b; git commit and person
> B does
> git add c/d; git commit?
Sorry, I wasn't clear. My assumption is that a shared repo
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
From: David Lang [mailto:da...@lang.hm]
Linus says that git does not have "proper locking", so think about it,
what do
you think will happen if person A does git add a/b; git commit and person
B does
git add c/d; git commit?
Sorry, I wasn't cl
On Wed, Jan 16, 2013 at 11:43 AM, Jeff King wrote:
> I think that is a reasonable rule that could be applied across all parts
> of the namespace hierarchy. And it could be applied by the client,
> because all you need to know is whether ref->old_sha1 is reachable from
> ref->new_sha1.
is_forwarda
> From: David Lang [mailto:da...@lang.hm]
>
> On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
>
> > 1. a bare repository that is normally accessed only by "git push" and
> > "git pull" (or "git fetch"), the central repository model.
>
> pulling from it would not be a problem, I could see issue
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
From: David Lang [mailto:da...@lang.hm]
On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
1. a bare repository that is normally accessed only by "git push" and
"git pull" (or "git fetch"), the central repository model.
pulling from it would
On Wed, Jan 16, 2013 at 08:19:28PM -0600, Chris Rorvick wrote:
> On Wed, Jan 16, 2013 at 11:43 AM, Jeff King wrote:
> > I think that is a reasonable rule that could be applied across all parts
> > of the namespace hierarchy. And it could be applied by the client,
> > because all you need to know
On Wed, Jan 16, 2013 at 9:11 PM, Jeff King wrote:
>> is_forwardable() did solve a UI issue. Previously all instances where
>> old is not reachable by new were assumed to be addressable with a
>> merge. is_forwardable() attempted to determine if the concept of
>> forwarding made sense given the i
On 01/16/2013 04:34 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> On 01/15/2013 07:51 PM, Matt Kraai wrote:
>>> On Tue, Jan 15, 2013 at 09:06:25AM +0100, Michael Haggerty wrote:
-static struct imap_list *parse_imap_list(struct imap *imap, char **sp)
+static struct imap_list
"David Lang" wrote in message
news:...
> >>
> >> On Thu, 17 Jan 2013, Matt Seitz (matseitz) wrote:
> >>
> >>> 2. a repository where only one user does "git add" and "git commit",
> >> while other users will do "git pull", the peer-to-peer model (you pull
> >> changes
> >> from me, I pull changes
1 - 100 of 102 matches
Mail list logo
