Chris Rorvick writes:
> On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano wrote:
>> It is fine when pushing into "refs/tags/" hierarchy. It is *NOT*
>> OK if the type check does not satisfy this function. In that case,
>> we do not actually see the existence of the destination as a
>> problem,
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano wrote:
> It is fine when pushing into "refs/tags/" hierarchy. It is *NOT*
> OK if the type check does not satisfy this function. In that case,
> we do not actually see the existence of the destination as a
> problem, but it is reported as such. W
"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
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
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 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 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
> 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 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
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
> 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]
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]
>
> 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
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
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'
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
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
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
>>
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
"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
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:
>
> 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
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
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 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
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
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
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
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
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
"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
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
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
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
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.
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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 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
> 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 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
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 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
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 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, 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, 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
---
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, 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
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
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
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
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
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
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
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
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);
> ^~~~
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
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
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
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
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
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
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
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
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
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
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
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
>>
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
--
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
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
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 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
1 - 100 of 102 matches
Mail list logo
