Re: Implementing reftable in Git

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

Re: Implementing reftable in Git

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

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

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: [RFC PATCH] gpg: add support for gpgsm

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

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

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 >

Re: BUG in git diff-index

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

[RFC PATCH] gpg: add support for gpgsm

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: [PATCH] Disown ssh+git and git+ssh

> > 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: Gsoc 16

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: GSoC 2016: applications open, libgit2 and git.git

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 2016: applications open, deadline = Fri, 19/2

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

[PATCH] Disown ssh+git and git+ssh

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

[PATCH] Disown ssh+git and git+ssh

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

Clarification on the git+ssh and ssh+git schemes

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

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

> 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

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

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"

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

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

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: curl

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

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

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

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

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: Returning error message from custom smart http server

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

Re: GIT, libcurl and GSS-Negotiate

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: [PATCH 2/2] fetch: handle overlaping refspecs on --prune

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

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

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

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

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 0/2] thin-pack capability for send-pack/receive-pack

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

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

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

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

' 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

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

://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

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] send-pack: don't send a thin pack when the server doesn't support it

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] send-pack: don't send a thin pack when the server doesn't support it

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] remote: filter out invalid remote configurations

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] remote: filter out invalid remote configurations

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

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

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

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

Re: Basic git-archive --remote question

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

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

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] pull: fail early if we know we can't merge from upstream

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] Documentation/git-commit: reword the --amend explanation

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

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

. 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

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

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: question re tags

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: Possible regression in ref advertisement

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

Possible regression in ref advertisement

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

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

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

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: Google Summer of Code 2013 (GSoC13)

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

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

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

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

. 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

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

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

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

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: Git ~unusable on slow lines :,'C

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: Bug report

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

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

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

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: checkout extra files

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

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

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

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

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

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

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

-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

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

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 2/3] branch: add --unset-upstream option

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

Re: libgit2 status

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.

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

-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: Git to use XDG Base Directory Standard

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

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

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

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

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

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

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

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: inconsistent logs when displayed on screen / piped to a file

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

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

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: git rebase -i does not rebase if all lines are removed

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 2/3] branch: suggest how to undo a --set-upstream when given one branch

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

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

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

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

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

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

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] branch: add -u as a shortcut for --set-upstream

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