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
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 ou
Johan Herland 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 place.
Junio C Hamano writes:
> Arnaud Fontaine 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 can sort of understand the
Johan Herland 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 exactly
Johan Herland 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
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
---
git-rebase--interactive.sh| 13 ++---
t/t3404-rebase-interactive.sh | 11 ++
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 b
Ramkumar Ramachandra 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 do
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 tri
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 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.
>
> Shouldn't ther
Ramkumar Ramachandra 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 easy and safe
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 exi
Ramkumar Ramachandra 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 = is_workflo
On Mon, Jun 24, 2013 at 9:28 AM, Junio C Hamano wrote:
> Johan Herland 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
On Mon, Jun 24, 2013 at 4:33 AM, Johan Herland wrote:
> On Mon, Jun 24, 2013 at 9:28 AM, Junio C Hamano wrote:
>> Johan Herland 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 lo
On Mon, Jun 24, 2013 at 9:59 AM, Junio C Hamano wrote:
> Johan Herland 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
>>>
On Mon, Jun 24, 2013 at 9:46 AM, Ramkumar Ramachandra
wrote:
> Johan Herland wrote:
>>> +static void setup_push_current(struct remote *remote, struct branch
>>> *branch)
>>> +{
>>> + if (!branch)
>>> + die(_(message_detached_head_die), remote->name);
>>> + add_refspec(br
On Mon, Jun 24, 2013 at 10:44 AM, Eric Sunshine wrote:
> On Mon, Jun 24, 2013 at 4:33 AM, Johan Herland wrote:
>> On Mon, Jun 24, 2013 at 9:28 AM, Junio C Hamano wrote:
>>> Johan Herland writes:
>>>
> + git --git-dir="${3:-repo1}" log -1 --format='%h %s' "$2" >actual
> &&
>>
Francis Moreau writes:
> On Thu, Jun 20, 2013 at 3:20 PM, Thomas Rast wrote:
>> positive=$(git rev-parse "$@" | grep -v '^\^')
>> negative=$(git rev-parse "$@" | grep '^\^')
>> boundary=$(git rev-list --boundary $positive ^master | sed -n 's/^-//p')
>> # the intersection is
>> git rev-
SZEDER Gábor 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 on a branc
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
---
Documentation/urls.txt
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
---
Documentation/diff-options.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documen
Fix refspec asterisks in the -t/--tags section of the fetch-options
documentation.
Signed-off-by: Fraser Tweedale
---
Documentation/fetch-options.txt | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
Fraser Tweedale 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::
> --tags:
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 writes:
>
> > diff --git a/Documentation/fetch-options.txt
> > b/Documentation/fetch-options.txt
> > index 9cb6496..f2ac3bc 100644
> > --- a/Documentati
Hi,
Le 21.06.2013 23:57, Junio C Hamano a écrit :
Junio C Hamano 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 (see my
other mail a
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 inse
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 somethi
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 status.
Ramkumar Ramachandra 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 --porcelain
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 --porce
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 ob
Arnaud Fontaine 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 space
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 a
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
Matthieu Moy 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 on what is the correct wa
Ramkumar Ramachandra 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 now and re-im
Junio C Hamano 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 needs to be fix
Ramkumar Ramachandra 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
> s->commitable and
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
Signed-off-by: Junio C Hamano
---
quote.c | 55 ++-
1 file changed, 2 insertions(+), 53 deletion
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() in
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
Signed-off
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:/msysgi
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 retur
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, press
Add new section "Interactive mode" for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin
Helped-by: Eric Sunshine
Signed-off-by: Junio C Hamano
---
Documentation/git-clean.txt | 65 +++--
1 file changed, 63 insertions(+), 2 deletions(-)
d
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
Signed-off-by: Ju
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
Comments-by: Matthieu Moy
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 4
builtin/clean.c | 49 +++
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as "color.interactive" and
"color.interactive." for command `git-add--interactive`.
Signed-off-by: Jiang Xin
Comments-by: Matthieu Moy
Signed-off-by: Junio C Hamano
---
Documentatio
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 and
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
Signed-off-by: Junio C Hamano
---
Documentati
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
Signed-off-by: Junio C Hamano
---
builtin/clean.c | 36
1 file
On Mon, Jun 24, 2013 at 4:19 PM, Ramkumar Ramachandra
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
Signed-off-by: Junio C Hamano
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755 t/t7301-clean-interactive.sh
diff --git a/t/t7301-clean-in
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.
Tha
Ramkumar Ramachandra 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 explicit
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,
Johan Herland 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 as more of a si
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
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 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.
>
> Signed-off-by: Fraser
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 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, but I can't rememb
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 repos
Matthieu Moy 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 executable in Git's tree
Use '>file' instead of '> file', in accordance with the coding
guidelines.
Signed-off-by: SZEDER Gábor
---
t/t9903-bash-prompt.sh | 232 -
1 file changed, 116 insertions(+), 116 deletions(-)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-promp
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 comma
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
---
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 @@ test_expect_success 'pro
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 us
Helped-by: Jeff King
Signed-off-by: SZEDER Gábor
---
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
+++ b/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
---
contrib/completion/git-prompt.sh | 201 ---
1 file changed, 101 insertions(+), 100
__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 symboli
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/)' command
substitution for each. That is not quite the most efficient way to
read single line single w
There are a couple of '$(git rev-parse --)' 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'),
- and
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 fork()+exec()i
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 substitution
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 t
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 ' to directly assign
the output to that variable.
zsh's printf doesn't support the '-v ' option, so stick with the
comm
__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 writes:
> Matthieu Moy 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
Ramkumar Ramachandra 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 worrie
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 wt_po
Yann Droneaud 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 I trust
what is in
Junio C Hamano writes:
> Matthieu Moy 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
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
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 writes:
Matthieu Moy 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.per
Junio C Hamano wrote:
> If you do not set anywhere (like branch.master.pushremote or
> remote.pushdefault) to push to "ram", and if you did not say "git
> push ram" but just said "git push", we will not push to "ram"
> (otherwise it is broken). So if the push is going to "ram", the
> user must hav
Matthieu Moy writes:
> Scripts that want the branch information can use --branch.
> Scripts that do not have absolutely nothing to gain in getting this
> extra output (only extra parser complexity).
OK, I could buy that.
I personally have always _assumed_ that the way the "--porcelain"
output w
Junio C Hamano writes:
> Johan Herland 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
1 - 100 of 164 matches
Mail list logo
