Re: Git push race condition?

2014-04-11 Thread Matthieu Moy
This finally happened again. Here's what the reflog looks like: 2805f68 master@{0}: push 96eebc0 master@{1}: push 75bd4a6 master@{2}: push abc30da master@{3}: push eba874f master@{4}: push 10981e7 master@{5}: push 76b3957 master@{6}: push 2e3ea06 master@{7}: push 9d4e778 master@{8}:

Re: [PATCH v7 2/2] Verify index file before we opportunistically update it

2014-04-11 Thread Torsten Bögershausen
On 2014-04-10 21.28, Junio C Hamano wrote: Yiannis Marangos yiannis.maran...@gmail.com writes: +n = xpread(fd, sha1, 20, st.st_size - 20); +if (n != 20) +goto out; I think it is possible for pread(2) to give you a short-read. The existing callers of emulated mmap

[PATCH] test: fix t7001 cp to use POSIX options

2014-04-11 Thread Kyle J. McKay
Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the t7001-mv test has used cp -a to perform a copy in several of the tests. However, the -a option is not required for a POSIX cp utility and some platforms' cp utilities do not support it. The POSIX equivalent of -a is -R -P -p.

[PATCH 0/3] Fix support for FreeBSD's /bin/sh

2014-04-11 Thread Kyle J. McKay
This patch series words around the FreeBSD /bin/sh problems that cause rebase to fail on FreeBSD as well as test t5560-http-backend-noserver. The rebase issue was first introduced in Git v1.8.4 which started using the return statement to return from a dot command script where the dot command

[PATCH 2/3] Revert rebase: fix run_specific_rebase's use of return on FreeBSD

2014-04-11 Thread Kyle J. McKay
This reverts commit 99855ddf4bd319cd06a0524e755ab1c1b7d39f3b. The workaround 99855ddf introduced to deal with problematic return statements in scripts run by dot commands located inside functions only handles one part of the problem. The issue has now been addressed by not using return

[PATCH 1/3] rebase: avoid non-function use of return on FreeBSD

2014-04-11 Thread Kyle J. McKay
Since a1549e10, 15d4bf2e and 01a1e646 (first appearing in v1.8.4) the git-rebase--*.sh scripts have used a return to return from the dot command that runs them. While this is allowed by POSIX, the FreeBSD /bin/sh utility behaves poorly under some circumstances when such a return is executed. In

[PATCH 3/3] test: fix t5560 on FreeBSD

2014-04-11 Thread Kyle J. McKay
Since fd0a8c2e (first appearing in v1.7.0), the t/t5560-http-backend-noserver.sh test has used a backslash escape inside a ${} expansion in order to specify a literal '?' character. Unfortunately the FreeBSD /bin/sh does not interpret this correctly. In a POSIX compliant shell, the following:

Re: [PATCH 1/3] rebase: avoid non-function use of return on FreeBSD

2014-04-11 Thread Matthieu Moy
Kyle J. McKay mack...@gmail.com writes: If script2.sh is changed to this: # script2.sh fixed main() { if [ 5 -gt 3 ]; then return 5 fi case bad in *) echo always shows esac echo should not get here ! : }

Re: [PATCH v2 0/9] Introduce publish tracking branch

2014-04-11 Thread Matthieu Moy
Felipe Contreras felipe.contre...@gmail.com writes: As it has been discussed before, our support for triangular workflows is lacking, and the following patch series aims to improve that situation. I'm not a heavy user of triangular workflow, so I'm not in the best position to comment (and I

Re: [PATCH v7 2/2] Verify index file before we opportunistically update it

2014-04-11 Thread Duy Nguyen
On Fri, Apr 11, 2014 at 2:28 AM, Junio C Hamano gits...@pobox.com wrote: +static int verify_index_from(const struct index_state *istate, const char *path) +{ + int fd; + ssize_t n; + struct stat st; + unsigned char sha1[20]; + + if (!istate-initialized) +

Re: Silly time stamps

2014-04-11 Thread Michael Haggerty
On 04/09/2014 10:50 PM, Mahmoud Asshole wrote: [...] Please conduct your discussions here in a civil tone. It is both more pleasant for all involved and also more likely to elicit a response. I hardly think that the waste of 12 bytes in every commit is an act of stupidity so inexcusable that

Re: [PATCH v2 6/9] branch: display publish branch

2014-04-11 Thread Jeff King
On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote: I noticed that this only picks up a publish-branch if branch.*.pushremote is configured. What happened to the case when remote.pushdefault is configured? What happens when branch.*.remote is not configured for @{upstream}?

Re: Our official home page and logo for the Git project

2014-04-11 Thread Javier Domingo Cansino
I have never thought on that logo as the Git logo (the red one), and thought it was [1]. Mainly because the logo itself has git inside. I have to agree with David Kastrup on that I see no connection to git only by the image (red one). Maybe is because I am accustomed to the older one[1] I started

Re: Our official home page and logo for the Git project

2014-04-11 Thread Jeff King
On Thu, Apr 10, 2014 at 10:24:24AM +1000, Andrew Ardill wrote: It's normal for an organisation to have a collection of logos to choose from, with one 'official' version. For example, a black and white version is useful for print. Similarly, it's useful to have a couple of different contrast

Re: [PATCH] test: fix t7001 cp to use POSIX options

2014-04-11 Thread Jeff King
On Fri, Apr 11, 2014 at 01:24:02AM -0700, Kyle J. McKay wrote: Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the t7001-mv test has used cp -a to perform a copy in several of the tests. However, the -a option is not required for a POSIX cp utility and some platforms' cp

Re: Handling empty directories in Git

2014-04-11 Thread Øyvind A . Holm
On 8 April 2014 16:47, Olivier LE ROY olivier_le_...@yahoo.com wrote: Hello, I have a project under SVN with contains empty directories. I would like to move this project on a Git server, still handling empty directories. The solution: put a .gitignore file in each empty directory to have

Re: Our official home page and logo for the Git project

2014-04-11 Thread Max Horn
My two cents: I like git-scm.com quite a bit. As for the logo, I think it's nice and simple, and based on experience I think that for every logo you'll find people who object to it. E.g. the red color of the log on git-scm.com looks great to me, while I dislike e.g. the color variation Felipe

[tig] [PATCH 0/3] log: colour the diffstat.

2014-04-11 Thread Kumar Appaiah
These patches add colourization to the log view. They reuse the diff stat drawing functions from the diff module directly. Kumar Appaiah (3): diff: Move diff stat addition to a common function diff: Move diff stat drawing to a common function log: Colour the diff stat include/tig/diff.h |

[tig] [PATCH 2/3] diff: Move diff stat drawing to a common function

2014-04-11 Thread Kumar Appaiah
Signed-off-by: Kumar Appaiah a.ku...@alumni.iitm.ac.in --- include/tig/diff.h | 1 + src/diff.c | 30 ++ 2 files changed, 19 insertions(+), 12 deletions(-) diff --git a/include/tig/diff.h b/include/tig/diff.h index ba40386..16299fe 100644 ---

[tig] [PATCH 1/3] diff: Move diff stat addition to a common function

2014-04-11 Thread Kumar Appaiah
Signed-off-by: Kumar Appaiah a.ku...@alumni.iitm.ac.in --- include/tig/diff.h | 1 + src/diff.c | 27 ++- 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/include/tig/diff.h b/include/tig/diff.h index be325c4..ba40386 100644 --- a/include/tig/diff.h

[tig] [PATCH 3/3] log: Colour the diff stat

2014-04-11 Thread Kumar Appaiah
This commit adds custom log_read and log_draw functions that utilize the diff stat drawing functions from the diff module. The absence of the triple hyphen separator prevents direct usage of the diff drawing functions directly. Signed-Off-By: Kumar Appaiah a.ku...@alumni.iitm.ac.in --- src/log.c

Re: Silly time stamps

2014-04-11 Thread Holger Hellmuth
Am 11.04.2014 13:08, schrieb Michael Haggerty: On 04/09/2014 10:50 PM, Mahmoud Asshole wrote: [...] Please conduct your discussions here in a civil tone. It is both more pleasant for all involved and also more likely to elicit a response. I hardly think that the waste of 12 bytes in every

Re: Our official home page and logo for the Git project

2014-04-11 Thread Felipe Contreras
Jeff King wrote: On Thu, Apr 10, 2014 at 10:24:24AM +1000, Andrew Ardill wrote: It's normal for an organisation to have a collection of logos to choose from, with one 'official' version. For example, a black and white version is useful for print. Similarly, it's useful to have a couple

Re: Our official home page and logo for the Git project

2014-04-11 Thread Felipe Contreras
Max Horn wrote: As for the logo, I think it's nice and simple, You don't think red represent an oldness in Git? Whereas green represents progress? and based on experience I think that for every logo you'll find people who object to it. So we should just accept any logo without thinking about

Re: [PATCH] test: fix t7001 cp to use POSIX options

2014-04-11 Thread Kyle J. McKay
On Apr 11, 2014, at 04:43, Jeff King wrote: On Fri, Apr 11, 2014 at 01:24:02AM -0700, Kyle J. McKay wrote: Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the t7001-mv test has used cp -a to perform a copy in several of the tests. However, the -a option is not required for a

Re: Our official home page and logo for the Git project

2014-04-11 Thread David Kastrup
Felipe Contreras felipe.contre...@gmail.com writes: Secondly, the logos that are not black, are bright red, which is horrible; not only do they look bad in almost every situation due to the contrast, but in a Git's mindeset red implies old, a minus, the hunk removed, an error, which is not

Re: [PATCH v2 6/9] branch: display publish branch

2014-04-11 Thread Felipe Contreras
Jeff King wrote: On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote: I noticed that this only picks up a publish-branch if branch.*.pushremote is configured. What happened to the case when remote.pushdefault is configured? What happens when branch.*.remote is not

Re: Our official home page and logo for the Git project

2014-04-11 Thread Vincent van Ravesteijn
On Fri, Apr 11, 2014 at 3:24 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Moreover, even the black ones have the issue I already mentioned; they picture the equivalent of two root commits (with no parents) that are immediately merged, and the history continues, but who is interested

Re: [PATCH 1/3] rebase: avoid non-function use of return on FreeBSD

2014-04-11 Thread Kyle J. McKay
On Apr 11, 2014, at 01:48, Matthieu Moy wrote: Kyle J. McKay mack...@gmail.com writes: If script2.sh is changed to this: # script2.sh fixed main() { if [ 5 -gt 3 ]; then return 5 fi case bad in *) echo always shows esac echo

Re: [PATCH v2 0/9] Introduce publish tracking branch

2014-04-11 Thread Felipe Contreras
Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: As it has been discussed before, our support for triangular workflows is lacking, and the following patch series aims to improve that situation. I'm not a heavy user of triangular workflow, so I'm not in the best

Re: Our official home page and logo for the Git project

2014-04-11 Thread Max Horn
On 11.04.2014, at 15:29, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: As for the logo, I think it's nice and simple, You don't think red represent an oldness in Git? Whereas green represents progress? No, I don't think that. Perhaps you think that, but if that is

Re: Silly time stamps

2014-04-11 Thread Max Horn
On 11.04.2014, at 15:19, Holger Hellmuth hellm...@ira.uka.de wrote: Am 11.04.2014 13:08, schrieb Michael Haggerty: On 04/09/2014 10:50 PM, Mahmoud Asshole wrote: [...] Please conduct your discussions here in a civil tone. It is both more pleasant for all involved and also more likely to

Re: Silly time stamps

2014-04-11 Thread Philip Oakley
From: Holger Hellmuth hellm...@ira.uka.de To: Michael Haggerty mhag...@alum.mit.edu Cc: Mahmoud Asshole a1209...@drdrb.net; git@vger.kernel.org If you look at Mahmoud's email address, it is from http://10minutemail.com/ 'the best disposable e-mail service.'. So it looks like s/he knew what

Re: Our official home page and logo for the Git project

2014-04-11 Thread Felipe Contreras
Max Horn wrote: On 11.04.2014, at 15:29, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: You don't think red represent an oldness in Git? Whereas green represents progress? No, I don't think that. Then you belong to the minority of Git users. Those of us that see

Re: Our official home page and logo for the Git project

2014-04-11 Thread Felipe Contreras
Vincent van Ravesteijn wrote: On Fri, Apr 11, 2014 at 3:24 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Moreover, even the black ones have the issue I already mentioned; they picture the equivalent of two root commits (with no parents) that are immediately merged, and the

Re: Our official home page and logo for the Git project

2014-04-11 Thread Philippe Vaucher
You don't think red represent an oldness in Git? Whereas green represents progress? No, I don't think that. Perhaps you think that, but if that is the case, it is based on your own sociocultural background. Hey, and let's not forget that supposedly 8% or so of all males are red-green

Re: Our official home page and logo for the Git project

2014-04-11 Thread Philippe Vaucher
FWIW, I think if you made a poll and asked which color is the most positive between green and red, the vast majority of people would say green. Examples could be traffic green lights vs red lights, or that in nature quiet peaceful usually involves green while danger/action involves red (tree

Re: [PATCH v7 2/2] Verify index file before we opportunistically update it

2014-04-11 Thread Yiannis Marangos
On Fri, Apr 11, 2014 at 09:47:09AM +0200, Torsten Bögershausen wrote: 6. process A applies a commit: - read the index into memory - take the lock - update the index file on disc - release the lock So here we can have race condition. Maybe we should implement Duy's

Re: Silly time stamps

2014-04-11 Thread Holger Hellmuth
Am 11.04.2014 17:14, schrieb Max Horn: More between privacy (or perhaps personal safety? think: dissident coder?) vs. feature that is useful to some people. Well, at least the reason mentioned in the gmane citation about knowing if it was 2 am for them, is strange. Did anyone ever check

Re: Our official home page and logo for the Git project

2014-04-11 Thread Michael Haggerty
On 04/09/2014 06:43 PM, Felipe Contreras wrote: Junio C Hamano wrote: - To officially adopt the logo that appears on the project home page as our project logo. I have made my objections to that logo before, but here it goes again: bright red is a horrible color for a logo, as it only

Re: Our official home page and logo for the Git project

2014-04-11 Thread Holger Hellmuth
Am 11.04.2014 17:39, schrieb Philippe Vaucher: FWIW, I think if you made a poll and asked which color is the most positive between green and red, the vast majority of people would say green. Examples could be traffic green lights vs red lights, or Coca-Cola uses red. So red is refreshing and

Re: Our official home page and logo for the Git project

2014-04-11 Thread Tim Chase
On 2014-04-11 13:32, Javier Domingo Cansino wrote: I have never thought on that logo as the Git logo (the red one), and thought it was [1]. Mainly because the logo itself has git inside. [1] Git logo: http://git-osx-installer.googlecode.com/files/GitLogo.jpg -- Like Javier, I too assumed

Re: Our official home page and logo for the Git project

2014-04-11 Thread Karsten Blees
Am 09.04.2014 18:43, schrieb Felipe Contreras: Junio C Hamano wrote: - To officially adopt the logo that appears on the project home page as our project logo. I have made my objections to that logo before, but here it goes again: bright red is a horrible color for a logo, as it only

Re: Our official home page and logo for the Git project

2014-04-11 Thread David Kastrup
Karsten Blees karsten.bl...@gmail.com writes: Additionally, orange/red alerts and attracts the eye while green is calming, uninteresting. Imagine a page with five different SCM logos. If you want git to stand out, choose orange/red. If you want git to be overlooked choose green. How about

Re: [PATCH v2 0/9] Introduce publish tracking branch

2014-04-11 Thread Matthieu Moy
Felipe Contreras felipe.contre...@gmail.com writes: My patch series only affects push.default=simple, perhaps you have a different configuration. Good catch. I have push.default=upstream (essentially for compatibility with old Git versions, I'd prefer simple actually). Maybe we want the

Re: [PATCH 1/3] rebase: avoid non-function use of return on FreeBSD

2014-04-11 Thread Matthieu Moy
Kyle J. McKay mack...@gmail.com writes: There are already nested functions with file inclusion between both levels of nesting in git-rebase--interactive.sh and git-rebase-- merge.sh now, so it's not introducing anything new. OK, so it's less serious than I thought. But still, we're

A little git humor: a git man page generator

2014-04-11 Thread Tim Chase
This crossed my path recently via the fossil mailing list http://git-man-page-generator.lokaltog.net/ but I thought folks here might enjoy the humor :-) (and I hadn't seen mention of it here on the list yet) -tkc -- To unsubscribe from this list: send the line unsubscribe git in the body of a

[PATCH v3 2/8] Add concept of 'publish' branch

2014-04-11 Thread Felipe Contreras
The publish branch is the branch the user wants to push to, akin to the upstream branch, which is the branch the user wants to use as a baseline. It overrides other configurations, such as push.default, and remote.name.push. The upstream branch is: branch.$name.remote branch.$name.merge The

[PATCH v3 4/8] push: add --set-publish option

2014-04-11 Thread Felipe Contreras
To setup publish tracking branch, like 'git branch --set-publish'. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-push.txt | 9 +- builtin/push.c | 2 ++ t/t5534-push-publish.sh| 70 ++

[PATCH v3 1/8] t5516 (fetch-push): fix test restoration

2014-04-11 Thread Felipe Contreras
We shouldn't modify the commits; it screws the following tests. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- t/t5516-fetch-push.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 67e0ab3..f4cf0db 100755 ---

[PATCH v3 0/8] Introduce publish tracking branch

2014-04-11 Thread Felipe Contreras
As it has been discussed before, our support for triangular workflows is lacking, and the following patch series aims to improve that situation. We have the concept of upstream branch (e.g. 'origin/master') which is to where our topic branches eventually should be merged to, so it makes sense

[PATCH v3 8/8] sha1_name: add support for @{publish} marks

2014-04-11 Thread Felipe Contreras
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/revisions.txt | 4 sha1_name.c | 49 - t/t1508-at-combinations.sh | 5 + 3 files changed, 40 insertions(+), 18 deletions(-) diff --git

[PATCH v3 7/8] sha1_name: simplify track finding

2014-04-11 Thread Felipe Contreras
It's more efficient to check for the braces first. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- sha1_name.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index 906f09d..aa3f3e0 100644 --- a/sha1_name.c +++

[PATCH v3 3/8] branch: add --set-publish-to option

2014-04-11 Thread Felipe Contreras
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-branch.txt | 11 +++ branch.c | 44 + branch.h | 2 ++ builtin/branch.c | 57 ++--- t/t3200-branch.sh

[PATCH v3 6/8] sha1_name: cleanup interpret_branch_name()

2014-04-11 Thread Felipe Contreras
The 'upstream' variable doesn't hold an upstream, but a branch, so make it clearer. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- sha1_name.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index

[PATCH v3 5/8] branch: display publish branch

2014-04-11 Thread Felipe Contreras
It does it along the upstream branch, if any. * publish ... [master, gh/publish: ahead 1] ... master ... [master, gh/master] ... Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- builtin/branch.c | 17 - t/t6040-tracking-info.sh | 5 +++-- 2 files

Re: Job Offer..

2014-04-11 Thread info
Attn: Sir / Madam, We have a job offer available for qualified applicants. You do not need to work from an office. You can work from home and earn ($2000)monthly. Contact us immediately on: Allen Lee eunibli...@gmail.com Fabric Land Inc. -- To unsubscribe from this list: send the line unsubscribe

Re: Our official home page and logo for the Git project

2014-04-11 Thread Max Horn
On 11.04.2014, at 17:39, Philippe Vaucher philippe.vauc...@gmail.com wrote: You don't think red represent an oldness in Git? Whereas green represents progress? No, I don't think that. Perhaps you think that, but if that is the case, it is based on your own sociocultural background.

Re: Our official home page and logo for the Git project

2014-04-11 Thread Max Horn
On 11.04.2014, at 17:21, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: On 11.04.2014, at 15:29, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: You don't think red represent an oldness in Git? Whereas green represents progress? No, I don't

Re: [PATCH v3 0/8] Introduce publish tracking branch

2014-04-11 Thread Matthieu Moy
Felipe Contreras felipe.contre...@gmail.com writes: * Override other configurations (such as push.default) I think I convinced myself that this is the right way to go since my last message. After all, push.default is, by definition, just a default. --- a/Documentation/config.txt +++

Re: Our official home page and logo for the Git project

2014-04-11 Thread Felipe Contreras
Max Horn wrote: On 11.04.2014, at 17:21, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: On 11.04.2014, at 15:29, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: You don't think red represent an oldness in Git? Whereas green represents

Re: Our official home page and logo for the Git project

2014-04-11 Thread Max Horn
On 11.04.2014, at 20:56, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: On 11.04.2014, at 17:21, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: On 11.04.2014, at 15:29, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: You don't

Re: [PATCH] test: fix t7001 cp to use POSIX options

2014-04-11 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Fri, Apr 11, 2014 at 01:24:02AM -0700, Kyle J. McKay wrote: Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the t7001-mv test has used cp -a to perform a copy in several of the tests. However, the -a option is not required for a POSIX cp

Re: [PATCH v7 2/2] Verify index file before we opportunistically update it

2014-04-11 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes: On Fri, Apr 11, 2014 at 2:28 AM, Junio C Hamano gits...@pobox.com wrote: Yiannis Marangos yiannis.maran...@gmail.com writes: + n = xpread(fd, sha1, 20, st.st_size - 20); + if (n != 20) + goto out; I think it is possible for pread(2)

Re: [PATCH v2 6/9] branch: display publish branch

2014-04-11 Thread Junio C Hamano
Jeff King p...@peff.net writes: For instance, it looks like your @{publish} requires config like: [branch master] pushremote = foo push = refs/heads/bar to operate. Setting pushremote affects what git push does; it will go to the foo remote. OK, and the same thing would happen if

Re: Our official home page and logo for the Git project

2014-04-11 Thread Junio C Hamano
Jeff King p...@peff.net writes: The git-scm.com page is mostly targeted at end users: what is it, how do I get it, where is the documentation. Things like a logo repository, or developer information is spread across various wikis and other sites. If there's interest, we can make

Re: [PATCH v2 0/9] Introduce publish tracking branch

2014-04-11 Thread Felipe Contreras
Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: My patch series only affects push.default=simple, perhaps you have a different configuration. Good catch. I have push.default=upstream (essentially for compatibility with old Git versions, I'd prefer simple

Re: Our official home page and logo for the Git project

2014-04-11 Thread Jonathan Nieder
Junio C Hamano wrote: In any case, this motion is not about let's declare the logo we see on git-scm.com today as _the_ official one. Phew. :) [...] Please help us by letting us answer Yup, that is a logo (among others) that represents our project, and we are OK with you using

Re: Our official home page and logo for the Git project

2014-04-11 Thread Ronnie Sahlberg
On Fri, Apr 11, 2014 at 12:25 PM, Junio C Hamano gits...@pobox.com wrote: Please help us by letting us answer Yup, that is a logo (among others) that represents our project, and we are OK with you using it to help promote our project instead. That is what I meant by our official

Re: [PATCH v3 2/8] Add concept of 'publish' branch

2014-04-11 Thread Junio C Hamano
Felipe Contreras felipe.contre...@gmail.com writes: The publish branch is the branch the user wants to push to, akin to the upstream branch, which is the branch the user wants to use as a baseline. It overrides other configurations, such as push.default, and remote.name.push. The upstream

Re: [PATCH v3 00/27] Clean up update-refs --stdin and implement ref_transaction

2014-04-11 Thread Ronnie Sahlberg
Nice. Once this is in I can add transactional support to receive-pack. On Mon, Apr 7, 2014 at 6:47 AM, Michael Haggerty mhag...@alum.mit.edu wrote: Here is v3. It is also available on GitHub [1]. Thanks to Junio and Brad for their comments about v2. I think I have addressed all of your

Re: [PATCH v2 6/9] branch: display publish branch

2014-04-11 Thread Felipe Contreras
Junio C Hamano wrote: Jeff King p...@peff.net writes: For instance, it looks like your @{publish} requires config like: [branch master] pushremote = foo push = refs/heads/bar to operate. Setting pushremote affects what git push does; it will go to the foo remote. OK,

wrong handling of text git attribute leading to files incorrectly reported as modified

2014-04-11 Thread Frank Ammeter
I’m not a git expert and this might be the wrong place to ask this question, so please send me somewhere else if I’m in the wrong place. I asked the same question on stack overflow, but didn’t get any response:

Re: Our official home page and logo for the Git project

2014-04-11 Thread Felipe Contreras
Max Horn wrote: On 11.04.2014, at 20:56, Felipe Contreras felipe.contre...@gmail.com wrote: Max Horn wrote: Come back when you have facts, as opposed to the illusion that you are the spokesperson of the (apparently silent) majority of Git users. Facts: 1) A hunk that removed (-)

Re: wrong handling of text git attribute leading to files incorrectly reported as modified

2014-04-11 Thread Torsten Bögershausen
On 2014-04-11 22.20, Frank Ammeter wrote: I’m not a git expert and this might be the wrong place to ask this question, so please send me somewhere else if I’m in the wrong place. I asked the same question on stack overflow, but didn’t get any response:

[PATCH v3 0/3] Make update refs more atomic

2014-04-11 Thread Ronnie Sahlberg
refs.c:ref_transaction_commit() intermingles doing updates and checks with actually applying changes to the refs in loops that abort on error. This is done one ref at a time and means that if an error is detected that will fail the operation partway through the list of refs to update we will end

[PATCH v3 2/3] refs.c: split delete_ref_loose() into a separate flag-for-deletion and commit phase

2014-04-11 Thread Ronnie Sahlberg
Change delete_ref_loose()) to just flag that a ref is to be deleted but do not actually unlink the files. Change commit_ref_lock() so that it will unlink refs that are flagged for deletion. Change all callers of delete_ref_loose() to explicitely call commit_ref_lock() to commit the deletion. The

[PATCH v3 1/3] refs.c: split writing and commiting a ref into two separate functions

2014-04-11 Thread Ronnie Sahlberg
Change the function write_ref_sha1() to just write the ref but not commit the ref or the lockfile. Add a new function commit_ref_lock() that will commit the change done by a previous write_ref_sha1(). Update all callers of write_ref_sha1() to call commit_ref_lock(). The new pattern for updating a

[PATCH v3 3/3] refs.c: change ref_transaction_commit to run the commit loops once all work is finished

2014-04-11 Thread Ronnie Sahlberg
During a transaction commit we will both update and delete refs. Since both update and delete now use the same pattern lock = lock_ref_sha1_basic() (or varient of) write_ref_sha1(lock)/delete_ref_loose(lock) unlock_ref(lock) | commit_ref_lock(lock) we can now simplify

Re: [PATCH v7 2/2] Verify index file before we opportunistically update it

2014-04-11 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Yeah, I was hoping that the real write codepath (as opposed to this is read only and we read the index without holding a lock---now we noticed that the index needs refreshing, and we know how the resulting refreshed index should look like, perhaps we

Re: [PATCH 3/3] test: fix t5560 on FreeBSD

2014-04-11 Thread Junio C Hamano
Kyle J. McKay mack...@gmail.com writes: Instead, we can use the [...] construct to defeat the special meaning of the '?' character and match it exactly in a way that works for the FreeBSD /bin/sh as well as other POSIX /bin/sh implementations. Changing the example like so:

Re: Our official home page and logo for the Git project

2014-04-11 Thread Brandon McCaig
Junio: On Fri, Apr 11, 2014 at 3:25 PM, Junio C Hamano gits...@pobox.com wrote: The pages at https://git.wiki.kernel.org/index.php/Main_Page are done primarily by developers, and between the two logos on that page, the one that appears inside the page under Main Page header has long been the

Re: [PATCH v3 2/3] refs.c: split delete_ref_loose() into a separate flag-for-deletion and commit phase

2014-04-11 Thread Junio C Hamano
Ronnie Sahlberg sahlb...@google.com writes: int commit_ref_lock(struct ref_lock *lock) { + if (lock-delete_ref) { + int flag = lock-delete_flag; + + if (!(flag REF_ISPACKED) || flag REF_ISSYMREF) { + /* loose */ + int

Git for Windows 1.9.2

2014-04-11 Thread Johannes Schindelin
Hi, the Git for Windows team just released version 1.9.2 of the Windows-specific installers. New Features * Comes with Git 1.9.2 plus Windows-specific patches. * Custom installer settings can be saved and loaded, for unsupervised installation on batches of machines (msysGit PR #168). * Comes

What's cooking in git.git (Apr 2014, #03; Fri, 11)

2014-04-11 Thread Junio C Hamano
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The number of topics cooking in 'next' has been shrinking, and the cycle is getting long. Hopefully we will have -rc0 late next week to close

Re: [PATCH v3 0/3] Make update refs more atomic

2014-04-11 Thread Junio C Hamano
Ronnie Sahlberg sahlb...@google.com writes: refs.c:ref_transaction_commit() intermingles doing updates and checks with actually applying changes to the refs in loops that abort on error. This is done one ref at a time and means that if an error is detected that will fail the operation partway

Re: [PATCH 1/3] rebase: avoid non-function use of return on FreeBSD

2014-04-11 Thread Kyle J. McKay
On Apr 11, 2014, at 10:30, Matthieu Moy wrote: Kyle J. McKay mack...@gmail.com writes: There are already nested functions with file inclusion between both levels of nesting in git-rebase--interactive.sh and git-rebase-- merge.sh now, so it's not introducing anything new. OK, so it's less

Re: [PATCH v7 2/2] Verify index file before we opportunistically update it

2014-04-11 Thread Yiannis Marangos
On Fri, Apr 11, 2014 at 01:43:47PM -0700, Junio C Hamano wrote: Having said that, nobody sane would be running two simultaneous operations that are clearly write-oriented competing with each other against the same index file. So in that sense that can be done as a less urgent follow-up for

[PATCH] remote-bzr: trivial test fix

2014-04-11 Thread Felipe Contreras
So that the committer is reset properly. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/test-bzr.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh index

RE: What's cooking in git.git (Apr 2014, #03; Fri, 11)

2014-04-11 Thread Felipe Contreras
Junio C Hamano wrote: * fc/complete-aliased-push (2014-04-09) 1 commit - completion: fix completing args of aliased push, fetch, etc. Will merge to 'next'. * fc/remote-helper-fixes (2014-04-09) 4 commits - remote-bzr: include authors field in pushed commits Before you do, you might

[PATCH] prompt: fix missing file errors in zsh

2014-04-11 Thread Felipe Contreras
zsh seems to have a bug while redirecting the stderr of the 'read' command: % read foo 2 /dev/null foo zsh: no such file or directory: foo Which causes errors to be displayed when certain files are missing. Let's add a convenience function to manually check if the file is readable before

Re: [PATCH v7 2/2] Verify index file before we opportunistically update it

2014-04-11 Thread Duy Nguyen
On Sat, Apr 12, 2014 at 3:43 AM, Junio C Hamano gits...@pobox.com wrote: Having said that, nobody sane would be running two simultaneous operations that are clearly write-oriented competing with each other against the same index file. When it comes to racing, sanity does not matter much.

Re: [PATCH v7 2/2] Verify index file before we opportunistically update it

2014-04-11 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com writes: On Sat, Apr 12, 2014 at 3:43 AM, Junio C Hamano gits...@pobox.com wrote: Having said that, nobody sane would be running two simultaneous operations that are clearly write-oriented competing with each other against the same index file. When it comes to

Re: Our official home page and logo for the Git project

2014-04-11 Thread Michael Haggerty
On 04/11/2014 09:25 PM, Junio C Hamano wrote: [...] The motion is about this: Outside people, like the party who approached us about putting our logo on their trinket, seem to associate that logo we see on git-scm.com today with our project, but we never officially said it