On Mon, Jun 24, 2013 at 6:33 AM, Junio C Hamano gits...@pobox.com wrote:
From: Ramkumar Ramachandra artag...@gmail.com
When remote.pushdefault or branch.name.pushremote is set (a triangular
workflow feature), master@{u} != origin, and push.default is set to
`upstream` or `simple`:
$ git
On Mon, Jun 24, 2013 at 6:33 AM, Junio C Hamano gits...@pobox.com wrote:
When branch.*.push configuration variable is defined for the current
branch, a lazy-typing git push (and git push there) will push
the commit at the tip of the current branch to the destination and
update the branch named
On Mon, Jun 24, 2013 at 6:33 AM, Junio C Hamano gits...@pobox.com wrote:
From: Ramkumar Ramachandra artag...@gmail.com
The setup creates two bare repositories: repo1 and repo2, but
test_push_commit() hard-codes checking in repo1 for the actual output.
Generalize it and its caller,
Junio C Hamano wrote:
@@ -59,6 +63,9 @@ else
return $?
fi
+ # always reset GIT_REFLOG_ACTION before calling any external
+ # scripts; they have no idea about our base_reflog_action
+ GIT_REFLOG_ACTION=$base_reflog_action
git am $git_am_opt --rebasing
Junio C Hamano wrote:
[PATCH 3/6] push: change `simple` to accommodate triangular workflows
Sqaushed in the fix to keep the semantics of simple when used in
the centralized workflow the same as before.
Yeah, I'm worried about this as I pointed out earlier. I don't like
erroring out
Johan Herland jo...@herland.net writes:
+ git --git-dir=${3:-repo1} log -1 --format='%h %s' $2 actual
Isn't ${3:-repo1} a bashism?
I do not think so. But now I looked at it again, I think I would
use ${3-repo1} form in this case myself. No caller passes an empty
string to the third
Junio C Hamano gits...@pobox.com writes:
Arnaud Fontaine ar...@debian.org writes:
Merge strategy and its options can be specified in `git rebase`, but
with `--interactive`, they were completely ignored.
And why is it a bad thing? If you meant s/--interactive/-m/ in the
above, then I
Johan Herland jo...@herland.net writes:
+static void setup_push_current(struct remote *remote, struct branch *branch)
+{
+ if (!branch)
+ die(_(message_detached_head_die), remote-name);
+ add_refspec(branch-name);
Here (and above) we add a refspec to tell Git
Johan Herland jo...@herland.net writes:
+static void setup_per_branch_push(struct branch *branch)
+{
+ struct strbuf refspec = STRBUF_INIT;
+
+ strbuf_addf(refspec, %s:%s,
+ branch-name, branch-push_name);
+ add_refspec(refspec.buf);
This goes back to
Fix inconsistency where `--strategy` and/or `--strategy-option` can be
specified in git rebase, but with `--interactive` argument only there
were completely ignored.
Signed-off-by: Arnaud Fontaine ar...@debian.org
---
git-rebase--interactive.sh| 13 ++---
Johan Herland wrote:
An earlier round of this change by mistake broke the safety for
simple mode we have had since day 1 of that mode to make sure that
the branch in the repository we update is set to be the one we fetch
and integrate with, but it has been fixed.
Shouldn't there be an
Ramkumar Ramachandra artag...@gmail.com writes:
+ # always reset GIT_REFLOG_ACTION before calling any external
+ # scripts; they have no idea about our base_reflog_action
+ GIT_REFLOG_ACTION=$base_reflog_action
git am $git_am_opt --rebasing --resolvemsg=$resolvemsg
Why
Junio C Hamano wrote:
@@ -194,7 +203,14 @@ static int is_workflow_triagular(struct remote *remote)
static void setup_default_push_refspecs(struct remote *remote)
{
struct branch *branch = branch_get(NULL);
- int triangular = is_workflow_triagular(remote);
+ int
To git@vger.kernel.org - git@vger.kernel.org,
Your email message Message could not be delivered did not reach your
recipient.
Please click to confirm your message:
http://www.tiscalimail.com/
Please vissit this link to find out more information:
http://www.tiscalimail.com/
Thank you.
--
Johan Herland jo...@herland.net writes:
An earlier round of this change by mistake broke the safety for
simple mode we have had since day 1 of that mode to make sure that
the branch in the repository we update is set to be the one we fetch
and integrate with, but it has been fixed.
Ramkumar Ramachandra artag...@gmail.com writes:
I hope (perhaps foolishly) to persuade you nevertheless. I fear that
if this series solidifies before I get there, we'll be stuck with this
stupid erroring-out behavior forever.
I do not think it is stupid at all.
'simple' is supposed to be an
Junio C Hamano wrote:
So you are forcing people to maintain _two_ variables, instead of
just _one_, without making anything simpler.
What's so hard to understand why it is a wrong design?
Fine. Let's say I buy your argument about one-variable versus
two-variables: how do you solve the
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
@@ -194,7 +203,14 @@ static int is_workflow_triagular(struct remote *remote)
static void setup_default_push_refspecs(struct remote *remote)
{
struct branch *branch = branch_get(NULL);
- int triangular =
On Mon, Jun 24, 2013 at 9:28 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
+ git --git-dir=${3:-repo1} log -1 --format='%h %s' $2 actual
Isn't ${3:-repo1} a bashism?
I do not think so. But now I looked at it again, I think I would
use
On Mon, Jun 24, 2013 at 4:33 AM, Johan Herland jo...@herland.net wrote:
On Mon, Jun 24, 2013 at 9:28 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
+ git --git-dir=${3:-repo1} log -1 --format='%h %s' $2 actual
Isn't ${3:-repo1} a bashism?
I do
On Mon, Jun 24, 2013 at 9:59 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
An earlier round of this change by mistake broke the safety for
simple mode we have had since day 1 of that mode to make sure that
the branch in the repository we update is set to
On Mon, Jun 24, 2013 at 9:46 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Johan Herland wrote:
+static void setup_push_current(struct remote *remote, struct branch
*branch)
+{
+ if (!branch)
+ die(_(message_detached_head_die), remote-name);
+
On Mon, Jun 24, 2013 at 10:44 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Jun 24, 2013 at 4:33 AM, Johan Herland jo...@herland.net wrote:
On Mon, Jun 24, 2013 at 9:28 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
+ git
Francis Moreau francis.m...@gmail.com writes:
On Thu, Jun 20, 2013 at 3:20 PM, Thomas Rast tr...@inf.ethz.ch wrote:
positive=$(git rev-parse $@ | grep -v '^\^')
negative=$(git rev-parse $@ | grep '^\^')
boundary=$(git rev-list --boundary $positive ^master | sed -n 's/^-//p')
# the
SZEDER Gábor sze...@ira.uka.de writes:
I suspect that detaching HEAD before a root commit is not possible by
design. What would HEAD contain then!? 'git checkout' seems to
corroborate:
$ git init
Initialized empty Git repository in /tmp/test/.git/
$ git checkout --detach
fatal: You are
The fact that the git transport has no end-to-end security is easily
overlooked. Add a brief security notice to the GIT URLS section
of the documentation stating that the git transport should be used
with caution on unsecured networks.
Signed-off-by: Fraser Tweedale fr...@frase.id.au
---
The default similarity index of 50% is documented in gitdiffcore(7)
but it is worth also mentioning it in the description of the
-M/--find-renames option.
Signed-off-by: Fraser Tweedale fr...@frase.id.au
---
Documentation/diff-options.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Fix refspec asterisks in the -t/--tags section of the fetch-options
documentation.
Signed-off-by: Fraser Tweedale fr...@frase.id.au
---
Documentation/fetch-options.txt | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/fetch-options.txt
Fraser Tweedale fr...@frase.id.au writes:
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 9cb6496..f2ac3bc 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -61,11 +61,12 @@ endif::git-pull[]
ifndef::git-pull[]
-t::
Right you are. I missed that; apologies for the noise.
Fraser
On Mon, Jun 24, 2013 at 01:35:13PM +0200, Thomas Rast wrote:
Fraser Tweedale fr...@frase.id.au writes:
diff --git a/Documentation/fetch-options.txt
b/Documentation/fetch-options.txt
index 9cb6496..f2ac3bc 100644
---
Hi,
Le 21.06.2013 23:57, Junio C Hamano a écrit :
Junio C Hamano gits...@pobox.com writes:
The helper may want to learn a way to be told to demote that error
to a warning.
Perhaps something like this?
Thanks for the patch.
I run my test again, eg. run git diff after a rebase failure
Hi,
It turns out that status.short and status.branch introduce two very
serious regressions. This series fixes them.
Thanks.
Ramkumar Ramachandra (2):
status: really ignore config with --porcelain
commit: make it work with status.short
builtin/commit.c | 8 +++-
1 file changed, 7
50e4f75 (status: introduce status.short to enable --short by default,
2013-06-11) introduced a regression in git commit; it is now impossible
to commit with status.short set.
This happens because commit internally runs run_status() to set
s-commitable and determine whether or not there is
1a22bd3 (Merge branch 'jg/status-config', 2013-06-23) introduced a
serious regression in --porcelain by introducing the configuration
variables status.short and status.branch. Contrary to its description,
the output of
$ git status --porcelain
now depends on the configuration variables
Ramkumar Ramachandra artag...@gmail.com writes:
Contrary to its description, the output of
$ git status --porcelain
now depends on the configuration variables status.short and
status.branch.
Ouch, indeed :-(.
The correct solution is therefore to skip the config parser completely
when
Junio C Hamano wrote:
'simple' is supposed to be an easy and safe default to help new
people. Your original patch to change its semantics for the central
workflow from the current 'make sure upstream is set and set to the
same name' to 'anything goes' is making the mode more dangerous than
Matthieu Moy wrote:
[...]
Before we begin, let me say that this series is written with the
emergency-fix mindset, and targets maint. I didn't spend time
thinking about how to do it best or even add tests.
The correct solution is therefore to skip the config parser completely
when --porcelain
Johan Herland wrote:
But then, does it make sense to
say that we will only ever have exactly _one_ push refspec in the
current context, and we should therefore replace the static const
char **refspec; string array with a single static const char
*refspec; string? That would make it obvious
Arnaud Fontaine ar...@debian.org writes:
+ $(echo $strategy_opts | sed s/'--\([^']*\)'/-X\1/g) \
Is it guaranteed $startegy_opts do not have a space in it?
strategy_opts may be something like (git-rebase.sh): '--foo' '--bar',
but I'm not sure what is wrong if there is a
Junio C Hamano wrote:
# on branch master, derived from origin
$ git push ram
And branch.master.push is set to next? Will you let her shoot herself
in the foot like this?
It is not shooting in the foot, if branch.master.push is explicitly
set to update next. I do not see any issue in
benoit.per...@ensimag.fr writes:
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 000..a2f0aa1
--- /dev/null
+++ b/contrib/mw-to-git/git-mw.perl
*.perl scripts are usually executable in Git's tree (although it's
usually better to run
Matthieu Moy matthieu@grenoble-inp.fr writes:
I really don't like this. If we go for a solution looking explicitely at
argv[], we should at least iterate over it (also not satisfactory
because --porcelain could be the argument of another switch).
Ram, thanks for a report.
I won't comment
Ramkumar Ramachandra artag...@gmail.com writes:
Matthieu Moy wrote:
[...]
Before we begin, let me say that this series is written with the
emergency-fix mindset, and targets maint.
maint shouldn't be necessary since the breakage hasn't been released. At
worse, we can revert the bad commits
Junio C Hamano gits...@pobox.com writes:
My knee-jerk reaction is that, because the
--porcelain output was designed to be extensible and scripts
reading from it is expected to ignore what it does not understand,
if the setting of status.branch is a problem, the reading side is
buggy and
Ramkumar Ramachandra artag...@gmail.com writes:
50e4f75 (status: introduce status.short to enable --short by default,
2013-06-11) introduced a regression in git commit; it is now impossible
to commit with status.short set.
This happens because commit internally runs run_status() to set
Johannes found that some relative_path tests should be skipped on Windows.
See this thread:
http://thread.gmane.org/gmane.comp.version-control.git/227706
In this reroll,
* I squash Johannes's patch into patch 01/16, and seven relative_path
test cases are skipped by marking with POSIX.
Since there is an enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
quote.c | 55 ++-
1
Add subcommand relative_path in test-path-utils, and add test cases
in t0060.
Johannes tested this commit on Windows, and found that some relative_path
tests should be skipped on Windows. This is because the bash on Windows
rewrites arguments of regular Windows programs, such as git and the
test
Original design of relative_path() is simple, just strip the prefix
(*base) from the absolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
reimplementation (path_relative()) in quote.c.
Borrowed some codes from path_relative()
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
quote_path_relative(). Remove unused parameters and change the order of
parameters for quote_path_relative() function.
Signed-off-by: Jiang Xin
Add new subcommand mingw_path in test-path-utils, so that we can get
the expected absolute paths on Windows. For example:
COMMAND LINELinux Windows
== = ===
test-path-utils mingw_path // C:/msysgit
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and
Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK,
Add new section Interactive mode for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin worldhello@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-clean.txt | 65
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
write_name_quoted_relative(). Remove unused parameters from
write_name_quoted_relative() and related functions.
Signed-off-by: Jiang Xin
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as color.interactive and
color.interactive.slot for command `git-add--interactive`.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
Before introducing interactive git-clean, refactor git-clean operations
into two phases:
* hold cleaning items in del_list,
* and remove them in a separate loop at the end.
We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated
Show what would be done and the user must confirm before actually
cleaning.
Would remove ...
Would remove ...
Would remove ...
Remove [y/n]?
Press y to start cleaning, and press n if you want to abort.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C
Add a new action for interactive git-clean: ask each. It's just like
the rm -i command, that the user must confirm one by one for each
file or directory to be cleaned.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/clean.c | 36
On Mon, Jun 24, 2013 at 4:19 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
# on branch master, derived from origin
$ git push ram
And branch.master.push is set to next? Will you let her shoot herself
in the foot like this?
It is not shooting in the foot, if
Add test cases for git-clean--interactive.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755
Junio C Hamano wrote:
As I said in the other message, I'll revert the merge of the topic
branch from 'master' for now, and queue this on top of the topic so
that we will have the preventive fix when the topic is in a better
shape for the other possible breakage on the --branch thing.
Thanks,
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
# on branch master, derived from origin
$ git push ram
And branch.master.push is set to next? Will you let her shoot herself
in the foot like this?
It is not shooting in the foot, if branch.master.push is
Junio C Hamano wrote:
Configuration related to the output format (like color=always) must
be ignored under --porcelain, but if we do not read core-ish
configuration variables (e.g. core.crlf) that affect the logic to
list what is changed what is not, we would not give the right
result, no?
Johan Herland jo...@herland.net writes:
I haven't yet dug deep enough to figure out an obvious failure mode
(and I probably should not have sent this email until I'd found one),
but I wonder if we'd be better off forcing the $remote and $remote_ref
configuration for a given branch to appear
Junio C Hamano wrote:
If the user said git push without an explicit request to push to
ram, and if branch.master.pushremote was not set to ram, and
still the command git push pushed the branch to ram, then I
would understand what you are worried about, but otherwise I do not
see how what you
On Sat, Jun 22, 2013 at 01:32:38PM -0300, Eduardo D'Avila wrote:
These tests where important to make sure that I wouldn't break anything during
the refactorization. Having them pass before *and* after refactorization
guarantees that nothing was broken (except for some subtle case that might
Fraser Tweedale fr...@frase.id.au writes:
The fact that the git transport has no end-to-end security is easily
overlooked. Add a brief security notice to the GIT URLS section
of the documentation stating that the git transport should be used
with caution on unsecured networks.
Fraser Tweedale wrote:
The default similarity index of 50% is documented in gitdiffcore(7)
but it is worth also mentioning it in the description of the
-M/--find-renames option.
Looks good from a quick look at diffcore.h:
#define DEFAULT_RENAME_SCORE 3 /* rename/copy similarity minimum
Matthieu Moy matthieu@grenoble-inp.fr writes:
Basically, having the CLI parser and the config parser flip two
different sets of variables, so we can discriminate who set what.
What annoys me is that this is the first instance of such a
requirement.
I don't think it's the first instance,
Hi,
I'm still trying to use .gitattributes text flag with CRLF line ending
files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status:
$ git init
Initialized empty Git
Matthieu Moy matthieu@grenoble-inp.fr writes:
benoit.per...@ensimag.fr writes:
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 000..a2f0aa1
--- /dev/null
+++ b/contrib/mw-to-git/git-mw.perl
*.perl scripts are usually
Use 'file' instead of ' file', in accordance with the coding
guidelines.
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
t/t9903-bash-prompt.sh | 232 -
1 file changed, 116 insertions(+), 116 deletions(-)
diff --git a/t/t9903-bash-prompt.sh
Hi,
displaying the git-specific bash prompt on Windows/MinGW takes quite
long, long enough to be noticeable. This is mainly caused by the
numerous fork()s and exec()s to create subshells and run git or other
commands, which are rather expensive on Windows.
This patch series eliminates many
Currently __gitdir() is duplicated in the git completion and prompt
scripts, while its tests are in the prompt test suite. This patch
series is about to change __git_ps1() in a way that it won't need
__gitdir() anymore and __gitdir() will be removed from the prompt
script.
So move all __gitdir()
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
t/t9903-bash-prompt.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index df36239a..416e6219 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -40,6 +40,15 @@
When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() runs 'cut -c1-7 .git/HEAD' to
show the 7 hexdigits abbreviated commit object name in the prompt.
Obviously, this neither respects core.abbrev nor produces a unique
object name.
Fix this by
Helped-by: Jeff King p...@peff.net
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
t/t9903-bash-prompt.sh | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 7c7f8b97..442b9a20 100755
--- a/t/t9903-bash-prompt.sh
Le 24.06.2013 18:37, Yann Droneaud a écrit :
I'm still trying to use .gitattributes text flag with CRLF line
ending files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status:
__git_ps1() finds out the path to the repository by using the
__gitdir() helper function. __gitdir() is basically just a wrapper
around 'git rev-parse --git-dir', extended with support for
recognizing a remote repository given as argument, to use the path
given on the command line, and with a few
... to gain one level of indentation for the bulk of the function.
(The patch looks quite unreadable, you'd better check it with 'git
diff -w'.)
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
contrib/completion/git-prompt.sh | 201 ---
1 file changed, 101
__git_ps1() runs the '$(git symbolic-ref HEAD)' command substitution
to find out whether we are on a branch and to find out the name of
that branch. This imposes the overhead of fork()ing a subshell and
fork()+exec()ing a git process.
Since HEAD is in most cases a single-line file and the
During an ongoing interactive rebase __git_ps1() finds out the name of
the rebased branch, the total number of patches and the number of the
current patch by executing a '$(cat .git/rebase-merge/FILE)' command
substitution for each. That is not quite the most efficient way to
read single line
There are a couple of '$(git rev-parse --opt)' command substitutions
in __git_ps1() and three of them are executed in the main code path:
- the first to get the path to the .git directory ('--git-dir'),
- the second to check whether we're inside the .git directory
('--is-inside-git-dir'),
-
When the dirty work tree and index status indicator is enabled,
__git_ps1() checks for changes in the index by running 'git diff-index
--cached --quiet HEAD --' and looking at its exit code. However, that
makes sense only when HEAD points to a valid commit: on an unborn
branch the failure of said
When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() now runs the '$(git rev-parse
--short HEAD)' command substitution to get the abbreviated detached
HEAD commit object name. This imposes the overhead of fork()ing a
subshell and
When enabled, the bash prompt can indicate the presence of untracked
files with a '%' sign. __git_ps1() checks for untracked files by running the
'$(git ls-files --others --exclude-standard)' command substitution,
and displays the indicator when there is no output.
Avoid this command
When the environment variable $GIT_PS1_SHOWSTASHSTATE is set
__git_ps1() checks the presence of stashes by running 'git rev-parse
--verify refs/stash'. This command not only checks that the
'refs/stash' ref exists but also, well, verifies that it's a valid
ref.
However, we don't need to be that
Before setting $PS1, __git_ps1() uses a command substitution to
redirect the output from a printf into a variable. Spare the overhead
of fork()ing a subshell by using 'printf -v var' to directly assign
the output to that variable.
zsh's printf doesn't support the '-v var' option, so stick with
__git_ps1() is usually added to the prompt inside a command
substitution, imposing the overhead of fork()ing a subshell. Using
__git_ps1() for $PROMPT_COMMAND is slightly faster, because it avoids
that command substitution.
Mention this in the comments about setting up the git prompt.
The whole
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Basically, having the CLI parser and the config parser flip two
different sets of variables, so we can discriminate who set what.
What annoys me is that this is the first instance of such a
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
If the user said git push without an explicit request to push to
ram, and if branch.master.pushremote was not set to ram, and
still the command git push pushed the branch to ram, then I
would understand what you are
Junio C Hamano wrote:
In any case, I am still not convinced yet that status.short is a
real problem if --porcelain readers trip with ## branchname
output. Isn't it that the readers are broken and need fixing?
If you're going to read the configuration and then scramble to reset
it in
Yann Droneaud ydrone...@opteya.com writes:
- Why git diff does not always report the CRLF/LF mismatch ?
Most likely because you are telling safecrlf not to error out but
just warn, and then you are not fixing the cause of the warning? So
diff would say Ok, you must know what you are doing, so
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
benoit.per...@ensimag.fr writes:
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 000..a2f0aa1
--- /dev/null
+++
On Mon, Jun 24, 2013 at 06:56:17PM +0200, Matthieu Moy wrote:
Good eyes. But if we encourage people to run non-*.perl version,
perhaps we should drop the executable bit from the source, no?
But by default, I'd say consistency is most important so if other *.perl
are executable, we should
Le 24.06.2013 18:37, Yann Droneaud a écrit :
I'm still trying to use .gitattributes text flag with CRLF line
ending files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status:
Le 2013-06-24 18:56, Matthieu Moy a écrit :
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
benoit.per...@ensimag.fr writes:
diff --git a/contrib/mw-to-git/git-mw.perl
b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 000..a2f0aa1
1 - 100 of 167 matches
Mail list logo
