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 th
> 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 use. I don't think it would be wrong to document that
>>> they ex
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 an
se if anybody goes looking for them
in the source code.
Signed-off-by: Carlos Martín Nieto
---
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
transport.c |
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 GSoC at all).
>
On Fri, 2016-02-19 at 09:06 +0100, Matthieu Moy wrote:
> Carlos Martín Nieto 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
> > candidate sele
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
> > active
> > all times Som
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 anybody goes looking for
> them
> i
ose a default for a particular
repository that may need to be occasionally overridden.
Signed-off-by: Carlos Martín Nieto
---
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-compatible ve
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 diff-i
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
>
On Thu, 2016-03-31 at 08:46 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto 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
> > trying
> > t
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 bump
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 first creates a "main" repo
On 23 Nov 2015, at 19:59, Marc Strapetz wrote:
> On 23.11.2015 18:04, Carlos Martín Nieto wrote:
>> Hello Mark,
>>
>> On 23 Nov 2015, at 12:04, Marc Strapetz wrote:
>>
>>> There is a strange "branch --set-upstream-to" failure for "clones&quo
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 implementat
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 for
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
---
Documentation/diff-heuristic-options.txt | 5 -
Documentation/diff-options.txt | 7 ++-
2 files ch
From: Carlos Martín Nieto
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 platform
From: Carlos Martín Nieto
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, introduce a variant
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
> >
> > We need to consider that a remote-tracking branch may match more than
> > one rhs of a fetch refspec. In such a case,
On Thu, 2014-02-27 at 12:19 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto writes:
>
> > From: Carlos Martín Nieto
> >
> > We need to consider that a remote-tracking branch may match more than
> > one rhs of a fetch refspec.
>
> Hmph, do we *need* to, r
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:
> > *
On Mon, 2014-05-19 at 18:12 +1000, Bryan Turner wrote:
> On Sat, May 17, 2014 at 9:01 AM, brian m. carlson
> 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
> >> permissions
> >> a
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 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
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
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
ot;bogus"]
hocus = pocus
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:
On Tue, 2013-08-27 at 07:50 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto writes:
>
> > In remote's configuration callback, anything that looks like
> > 'remote..*' creates a remote ''. This remote may not end
> > up having any configuration
Not every server out there supports fixing thin packs, so let's send
them a full pack.
Signed-off-by: Carlos Martín Nieto
---
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
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
k' in anticipation of the client
toggling the assumption and document this capability when used by
receive-pack.
Signed-off-by: Carlos Martín Nieto
---
Documentation/technical/protocol-capabilities.txt | 20 +++-
builtin/receive-pack.c| 2 +-
2 fil
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
http://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-p
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 c
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 w
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 t
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 e
On Thu, 2015-04-16 at 10:16 -0700, Junio C Hamano wrote:
> Jeff King 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 "s/
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 th
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/a
at
run-time in order to push to it.
Signed-off-by: Carlos Martín Nieto
---
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 +++
remo
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
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 freed.
should be freed. 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
---
Dan Rosén writes:
>
> git branch --set-upstream master origin/
>
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 http://vger.kernel.org/majordomo-inf
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.
Document
iginal patch:
Sorry I keep forgetting lately, it seems I've been away from core git
too long.
Signed-off-by: Carlos Martín Nieto
> > -- >8 --
> > From: Carlos Martín Nieto
> >
> > The explanation for 'git commit --amend' talks about preparing a tree
&
On Thu, 2013-04-04 at 10:04 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto 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,
know whether we have
enough information to merge and can fail immediately otherwise.
Signed-off-by: Carlos Martín Nieto
---
git-pull.sh | 62 -
1 file changed, 45 insertions(+), 17 deletions(-)
I can't quite decide whether the be
On Thu, 2013-04-11 at 10:37 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto 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
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
---
Documentation/git-branch.txt | 5 +
builtin
ng 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):
b
tions allows us 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
---
Documentation/git-branch.txt | 9 -
builtin/branch.c | 17 +++--
t/t3200-
On Mon, 2012-08-20 at 11:50 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto 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
Lanoxx 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 starting at 1.7
ch --set-upstream-to origin/master
Signed-off-by: Carlos Martín Nieto
---
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 clea
Nicolas Sebrecht 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.
>
> Right
Junio C Hamano writes:
> Carlos Martín Nieto 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-u
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> c...@elego.de (Carlos Martín Nieto) writes:
>>
>>> Junio C Hamano writes:
>>>
>>>> Carlos Martín Nieto writes:
>>>>
>>>>> diff --git a/t/t3200-branch.sh b/t/t3200-
w an error 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-t
tions allows us 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
---
Documentation/git-branch.txt | 9 -
builtin/branch.c | 17 +++--
t/t3200-
ch --set-upstream-to origin/master
Signed-off-by: Carlos Martín Nieto
---
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
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
---
Documentation/git-branch.txt | 5 +
builtin
Junio C Hamano writes:
> Carlos Martín Nieto 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.
>>
Ralf Thielow writes:
> On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto 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 indic
Junio C Hamano writes:
> Ralf Thielow writes:
>
>> On Fri, Aug 31, 2012 at 5:22 PM, Carlos Martín Nieto wrote:
>>> Ralf Thielow writes:
>>>
>>>> On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto wrote:
>>>>> behaviour. To work aroun
Angelo Borsotti writes:
> Hello,
>
> the man page of git checkout states:
>
> git checkout [-p|--patch] [] [--] ...
>
> It updates the named paths in the working tree from the index file or
> from a named ...
>
> This means that for each file denoted by pathspec, git tries to
> restore it from t
Angelo Borsotti 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 ...".
>
> In my example, the
Keep it in the list.
Angelo Borsotti 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
>> refers, as alw
, we realise that it's an alias and do the right thing
Signed-off-by: Carlos Martín Nieto
---
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
%
Junio C Hamano writes:
> Carlos Martín Nieto 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
Konstantin Khomoutov writes:
> On Fri, 5 Oct 2012 14:13:49 +0400
> Муковников Михаил 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 12.2.0: Sat Aug 25
>> 00:48:52 PDT 2012; root
Marcel Partap 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 moving.
> U
Marcel Partap 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 to
>
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(
simpler 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 branc
of
git branch --set-upstream origin/master master
git branch --set-upstream-to origin/master
Signed-off-by: Carlos Martín Nieto
---
builtin/branch.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/builtin/branch.c b/builtin/branch.c
index c886fc0..5551227
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.
---
create_branch() uses install_branch_config() which may also set
branch.foo.rebase, so
The existing --set-uptream option can cause confusion, as it uses the
usual branch convention of assuming a starting point of HEAD if none
is specified, causing
git branch --set-upstream origin/master
to create a new local branch 'origin/master' that tracks the current
branch. As --set-upstre
On Tue, 2012-07-10 at 19:20 +0200, Matthieu Moy wrote:
> Carlos Martín Nieto writes:
>
> > --- a/builtin/branch.c
> > +++ b/builtin/branch.c
> > @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const
> > char *prefix)
> >
On Tue, 2012-07-10 at 11:02 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto 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 --uns
On Tue, 2012-07-10 at 10:40 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto 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
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
On Wed, 2012-07-11 at 09:53 -0700, Junio C Hamano wrote:
> Carlos Martín Nieto 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 "
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 li
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 th
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
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
---
This produces suboptimal output in case
Michael Schubert 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
>>
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 betwe
On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto 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
> &
On Mon, 2013-02-25 at 11:27 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto 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
On Mon, 2013-02-25 at 12:07 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto 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?
&g
On Mon, 2013-02-25 at 13:16 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto 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.
> >
>
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 commi
96 matches
Mail list logo
