* 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] 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
* [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: 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
* 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: 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] 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: 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] 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
* [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
* 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
* 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
* 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: 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: 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: 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: 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: 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: [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: 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] 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: git bisect view's use of DISPLAY environment variable in Cygwin
From: Hannu Koivisto @ 2008-10-29 13:31 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0810290144450.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I submitted a patch a while ago, saying
>
> bisect view: call gitk if Cygwin's SESSIONNAME variable is set
>
> See
> http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=a2637a3a003646c69ab5a6b85f0ee1bfac15e0b0
Unfortunately this approach doesn't seem to work if you run git
bisect view from, say, cmd (probably applies to other non-Cygwin
shells as well). I'm puzzled as to why this happens; I wrote a
simple shell script that echoes $SESSIONNAME and no matter how I
run it from cmd it always echoes Console.
It's certainly better than nothing and I wouldn't mind it ending up
to the official git but...
--
Hannu
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Miles Bader @ 2008-10-29 13:29 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <490833AD.70806@gmail.com>
On Oct 29, 2008 6:58pm, Liu Yubao <yubao.liu@gmail.com> wrote:
> > Extremely useful. I usually keep local branches closely synchronized
> > with a remote "central" version, and tracking branches make the frequent
> > push/pull much more convenient.
>
> In my work flow, I don't keep changes in local branch for long time,
> I rebase it regularly and push them to central branch or discard them
> if the upstream rejects.
>
> You are right, I realize tracking branches is useful for people who keeps
> local changes for long time and track the upstream branch at the same
> time.
I don't keep local changes for a long time, I push daily. The local
tracking branch and the corresponding remote branch are basically copies of
each other, in different locations. I also do regularly rebasing, but
against a _different_ remote branch.
There are never merge commits, because all merges done by pull are
fast-forwards. If I were to push changes from multiple working directories
to the central location, I'd have to be more careful about the pull-merging
-- a rebase-on-pull as you suggest would be useful -- but I generally don't.
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: Do most people feel tracking branches useful?
From: Andreas Ericsson @ 2008-10-29 11:53 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <49083957.2060702@gmail.com>
Liu Yubao wrote:
> Andreas Ericsson wrote:
>> Liu Yubao wrote:
>>
>> Use "git fetch" instead of "git pull" and you won't need the 'my' branch.
>> If you use "git pull --rebase" you won't need to bother at all.
>>
> Thank you very much, I didn't know the "--rebase" option, now I learn
> the 'branch.<name>.rebase' configuration too by "git help pull".
>
> [...snip...]
>
>> I can't understand why you're working so hard for a linear history, but
>> perhaps
>> that's just an effect of only having leaf developers. I also can't
>> understand
> You got it exactly, we are leaf developers and make enhancement mostly,
> we don't want the upstream branch full of merging commit for many
> not so major changes. I remember keeping linear history is recommended
> in git's documentation.
>
That should probably be rephrased to "Think before you merge" or something
like that. Keeping history linear provides very little value in itself,
but mindlessly criss-cross-merging makes history difficul to review for
no good reason. Any perceived value of mindless merging is quickly
nullified once one starts looking at "git rerere".
The only time you'll run into problems with non-linear history is when
you're bisecting, and bisection ends up at a merge-commit where all the
merged branhces tips' pre-merge work flawlessly, but the merge-commit
itself introduces breakage by erroneously resolving a conflict, or by
introducing changes of its own (git commit --amend, fe).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Wincent Colaiuta @ 2008-10-29 10:59 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster, Jeff King
In-Reply-To: <1225241048-99267-1-git-send-email-dsymonds@gmail.com>
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...)
Wincent
^ 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