[PATCH 1/2] fetch: add a failing test for prunning with overlapping refspecs

2014-02-27 Thread Carlos Martín Nieto
From: Carlos Martín Nieto c...@dwim.me When a remote has multiple fetch refspecs and these overlap in the target namespace, fetch may prune a remote-tracking branch which still exists in the remote. The test uses a popular form of this, by putting pull requests as stored in a popular hosting

[PATCH 2/2] fetch: handle overlaping refspecs on --prune

2014-02-27 Thread Carlos Martín Nieto
From: Carlos Martín Nieto c...@dwim.me We need to consider that a remote-tracking branch may match more than one rhs of a fetch refspec. In such a case, it is not enough to stop at the first match but look at all of the matches in order to determine whether a head is stale. To this goal

Re: [PATCH 2/2] fetch: handle overlaping refspecs on --prune

2014-02-27 Thread Carlos Martín Nieto
On Thu, 2014-02-27 at 11:21 +0100, Michael Haggerty wrote: On 02/27/2014 10:00 AM, Carlos Martín Nieto wrote: From: Carlos Martín Nieto c...@dwim.me We need to consider that a remote-tracking branch may match more than one rhs of a fetch refspec. In such a case, it is not enough to stop

Re: [PATCH 2/2] fetch: handle overlaping refspecs on --prune

2014-02-28 Thread Carlos Martín Nieto
On Thu, 2014-02-27 at 12:19 -0800, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: From: Carlos Martín Nieto c...@dwim.me We need to consider that a remote-tracking branch may match more than one rhs of a fetch refspec. Hmph, do we *need* to, really? Do you mean

Re: GIT, libcurl and GSS-Negotiate

2014-05-12 Thread Carlos Martín Nieto
On Sat, 2014-05-10 at 21:01 +, brian m. carlson wrote: On Mon, May 05, 2014 at 12:21:33PM +0200, Ivo Bellin Salarin wrote: Well, I'm on Windows. using `git version 1.9.2.msysgit.0`. You can find all the exchanges, recorded with wireshark, of the following usecases: * git vanilla

Re: Returning error message from custom smart http server

2014-05-19 Thread Carlos Martín Nieto
On Mon, 2014-05-19 at 18:12 +1000, Bryan Turner wrote: On Sat, May 17, 2014 at 9:01 AM, brian m. carlson sand...@crustytoothpaste.net wrote: On Tue, May 13, 2014 at 09:39:59AM +0200, Ákos, Tajti wrote: Dear List, we implemented our own git smart http server to be able to check

[PATCH] branch: make sure the upstream remote is configured

2013-07-26 Thread Carlos Martín Nieto
to push to it. Signed-off-by: Carlos Martín Nieto c...@elego.de --- It's somewhat surprising that there didn't seem to be a way to distinguish named remotes from those created from a command-line path, but I guess nobody needed to. branch.c | 11 +++ remote.h

Re: [PATCH] branch: make sure the upstream remote is configured

2013-07-26 Thread Carlos Martín Nieto
On Fri, 2013-07-26 at 14:43 -0400, Jeff King wrote: On Fri, Jul 26, 2013 at 07:39:37PM +0200, Carlos Martín Nieto wrote: A command of e.g. git push --set-upstream /tmp/t master will call install_branch_config() with a remote name of /tmp/t. This function will set

[PATCH] remote: filter out invalid remote configurations

2013-08-27 Thread Carlos Martín Nieto
will show a remote 'bogus' in the listing, even though it won't work as a remote name for either git-fetch or git-push. Filter out the remotes that we created which have no urls in order to work around such configuration entries. Signed-off-by: Carlos Martín Nieto c...@elego.de --- Due to git's

Re: [PATCH] remote: filter out invalid remote configurations

2013-08-30 Thread Carlos Martín Nieto
On Tue, 2013-08-27 at 07:50 -0700, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: In remote's configuration callback, anything that looks like 'remote.name.*' creates a remote 'name'. This remote may not end up having any configuration for a remote, but it's still

[PATCH 3/3] branch: suggest how to undo a --set-upstream when given one branch

2012-08-20 Thread Carlos Martín Nieto
of git branch --set-upstream origin/master master git branch --set-upstream-to origin/master While we're at it, add a notice that the --set-upstream flag is deprecated and will be removed at some point. Signed-off-by: Carlos Martín Nieto c...@elego.de --- This produces suboptimal output

[PATCH 2/3] branch: add --unset-upstream option

2012-08-20 Thread Carlos Martín Nieto
We have ways of setting the upstream information, but if we want to unset it, we need to resort to modifying the configuration manually. Teach branch an --unset-upstream option that unsets this information. Signed-off-by: Carlos Martín Nieto c...@elego.de --- Documentation/git-branch.txt | 5

[PATCH 0/3] Improve branch UI for setting upstream information

2012-08-20 Thread Carlos Martín Nieto
on which of the behaviours the user wants to have. Using --set-upsteam with one argument now also leads to a message explaining how to undo it. For that, branch has learnt --unset-upstream which will remove the upstream information for the given branch (or HEAD). Carlos Martín Nieto (3): branch

[PATCH 1/3] branch: introduce --set-upstream-to

2012-08-20 Thread Carlos Martín Nieto
to type git branch --set-upstream-to origin/master to set the current branch's upstream to be origin's master. Signed-off-by: Carlos Martín Nieto c...@elego.de --- Documentation/git-branch.txt | 9 - builtin/branch.c | 17 +++-- t/t3200-branch.sh

Re: [PATCH 3/3] branch: suggest how to undo a --set-upstream when given one branch

2012-08-21 Thread Carlos Martín Nieto
On Mon, 2012-08-20 at 11:50 -0700, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: This interface is error prone, and a better one (--set-upstream-to) exists. Suggest how to fix a --set-upstream invocation in case the user only gives one argument, which makes it likely

Re: Git to use XDG Base Directory Standard

2012-08-22 Thread Carlos Martín Nieto
Lanoxx lan...@gmx.net writes: Hi, Git and Gitk are currently using the ~/.gitconfig and ~/.gitk files in the $HOME directory. It would be nice to use the XDG Base Directory standard for the location instead, see [1] and [2]. Are there any plans regarding this standard? Git does this

[PATCHv2 3/3] branch: deprecate --set-upstream and show help if we detect possible mistaken use

2012-08-23 Thread Carlos Martín Nieto
-to origin/master Signed-off-by: Carlos Martín Nieto c...@elego.de --- The 'track' in the message is still not great, but it does fit with the one above. Maybe if we make it say If youw wanted [...] track the remote-tracking branch 'origin/master' it would be clearer? I've simplified and tightened

Re: libgit2 status

2012-08-25 Thread Carlos Martín Nieto
Nicolas Sebrecht nicolas.s@gmx.fr writes: The 25/08/12, Vicent Marti wrote: The development of libgit2 happens 100% in the open. I don't know what commercial entity are you talking about, but there are several companies and independent contributors working on the Library at the moment.

Re: [PATCH 2/3] branch: add --unset-upstream option

2012-08-27 Thread Carlos Martín Nieto
Junio C Hamano gits...@pobox.com writes: Carlos Martín Nieto c...@elego.de writes: diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index e9019ac..93e5d6e 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -383,6 +383,22 @@ test_expect_success 'use --set-upstream-to modify

Re: [PATCH 2/3] branch: add --unset-upstream option

2012-08-27 Thread Carlos Martín Nieto
Junio C Hamano gits...@pobox.com writes: Junio C Hamano gits...@pobox.com writes: c...@elego.de (Carlos Martín Nieto) writes: Junio C Hamano gits...@pobox.com writes: Carlos Martín Nieto c...@elego.de writes: diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index e9019ac..93e5d6e

[PATCHv2 0/3] Improve branch UI for setting upstream information

2012-08-30 Thread Carlos Martín Nieto
message (not it's just if the branch is new and exists as remote-tracking) which I already sent as a reply in the other thread; and making --unset-upstream error out on bad input, which I already mentioned above. cmn Carlos Martín Nieto (3): branch: introduce --set-upstream-to branch: add

[PATCH 3/3] branch: deprecate --set-upstream and show help if we detect possible mistaken use

2012-08-30 Thread Carlos Martín Nieto
-to origin/master Signed-off-by: Carlos Martín Nieto c...@elego.de --- builtin/branch.c | 26 ++ t/t3200-branch.sh | 34 ++ 2 files changed, 60 insertions(+) diff --git a/builtin/branch.c b/builtin/branch.c index 557995d..5e95e35 100644

[PATCH 2/3] branch: add --unset-upstream option

2012-08-30 Thread Carlos Martín Nieto
We have ways of setting the upstream information, but if we want to unset it, we need to resort to modifying the configuration manually. Teach branch an --unset-upstream option that unsets this information. Signed-off-by: Carlos Martín Nieto c...@elego.de --- Documentation/git-branch.txt | 5

Re: [PATCHv2 0/3] Improve branch UI for setting upstream information

2012-08-30 Thread Carlos Martín Nieto
Junio C Hamano gits...@pobox.com writes: Carlos Martín Nieto c...@elego.de writes: As a result of making --unset-upstream fail if the given branch doesn't exist, I discovered a copy-paste error in on the the tests in the patch after it, so I'm resending the whole thing. The changes from

Re: [PATCH 1/3] branch: introduce --set-upstream-to

2012-08-31 Thread Carlos Martín Nieto
Ralf Thielow ralf.thie...@gmail.com writes: On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto c...@elego.de wrote: behaviour. To work around this, introduce --set-upstream-to which accepts a compulsory argument indicating what the new upstream branch should be and one optinal argument

Re: checkout extra files

2012-09-03 Thread Carlos Martín Nieto
Angelo Borsotti angelo.borso...@gmail.com writes: Hello, the man page of git checkout states: git checkout [-p|--patch] [tree-ish] [--] pathspec... It updates the named paths in the working tree from the index file or from a named tree-ish ... This means that for each file denoted by

Re: checkout extra files

2012-09-03 Thread Carlos Martín Nieto
Angelo Borsotti angelo.borso...@gmail.com writes: [please keep it in the list] Hi Carlos, the behavior is quite clear, but the man pages do not describe it properly. The man pages state: It updates the named paths in the working tree from the index file or from a named tree-ish

Re: checkout extra files

2012-09-03 Thread Carlos Martín Nieto
Keep it in the list. Angelo Borsotti angelo.borso...@gmail.com writes: Hi Carlos, That grouping is not what it's saying. It doesn't update the files that exist in the working tree matching some glob. It updates the files in the working tree from either the index or a treeish. The pathspec

[PATCH] run-command: don't try to execute directories

2012-10-02 Thread Carlos Martín Nieto
and do the right thing Signed-off-by: Carlos Martín Nieto c...@elego.de --- This comes from a case in #git. Not sure if this is worth it, or the better solution is just to say no to dirs in $PATH. After writing all of that, I thought to check the shell, and indeed % git-foo zsh: permission

Re: [PATCH] run-command: don't try to execute directories

2012-10-02 Thread Carlos Martín Nieto
Junio C Hamano gits...@pobox.com writes: Carlos Martín Nieto c...@elego.de writes: When looking through $PATH to try to find an external command, locate_in_PATH doesn't check that it's trying to execute a file. Add a check to make sure we won't try to execute a directory. This also stops

Re: Bug report

2012-10-05 Thread Carlos Martín Nieto
Konstantin Khomoutov flatw...@users.sourceforge.net writes: On Fri, 5 Oct 2012 14:13:49 +0400 Муковников Михаил m.mukovni...@gmail.com wrote: There's a problem using git with files having cyrillic 'й' in their name, git just can't track them. uname: Darwin 12.2.0 Darwin Kernel Version

Re: Git ~unusable on slow lines :,'C

2012-10-08 Thread Carlos Martín Nieto
Marcel Partap mpar...@gmx.net writes: Dear Git Devs, I love GIT, but since a couple of months I'm on 3G and after my traffic limit is transcended, things slow down to a feeble 8KiB/s. Jst like back then - things moved somewhat slower. And I'm fine with that - as long as things just keep

Re: Git ~unusable on slow lines :,'C

2012-10-09 Thread Carlos Martín Nieto
Marcel Partap mpar...@gmx.net writes: Bam, the server kicked me off after taking to long to sync my copy. This is unrelated to git. The HTTP server's configuration is too impatient. Yes. How does that mean it is unrelated to git? - git fetch should show the total amount of data it is about

Re: Basic git-archive --remote question

2013-06-25 Thread Carlos Martín Nieto
On Mon, 2013-06-24 at 15:53 -0400, Greg Freemyer wrote: I'm trying to create a tarball from a git tag and I can't get the syntax right. The documentation is not very clear. Can someone help me? == details git v1.8.1.4 The upstream git repo is at: https://github.com/dkovar/analyzeMFT

[PATCH] config: don't segfault when given --path with a missing value

2012-11-13 Thread Carlos Martín Nieto
When given a variable without a value, such as '[section] var' and asking git-config to treat it as a path, git_config_pathname returns an error and doesn't modify its output parameter. show_config assumes that the call is always successful and sets a variable to indicate that vptr should be

[PATCH] config: don't segfault when given --path with a missing value

2012-11-15 Thread Carlos Martín Nieto
. In case of an error however, trying to do this will cause the program to be killed, as it's pointing to memory in the stack. Detect the error and return immediately to avoid freeing or accessing the uninitialed memory in the stack. Signed-off-by: Carlos Martín Nieto c...@elego.de --- On Thu

Re: Inconsistency in messages about --set-upstream from git pull and git branch

2012-12-01 Thread Carlos Martín Nieto
Dan Rosén d...@student.chalmers.se writes: git branch --set-upstream master origin/branch This has been fixed already in 1.8.0.1 cmn -- 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

Re: Google Summer of Code 2013 (GSoC13)

2013-02-21 Thread Carlos Martín Nieto
Michael Schubert s...@schu.io writes: On 02/18/2013 06:42 PM, Jeff King wrote: I will do it again, if people feel strongly about Git being a part of it. However, I have gotten a little soured on the GSoC experience. Not because of anything Google has done; it's a good idea, and I think they

Possible regression in ref advertisement

2013-02-25 Thread Carlos Martín Nieto
Hi all, When testing to see if a different implementation was in shape, I came across something odd where newer git doesn't advertise one of the refs in the git repo. Running `git ls-remote .` or `git-upload-pack` in my git repo, newer git versions omit peeling the v1.8.0-rc3 tag. The diff

Re: Possible regression in ref advertisement

2013-02-25 Thread Carlos Martín Nieto
On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: Hi all, When testing to see if a different implementation was in shape, I came across something odd where newer git doesn't advertise one of the refs in the git repo. Running `git ls

Re: Possible regression in ref advertisement

2013-02-25 Thread Carlos Martín Nieto
On Mon, 2013-02-25 at 11:27 -0800, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote: ... Interesting. git ls-remote . | grep 1.8.0- for maint, master, next and pu produce identical results for me, all showing peeled

Re: Possible regression in ref advertisement

2013-02-25 Thread Carlos Martín Nieto
On Mon, 2013-02-25 at 12:07 -0800, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: A shot in the dark, as I do not seem to be able to reproduce the issue with anything that contains the commit. Perhaps your .git/packed-refs is corrupt? My packed-refs file did not end

Re: Possible regression in ref advertisement

2013-02-26 Thread Carlos Martín Nieto
On Mon, 2013-02-25 at 13:16 -0800, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: As packed-refs file is expected to be a text file, it is not surprising to get an undefined result if the it ends with an incomplete line. I guess that depends on what you mean

Re: question re tags

2013-03-08 Thread Carlos Martín Nieto
On Fri, 2013-03-08 at 15:16 +, John Stean wrote: Ive been tagging some commits using tortoise git , for example with v1.0, v1.1 etc. In tortoise git log the tag sits alongside the commit as I expect. But when I do a git describe it outputs the first tag along with the latest commit. What

Re: [PATCH] branch: add -u as a shortcut for --set-upstream

2012-07-08 Thread Carlos Martín Nieto
On Fri, 2012-07-06 at 10:32 -0500, Jonathan Nieder wrote: Hi Carlos, Carlos Martín Nieto wrote: Add this shortcut just like git-push has it. [...] --- a/builtin/branch.c +++ b/builtin/branch.c @@ -724,7 +724,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix

[PATCH 0/3] A better way of handling upstream information in git-branch

2012-07-10 Thread Carlos Martín Nieto
to remove the whole branch.foo configuration, but that wouldn't be very safe, as we may have more things there (either the future git or some external tool). Carlos Martín Nieto (3): branch: introduce --set-upstream-to branch: suggest how to undo a --set-upstream when given one branch branch: add

[PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

2012-07-10 Thread Carlos Martín Nieto
of git branch --set-upstream origin/master master git branch --set-upstream-to origin/master Signed-off-by: Carlos Martín Nieto c...@elego.de --- builtin/branch.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/builtin/branch.c b/builtin/branch.c index c886fc0

Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

2012-07-11 Thread Carlos Martín Nieto
On Tue, 2012-07-10 at 19:20 +0200, Matthieu Moy wrote: Carlos Martín Nieto c...@elego.de writes: --- a/builtin/branch.c +++ b/builtin/branch.c @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char *prefix) info and making sure new_upstream

Re: [PATCH 3/3] branch: add --unset-upstream option

2012-07-11 Thread Carlos Martín Nieto
On Tue, 2012-07-10 at 11:02 -0700, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: We have ways of setting the upstream information, but if we want to unset it, we need to resort to modifying the configuration manually. Teach branch an --unset-upstream option that unsets

Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

2012-07-11 Thread Carlos Martín Nieto
On Tue, 2012-07-10 at 10:40 -0700, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: This interface is error prone, and a better one (--set-upstream-to) exists. Suggest how to fix a --set-upstream invocation in case the user only gives one argument, which makes it likely

Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

2012-07-11 Thread Carlos Martín Nieto
On Tue, 2012-07-10 at 18:00 -0500, Jonathan Nieder wrote: Junio C Hamano wrote: I think it is better to leave them emitted unconditionally to the standard error stream, in order to train users away from using the old option that

Re: [PATCH 3/3] branch: add --unset-upstream option

2012-07-12 Thread Carlos Martín Nieto
On Wed, 2012-07-11 at 09:53 -0700, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: I've added a bit of code to also remove branch.foo.rebase, which I'd also consider to be part of the upstream information. If git branch -t or git branch --set-upstream took another option

Re: git rebase -i does not rebase if all lines are removed

2012-07-17 Thread Carlos Martín Nieto
On Tue, 2012-07-17 at 13:46 +0300, Orgad and Raizel Shaneh wrote: Make a commit on top of master. git rebase -i origin/master Remove the commit. Git prints Nothing to do and does not rebase. Running 'git rebase -i' when there are no local commits has 'noop' in the first line, and

Re: [PATCH] branch: make --set-upstream saner without an explicit starting point

2012-07-18 Thread Carlos Martín Nieto
On Tue, 2012-07-17 at 22:56 -0700, Junio C Hamano wrote: Ping on a seemingly stalled discussion (no need to rush but just checking). I've implemented the feedback, but been slacking on writing the tests which is what's stopped me from re-sending the series. cmn -- To unsubscribe from

Re: inconsistent logs when displayed on screen / piped to a file

2012-07-30 Thread Carlos Martín Nieto
On Mon, 2012-07-30 at 15:39 +0200, Michael J Gruber wrote: a) probes your terminal for the number of columns and uses all available space. b) goes to a file and has no connected terminal, thus uses a default column number. You can change that number using COLUMNS=YourNumber git log

[PATCH] Documentation/git-commit: reword the --amend explanation

2013-04-03 Thread Carlos Martín Nieto
The explanation for 'git commit --amend' talks about preparing a tree object, which shouldn't be how user-facing documentation talks about commit. Reword it to say it works as usual, but replaces the current commit. --- The current text is from 2006, which I guess explains the wording.

Re: [PATCH] Documentation/git-commit: reword the --amend explanation

2013-04-04 Thread Carlos Martín Nieto
. Signed-off-by: Carlos Martín Nieto c...@elego.de -- 8 -- From: Carlos Martín Nieto c...@elego.de The explanation for 'git commit --amend' talks about preparing a tree object, which shouldn't be how user-facing documentation talks about commit. Reword it to say it works as usual

Re: [PATCH] Documentation/git-commit: reword the --amend explanation

2013-04-05 Thread Carlos Martín Nieto
On Thu, 2013-04-04 at 10:04 -0700, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: On Wed, 2013-04-03 at 23:25 +0100, Philip Oakley wrote: + Replace the tip of the current branch with a fresh commit. [or updated commit, or new commit, or ...] Ack, we should lead

[PATCH] pull: fail early if we know we can't merge from upstream

2013-04-11 Thread Carlos Martín Nieto
have enough information to merge and can fail immediately otherwise. Signed-off-by: Carlos Martín Nieto c...@elego.de --- git-pull.sh | 62 - 1 file changed, 45 insertions(+), 17 deletions(-) I can't quite decide whether the behaviour

Re: [PATCH] pull: fail early if we know we can't merge from upstream

2013-04-12 Thread Carlos Martín Nieto
On Thu, 2013-04-11 at 10:37 -0700, Junio C Hamano wrote: Carlos Martín Nieto c...@elego.de writes: I can't quite decide whether the behaviour of 'git pull' with no upstream configured but a default remote with no fetch refspecs merging the remote's HEAD is a feature, a bug or something

[PATCH] send-pack: don't send a thin pack when the server doesn't support it

2013-10-08 Thread Carlos Martín Nieto
Not every server out there supports fixing thin packs, so let's send them a full pack. Signed-off-by: Carlos Martín Nieto c...@elego.de --- It's not always possible to support thin packs (sometimes there isn't even an object database to grab bases out of). And in any case git shouldn't create

Re: [PATCH] send-pack: don't send a thin pack when the server doesn't support it

2013-10-19 Thread Carlos Martín Nieto
On Tue, 2013-10-08 at 15:22 -0700, Jonathan Nieder wrote: Duy Nguyen wrote: Or maybe it's not that late. How about you go with your patch and add thin-pack capability to receive-pack too? When new git push is used against old server, thin pack is disabled. But that's not a big deal (I

[PATCH 1/2] receive-pack: advertise thin-pack

2013-11-06 Thread Carlos Martín Nieto
' in anticipation of the client toggling the assumption and document this capability when used by receive-pack. Signed-off-by: Carlos Martín Nieto c...@elego.de --- Documentation/technical/protocol-capabilities.txt | 20 +++- builtin/receive-pack.c| 2 +- 2

[PATCH 2/2] send-pack: only send a thin pack if the server supports it

2013-11-06 Thread Carlos Martín Nieto
In combination a the previous patch making receive-pack advertise the thin-pack capability, this allows git to push to a server in a constrained environment which is not able to fix thin packs while taking advantage of the feature for servers which can. Signed-off-by: Carlos Martín Nieto c

[PATCH 0/2] thin-pack capability for send-pack/receive-pack

2013-11-06 Thread Carlos Martín Nieto
://thread.gmane.org/gmane.comp.version-control.git/235766/focus=236402 Carlos Martín Nieto (2): receive-pack: advertise thin-pack send-pack: only send a thin pack if the server supports it Documentation/technical/protocol-capabilities.txt | 20 +++- builtin/receive-pack.c

Re: [PATCH 0/2] thin-pack capability for send-pack/receive-pack

2013-11-06 Thread Carlos Martín Nieto
On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote: I'll queue these for now, but I doubt the wisdom of this series, given that the ship has already sailed long time ago. Currently, no third-party implementation of a receiving end can accept thin push, because thin push is not a

Re: [PATCH 0/2] thin-pack capability for send-pack/receive-pack

2013-11-23 Thread Carlos Martín Nieto
On Wed, 2013-11-06 at 15:42 -0800, Shawn Pearce wrote: On Wed, Nov 6, 2013 at 1:41 PM, Carlos Martín Nieto c...@elego.de wrote: On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote: I'll queue these for now, but I doubt the wisdom of this series, given that the ship has already sailed

[PATCH] send-pack: don't send a thin pack to a server which doesn't support it

2013-11-23 Thread Carlos Martín Nieto
Up to now git has assumed that all servers are able to fix thin packs. This is however not always the case. Document the 'no-thin' capability and prevent send-pack from generating a thin pack if the server advertises it. --- This is a re-roll of the series I sent earlier this month, switching it

Re: [PATCH] send-pack: don't send a thin pack to a server which doesn't support it

2013-11-23 Thread Carlos Martín Nieto
On Sat, 2013-11-23 at 17:07 +0100, Carlos Martín Nieto wrote: Up to now git has assumed that all servers are able to fix thin packs. This is however not always the case. Document the 'no-thin' capability and prevent send-pack from generating a thin pack if the server advertises it. Sorry

Re: curl

2015-04-28 Thread Carlos Martín Nieto
On Tue, 2015-04-28 at 00:57 -0400, Jeff King wrote: On Mon, Apr 27, 2015 at 11:49:51PM -0300, Thiago Farina wrote: Is it right that git uses libcurl to download while libgit2 does without it? I'm not sure if you mean right as in this statement is true or as in is this a good thing that it

Re: [PATCH] dir: allow a BOM at the beginning of exclude files

2015-04-16 Thread Carlos Martín Nieto
On Thu, 2015-04-16 at 17:03 +0200, Johannes Schindelin wrote: Hi Carlos, On 2015-04-16 16:05, Carlos Martín Nieto wrote: Some text editors like Notepad or LibreOffice write an UTF-8 BOM in order to indicate that the file is Unicode text rather than whatever the current locale would

Re: [PATCH] dir: allow a BOM at the beginning of exclude files

2015-04-16 Thread Carlos Martín Nieto
On Thu, 2015-04-16 at 16:05 +0200, Carlos Martín Nieto wrote: Some text editors like Notepad or LibreOffice write an UTF-8 BOM in order to indicate that the file is Unicode text rather than whatever the current locale would indicate. If someone uses such an editor to edit a gitignore file

[PATCH] dir: allow a BOM at the beginning of exclude files

2015-04-16 Thread Carlos Martín Nieto
Some text editors like Notepad or LibreOffice write an UTF-8 BOM in order to indicate that the file is Unicode text rather than whatever the current locale would indicate. If someone uses such an editor to edit a gitignore file, we are left with those three bytes at the beginning of the file. If

Re: [PATCH] dir: allow a BOM at the beginning of exclude files

2015-04-16 Thread Carlos Martín Nieto
On Thu, 2015-04-16 at 10:16 -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Thu, Apr 16, 2015 at 08:39:55AM -0700, Junio C Hamano wrote: test_expect_success 'status untracked directory with --ignored' ' echo ignored .gitignore +sed -e

Re: [PATCH v2 40/43] refs: allow ref backend to be set for clone

2015-10-12 Thread Carlos Martín Nieto
On Tue, 2015-10-06 at 14:09 -0400, David Turner wrote: > On Mon, 2015-10-05 at 21:58 -0400, Jeff King wrote: > > On Mon, Oct 05, 2015 at 09:29:37PM -0400, David Turner wrote: > > > > > > Therefore, I don't think this can be merged without a bump to > > > > core.repositoryformatversion. Such a

Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

2015-11-24 Thread Carlos Martín Nieto
On 23 Nov 2015, at 19:59, Marc Strapetz <marc.strap...@syntevo.com> wrote: > On 23.11.2015 18:04, Carlos Martín Nieto wrote: >> Hello Mark, >> >> On 23 Nov 2015, at 12:04, Marc Strapetz <marc.strap...@syntevo.com> wrote: >> >>> There is a strang

Re: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

2015-11-23 Thread Carlos Martín Nieto
Hello Mark, On 23 Nov 2015, at 12:04, Marc Strapetz wrote: > There is a strange "branch --set-upstream-to" failure for "clones" which > haven't been created using "git clone" but constructed using "git init", "git > remote add" and "git fetch". > > Following script

Clarification on the git+ssh and ssh+git schemes

2016-02-05 Thread Carlos Martín Nieto
Hello gits, git supports using git+ssh:// and ssh+git:// instead of ssh:// or the rsync-style format. The first two are however not documented in the git-clone manage as acceptable protocols (which is what I think of as the canonical source for what you can use). There are tests to make sure

[PATCH] Disown ssh+git and git+ssh

2016-02-12 Thread Carlos Martín Nieto
These were silly from the beginning, but we have to support them for compatibility. That doesn't mean we have to show them in the documentation. These were already left out of the main list, but a reference in the main manpage was left, so remove that. Also add a note to discourage their use if

Re: Clarification on the git+ssh and ssh+git schemes

2016-02-05 Thread Carlos Martín Nieto
> On 05 Feb 2016, at 14:11, Junio C Hamano wrote: > > Linus Torvalds writes: > >> On Fri, Feb 5, 2016 at 11:30 AM, Jeff King wrote: >>> >>> I suspect they were not really documented because nobody wanted to >>> encourage their

[PATCH] Disown ssh+git and git+ssh

2016-02-15 Thread Carlos Martín Nieto
if anybody goes looking for them in the source code. Signed-off-by: Carlos Martín Nieto <c...@dwim.me> --- I've updated the wording, so we talk about different ways of spelling ssh rather than talking about schemes. Documentation/git.txt | 2 +- connect.c | 4 trans

Re: GSoC 2016: applications open, deadline = Fri, 19/2

2016-02-18 Thread Carlos Martín Nieto
On Wed, 2016-02-17 at 13:33 -0800, Junio C Hamano wrote: > Jeff King writes: > > > On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote: > > > > > > I am wondering if we heard from libgit2 folks if they want us > > > > to > > > > host them (or they want to participate in

Re: GSoC 2016: applications open, libgit2 and git.git

2016-02-19 Thread Carlos Martín Nieto
On Fri, 2016-02-19 at 09:06 +0100, Matthieu Moy wrote: > Carlos Martín Nieto <c...@dwim.me> writes: > > > We still have most of the same things open as for the 2014 list. > > I'll > > ask around to see if we have. Last year I wasn't involved in the > > candi

Re: Gsoc 16

2016-03-19 Thread Carlos Martín Nieto
On Tue, 2016-03-15 at 14:33 -0700, Stefan Beller wrote: > On Tue, Mar 15, 2016 at 2:23 PM, Pranit Bauva > wrote: > > > > Hey, > > > > Open Source projects run because of people who contribute in their > > free time (mainly). It might not be possible for someone to be >

Re: [PATCH] Disown ssh+git and git+ssh

2016-03-24 Thread Carlos Martín Nieto
> > making them seem overly important. > I've been waiting for an update for it but got tired of it. > Instead of discarding the topic, let's amend it like so: Sorry, I missed the call for the rewording. The below looks good to me. Thanks. > > -- >8 -- > From: Carlos Martín Nieto

Re: [RFC PATCH] gpg: add support for gpgsm

2016-03-31 Thread Carlos Martín Nieto
On Thu, 2016-03-31 at 08:46 -0700, Junio C Hamano wrote: > Carlos Martín Nieto <c...@dwim.me> writes: > > > > > Detect the gpgsm block header and run this command instead of gpg. > > On the signing side, ask gpgsm if it knows the signing key we're > > tr

[RFC PATCH] gpg: add support for gpgsm

2016-03-31 Thread Carlos Martín Nieto
a default for a particular repository that may need to be occasionally overridden. Signed-off-by: Carlos Martín Nieto <c...@dwim.me> --- Out there in the so-called "real world", companies like using X509 to sign things. Currently you can set 'gpg.program' to gpgsm to get gpg-compati

Re: BUG in git diff-index

2016-03-31 Thread Carlos Martín Nieto
On Thu, 2016-03-31 at 12:39 +, Andy Lowry wrote: > Following transcript illustrates what I believe to be a bug in git > diff- > index. The session used a git built from latest source, located in  > /tmp/git/git. > > 1. New repo, create empty file A, commit changes. > 2. touch A > 3. git

Re: [RFC PATCH] gpg: add support for gpgsm

2016-03-31 Thread Carlos Martín Nieto
On Thu, 2016-03-31 at 10:22 -0400, Jeff King wrote: > On Thu, Mar 31, 2016 at 03:51:44PM +0200, Carlos Martín Nieto wrote: > > > > > Detect the gpgsm block header and run this command instead of gpg. > This part makes sense to me, and is a strict improvement (though >

[PATCH] diff: --indent-heuristic is no longer experimental

2017-10-29 Thread Carlos Martín Nieto
This heuristic has been the default since 2.14 so we should not confuse our users by saying that it's experimental and off by default. Signed-off-by: Carlos Martín Nieto <c...@dwim.me> --- Documentation/diff-heuristic-options.txt | 5 - Documentation/diff-options.txt | 7

Re: Implementing reftable in Git

2018-05-09 Thread Carlos Martín Nieto
Hi all, On Wed, 2018-05-09 at 09:48 -0700, Jonathan Nieder wrote: > Hi, > > Christian Couder wrote: > > > I might start working on implementing reftable in Git soon. > > Yay! > > [...] > > So I think the most straightforward and compatible way to do it would > > be to port the JGit

Re: Implementing reftable in Git

2018-05-09 Thread Carlos Martín Nieto
On Wed, 2018-05-09 at 10:54 -0700, Jonathan Nieder wrote: > Carlos Martín Nieto wrote: > > On Wed, 2018-05-09 at 09:48 -0700, Jonathan Nieder wrote: > > > If you would like the patches at https://git.eclipse.org/r/q/topi > > > c:reftable > > > relicensed