* Re: [PATCH] git show <tree>: show mode and hash, and handle -r
From: Johannes Schindelin @ 2008-10-29 14:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git, schacon
In-Reply-To: <49080EA4.9080404@viscovery.net>
Hi,
On Wed, 29 Oct 2008, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > Now, git show <tree> shows some more information, and with the -r option,
> > it recurses into subdirectories.
> >
> > Requested by Scott Chacon.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > The only quirk is the command line parsing for -r: we cannot use
> > DIFF_OPT_TST(&rev.diffopt, RECURSIVE), because that is switched
> > on not only by cmd_log_init(), but implicitly by
> > diff_setup_done(), because FORMAT_PATCH is selected by git-show.
>
> This comment should for sure go into the commit message.
Fair enough.
Junio, you want me to resend?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Brandon Casey @ 2008-10-29 14:33 UTC (permalink / raw)
To: Jeff King; +Cc: Stephan Beyer, David Symonds, git, gitster
In-Reply-To: <20081029010534.GA8833@sigill.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 29, 2008 at 02:01:07AM +0100, Stephan Beyer wrote:
>
>> I'm still not understanding, what it's for.
>> Usability? Because doing
>> git config --global alias.staged 'diff --cached'
>> is lame?
>
> You are missing some of the context,
Yeah, it would have been nice if there was audio.
Anyone take minutes, possibly?
btw the term "staged" makes perfect sense to me, whereas "cached"
was not intuitively obvious to me.
-brandon
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Pascal Obry @ 2008-10-29 14:58 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster
In-Reply-To: <1225237145-95435-1-git-send-email-dsymonds@gmail.com>
What about :
$ git config --global alias.staged "diff --cached"
I'm using this since some time.
--
--|------------------------------------------------------
--| 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: Johannes Schindelin @ 2008-10-29 15:08 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: David Symonds, git, gitster, Jeff King
In-Reply-To: <C0BD1E4B-130F-4A16-8865-8EEABE1431FD@wincent.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 859 bytes --]
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.
Ciao,
Dscho
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Johannes Schindelin @ 2008-10-29 15:10 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0810281801l29253e02g95c7a6851c4c4db3@mail.gmail.com>
Hi,
On Wed, 29 Oct 2008, Geoff Russell wrote:
> I want to export "the last N days" of a repository to create a copy
> which has an origin which is the state of the repository N days ago and
> has all the history between then and now.
>
> Can fast-export do this?
Yes. See the --since=... option.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Jeff King @ 2008-10-29 15:19 UTC (permalink / raw)
To: Brandon Casey; +Cc: Stephan Beyer, David Symonds, git, gitster
In-Reply-To: <HUCQtsE3HvgGu_KDktGNx0KyijzaFKOESHnzFagEbf4erQlMxjgVNQ@cipher.nrlssc.navy.mil>
On Wed, Oct 29, 2008 at 09:33:08AM -0500, Brandon Casey wrote:
> > You are missing some of the context,
>
> Yeah, it would have been nice if there was audio.
> Anyone take minutes, possibly?
There's no audio. Some of the slides will be available. I took notes on
at least one of the discussions, which I will try to summarize and post.
And I think some of the discussion will end up as patches, which will
hopefully provide full justification in their commit messages. ;)
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] diff: support making output friendlier for fine, grand users
From: Johannes Schindelin @ 2008-10-29 15:28 UTC (permalink / raw)
To: David Brown
Cc: Petr Baudis, git, Scott Chacon, Tom Preston-Werner, Jeff King,
J.H., Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <20081029150731.GA9942@linode.davidb.org>
Hi,
On Wed, 29 Oct 2008, David Brown wrote:
> On Tue, Oct 28, 2008 at 10:23:52PM -0700, Petr Baudis wrote:
>
> >+ }
> >+ else if (!strcmp(arg, "--pirate")) {
> >+ printf("Arrrr! These be yer fine changes, me 'earty!!\n");
>
> We need to wait until Sept 19 to apply this patch, however.
We could back-date it, of course.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Stephan Beyer @ 2008-10-29 15:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, David Symonds, git, gitster, Jeff King
In-Reply-To: <alpine.DEB.1.00.0810291604200.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Hi,
Johannes Schindelin wrote:
> 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.
I'm not sure if yet more commands really help newbies.
I *see* the problem that talking about the index, the cache and the staging
area can be difficult to newbies. But then I'd rather vote for "git diff
--staged" (instead of --cached) or "git show --staged" (both make sense
in some way).
Perhaps it is even sufficient to add a help text to "git status", like
this:
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
+# (use "git diff --cached" to see a diff of staged files)
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.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 1/1] diff: support making output friendlier for fine, grand users
From: David Brown @ 2008-10-29 15:07 UTC (permalink / raw)
To: Petr Baudis
Cc: git, Johannes Schindelin, Scott Chacon, Tom Preston-Werner,
Jeff King, J.H., Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <1225257832-29086-1-git-send-email-pasky@suse.cz>
On Tue, Oct 28, 2008 at 10:23:52PM -0700, Petr Baudis wrote:
>+ }
>+ else if (!strcmp(arg, "--pirate")) {
>+ printf("Arrrr! These be yer fine changes, me 'earty!!\n");
We need to wait until Sept 19 to apply this patch, however.
David
^ permalink raw reply
* 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
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