* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Johannes Schindelin @ 2008-10-29 15:48 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Wincent Colaiuta, David Symonds, git, gitster, Jeff King
In-Reply-To: <20081029152202.GA10029@leksak.fem-net>
Hi,
On Wed, 29 Oct 2008, Stephan Beyer wrote:
> For me, a "git staged" feels wrong without a "git stage" (alias for "git
> add") and "git unstage <file>" (alias for "git reset <file>"). And I
> think the list of examples can easily be continued.
http://article.gmane.org/gmane.comp.version-control.git/99340
Thanks,
Dscho
^ permalink raw reply
* Using the --track option when creating a branch
From: Bill Lear @ 2008-10-29 15:23 UTC (permalink / raw)
To: git
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.
Before I tell the rest of the team that this is the correct way
to do things, I need to be sure I am correct, so if anyone here
can confirm or deny this, I'd appreciate it.
Also, once a branch has been created, how can we add a '--track' option
after the fact?
Finally, is there a 'global' config setting that would set this behavior
for all repos (new or existing)?
We are using git 1.6.* versions here, mostly.
Thanks.
Bill
^ permalink raw reply
* [PATCH] git-diff: Add --staged as a synonym for --cached.
From: David Symonds @ 2008-10-29 16:15 UTC (permalink / raw)
To: git, gitster, Jeff King, Johannes Schindelin, Stephan Beyer; +Cc: David Symonds
---
Consider this as a replacement to the previous git-staged series.
Documentation/git-diff.txt | 1 +
builtin-diff.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index c53eba5..a2f192f 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -33,6 +33,7 @@ forced by --no-index.
commit relative to the named <commit>. Typically you
would want comparison with the latest commit, so if you
do not give <commit>, it defaults to HEAD.
+ --staged is a synonym of --cached.
'git diff' [--options] <commit> [--] [<path>...]::
diff --git a/builtin-diff.c b/builtin-diff.c
index 2de5834..7ceceeb 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -118,7 +118,7 @@ static int builtin_diff_index(struct rev_info *revs,
int cached = 0;
while (1 < argc) {
const char *arg = argv[1];
- if (!strcmp(arg, "--cached"))
+ if (!strcmp(arg, "--cached") || !strcmp(arg, "--staged"))
cached = 1;
else
usage(builtin_diff_usage);
@@ -320,7 +320,8 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
const char *arg = argv[i];
if (!strcmp(arg, "--"))
break;
- else if (!strcmp(arg, "--cached")) {
+ else if (!strcmp(arg, "--cached") ||
+ !strcmp(arg, "--staged")) {
add_head_to_pending(&rev);
if (!rev.pending.nr)
die("No HEAD commit to compare with (yet)");
--
1.6.0
^ permalink raw reply related
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Wincent Colaiuta @ 2008-10-29 16:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Symonds, git, gitster, Jeff King
In-Reply-To: <alpine.DEB.1.00.0810291604200.22125@pacific.mpi-cbg.de.mpi-cbg.de>
El 29/10/2008, a las 16:08, Johannes Schindelin escribió:
> Hi,
>
> On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
>
>> El 29/10/2008, a las 1:44, David Symonds escribió:
>>
>>> +SCRIPT_SH += git-staged.sh
>>
>> Isn't this exactly what aliases are for?
>> git config --global alias.staged "diff --cached"
>> (Rather than adding yet another command...)
>
> The difference being, of course, that we do not ship default aliases
> (and
> neither do we plan to...).
>
> So saying "this is what aliases are for" you ask for _newbies_ to
> add it
> for themselves. We are talking the same newbies who should be
> helped by
> that command, and typically do not know that there are Git aliases
> yet.
>
> Even worse, just sum the times it takes everybody to make that
> alias, and
> then compare with the time it would take to include something like
> David
> posted in git.git. It should be obvious that the time balance is
> absolutely horrible.
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.
W
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Santi Béjar @ 2008-10-29 16:25 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18696.32778.842933.486171@lisa.zopyra.com>
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)
>
> Before I tell the rest of the team that this is the correct way
> to do things, I need to be sure I am correct, so if anyone here
> can confirm or deny this, I'd appreciate it.
It should just work (at least in the lastest releases) when creating a
branch from a remote branch.
$ git checkout -b X origin/X
or
$ git branch X origin/X
Branch X set up to track remote branch refs/remotes/origin/X
>
> Also, once a branch has been created, how can we add a '--track' option
> after the fact?
It it just two configs (apart from the remote repository). A help
message should appear when using "git pull" without arguments and it
cannot figure out the branch to merge:
$ # currently in branch next
$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.next.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.next.remote = <nickname>
branch.next.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
[end]
so to add it after the fact you should execute:
$ git config branch.next.remote origin
$ git config branch.next.merge refs/heads/next
>
> Finally, is there a 'global' config setting that would set this behavior
> for all repos (new or existing)?
See above.
>
> We are using git 1.6.* versions here, mostly.
>
Santi
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-10-29 16:42 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster, Johannes Schindelin, Stephan Beyer
In-Reply-To: <1225296936-1357-1-git-send-email-dsymonds@gmail.com>
On Wed, Oct 29, 2008 at 09:15:36AM -0700, David Symonds wrote:
> Consider this as a replacement to the previous git-staged series.
I think this is a much more sensible (actual) approach.
> diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
> index c53eba5..a2f192f 100644
> --- a/Documentation/git-diff.txt
> +++ b/Documentation/git-diff.txt
> @@ -33,6 +33,7 @@ forced by --no-index.
> commit relative to the named <commit>. Typically you
> would want comparison with the latest commit, so if you
> do not give <commit>, it defaults to HEAD.
> + --staged is a synonym of --cached.
Hmm. I wonder if it would make it more sense to make the "official" name
--staged, and leave --cached forever as a synonym. If the goal is giving
sane names to end users, then we should probably advertise the sane
ones.
OTOH, maybe it is better to start slow, let people who are doing
training materials mention --staged, and see how that works.
> @@ -118,7 +118,7 @@ static int builtin_diff_index(struct rev_info *revs,
> int cached = 0;
> while (1 < argc) {
> const char *arg = argv[1];
> - if (!strcmp(arg, "--cached"))
> + if (!strcmp(arg, "--cached") || !strcmp(arg, "--staged"))
> cached = 1;
> else
> usage(builtin_diff_usage);
I had to investigate this hunk closely, as it really looks at first
glance (from the function name, and the fact that there are two hunks,
one here and one for cmd_diff) that this is impacting diff-index
--cached, but it's not. We just checked --cached in two different places
inside git-diff (but at least one of them is prefixed by a comment that
includes the world "Eek.").
-Peff
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: David Symonds @ 2008-10-29 16:50 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster, Johannes Schindelin, Stephan Beyer
In-Reply-To: <20081029164253.GA3172@sigill.intra.peff.net>
On Wed, Oct 29, 2008 at 9:42 AM, Jeff King <peff@peff.net> wrote:
> Hmm. I wonder if it would make it more sense to make the "official" name
> --staged, and leave --cached forever as a synonym. If the goal is giving
> sane names to end users, then we should probably advertise the sane
> ones.
I agree. If there's some consensus, I can make that shift, keeping
--cached as a backward-compatibility synonym.
Dave.
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Johannes Schindelin @ 2008-10-29 17:03 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: David Symonds, git, gitster, Jeff King
In-Reply-To: <08FC4756-8890-449D-BB55-90E4761C9B93@wincent.com>
Hi,
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.
It does not need to hurt, either. Just think of init-db. Ever heard of
it? We still have it, yet it is not relevant.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Johannes Schindelin @ 2008-10-29 17:06 UTC (permalink / raw)
To: David Symonds; +Cc: Jeff King, git, gitster, Stephan Beyer
In-Reply-To: <ee77f5c20810290950k6d7acfcbt90b6280c290bd532@mail.gmail.com>
Hi,
On Wed, 29 Oct 2008, David Symonds wrote:
> On Wed, Oct 29, 2008 at 9:42 AM, Jeff King <peff@peff.net> wrote:
>
> > Hmm. I wonder if it would make it more sense to make the "official"
> > name --staged, and leave --cached forever as a synonym. If the goal is
> > giving sane names to end users, then we should probably advertise the
> > sane ones.
>
> I agree. If there's some consensus, I can make that shift, keeping
> --cached as a backward-compatibility synonym.
Yes, I would like that, too.
However, note that we have to hash out what to do about the convention
that --cached traditionally means that only the staging area (formerly
known as "the index") is affected, while --index means that the command
touches the working directory, too.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] increase git el1T3nEss
From: Jeff King @ 2008-10-29 17:06 UTC (permalink / raw)
To: Petr Baudis
Cc: git, Johannes Schindelin, Scott Chacon, Tom Preston-Werner, J.H.,
Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <1225257832-29086-1-git-send-email-pasky@suse.cz>
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';
+ }
+ return in;
+}
+
+static int elitecmp(const char *a, const char *b) {
+ while (1) {
+ char ca = deelite(*a), cb = deelite(*b);
+ if (ca != cb)
+ return ca < cb ? -1 : 1;
+ if (!ca)
+ return 0;
+ a++;
+ b++;
+ }
+}
+
static void handle_internal_command(int argc, const char **argv)
{
const char *cmd = argv[0];
@@ -381,7 +406,7 @@ static void handle_internal_command(int argc, const char **argv)
for (i = 0; i < ARRAY_SIZE(commands); i++) {
struct cmd_struct *p = commands+i;
- if (strcmp(p->cmd, cmd))
+ if (elitecmp(p->cmd, cmd))
continue;
exit(run_command(p, argc, argv));
}
--
1.6.0.3.764.ge6f2.dirty
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-10-29 17:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Symonds, git, gitster, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0810291804400.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Wed, Oct 29, 2008 at 06:06:09PM +0100, Johannes Schindelin wrote:
> However, note that we have to hash out what to do about the convention
> that --cached traditionally means that only the staging area (formerly
> known as "the index") is affected, while --index means that the command
> touches the working directory, too.
If we assume that we have only the word "stage" and variations
available, then there aren't too many options.
only the staging area:
--stage-only, --staged-only
both:
--staged (as opposed to --staged-only) --stage-and-worktree (too
long), --both (not descriptive enough), --stage-too (yuck)
-Peff
^ permalink raw reply
* Re: [PATCH] increase git el1T3nEss
From: Miklos Vajna @ 2008-10-29 17:11 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>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
On Wed, Oct 29, 2008 at 01:06:31PM -0400, Jeff King <peff@peff.net> 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".
Testcase?
(I hope it was not serious, just like my question. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Pascal Obry @ 2008-10-29 17:13 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, David Symonds, git, gitster, Jeff King
In-Reply-To: <alpine.DEB.1.00.0810291801580.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin a écrit :
> 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.
>
> It does not need to hurt, either. Just think of init-db. Ever heard of
> it? We still have it, yet it is not relevant.
In this specific case adding a new command as an alias for a
command+option seems wrong! I much prefer adding the alias --staged for
--cached - as proposed now - if it can make things easier for new comers.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Wincent Colaiuta @ 2008-10-29 17:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Symonds, git, gitster, Jeff King
In-Reply-To: <alpine.DEB.1.00.0810291801580.22125@pacific.mpi-cbg.de.mpi-cbg.de>
El 29/10/2008, a las 18:03, Johannes Schindelin escribió:
> Hi,
>
> 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.
> It does not need to hurt, either. Just think of init-db. Ever
> heard of
> it? We still have it, yet it is not relevant.
The comparison isn't really valid. init-db is effectively invisible,
but you're talking about adding a new "in your face" porcelain command.
W
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Teemu Likonen @ 2008-10-29 18:30 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, David Symonds, git, gitster, Jeff King
In-Reply-To: <E4E10B61-FA92-417C-9046-F9DE3B48C2A6@wincent.com>
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
It's also good idea to pretty much always teach those three together.
^ permalink raw reply
* [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
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