2013/1/16 Junio C Hamano gits...@pobox.com:
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 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 g...@drmicha.warpmail.net 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
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
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 pclo...@gmail.com
---
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
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 for
On Wed, Jan 16, 2013 at 1:53 AM, Chris Rorvick ch...@rorvick.com wrote:
On Tue, Jan 15, 2013 at 5:10 PM, Ben Walton bdwal...@gmail.com 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
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 config
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
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 are
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 those
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
This shows
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
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 m...@quendi.de
---
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
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 running the
Michael Haggerty mhag...@alum.mit.edu 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
Ben Walton bdwal...@gmail.com 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
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 g...@drmicha.warpmail.net 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
On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano gits...@pobox.com wrote:
Michael J Gruber g...@drmicha.warpmail.net 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
Junio C Hamano venit, vidit, dixit 16.01.2013 16:50:
Michael J Gruber g...@drmicha.warpmail.net 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
Phil Hord venit, vidit, dixit 16.01.2013 17:15:
On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano gits...@pobox.com wrote:
Michael J Gruber g...@drmicha.warpmail.net 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
Max Horn m...@quendi.de 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
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 return
Junio C Hamano gits...@pobox.com writes:
Max Horn m...@quendi.de 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
Jeff King p...@peff.net 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
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 to
Max Horn m...@quendi.de 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
Jeff King p...@peff.net 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
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:
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 files., me);
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 p...@peff.net 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
Adam Spiers g...@adamspiers.org 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
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,
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 you have
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 +-
On Wed, 16 Jan 2013 09:50:57 -0800, Jeff King p...@peff.net 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
On Wed, 16 Jan 2013 17:49:09 +
Lang, David david.l...@uhn.ca 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
On Wed, Jan 16, 2013 at 10:00 AM, Martin von Zweigbergk
martinv...@gmail.com 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
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 is
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 p...@peff.net 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
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 is OK
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
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 the
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 for its
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
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 pclo...@gmail.com
FWIW, of the three versions proposed, this one makes the most sense to
me. Looks good.
--
To unsubscribe from
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.
Is it
Duy Nguyen pclo...@gmail.com 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()
From: Junio C Hamano gits...@pobox.com
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 #bugid form, for example.
The support we offer these use cases is not very friendly to the end
users. They have a
Michael J Gruber g...@drmicha.warpmail.net 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
Junio C Hamano gits...@pobox.com 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
On Wed, 16 Jan 2013 10:21:56 -0800
Jeff King p...@peff.net 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
Andreas Schwab sch...@linux-m68k.org writes:
Junio C Hamano gits...@pobox.com 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)
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
Junio C Hamano wrote:
Robin Rosenberg robin.rosenb...@dewire.com 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
Ralf Thielow ralf.thie...@gmail.com writes:
From: Junio C Hamano gits...@pobox.com
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 #bugid form, for example.
The support we offer these use cases is
Ben Walton bdwal...@gmail.com writes:
On Wed, Jan 16, 2013 at 3:37 PM, Junio C Hamano gits...@pobox.com wrote:
Ben Walton bdwal...@gmail.com 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
Jeff King p...@peff.net 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
Am 16.01.2013 20:18, schrieb Ralf Thielow:
From: Junio C Hamano gits...@pobox.com
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 #bugid form, for example.
The support we offer these use cases is
Konstantin Khomoutov kostix+...@007spb.ru wrote in message
news:20130116233744.7d0775eaec98ce154a9de...@domain007.com...
On Wed, 16 Jan 2013 10:21:56 -0800
Jeff King p...@peff.net wrote:
I agree that performance is not ideal (although if you are on a fast
LAN, it probably would not
Junio C Hamano gits...@pobox.com 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
Adam Spiers g...@adamspiers.org 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
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
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 performance and bug-free
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
of
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 as
the
On Thu, Jan 17, 2013 at 12:08 AM, John Keeping j...@keeping.me.uk 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
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 apeli...@gmail.com wrote:
On Thu, Jan 17, 2013 at 12:08 AM, John Keeping j...@keeping.me.uk wrote:
On Wed, Jan 16, 2013 at
David Lang da...@lang.hm wrote in message
news:alpine.deb.2.02.1301161459060.21...@nftneq.ynat.uz...
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
Antoine Pelisse apeli...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Antoine Pelisse apeli...@gmail.com 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
On Wed, 16 Jan 2013, Matt Seitz (matseitz) wrote:
David Lang da...@lang.hm wrote in message
news:alpine.deb.2.02.1301161459060.21...@nftneq.ynat.uz...
But if you try to have one filesystem, with multiple people running git on their
machines against that shared filesystem, I would expect you
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
+++
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
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 of
actions.
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 repository
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
On Wed, Jan 16, 2013 at 11:43 AM, Jeff King p...@peff.net 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.
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 issues with multiple
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 not
On Wed, Jan 16, 2013 at 08:19:28PM -0600, Chris Rorvick wrote:
On Wed, Jan 16, 2013 at 11:43 AM, Jeff King p...@peff.net 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
On Wed, Jan 16, 2013 at 9:11 PM, Jeff King p...@peff.net 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
On 01/16/2013 04:34 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
David Lang da...@lang.hm wrote in message
news:alpine.deb.2.02.1301161843390.21...@nftneq.ynat.uz...
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
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com 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
Chris Rorvick ch...@rorvick.com writes:
On Wed, Jan 16, 2013 at 10:48 AM, Junio C Hamano gits...@pobox.com 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
98 matches
Mail list logo
