* [ANNOUNCE] Gitbuilder 0.2.0 is released
From: Avery Pennarun @ 2008-10-29 18:37 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I'd like to announce the new v0.2.0 release of gitbuilder, an
auto-bisecting autobuilder tool for git-based projects. The new
version incorporates several suggestions from end users, including:
- a new bar at the top shows the most recent builds and their status
- the RSS link is now more obvious
- non-fatal warnings now turn your build yellow instead of green
- we now count and report warnings, errors, and test failures separately
- a new changelog script can email recent changes in your repo on a
daily/weekly schedule
You can see some running gitbuilder examples (including one that
tracks git.git) here:
http://versabanq.com/demo/build/
And you can download the source code (in perl+shell) here:
http://github.com/apenwarr/gitbuilder/
Enjoy!
Have fun,
Avery
^ permalink raw reply
* Re: [VOTE] git versus mercurial
From: Shawn O. Pearce @ 2008-10-29 19:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: walt, git
In-Reply-To: <alpine.DEB.1.00.0810281445190.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 28 Oct 2008, walt wrote:
>
> > walt wrote:
> > > No, no, I'm not the one calling for a vote. You old-timers here will
> > > know the name Matt Dillon, who is leading the dragonflybsd project
> > > (www.dragonflybsd.org).
> > >
> > > Matt is the one who is calling for the vote in his thread "Vote for
> > > your source control system" in the dragonfly.kernel group, accessible
> > > via nntp://nntp.dragonflybsd.org...
> >
> > The official vote was 19 to 19, plus one for perforce and one for svn.
> > Matt has proposed a primary git repository and a mirror in hg, and
> > that's being debated now.
FWIW at the Google Summer of Code Mentor Summit this past weekend
we had a "Git vs. Hg" talk with both Git and Hg represented by
contributors to each project.
Slides are online here:
http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Johannes Schindelin @ 2008-10-29 19:23 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: David Symonds, git, gitster, Jeff King
In-Reply-To: <E4E10B61-FA92-417C-9046-F9DE3B48C2A6@wincent.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 799 bytes --]
Hi,
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
> El 29/10/2008, a las 18:03, Johannes Schindelin escribió:
>
> >On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
> >
> > >Git already has too many commands. Adding more is not going to clear
> > >up newbie confusion, and will only waste time because people will
> > >complain about it and ask why there is this kind of duplication.
> >
> >I completely disagree. If the existing set of commands causes
> >confusion, we need to deprecate those parts and add new commands.
> >Even if we have a ton of commands already.
>
> The confusion isn't at the command level; it's at the switch/option
> level. The solution isn't to add a new command.
Seems that at leat one guy who does Git training disagrees with you, _in
addition_ to me.
Ciao,
Dscho
^ permalink raw reply
* A typesetting problem with git man pages
From: Teemu Likonen @ 2008-10-29 19:16 UTC (permalink / raw)
To: git
I compile git and its man pages myself and I just noticed that the man
pages (invoked with "git help log", for example) have a typesetting
problem. There are ".ft" commands here and there, like this:
.ft C
[i18n]
commitencoding = ISO-8859-1
.ft
Does anybody know why "man" prints those ".ft" commands? The
corresponding code in git-log.1 file is this:
\&.ft C
[i18n]
commitencoding = ISO\-8859\-1
\&.ft
Recently I upgraded my system from Debian 4.0 (Etch) to 5.0 (Lenny) and
it is possible that some tools which are related to compiling the man
pages are now newer versions.
^ permalink raw reply
* Re: A typesetting problem with git man pages
From: Jonas Fonseca @ 2008-10-29 19:35 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <87skqfus7v.fsf@iki.fi>
On Wed, Oct 29, 2008 at 20:16, Teemu Likonen <tlikonen@iki.fi> wrote:
> Does anybody know why "man" prints those ".ft" commands? The
> corresponding code in git-log.1 file is this:
>
> \&.ft C
> [i18n]
> commitencoding = ISO\-8859\-1
> \&.ft
>
> Recently I upgraded my system from Debian 4.0 (Etch) to 5.0 (Lenny) and
> it is possible that some tools which are related to compiling the man
> pages are now newer versions.
I had a similar problem after upgrading on Ubuntu and came up with a
patch to optionally disable some of asciidoc.conf (commit
7f55cf451c9e7). Try putting DOCBOOK_XSL_172=Yes in your config.mak.
--
Jonas Fonseca
^ permalink raw reply
* Re: A typesetting problem with git man pages
From: Jeff King @ 2008-10-29 19:39 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <87skqfus7v.fsf@iki.fi>
On Wed, Oct 29, 2008 at 09:16:52PM +0200, Teemu Likonen wrote:
> I compile git and its man pages myself and I just noticed that the man
> pages (invoked with "git help log", for example) have a typesetting
> problem. There are ".ft" commands here and there, like this:
I think this is Yet Another docbook or asciidoc issue. The resulting XML
from asciidoc is:
<literallayout>
.ft C
... the actual example contents ...
.ft
</literallayout>
which kind of seems wrong to me, since it implies that that is part of
the literal layout, and would be subject to quoting. It gets rendered
into git-log.1 as:
\&.ft C
... the actual examples contents
\&.ft
so the problem is the extra \&. But I don't know why that is being
generated. It _should_ be part of the character entity, I thought, but
xmlto seems to be rendering it as the newline character entity _plus_
the ampersand.
So it seems like a bug to me in the XML parser, but it is more likely
that I'm somehow clueless about XML.
-Peff
^ permalink raw reply
* Re: [VOTE] git versus mercurial
From: Johannes Schindelin @ 2008-10-29 19:48 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Shawn O. Pearce, walt, git
In-Reply-To: <alpine.LNX.2.00.0810291335400.7553@suse104.zenez.com>
Hi,
On Wed, 29 Oct 2008, Boyd Lynn Gerber wrote:
> On Wed, 29 Oct 2008, Shawn O. Pearce wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > On Tue, 28 Oct 2008, walt wrote:
> > > > walt wrote:
> > > > > No, no, I'm not the one calling for a vote. You old-timers here
> > > > > will know the name Matt Dillon, who is leading the dragonflybsd
> > > > > project (www.dragonflybsd.org).
> > > > >
> > > > > Matt is the one who is calling for the vote in his thread "Vote
> > > > > for your source control system" in the dragonfly.kernel group,
> > > > > accessible via nntp://nntp.dragonflybsd.org...
> > > >
> > > > The official vote was 19 to 19, plus one for perforce and one for
> > > > svn. Matt has proposed a primary git repository and a mirror in
> > > > hg, and that's being debated now.
> >
> > FWIW at the Google Summer of Code Mentor Summit this past weekend we
> > had a "Git vs. Hg" talk with both Git and Hg represented by
> > contributors to each project.
> >
> > Slides are online here:
> >
> > http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr
>
> But how do I save the presentation? I do not seem to be able to do it.
> I would like to view it off-line.
Just an idea: print to PDF? There is a link "print slides" on the lower
right.
Ciao,
Dscho
^ permalink raw reply
* Re: [VOTE] git versus mercurial
From: Boyd Lynn Gerber @ 2008-10-29 19:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, walt, git
In-Reply-To: <20081029191140.GB29357@spearce.org>
On Wed, 29 Oct 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Tue, 28 Oct 2008, walt wrote:
>>> walt wrote:
>>>> No, no, I'm not the one calling for a vote. You old-timers here will
>>>> know the name Matt Dillon, who is leading the dragonflybsd project
>>>> (www.dragonflybsd.org).
>>>>
>>>> Matt is the one who is calling for the vote in his thread "Vote for
>>>> your source control system" in the dragonfly.kernel group, accessible
>>>> via nntp://nntp.dragonflybsd.org...
>>>
>>> The official vote was 19 to 19, plus one for perforce and one for svn.
>>> Matt has proposed a primary git repository and a mirror in hg, and
>>> that's being debated now.
>
> FWIW at the Google Summer of Code Mentor Summit this past weekend
> we had a "Git vs. Hg" talk with both Git and Hg represented by
> contributors to each project.
>
> Slides are online here:
>
> http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr
But how do I save the presentation? I do not seem to be able to do it. I
would like to view it off-line.
Thanks,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Wincent Colaiuta @ 2008-10-29 19:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Symonds, git, gitster, Jeff King
In-Reply-To: <alpine.DEB.1.00.0810292022480.22125@pacific.mpi-cbg.de.mpi-cbg.de>
El 29/10/2008, a las 20:23, Johannes Schindelin escribió:
> Hi,
>
> On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
>
>> El 29/10/2008, a las 18:03, Johannes Schindelin escribió:
>>
>>> On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
>>>
>>>> Git already has too many commands. Adding more is not going to
>>>> clear
>>>> up newbie confusion, and will only waste time because people will
>>>> complain about it and ask why there is this kind of duplication.
>>>
>>> I completely disagree. If the existing set of commands causes
>>> confusion, we need to deprecate those parts and add new commands.
>>> Even if we have a ton of commands already.
>>
>> The confusion isn't at the command level; it's at the switch/option
>> level. The solution isn't to add a new command.
>
> Seems that at leat one guy who does Git training disagrees with you,
> _in
> addition_ to me.
That's what I call a "zero value" addition to the thread, seeing as
anyone reading the thread _already_ knows the opinions of the
participants who've posted.
Adding a separate command to an already overwhelming command set in
order to address confusion about options to "git diff" is a case of
"duct-tape UI design".
Wincent
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Felipe Contreras @ 2008-10-29 19:49 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster
In-Reply-To: <1225237145-95435-1-git-send-email-dsymonds@gmail.com>
On Wed, Oct 29, 2008 at 1:39 AM, David Symonds <dsymonds@gmail.com> wrote:
> Signed-off-by: David Symonds <dsymonds@gmail.com>
> ---
> This isn't a particularly serious patch, but is very relevant to our
> current discussion at GitTogether '08.
I've thought about some commands like:
git stage $file (git add $file)
git unstage $file (git reset $file)
Perhaps
git stage add
git stage rm
And then your proposal would fit with:
git stage diff
Or something like that.
--
Felipe Contreras
^ permalink raw reply
* Re: [VOTE] git versus mercurial
From: Boyd Lynn Gerber @ 2008-10-29 19:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, walt, git
In-Reply-To: <alpine.DEB.1.00.0810292047530.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Wed, 29 Oct 2008, Johannes Schindelin wrote:
> On Wed, 29 Oct 2008, Boyd Lynn Gerber wrote:
>> On Wed, 29 Oct 2008, Shawn O. Pearce wrote:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>> On Tue, 28 Oct 2008, walt wrote:
>>>>> walt wrote:
>>>>>> No, no, I'm not the one calling for a vote. You old-timers here
>>>>>> will know the name Matt Dillon, who is leading the dragonflybsd
>>>>>> project (www.dragonflybsd.org).
>>>>>>
>>>>>> Matt is the one who is calling for the vote in his thread "Vote
>>>>>> for your source control system" in the dragonfly.kernel group,
>>>>>> accessible via nntp://nntp.dragonflybsd.org...
>>>>>
>>>>> The official vote was 19 to 19, plus one for perforce and one for
>>>>> svn. Matt has proposed a primary git repository and a mirror in
>>>>> hg, and that's being debated now.
>>>
>>> FWIW at the Google Summer of Code Mentor Summit this past weekend we
>>> had a "Git vs. Hg" talk with both Git and Hg represented by
>>> contributors to each project.
>>>
>>> Slides are online here:
>>>
>>> http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr
>>
>> But how do I save the presentation? I do not seem to be able to do it.
>> I would like to view it off-line.
>
> Just an idea: print to PDF? There is a link "print slides" on the lower
> right.
That worked. I had to make my window full screen to see the option. It
did not show-up in my normal window.
Thanks,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: A typesetting problem with git man pages
From: Jonas Fonseca @ 2008-10-29 20:14 UTC (permalink / raw)
To: Jeff King; +Cc: Teemu Likonen, git
In-Reply-To: <20081029193958.GA12856@sigill.intra.peff.net>
On Wed, Oct 29, 2008 at 20:39, Jeff King <peff@peff.net> wrote:
> so the problem is the extra \&. But I don't know why that is being
> generated. It _should_ be part of the character entity, I thought, but
> xmlto seems to be rendering it as the newline character entity _plus_
> the ampersand.
>
> So it seems like a bug to me in the XML parser, but it is more likely
> that I'm somehow clueless about XML.
The way I understand it is that the DocBook XSL (stylesheet) doing the
conversion from xml to the manpage ensures that possible problematic
characters that could break the manpage are escaped. A dot in the
start of a line is problematic since it could be interpreted as markup
by the manpage viewer and in the mentioned case, the code was not
generated by the stylesheet, thus it must be escaped. So IMO, the
stylesheet is hardly to blame, the problem is that the asciidoc.conf
file defines a macro for literallayout, in which it expects manpage
code to be passed through unescaped.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: David Kågedal @ 2008-10-29 20:24 UTC (permalink / raw)
To: git
Cc: Teemu Likonen, Wincent Colaiuta, Johannes Schindelin,
David Symonds, gitster, Jeff King
In-Reply-To: <878ws7w8xc.fsf@iki.fi>
Teemu Likonen <tlikonen@iki.fi> writes:
> Wincent Colaiuta (2008-10-29 18:42 +0100) wrote:
>
>> El 29/10/2008, a las 18:03, Johannes Schindelin escribió:
>>> I completely disagree. If the existing set of commands causes
>>> confusion, we need to deprecate those parts and add new commands.
>>> Even if we have a ton of commands already.
>>
>> The confusion isn't at the command level; it's at the switch/option
>> level. The solution isn't to add a new command.
>
> I don't remember being confused in particular area but I think it's a
> _very_ good thing that the following three are behind the same "diff"
> command:
>
> git diff
> git diff --cached (or --staged)
> git diff HEAD
One irregularity hear is that there is no way to explicitly say what
you want to compare against the index (the staging area). Diff
compares two things to each other, and a more regular and general way
to express what it does would be something like
git diff STAGE WORKTREE (like "git diff" today)
git diff HEAD WORKTREE (like "git diff HEAD" today)
git diff WORKTREE HEAD (like "git diff -R HEAD" today)
git diff HEAD STAGE (like "git diff --cached" today)
git diff commit STAGE (like "git diff --cached commit" today)
To me, it isn't obvious that --cached changes the thing you *compare*
rather than the thing you compare *against*. I think it would be
useful to have a way of explicitly stating what you compare, something
like what I wrote above, and then having useful shortcuts for common
cases (like that no arguments compares the work tree against the
stage).
--
David Kågedal
^ permalink raw reply
* [PATCH 1/7] Documentation: do not use regexp in refspec descriptions
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-1-git-send-email-mail@cup.kalibalik.dk>
The refspec format description was a mix of regexp and BNF, making it
very difficult to read.
The syntax is now easier to read, though wrong: all parts of the
refspec are actually optional.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 2 +-
Documentation/pull-fetch-param.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6150b1b..df99c0b 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -32,7 +32,7 @@ OPTIONS
<refspec>...::
The canonical format of a <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
+ `[+]<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index ebdd948..0ff1700 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -6,7 +6,7 @@
<refspec>::
The canonical format of a <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
+ `[+]<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* Some updates to refspec documentation
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster
I have skimmed the git-push manpage many times over a period of
several months, without fully understanding it. Today I sat down and
figured it out. It took some experiments and a little reading of the
source.
Here I offer some updates to the refspec documentation, so that others
can hopefully learn it faster than I did. As I expect some changes to
be more controversial than others, I have split it up in several small
parts. Feel free to squash.
There is a risk that I have changed some things to be wrong. I wanted
to make this update while I was still a frustrated newbie.
Anders
^ permalink raw reply
* [PATCH 3/7] Documentation: rework SHA1 description in git push
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-3-git-send-email-mail@cup.kalibalik.dk>
Get rid of a double pair of parentheses. The arbitrary SHA1 is a
special case, so it can be postponed a bit.
Also mention HEAD, which is possibly the most useful SHA1 in this
situation.
Mention that a SHA1 cannot be automatically matched to a <dst>.
Add HEAD as an example of an arbitrary SHA1.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 02c7dae..fb9fb97 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -38,9 +38,7 @@ OPTIONS
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
-The <src> side represents the source branch (or arbitrary
-"SHA1 expression", such as `master~4` (four parents before the
-tip of `master` branch); see linkgit:git-rev-parse[1]) that you
+The <src> side represents the source branch that you
want to push. The <dst> side represents the destination location.
+
The local ref that matches <src> is used
@@ -63,6 +61,10 @@ the local side, the remote side is updated if a head of the same name
already exists on the remote side. This is the default operation mode
if no explicit refspec is found (that is neither on the command line
nor in any Push line of the corresponding remotes file---see below).
++
+The <src> can be an arbitrary "SHA1 expression", such as `HEAD`
+or `master~4` (see linkgit:git-rev-parse[1]). In this case, a
+<dst> location has to be named.
--all::
Instead of naming each ref to push, specifies that all
@@ -193,6 +195,10 @@ git push origin master::
with it. If `master` did not exist remotely, it would be
created.
+git push origin HEAD:master::
+ Push the current head to the remote ref matching `master` in
+ the `origin` repository.
+
git push origin :experimental::
Find a ref that matches `experimental` in the `origin` repository
(e.g. `refs/heads/experimental`), and delete it.
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 2/7] Documentation: git push repository can also be a remote
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-2-git-send-email-mail@cup.kalibalik.dk>
This is copied from pull-fetch-param.txt and helps the reader
to not get stuck in the URL section.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index df99c0b..02c7dae 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -28,7 +28,9 @@ OPTIONS
-------
<repository>::
The "remote" repository that is destination of a push
- operation. See the section <<URLS,GIT URLS>> below.
+ operation. This parameter can be either a URL
+ (see the section <<URLS,GIT URLS>> below) or the name
+ of a remote (see the section <<REMOTES,REMOTES>> below).
<refspec>...::
The canonical format of a <refspec> parameter is
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 6/7] Documentation: mention branches rather than heads
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-6-git-send-email-mail@cup.kalibalik.dk>
Most of the git push page talks about branches, so make it consistent
also in this paragraph.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 52035db..4e339c7 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -53,8 +53,8 @@ Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
+
The special refspec `:` (or `+:` to allow non-fast forward updates)
-directs git to push "matching" heads: for every head that exists on
-the local side, the remote side is updated if a head of the same name
+directs git to push "matching" branches: for every branch that exists on
+the local side, the remote side is updated if a branch of the same name
already exists on the remote side. This is the default operation mode
if no explicit refspec is found (that is neither on the command line
nor in any Push line of the corresponding remotes file---see below).
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 5/7] Documentation: elaborate on pushing tags
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-5-git-send-email-mail@cup.kalibalik.dk>
Make the description of pushing tags easier to read, but move the
shorthand notation towards the end of the description. This gives
a better flow.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 9788d49..52035db 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -38,7 +38,7 @@ OPTIONS
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
-The <src> side represents the source branch that you
+The <src> side represents the source branch or tag that you
want to push. The <dst> side represents the destination location.
+
The local ref that matches <src> is used
@@ -46,8 +46,6 @@ to fast forward the remote ref that matches <dst>. If
the optional leading plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
-`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
-+
A parameter <ref> without a colon pushes the <ref> from the source
repository to the destination repository under the same name.
+
@@ -64,6 +62,10 @@ nor in any Push line of the corresponding remotes file---see below).
The <src> can be an arbitrary "SHA1 expression", such as `HEAD`
or `master~4` (see linkgit:git-rev-parse[1]). In this case, a
<dst> location has to be named.
++
+When pushing tags, `tag <tag>` can be used as a shorthand for
+`refs/tags/<tag>:refs/tags/<tag>`. This should be specified as
+two arguments (that is, without quotes in the shell).
--all::
Instead of naming each ref to push, specifies that all
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 4/7] Documentation: remove a redundant elaboration
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-4-git-send-email-mail@cup.kalibalik.dk>
The comment in parentheses is wrong, as one has to leave out both the
colon and <dst>. This situation is covered by the section a few lines
down:
A parameter <ref> without a colon pushes the <ref> from the source
repository to the destination repository under the same name.
So, just remove the parentheses.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fb9fb97..9788d49 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -42,8 +42,7 @@ The <src> side represents the source branch that you
want to push. The <dst> side represents the destination location.
+
The local ref that matches <src> is used
-to fast forward the remote ref that matches <dst> (or, if no <dst> was
-specified, the same ref that <src> referred to locally). If
+to fast forward the remote ref that matches <dst>. If
the optional leading plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 7/7] Documentation: avoid using undefined parameters
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-7-git-send-email-mail@cup.kalibalik.dk>
The <ref> parameter has not been introduced, so rewrite to
avoid it.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4e339c7..e848ff9 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -46,8 +46,8 @@ to fast forward the remote ref that matches <dst>. If
the optional leading plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
-A parameter <ref> without a colon pushes the <ref> from the source
-repository to the destination repository under the same name.
+A lonely <src> parameter (without a colon and a destination) pushes
+the <src> to the same name in the destination repository.
+
Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* Re: [PATCH] increase git el1T3nEss
From: Daniel Barkalow @ 2008-10-29 20:28 UTC (permalink / raw)
To: Jeff King
Cc: Petr Baudis, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <20081029170631.GA12078@sigill.intra.peff.net>
On Wed, 29 Oct 2008, Jeff King wrote:
> The uptake of git by script kiddies has been disappointingly
> minimal. Let's make it more palatable by allowing mixed-case
> and l33t-speak commands.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This commit was made by "git c0mM1t".
>
> git.c | 27 ++++++++++++++++++++++++++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/git.c b/git.c
> index 89feb0b..fd0ca67 100644
> --- a/git.c
> +++ b/git.c
> @@ -261,6 +261,31 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
> return 0;
> }
>
> +static char deelite(char in) {
> + if (isalpha(in))
> + return tolower(in);
> + switch (in) {
> + case '0': return 'o';
> + case '1': return 'i';
> + case '3': return 'e';
> + case '5': return 's';
> + case '7': return 'l';
Your mapping doesn't comply with ISO 1337.5p34k; 1 can be l (in addition
to i), and 7 is T. Also, you're missing 4.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Bill Lear @ 2008-10-29 20:33 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0810290925s493cdc6oc7534904c864db28@mail.gmail.com>
On Wednesday, October 29, 2008 at 17:25:37 (+0100) Santi Béjar writes:
>On Wed, Oct 29, 2008 at 4:23 PM, Bill Lear <rael@zopyra.com> wrote:
>> We have had a few "crossed stream" problems when developers are
>> working on a local branch and they do an unguarded git push/pull,
>> when they really intended to do git push/pull origin branchname.
>>
>> We use git in a way that makes it desirable for us to only push/pull
>> to the same remote branch. So, if I'm in branch X, I want 'git push'
>> to push to origin/X, and 'git pull' to fetch into origin/X and then
>> merge into X from origin/X.
>>
>> In other words, we want git push/pull to behave in branches other than
>> master the same way it does when in master.
>>
>> I have discovered the '--track' option when creating a local branch,
>> and this appears to me to be the thing that gives us the desired
>> behavior.
>
>branch.autosetupmerge controls if --track is used by default (it is
>true by default since a long time)
>(See "git help config" for details)
Ah, problem solved then. I'll just have everyone upgrade to the
latest git. Thanks very much, Santi.
Bill
^ permalink raw reply
* Re: [PATCH 5/7] Documentation: elaborate on pushing tags
From: Daniel Barkalow @ 2008-10-29 20:40 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster
In-Reply-To: <1225311945-17100-6-git-send-email-mail@cup.kalibalik.dk>
On Wed, 29 Oct 2008, Anders Melchiorsen wrote:
> Make the description of pushing tags easier to read, but move the
> shorthand notation towards the end of the description. This gives
> a better flow.
>
> Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
> ---
> Documentation/git-push.txt | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 9788d49..52035db 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -38,7 +38,7 @@ OPTIONS
> by the source ref, followed by a colon `:`, followed by
> the destination ref.
> +
> -The <src> side represents the source branch that you
> +The <src> side represents the source branch or tag that you
> want to push. The <dst> side represents the destination location.
> +
> The local ref that matches <src> is used
> @@ -46,8 +46,6 @@ to fast forward the remote ref that matches <dst>. If
> the optional leading plus `+` is used, the remote ref is updated
> even if it does not result in a fast forward update.
> +
> -`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
> -+
> A parameter <ref> without a colon pushes the <ref> from the source
> repository to the destination repository under the same name.
> +
> @@ -64,6 +62,10 @@ nor in any Push line of the corresponding remotes file---see below).
> The <src> can be an arbitrary "SHA1 expression", such as `HEAD`
> or `master~4` (see linkgit:git-rev-parse[1]). In this case, a
> <dst> location has to be named.
> ++
> +When pushing tags, `tag <tag>` can be used as a shorthand for
> +`refs/tags/<tag>:refs/tags/<tag>`. This should be specified as
> +two arguments (that is, without quotes in the shell).
I think this should be "When pushing a tag, ...", to avoid confusion with
"--tags", which pushes (all) tags and doesn't need the "tag <tag>"
arguments.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Some updates to refspec documentation
From: Anders Melchiorsen @ 2008-10-29 20:41 UTC (permalink / raw)
To: git
In-Reply-To: <1225311945-17100-1-git-send-email-mail@cup.kalibalik.dk>
During my struggle, I also found a git push usability problem. The
refspec ":dst" will delete the remote branch without warning.
While this is indeed documented, you cannot blame somebody for
thinking that a left out <src> will default to HEAD, as it does for so
many other commands.
In a CVS-like setup, with everybody pushing to master, this could
cause havoc.
As the "git push <repository> :<dst>" operation is destructive, I
think it should be protected by the -f option.
For the record, I did realize this before trying to push ":master" :-).
Anders.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox