[PATCH] git-svn.txt: Remove mentions of repack options

Git no longer seems to use these flags or their associated config keys; when they are present, git-svn outputs a message indicating that they are being ignored. Signed-off-by: Lawrence Velázquez --- Documentation/git-svn.txt | 15 --- 1 file changed, 15 deletions(-) diff --git a/Doc

Re: [PATCH 22/32] checkout: support checking out into a new working directory

On Tue, Sep 02, 2014 at 10:51:47AM -0400, Marc Branchaud wrote: > MULTIPLE WORKING TREES > -- > > A git repository can support multiple working trees, allowing you to check > out more than one branch at a time. With `git checkout --to` a new working > tree is associated with t

Re: [PATCH 18/18] signed push: final protocol update

On Thu, Sep 4, 2014 at 4:57 PM, Junio C Hamano wrote: > Shawn Pearce writes: > >> As you know, the stateless HTTP thing doesn't allow the nonce on the >> server to be carried from the initial ref advertisement into the final >> receive-pack. We would either need to write the nonce to disk and loa

Re: [RFC PATCHv2 1/2] am: add gitk patch format

(added back git ml because I accidentally dropped the Cc when replying to Junio). On Fri, Sep 5, 2014 at 10:57 AM, Junio C Hamano wrote: >>> I doubt that a patchset that does >>> not update mailinfo and mailsplit to extract information and to undo >>> the indentation could be a right solution. >>

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

On Fri, Sep 5, 2014 at 12:14 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Duy Nguyen writes: >> >>> On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano wrote: * nd/multiple-work-trees (2014-07-29) 39 commits Reroll posted, but haven't picked up yet. How would this interac

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

On Thu, Sep 4, 2014 at 11:51 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano wrote: >>> * nd/multiple-work-trees (2014-07-29) 39 commits >>> >>> Reroll posted, but haven't picked up yet. How would this interact >>> with rr/transaction series

Re: git format-patch --in-reply-to allows header injection. Intended?

Niklas Hambüchen writes: > On 04/09/14 23:36, Junio C Hamano wrote: >> While I do not think of a reason to specify such a string to the >> in-reply-to option (I'd rather edit the output in the editor if I >> wanted to do anything fancy [*1*]), I do not think there is a reason >> why you want to a

Re: [PATCH 18/18] signed push: final protocol update

Shawn Pearce writes: > As you know, the stateless HTTP thing doesn't allow the nonce on the > server to be carried from the initial ref advertisement into the final > receive-pack. We would either need to write the nonce to disk and load > it back up later (ick), or use some sort of stateless non

Re: [RFC PATCHv2 1/2] am: add gitk patch format

Hi Junio, On Fri, Sep 5, 2014 at 5:21 AM, Junio C Hamano wrote: > Chris Packham writes: > >> Another thing that I've since realised is that this 'gitk' format is >> also what you've get from git show or git log -p. So this is actually >> allowing (for better or worse) things like 'git show $sha1

Re: Interactive staging not functioning properly?

Sorry, I just realized that when the hunks are across file boundaries, it won't go back to it. I think this is a bit misleading, it would be great to see it go back to the ACTUAL previous hunk, regardless of which file it came from. On Thu, Sep 4, 2014 at 4:54 PM, Robert Dailey wrote: > I run the

Interactive staging not functioning properly?

I run the following: $ git add -p I skip the first hunk by typing "n". At the next hunk, I try "k" and "K". In both cases, it shows me the same hunk I'm on again and says "No previous hunk". Is this intended behavior? I expect to be taken back to the previous hunk that I did not stage. Running

Re: git format-patch --in-reply-to allows header injection. Intended?

On 04/09/14 23:36, Junio C Hamano wrote: > While I do not think of a reason to specify such a string to the > in-reply-to option (I'd rather edit the output in the editor if I > wanted to do anything fancy [*1*]), I do not think there is a reason > why you want to add a code to forbid such use, eit

Re: GSoC 2014 retrospective (Git Config API Improvements)

Tanay Abhra writes: > GSoC Experience > --- > ... > Conclusion > -- > > So a great summer comes to an end. Hopefully I would still be part of > Git's community > and will continue working on it to improve it. I like to thank my > mentors for being patient > with me and helping

Re: git format-patch --in-reply-to allows header injection. Intended?

Niklas Hambüchen writes: > For example, if you pass "--in-reply-to=\nTo: (notice lack of trailing `>`), then the generated email will actually > contain a > To: > header. While I do not think of a reason to specify such a string to the in-reply-to option (I'd rather edit the output in the ed

[PATCH v2] setup.c: set workdir when gitdir is not default

When gitfile is used, git sets GIT_DIR environment variable for subsequent commands, and that commands start working in mode "GIT_DIR set, workdir current", which is incorrect for the case when git runs from subdirectory of repository. This can be observed at least for running aliases - git fails w

git format-patch --in-reply-to allows header injection. Intended?

Hi, I just wanted to ask if the --in-reply-to flag of git format-patch is supposed to write the given string unmodified into the email or whether it ought to perform some check against header injection. For example, if you pass "--in-reply-to=\nTo: `), then the generated email will actually conta

Re: [PATCH v3 20/21] signed push: add "pushee" header to push certificate

On Thu, Sep 4, 2014 at 1:04 PM, Junio C Hamano wrote: > Record the URL of the intended recipient for a push (after > anonymizing it if it has authentication material) on a new "pushee > URL" header. Because the networking configuration (SSH-tunnels, > proxies, etc.) on the pushing user's side var

Re: Configurable filename for what is now .gitignore

I see, tnx for the pointer. Would inclusion of this patch be viable option then? Patch below, it is possible to look at it here to: Patch: https://github.com/teonsystems/git/commit/27449825ff4d7bb3eecb5a3e32692aaf1ab1a026 Branch: https://github.com/teonsystems/git/commits/feature/configurable

[PATCH v3 20/21] signed push: add "pushee" header to push certificate

Record the URL of the intended recipient for a push (after anonymizing it if it has authentication material) on a new "pushee URL" header. Because the networking configuration (SSH-tunnels, proxies, etc.) on the pushing user's side varies, the receiving repository may not know the single canonical

[PATCH v3 15/21] pack-protocol doc: typofix for PKT-LINE

Everywhere else we use PKT-LINE to denote the pkt-line formatted data, but "shallow/deepen" messages are described with PKT_LINE(). Fix them. Signed-off-by: Junio C Hamano --- Documentation/technical/pack-protocol.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Docum

[PATCH v3 21/21] signed push: fortify against replay attacks

In order to prevent a valid push certificate for pushing into an repository from getting replayed to push to an unrelated one, send a nonce string from the receive-pack process and have the signer include it in the push certificate. The original nonce is exported as GIT_PUSH_CERT_NONCE for the hoo

[PATCH v3 06/21] send-pack: refactor decision to send update per ref

A new helper function ref_update_to_be_sent() decides for each ref if the update is to be sent based on the status previously set by set_ref_status_for_push() and also if this is a mirrored push. Signed-off-by: Junio C Hamano --- send-pack.c | 36 +--- 1 file chan

[PATCH v3 07/21] send-pack: always send capabilities

We tried to avoid sending one extra byte, NUL and nothing behind it to signal there is no protocol capabilities being sent, on the first command packet on the wire, but it just made the code look ugly. Signed-off-by: Junio C Hamano --- send-pack.c | 4 +--- 1 file changed, 1 insertion(+), 3 dele

[PATCH v3 19/21] signed push: remove duplicated protocol info

With the interim protocol, we used to send the update commands even though we already send a signed copy of the same information when push certificate is in use. Update the send-pack/receive-pack pair not to do so. The notable thing on the receive-pack side is that it makes sure that there is no

[PATCH v3 12/21] send-pack: clarify that cmds_sent is a boolean

We use it to make sure that the feature request is sent only once on the very first request packet (ignoring the "shallow " line, which was an unfortunate mistake we cannot retroactively fix with existing receive-pack already deployed in the field) and we set it to "true" with cmds_sent++, not beca

[PATCH v3 13/21] gpg-interface: move parse_gpg_output() to where it should be

Earlier, ffb6d7d5 (Move commit GPG signature verification to commit.c, 2013-03-31) moved this helper that used to be in pretty.c (i.e. the output code path) to commit.c for better reusability. It was a good first step in the right direction, but still suffers a myopic view that commits will be the

[PATCH v3 17/21] receive-pack: GPG-validate push certificates

Reusing the GPG signature check helpers we already have, verify the signature in receive-pack and give the results to the hooks via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment variables. Policy decisions, such as accepting or rejecting a good signature by a key that is not fully trusted, is left

[PATCH v3 11/21] send-pack: refactor inspecting and resetting status and sending commands

The main loop over remote_refs list inspects the ref status to see if we need to generate pack data (i.e. a delete-only push does not need to send any additional data), resets it to "expecting the status report" state, and formats the actual update commands to be sent. Split the former two out of

[PATCH v3 16/21] push: the beginning of "git push --signed"

While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particular branch. My signing v2.0.1 tag only means I want to call the version v2.0.1, and it d

[PATCH v3 09/21] receive-pack: factor out capability string generation

Similar to the previous one for send-pack, make it easier and cleaner to add to capability advertisement. Signed-off-by: Junio C Hamano --- builtin/receive-pack.c | 22 ++ 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/builtin/receive-pack.c b/builtin/receive-

[PATCH v3 14/21] gpg-interface: move parse_signature() to where it should be

Our signed-tag objects set the standard format used by Git to store GPG-signed payload (i.e. the payload followed by its detached signature), and it made sense to have a helper to find the boundary between the payload and its signature in tag.c back then. Newer code added later to parse other kind

[PATCH v3 08/21] send-pack: factor out capability string generation

A run of 'var ? " var" : ""' fed to a long printf string in a deeply nested block was hard to read. Move it outside the loop and format it into a strbuf. As an added bonus, the trick to add "agent=" by using two conditionals is replaced by a more readable version. Signed-off-by: Junio C Hamano

[PATCH v3 18/21] send-pack: send feature request on push-cert packet

We would want to update the interim protocol so that we do not send the usual update commands when the push certificate feature is in use, as the same information is in the certificate. Once that happens, the push-cert packet may become the only protocol command, but then there is no packet to put

[PATCH v3 10/21] send-pack: rename "new_refs" to "need_pack_data"

The variable counts how many non-deleting command is being sent, but is only checked with 0-ness to decide if we need to send the pack data. Signed-off-by: Junio C Hamano --- send-pack.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/send-pack.c b/send-pack.c index c1

[PATCH v3 03/21] receive-pack: do not reuse old_sha1[] for other things

This piece of code reads object names of shallow boundaries, not old_sha1[], i.e. the current value the ref points at, which is to be replaced by what is in new_sha1[]. Signed-off-by: Junio C Hamano --- builtin/receive-pack.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --

[PATCH v3 05/21] send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher

20e8b465 (refactor ref status logic for pushing, 2010-01-08) restructured the code to set status for each ref to be pushed, but did not quite go far enough. We inspect the status set earlier by set_refs_status_for_push() and then perform yet another update to the status of a ref with an otherwise

[PATCH v3 00/21] Signed push

The first round is found at $gmane/255520. The second round is found at $gmane/255701. While signed tags and commits assert that the objects thusly signed came from you, who signed these objects, there is not a good way to assert that you wanted to have a particular object at the tip of a particul

[PATCH v3 04/21] receive-pack: factor out queueing of command

Make a helper function to accept a line of a protocol message and queue an update command out of the code from read_head_info(). Signed-off-by: Junio C Hamano --- builtin/receive-pack.c | 50 +- 1 file changed, 29 insertions(+), 21 deletions(-) di

[PATCH v3 01/21] receive-pack: do not overallocate command structure

An "update" command in the protocol exchange consists of 40-hex old object name, SP, 40-hex new object name, SP, and a refname, but the first instance is further followed by a NUL with feature requests. The command structure, which has a flex-array member that stores the refname at the end, was al

[PATCH v3 02/21] receive-pack: parse feature request a bit earlier

Ideally, we should have also allowed the first "shallow" to carry the feature request trailer, but that is water under the bridge now. This makes the next step to factor out the queuing of commands easier to review. Signed-off-by: Junio C Hamano --- builtin/receive-pack.c | 26 ++---

GSoC 2014 retrospective (Git Config API Improvements)

GSoC 2014 retrospective (Git Config API Improvements) - GSoC (Google Summer Of Code) 2014 ended on 18th August. I was one of three students that Git chose under GSoC 2014. My mentors were Matthieu Moy and Ramkumar Ramachandra. My project was Git

Re: [BUG (maybe)] git rev-parse --verify --quiet isn't quiet

Junio C Hamano writes: > I would suspect that this may be fine. > > "rev-parse --verify" makes sure the named object exists, but in this > case @{u} does not even name any object, does it? Hmph, but "rev-parse --verify no-such-branch" does *not* name any object, we would want to see it barf, and

Re: [PATCH] parse-options: detect attempt to add a duplicate short option name

It is easy to overlook an already assigned single-letter option name and try to use it for a new one. Help the developer to catch it before such a mistake escapes the lab. This retroactively forbids any short option name (which is defined to be of type "int") outside the ASCII printable range. W

Re: [BUG (maybe)] git rev-parse --verify --quiet isn't quiet

Øystein Walle writes: > I noticed this while writing a small script for myself: > > $ git rev-parse --verify --quiet '@{u}' > fatal: No upstream configured for branch 'local' > > The functions that get run when rev-parse does its thing all return a > pointer to a strbuf, return the length

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

Junio C Hamano writes: > You can see the interactions by checking > > $ git show 'pu^{/^Merge branch .nd/multi}' refs.c Here is how it may look like. Merge branch 'nd/multiple-work-trees' into pu diff --cc refs.c index b50b329,00b2312..f04d934 --- a/refs.c +++ b/refs.c @@@ -1359,34 -15

Re: [PATCH] parse-options: detect attempt to add a duplicate short option name

René Scharfe writes: >> Not quite, as an opt with long name is reported with the long name >> only, which is not very nice when the problem we are reporting is >> about its short variant. > > Perhaps something like the patch below helps, here and in general? Excellent. Not just this particular

Re: [RFC PATCHv2 1/2] am: add gitk patch format

Chris Packham writes: > Another thing that I've since realised is that this 'gitk' format is > also what you've get from git show or git log -p. So this is actually > allowing (for better or worse) things like 'git show $sha1 | git am > --patch-format=gitk'[*1*]. That may mean that we should call

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

Junio C Hamano writes: > Duy Nguyen writes: > >> On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano wrote: >>> * nd/multiple-work-trees (2014-07-29) 39 commits >>> >>> Reroll posted, but haven't picked up yet. How would this interact >>> with rr/transaction series which is pretty much all about

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

Duy Nguyen writes: > On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano wrote: >> * nd/multiple-work-trees (2014-07-29) 39 commits >> >> Reroll posted, but haven't picked up yet. How would this interact >> with rr/transaction series which is pretty much all about the refs? > > Haven't checked out

Git submodule add with branch and depth option

Hi, I am trying to add a submodule using the following command: $ git submodule add -b gcc-4_9-branch --depth 1 https://github.com/gcc-mirror/gcc.git src As you can see, I am trying to clone a single commit from the 'gcc-4_9-branch' branch, and avoid downloading the entire history of that branch

Re: [PATCH] setup.c: set workdir when gitdir is not default

On Thu, Sep 04, 2014 at 06:44:08AM -0400, Eric Sunshine wrote: > > + mkdir -p subdir && > > + cd subdir && > > + git testalias > > If a new test is added following this one, it will be run from within > 'subdir', which might come as a surprise as the author of the new > test. Wra

Re: [PATCH] setup.c: set workdir when gitdir is not default

On Thu, Sep 04, 2014 at 05:53:34PM +0700, Duy Nguyen wrote: > On Thu, Sep 4, 2014 at 5:42 AM, Max Kirillov wrote: >> /* #0, #1, #5, #8, #9, #12, #13 */ >> set_git_work_tree("."); > > I wonder if we should setenv(GIT_WORK_TREE_) from inside this function > instead. A quick glance o

Re: [PATCH 22/32] checkout: support checking out into a new working directory

On Wed, Sep 3, 2014 at 12:33 AM, Junio C Hamano wrote: > Marc Branchaud writes: > >> On 14-09-02 08:27 AM, Duy Nguyen wrote: >>> After reading this "multiple checkout mode" in git-checkout.txt, I'm >>> tempted to rewrite it like this. I think the example makes it clearer >>> what I mean. If nobod

Re: [PATCH] gc --auto: do not run 'pack-refs' and 'reflog expire' twice

On Wed, Sep 3, 2014 at 2:16 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Nguyễn Thái Ngọc Duy writes: >> >>> In the --auto code path, gc_before_repack() is called once in parent >>> process then again in the forked process. Stop the second run. >> >> Hmph. Is the true reason why thi

HELP-DESK!!

520MB 520MB Quota mail size 97.9% Your password will expires TODAY CLICK-HERE-TO-ACTIVATE your email account for 2014: to validate your E-mail. Thanks System Administrator MAILBOX PORTAL -- To unsubscribe from this list: send the line "unsubscribe git" in th

[PATCH] fix calloc() and xcalloc() argument ordering

@number first, @size second argument. Signed-off-by: Arjun Sreedharan --- builtin/for-each-ref.c | 2 +- imap-send.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c index 47bd624..69bba06 100644 --- a/builtin/for-e

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

On Wed, Sep 3, 2014 at 5:06 AM, Junio C Hamano wrote: > * nd/multiple-work-trees (2014-07-29) 39 commits > > Reroll posted, but haven't picked up yet. How would this interact > with rr/transaction series which is pretty much all about the refs? Haven't checked out that topic yet. But ref chang

[PATCH] archive: support filtering paths with glob

This patch fixes two problems with using :(glob) (or even "*.c" without ":(glob)"). The first one is we forgot to turn on the 'recursive' flag in struct pathspec. Without that, tree_entry_interesting() will not mark potential directories "interesting" so that it can confirm whether those directori

Re: Can git detect and manage source file's extensional attribute by command 'setfattr' ?

On Thu, Sep 04, 2014 at 04:11:06PM +0800, wangfeng wangfeng wrote: > Hi , > I know that git can cope with file's chmod. But how about > setfattr? I have tried to set some extensional attribute with command > : > > setfattr -n user.t1 -v 1 testfile.txt > > It seems like git cannot dete

Re: Importing from RTC to GIT

On Wed, Sep 03, 2014 at 12:22:20PM -0600, Jeremy Davis wrote: > We really need to preserve the version history of all artifacts and > wanted to see if there is an import utility available to do this.  If > not, we can go through and import off of our milestone baselines in > separate workspaces but

[BUG (maybe)] git rev-parse --verify --quiet isn't quiet

Hi, I noticed this while writing a small script for myself: $ git rev-parse --verify --quiet '@{u}' fatal: No upstream configured for branch 'local' The functions that get run when rev-parse does its thing all return a pointer to a strbuf, return the length of the modified buf or somethi

Re: [PATCH] setup.c: set workdir when gitdir is not default

On Thu, Sep 4, 2014 at 5:42 AM, Max Kirillov wrote: > diff --git a/setup.c b/setup.c > index 0a22f8b..bcf4e31 100644 > --- a/setup.c > +++ b/setup.c > @@ -508,8 +508,10 @@ static const char *setup_discovered_git_dir(const char > *gitdir, > > /* #0, #1, #5, #8, #9, #12, #13 */ > se

Re: [PATCH] setup.c: set workdir when gitdir is not default

On Wed, Sep 3, 2014 at 6:42 PM, Max Kirillov wrote: > When gitfile is used, git sets GIT_DIR environment variable for > subsequent commands, and that commands start working in mode "GIT_DIR > set, workdir current", which is incorrect for the case when git runs > from subdirectory of repository. Th

Re: [RFC/PATCH 2/3] revert/cherry-pick: Add --no-verify option, and pass it on to commit

On Wed, Sep 3, 2014 at 9:32 PM, Junio C Hamano wrote: > Johan Herland writes: >> diff --git a/builtin/revert.c b/builtin/revert.c >> index f9ed5bd..831c2cd 100644 >> --- a/builtin/revert.c >> +++ b/builtin/revert.c >> @@ -91,6 +91,7 @@ static void parse_args(int argc, const char **argv, struct >

Can git detect and manage source file's extensional attribute by command 'setfattr' ?

Hi , I know that git can cope with file's chmod. But how about setfattr? I have tried to set some extensional attribute with command : setfattr -n user.t1 -v 1 testfile.txt It seems like git cannot detect it. So do I need some config option for git? Or doesn't it have this feature?

Re: Next Git conference or meeting

It would be nice however for the 10th anniversary having a new "Git-Together" again as the old times at Google's in Mountain View CA. Paris however is an attractive option for me personally (2h train from my doorstep), better than Seattle for sure ;-) Luca. On 3 Sep 2014, at 21:59, Jeff King w