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

On Fri, Apr 11, 2014 at 2:28 AM, Junio C Hamano wrote: > Yiannis Marangos 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 and

[no subject]

Get a loan @ 2% interest rate with Mercantile Finance,Blacklisted are welcome.For more info:email: mercantilefinanceloanserv...@webmail.co.za -- 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://vg

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

Ramkumar Ramachandra wrote: > Felipe Contreras wrote: > > Signed-off-by: Felipe Contreras > > Please write a commit message, preferably showing the new git-branch output. Yeah... this has been sitting in git-fc for quite a while, I wasn't expecting to send this patch series again given that nobo

Re: [PATCH v2 9/9] sha1_name: add support for @{publish} marks

Ramkumar Ramachandra wrote: > Felipe Contreras wrote: > > diff --git a/sha1_name.c b/sha1_name.c > > index aa3f3e0..a36852d 100644 > > --- a/sha1_name.c > > +++ b/sha1_name.c > > @@ -415,9 +415,9 @@ static int ambiguous_path(const char *path, int len) > > return slash; > > } > > > > -stati

Re: [PATCH v2 8/9] sha1_name: simplify track finding

Ramkumar Ramachandra wrote: > Felipe Contreras wrote: > > It's more efficient to check for the braces first. > > Why is it more efficient? So you can error out quickly in the case of > a malformed string? That's one reason. The other is that get_sha1_basic() calls upstream_mark() when we _already

Re: [PATCH v2 9/9] sha1_name: add support for @{publish} marks

Ramkumar Ramachandra wrote: > Felipe Contreras wrote: > > @@ -1068,23 +1069,35 @@ static const char *get_upstream_branch(const char > > *name_buf, int len) > > */ > > if (!branch) > > die(_("HEAD does not point to a branch")); > > - if (!branch->merge || !bra

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

Felipe Contreras wrote: > Signed-off-by: Felipe Contreras Please write a commit message, preferably showing the new git-branch output. 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? -- To u

Re: [PATCH v2 9/9] sha1_name: add support for @{publish} marks

Felipe Contreras wrote: > diff --git a/sha1_name.c b/sha1_name.c > index aa3f3e0..a36852d 100644 > --- a/sha1_name.c > +++ b/sha1_name.c > @@ -415,9 +415,9 @@ static int ambiguous_path(const char *path, int len) > return slash; > } > > -static inline int upstream_mark(const char *string, i

Re: [PATCH v2 7/9] sha1_name: cleanup interpret_branch_name()

Felipe Contreras wrote: > sha1_name.c | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) I like this variable rename. This instance has annoyed me in the past. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@v

Re: [PATCH v2 8/9] sha1_name: simplify track finding

Felipe Contreras wrote: > It's more efficient to check for the braces first. Why is it more efficient? So you can error out quickly in the case of a malformed string? I'm personally not thrilled about this change. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a m

Re: [PATCH v2 9/9] sha1_name: add support for @{publish} marks

Felipe Contreras wrote: > @@ -1068,23 +1069,35 @@ static const char *get_upstream_branch(const char > *name_buf, int len) > */ > if (!branch) > die(_("HEAD does not point to a branch")); > - if (!branch->merge || !branch->merge[0]->dst) { > - if

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

A handful of minimum tweaks [*1*] here and there were necessary in order to queue the series on 'pu', but to me, the feature looked like quite a straight-forward addition. I'd be dropping the jk/branch-at-publish-rebased from 'pu', at least tentatively, as that one was primarily Peff giving Ram a

Re: [PATCH 0/4] Make update_refs more atomic V2

Junio C Hamano writes: > CC'ing Michael who has been active in this area as an area expert. > > Ronnie, please make it a habit to run something like > > $ git shortlog --no-merges --since=18.months ... > > to help you decide who your series may want to be reviewed by, > before sending them. >

Re: [PATCH 4/4] refs.c: sort the refs by new_sha1 and merge the two update/delete loops into one

On Thu, Apr 10, 2014 at 12:01 PM, Junio C Hamano wrote: > Ronnie Sahlberg writes: > >> We want to make sure that we update all refs before we delete any refs >> so that there is no point in time where the tips may not be reachable >> from any ref in the system. >> We currently acheive this by fir

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

Ramkumar Ramachandra wrote: > My primary concern is that the proposed @{publish} should be a first-class > citizen; if it has everything that @{u} has, then we're both good: you'd > primarily use @{u}, while I'd primarily use @{publish}. Something like this? http://article.gmane.org/gmane.comp.ve

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

Yiannis Marangos 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 and index-pack are prepared to handle a short-read correctly, but I do n

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

Ramkumar Ramachandra wrote: > We already have a branch.*.pushremote, and I don't see the value of > branch.*.pushbranch (what you're referring to as pushupstream, I assume) > except for Gerrit users. Frankly, I don't use full triangular workflows > myself mainly because my prompt is compromised: wh

Re: [PATCH v8 1/2] Add xpread()

Johannes Sixt writes: > Am 10.04.2014 20:54, schrieb Yiannis Marangos: >> +ssize_t xpread(int fd, void *buf, size_t len, off_t offset) >> +{ >> +ssize_t nr; >> +if (len > MAX_IO_SIZE) >> +len = MAX_IO_SIZE; > > Odd indentation here. > > -- Hannes Good eyes, even though this is co

[PATCH v2 9/9] sha1_name: add support for @{publish} marks

Signed-off-by: Felipe Contreras --- Documentation/revisions.txt | 4 sha1_name.c | 49 - t/t1508-at-combinations.sh | 5 + 3 files changed, 40 insertions(+), 18 deletions(-) diff --git a/Documentation/revisions.txt b/Documen

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

Signed-off-by: Felipe Contreras --- builtin/branch.c | 17 - t/t6040-tracking-info.sh | 5 +++-- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/builtin/branch.c b/builtin/branch.c index 17773d7..e0a8d0a 100644 --- a/builtin/branch.c +++ b/builtin/branch.c

[PATCH v2 7/9] sha1_name: cleanup interpret_branch_name()

The 'upstream' variable doesn't hold an "upstream", but a branch, so make it clearer. Signed-off-by: Felipe Contreras --- sha1_name.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index 6fca869..906f09d 100644 --- a/sha1_

[PATCH v2 8/9] sha1_name: simplify track finding

It's more efficient to check for the braces first. Signed-off-by: Felipe Contreras --- 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 +++ b/sha1_name.c @@ -417,7 +417,7 @@ stati

[PATCH v2 5/9] push: add --set-publish option

To setup publish tracking branch, like 'git branch --set-publish'. Signed-off-by: Felipe Contreras --- Documentation/git-push.txt | 9 +- builtin/push.c | 2 ++ t/t5529-push-publish.sh| 70 ++ transport.c| 28 +

[PATCH v2 4/9] t: branch add publish branch tests

Signed-off-by: Felipe Contreras --- t/t3200-branch.sh | 76 +++ 1 file changed, 76 insertions(+) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index fcdb867..8cd21d1 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -907,4 +907,80

[PATCH v2 2/9] Add concept of 'publish' branch

The upstream branch is: branch.$name.remote branch.$name.merge The publish branch is: branch.$name.pushremote branch.$name.push Signed-off-by: Felipe Contreras --- builtin/push.c | 19 +++ remote.c | 34 -- remote.h | 4

[PATCH v2 1/9] push: trivial reorganization

Signed-off-by: Felipe Contreras --- builtin/push.c | 35 +++ 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/builtin/push.c b/builtin/push.c index 0e50ddb..d10aefc 100644 --- a/builtin/push.c +++ b/builtin/push.c @@ -155,20 +155,11 @@ static NORETUR

[PATCH v2 3/9] branch: allow configuring the publish branch

Signed-off-by: Felipe Contreras --- Documentation/git-branch.txt | 11 + branch.c | 43 + branch.h | 2 ++ builtin/branch.c | 57 4 files changed, 108 insertio

[PATCH v2 0/9] Introduce publish tracking branch

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 that

Re: Git push race condition?

On Tue, Mar 25, 2014 at 10:57 AM, Jeff King wrote: > On Tue, Mar 25, 2014 at 09:45:20AM -0400, Scott Sandler wrote: > >> Version of git on the server? git version 1.8.3-rc0 > > There was significant work done between v1.8.3 and v1.8.4 on handling > races in the ref code. As I said before, I don't

Re: [PATCH v8 1/2] Add xpread()

Am 10.04.2014 20:54, schrieb Yiannis Marangos: > +ssize_t xpread(int fd, void *buf, size_t len, off_t offset) > +{ > + ssize_t nr; > + if (len > MAX_IO_SIZE) > + len = MAX_IO_SIZE; Odd indentation here. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" i

Re: [PATCH 4/4] refs.c: sort the refs by new_sha1 and merge the two update/delete loops into one

Ronnie Sahlberg writes: > We want to make sure that we update all refs before we delete any refs > so that there is no point in time where the tips may not be reachable > from any ref in the system. > We currently acheive this by first looping over all updates and applying > them before we run a

[PATCH v8 1/2] Add xpread()

xpread() pay attention to EAGAIN/EINTR, so it will resume automatically on interrupted call. Signed-off-by: Yiannis Marangos --- This is actually the 2nd version of this commit but before I emailed it as version 7 because it's a dependency of [PATCH v7 2/2]. Is this the correct way to introduce

Re: [PATCH 0/4] Make update_refs more atomic V2

CC'ing Michael who has been active in this area as an area expert. Ronnie, please make it a habit to run something like $ git shortlog --no-merges --since=18.months ... to help you decide who your series may want to be reviewed by, before sending them. Thanks. Ronnie Sahlberg writes: > r

Re: [PATCH] Add support for commit attributes

On 10.04.2014, at 19:28, Felipe Contreras wrote: > Diego Lago wrote: >> Commit attributes are custom commit extra headers the user can >> add to the commit object. >> >> The motivation for this patch is that in my company we have a custom >> continuous integration software that uses a custom fo

Re: [PATCH v7 1/2] Add xpread() and xpwrite()

On Thu, Apr 10, 2014 at 11:35:42AM -0700, Junio C Hamano wrote: > We do not even use pwrite(); please don't add anything unnecessary > and unexercised, like xpwrite(), as potential bugs in it will go > unnoticed long after its introduction until it first gets used. Correct, my mistake. -- To unsub

[PATCH 0/4] Make update_refs more atomic V2

refs.c:update_refs() 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 after only some of the ref operations have been been updated on the

[PATCH 4/4] refs.c: sort the refs by new_sha1 and merge the two update/delete loops into one

We want to make sure that we update all refs before we delete any refs so that there is no point in time where the tips may not be reachable from any ref in the system. We currently acheive this by first looping over all updates and applying them before we run a second loop and perform all the dele

Re: [PATCH v7 1/2] Add xpread() and xpwrite()

Yiannis Marangos writes: > xpread() and xpwrite() pay attention to EAGAIN/EINTR, so they will resume > automatically on interrupted call. We do not even use pwrite(); please don't add anything unnecessary and unexercised, like xpwrite(), as potential bugs in it will go unnoticed long after its i

[PATCH v7 1/2] Add xpread() and xpwrite()

xpread() and xpwrite() pay attention to EAGAIN/EINTR, so they will resume automatically on interrupted call. Signed-off-by: Yiannis Marangos --- builtin/index-pack.c | 2 +- compat/mmap.c| 4 +--- git-compat-util.h| 2 ++ wrapper.c| 36 +

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

Before we proceed to "opportunistic update" we must verify that the current index file is the same as the one that we read before. There is a possible race if we don't do this. In the example below git-status does "opportunistic update" and git-rebase updates the index, but the race can happen in g

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

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 n

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

During update_refs we will both be deleting refs as well as updating/changing the refs. Since both delete and update now use the same lock/update/commit pattern lock = lock_ref_sha1_basic() (or varient of) write_ref_sha1(lock)/delete_ref_loose(lock) unlock_ref(lock) | commit_ref_lock(l

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

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

RE: [PATCH] Add support for commit attributes

Diego Lago wrote: > Commit attributes are custom commit extra headers the user can > add to the commit object. > > The motivation for this patch is that in my company we have a custom > continuous integration software that uses a custom formatted commit > message (currently in YALM format) to show

Re: [PATCH 17/19] Portable alloca for Git

Erik Faye-Lund writes: >> Subject: [PATCH] mingw: activate alloca >> >> Both MSVC and MINGW have alloca(3) definitions in malloc.h, so by moving >> win32-compat alloca.h from compat/vcbuild/include/ to compat/win32/ , >> which is included by both MSVC and MINGW CFLAGS, we can make alloca() >> wor

Re: [PATCH] Add support for commit attributes

Junio C Hamano writes: > I actually think this "recording information about commits" is > exactly the use-case notes were invented to address, and if it is > found cumbersome to use, the reason why it is cumbersome needs to be > discovered and use of notes needs to be improved. Hooks and/or a >

Re: [PATCH] Add support for commit attributes

Duy Nguyen writes: > If the problem is polluting human eyes, wouldn't it be better to make > git-log to filter it out? For example, we could tell git that all > fields (in the message body) that start with X- are "rubbish", so > instead of showing "X-something: base64 stuff...", it shows > "X-som

Re: [PATCH v5] Verify index file before we opportunistically update it

Duy Nguyen writes: > verify_hdr() is a bit expensive because you need to digest the whole > index file (could big as big as 14MB on webkit). Could we get away > without it? I mean, is it enough that we pick the last 20 bytes and > compare it with istate->sha1? If we only need 20 bytes, pread() ma

[PATCH v6] Verify index file before we opportunistically update it

Before we proceed to "opportunistic update" we must verify that the current index file is the same as the one that we read before. There is a possible race if we don't do this. In the example below git-status does "opportunistic update" and git-rebase updates the index, but the race can happen in g

Re: [PATCH v5] Verify index file before we opportunistically update it

On Thu, Apr 10, 2014 at 05:40:55PM +0700, Duy Nguyen wrote: > verify_hdr() is a bit expensive because you need to digest the whole > index file (could big as big as 14MB on webkit). Could we get away > without it? I mean, is it enough that we pick the last 20 bytes and > compare it with istate->sha

[no subject]

ZasheD

Re: [PATCH v5] Verify index file before we opportunistically update it

On Thu, Apr 10, 2014 at 12:34 PM, Yiannis Marangos wrote: > +/* > + * This function verifies if index_state has the correct sha1 of an index > file. > + * Don't die if we have any other failure, just return 0. > + */ > +static int verify_index_from(const struct index_state *istate, const char >

SUSPECT: General web-mail maintenance

General web-mail maintenance Dear Account Owner, We want to upgrade all email account scheduled for today as part of our duty to strengthen security of your mailbox. CLICK HERE to upgrade your account to Outlook Web Apps 2014. If your settings is not updated today, y

Re: [PATCH] Add support for commit attributes

On Thu, Apr 10, 2014 at 1:27 PM, Diego Lago González wrote: > Writing this data into the message, the user is forced to write it in the > correct format (I think is better to write key=value pairs as an option > instead of writing as message lines with spaces in key, between key and > equal sign a

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

Andrew Ardill writes: > I think it is fair to say that the red version is the one people > recognise as 'git' and so should be kept as the official version. Who is "people"? I never associated anything with it. I had to look at the actual web page to see what people are talking about. It's fa