On Tue, 18 Jun 2013, Jeff King wrote:
TL;DR: I'm just confirming what's said here! =)
My understanding of curl's pointer requirements are:
1. Older versions of curl (and I do not recall which version off-hand,
but it is not important) stored just the pointer. Calling code was
required
On Sat, Jun 15, 2013 at 04:01:04PM +0200, Mark Abraham wrote:
> Controlled by new configuration option
> "color.word-diff-in-interactive-add". There is no existing support for
> "git add" to pass a command-line option like "--word-diff=color" to
> git-add--interactive.perl, so a configuration opti
On Mon, Jun 17, 2013 at 06:40:49PM -0700, Brandon Casey wrote:
> From: Brandon Casey
>
> remote_find_tracking() populates the query struct with an allocated
> string in the dst member. So, we do not need to xstrdup() the string,
> since we can transfer ownership from the query struct (which wil
On Tue, Jun 18, 2013 at 04:17:03AM +0200, SZEDER Gábor wrote:
> The whole series speeds up the bash prompt on Windows/MSysGit
> considerably. Here are some timing results in two scenarios, repeated
> 10 times:
>
> At the top of the work tree, before:
>
> $ time for i in {0..9} ; do prompt="
On Tue, Jun 18, 2013 at 04:16:55AM +0200, SZEDER Gábor wrote:
> - echo "#!$SHELL_PATH" >fake_editor.sh &&
> - cat >>fake_editor.sh <<\EOF &&
> -echo "exec echo" >"$1"
> -echo "edit $(git log -1 --format="%h")" >>"$1"
> -echo "exec echo" >>"$1"
> -EOF
> + cat >fake_editor.sh <<-EOF &&
>
On Mon, Jun 17, 2013 at 11:18:45AM +0200, Thomas Rast wrote:
> Here's the promised reroll. It integrates everyone's suggestions (I
> hope I didn't miss any), most notably the two by Peff:
Thanks. With the exception of a few comments on patch 3, this looks good
to me.
I agree with your "gross ha
On Mon, Jun 17, 2013 at 11:18:48AM +0200, Thomas Rast wrote:
> As suggested by Jeff King, this takes care to wrap the entire test_expect_*
> block, but nothing else, in the verbose toggling. To that end we use
> a new pair of hook functions. The placement is a bit weird because we
> need to wait
On Mon, Jun 17, 2013 at 07:00:40PM -0700, Brandon Casey wrote:
> Curl requires that we manage any strings that we pass to it as pointers.
> So, we should not be overwriting this strbuf after we've passed it to
> curl.
My understanding of curl's pointer requirements are:
1. Older versions of cu
Hi Thomas,
Thomas Ackermann wrote:
> This target was only used to create user-manual.pdf with dblatex
> using a separate style definition than was used for user-manual.html.
> These two style definitions had to be maintained separately and
> so made improvements to user-manual.html unnecessarily
Jun 17, 2013 at 01:14:51PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>> Signed-off-by: John Keeping
>> ---
>
> Thanks; will directly apply 1/2 on maint. I am not absolutely sure
> about this one, where variables related to an optional "info"
> support used to be in one place but with
On Mon, Jun 17, 2013 at 10:16 PM, SZEDER Gábor wrote:
> From: SZEDER Gábor
>
> __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 r
On Mon, Jun 17, 2013 at 10:00 PM, Brandon Casey wrote:
> From: Brandon Casey
>
> Curl requires that we manage any strings that we pass to it as pointers.
> So, we should not be overwriting this strbuf after we've passed it to
> curl.
>
> Additionally, it is unnecessary since we only prompt for th
Forgot to mention that it's built on top of 2847cae8 (prompt: squelch
error output from cat, 2013-06-14).
Best,
Gábor
On Tue, Jun 18, 2013 at 04:16:53AM +0200, SZEDER Gábor wrote:
> Hi,
>
> displaying the git-specific bash prompt on Windows/MinGW takes quite
> long, long enough to be noticeabl
The use of colors in a prompt is only possible in
pcmode (using the variable PROMPT_COMMAND).
Enable color prompt in non-pcmode (using the variable
PS1) for both Bash and ZSH.
Signed-off-by: Eduardo R. D'Avila
---
15 9 contrib/completion/git-prompt.sh
19 0 t/t9903-bash-prom
From: SZEDER Gábor
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
From: SZEDER Gábor
>From the four '$(git rev-parse --)' command substitutions
__git_ps1() executes three in its 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 the
From: SZEDER Gábor
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 do
From: SZEDER Gábor
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 a variable.
zsh's printf doesn't support the '-v ' option, so s
From: SZEDER Gábor
When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() runs the '$(cut -c1-7
.git/HEAD)' command substitution to put the 7 hexdigits abbreviated
commit object name in the prompt. This imposes the overhead of
fork()ing a subsh
From: SZEDER Gábor
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 1047c664..48460ef6 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -40,6 +40,15 @@ tes
From: SZEDER Gábor
... 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, 1
From: SZEDER Gábor
__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
From: SZEDER Gábor
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
From: SZEDER Gábor
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
From: SZEDER Gábor
Also move the shebang line into the here document.
Signed-off-by: SZEDER Gábor
---
t/t9903-bash-prompt.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 7c7f8b97..b0af5d5f 100755
--- a/t/
The use of colors in a prompt is only possible in
pcmode (using the variable PROMPT_COMMAND).
Enable color prompt in non-pcmode (using the variable
PS1) for both Bash and ZSH.
Signed-off-by: Eduardo R. D'Avila
---
15 9 contrib/completion/git-prompt.sh
19 0 t/t9903-bash-prom
From: SZEDER Gábor
__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
From: SZEDER Gábor
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
__git_ps1_colorize_gitstring() sets color codes and
builds the prompt gitstring. It has duplicated code
to handle color codes for bash and zsh shells.
__git_ps1() also has duplicated logic to build the
prompt gitstring.
Remove duplication of logic to build gitstring in
__git_ps1_colorize_gitstring
From: SZEDER Gábor
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
git-prompt.sh lacks tests for PROMPT_COMMAND mode.
Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh
Having these tests enables an upcoming refactor in
a safe way.
Signed-off-by: Eduardo R. D'Avila
---
254 0 t/t9903-
From: Brandon Casey
Curl requires that we manage any strings that we pass to it as pointers.
So, we should not be overwriting this strbuf after we've passed it to
curl.
Additionally, it is unnecessary since we only prompt for the user name
and password once, so we end up overwriting the strbuf w
From: Brandon Casey
Prior to commit fa83a33b, the 'git checkout' DWIMery would create a
new local branch if the specified branch name did not exist and it
matched exactly one ref in the "remotes" namespace. It searched
the "remotes" namespace for matching refs using a simple comparison
of the tr
From: Brandon Casey
remote_find_tracking() populates the query struct with an allocated
string in the dst member. So, we do not need to xstrdup() the string,
since we can transfer ownership from the query struct (which will go
out of scope at the end of this function) to our callback struct, but
René Scharfe writes:
> How about going into the opposite direction and moving df_conflicts
> handling more into traverse_tree? If the function saved the mask
> and dirmask in traverse_info then callbacks could calculate the
> cumulated d/f conflicts by walking the info chain, similar to how
> ma
René Scharfe writes:
> Am 17.06.2013 22:44, schrieb Junio C Hamano:
>>
>> ... Or, perhaps we can
>>
>> - add df_conflict to struct unpack_trees_options;
>>
>> - have traverse_info->data point at struct unpack_trees_options as
>> before; and
>>
>> - save the old value of o->df_confl
Antoine Pelisse writes:
> Re-reading note: OK, This last sentence ("If not we will eventually be
> too far and break") is actually a bug. We might break before we find
> something interesting while we should keep going. For example in such
> a case, we should display like this, but won't:
Glad t
Am 17.06.2013 22:44, schrieb Junio C Hamano:
> René Scharfe writes:
>
>>> The information is only useful for the unpack_trees callback, and
>>> "info->data" is a more appropriate place to hang such a callback
>>> specific data.
>>>
>>> Perhaps we should use info->data field to point at
>>>
>>>
On 18 June 2013, Daniel Stenberg wrote:
> On Tue, 18 Jun 2013, LCD 47 wrote:
>
> > Cloning with the git protocol works as expected.
> >
> >A search on the net shows people having the same problem more than an
> >year ago, and the solution there seems to imply that Git can't cope
> >with async D
On Tue, 18 Jun 2013, LCD 47 wrote:
Cloning with the git protocol works as expected.
A search on the net shows people having the same problem more than an year
ago, and the solution there seems to imply that Git can't cope with async
DNS in curl:
http://osdir.com/ml/freebsd-ports-bugs/201
The following snippet illustrates the problem:
$ uname -srvm
Linux 3.9.5-smp #2 SMP Mon Jun 10 02:54:26 CDT 2013 i686
$ git --version
git version 1.8.3
$ git clone https://github.com/torvalds/linux.git
Cloning into 'linux'...
fatal: unable to access 'https://github.com/torvalds/linux.git/':
Am 17.06.2013 22:44, schrieb Junio C Hamano:
> René Scharfe writes:
>
>>> The information is only useful for the unpack_trees callback, and
>>> "info->data" is a more appropriate place to hang such a callback
>>> specific data.
>>>
>>> Perhaps we should use info->data field to point at
>>>
>>>
Marc Branchaud writes:
> On 13-06-17 01:52 PM, Matthieu Moy wrote:
>> The behavior of "git push --force" is rather clear when it updates only
>> one remote ref, but running it when pushing several branches can really
>> be dangerous. Warn the users a bit more and give them the alternative to
>> p
+ } else if (changes != ULONG_MAX &&
+xch->i1 + changes - (lxch->i1 + lxch->chg1) >
max_common) {
+ break;
>>
>> If we are no longer in "interesting zone" (changes != ULONG_MAX), it
>> means we will stop if the distance is
On 13-06-17 01:52 PM, Matthieu Moy wrote:
The behavior of "git push --force" is rather clear when it updates only
one remote ref, but running it when pushing several branches can really
be dangerous. Warn the users a bit more and give them the alternative to
push only one branch.
Signed-off-by:
Junio C Hamano writes:
> Note that this has to further change if Ram's triangular push fix
> comes before 2.0.
I didn't follow precisely this topic. In any case, better have this in
the patch, if only as a reminder that this part will need to be updated.
> I am not sure if these original two li
René Scharfe writes:
>> The information is only useful for the unpack_trees callback, and
>> "info->data" is a more appropriate place to hang such a callback
>> specific data.
>>
>> Perhaps we should use info->data field to point at
>>
>> struct {
>> struct unpack_trees_option
Am 16.06.2013 16:18, schrieb John Keeping:
> Changes since v3:
>
> * There are four new patches, three of which are style fixes for
> existing tests and one fixes an existing error message to return a
> more accurate path when recursing.
>
> * You now cannot run "git submodule add " from a
>
Am 16.06.2013 02:56, schrieb Junio C Hamano:
> One thing renaming df_conficts to conflicts really proves is that
> this field is not used by the traverse_trees machinery at all.
>
> Before this patch, the bits in conflicts (now df_conflicts) mask had
> the semantics that is not consistent with the
Ralf Thielow writes:
> 2013/6/17 Junio C Hamano :
>> Ralf Thielow writes:
>>
>>> When cherry-pick is in progress, 'git status' gives the advice to
>>> run "git commit" to finish the cherry-pick. However, this won't continue
>>> the sequencer.
>>> "git status" should give the advice of running "g
John Keeping writes:
> Signed-off-by: John Keeping
> ---
Thanks; will directly apply 1/2 on maint. I am not absolutely sure
about this one, where variables related to an optional "info"
support used to be in one place but with the patch only "infodir" is
separated away. Maybe it is not a big
David Aguilar writes:
> On Sun, Jun 16, 2013 at 10:51 AM, John Keeping wrote:
>> Instead of needing a wrapper to call the diff/merge command, simply
>> provide the diff_cmd and merge_cmd functions for user-specified tools in
>> the same way as we do for built-in tools.
>>
>> Signed-off-by: John
Junio C Hamano writes:
> Dennis Kaarsemaker writes:
>
>> I'm doing daily builds of git, using many workers and a shared git.git,
>> with per-worker checkouts
>
> OK, so GIT_DIR is explicitly specified in these "workers".
>
> Makes sense.
Actually it does not. What if GIT_DIR is an empty stri
Dennis Kaarsemaker writes:
> I'm doing daily builds of git, using many workers and a shared git.git,
> with per-worker checkouts
OK, so GIT_DIR is explicitly specified in these "workers".
Makes sense.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message t
Makes sense; thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Antoine Pelisse writes:
>>> + unsigned long changes = ULONG_MAX;
>
> Let me explain what "changes" means, as I know it will help the rest
> of the message:
> It counts the number of *added* blank lines we have ignored since
> "lxch" (needed to calculate the distance between lxch and xch)
> It
Matthieu Moy writes:
> Signed-off-by: Matthieu Moy
> ---
> This is to be squashed into jc/push-2.0-default-to-simple
>
> (Noticed while writing the other patch about --force)
Thanks.
Note that this has to further change if Ram's triangular push fix
comes before 2.0.
I am not sure if these ori
Matthieu Moy writes:
> The behavior of "git push --force" is rather clear when it updates only
> one remote ref, but running it when pushing several branches can really
> be dangerous. Warn the users a bit more and give them the alternative to
> push only one branch.
>
> Signed-off-by: Matthieu M
Can someone take a look at this and let me know what I'm doing wrong?
Also, what's the best way to test filters? I can't really do -Debug or
really even print various output.
https://github.com/ag4ve/github-test
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
2013/6/17 Junio C Hamano :
> Ralf Thielow writes:
>
>> When cherry-pick is in progress, 'git status' gives the advice to
>> run "git commit" to finish the cherry-pick. However, this won't continue
>> the sequencer.
>> "git status" should give the advice of running "git cherry-pick --continue"
>> o
Ralf Thielow writes:
> When cherry-pick is in progress, 'git status' gives the advice to
> run "git commit" to finish the cherry-pick. However, this won't continue
> the sequencer.
> "git status" should give the advice of running "git cherry-pick --continue"
> or "git cherry-pick --abort".
Is th
On Mon, Jun 17, 2013 at 6:18 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> So here is a more thorough description of the option:
>
>> - real changes are interesting
>
> OK, I think I can understand it.
>
>> - blank lines that are close enough (less than context size) to
>> interestin
Ramkumar Ramachandra writes:
> + test $# == 1 ||
This is broken under POSIX shells. No need to resend (will locally
patch up).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
Mathieu Lienard--Mayor
writes:
> When in the middle of a rebase, it can be annoying to go in .git
> in order to find the SHA1 of the commit where the rebase stopped.
>
> git-status now includes this information in its default output.
> With this new information, the message is now shorter, to avo
Signed-off-by: Matthieu Moy
---
This is to be squashed into jc/push-2.0-default-to-simple
(Noticed while writing the other patch about --force)
Documentation/git-push.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-pus
This target was only used to create user-manual.pdf with dblatex
using a separate style definition than was used for user-manual.html.
These two style definitions had to be maintained separately and
so made improvements to user-manual.html unnecessarily hard.
Signed-off-by: Thomas Ackermann
---
From: "Matthieu Moy"
Sent: Monday, June 17, 2013 6:20 PM
"Philip Oakley" writes:
+ Note that `--force` applies to all the refs that are pushed,
+ hence using `git push --all --force`, or `git push --force`
+ with `push.default` set to `matching` may override refs
other
+
Junio C Hamano writes:
> In other words, the order I was anticipating to see after the
> discussion (this is different from saying "A series that is not
> ordered like this is unacceptable") was:
>
>> wt-status: remove unused field in grab_1st_switch_cbdata
>
> This is an unrelated clean-up, an
On Mon, Jun 17, 2013 at 6:18 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> So here is a more thorough description of the option:
>
>> - real changes are interesting
>
> OK, I think I can understand it.
>
>> - blank lines that are close enough (less than context size) to
>> interestin
Junio C Hamano writes:
> Will replace what has been queued on 'pu'.
... after fixing an indentation error, that is.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-in
Ramkumar Ramachandra writes:
> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
> index bf08d4e..739624e 100755
> --- a/t/t7512-status-help.sh
> +++ b/t/t7512-status-help.sh
> @@ -188,10 +188,9 @@ test_expect_success 'status when rebasing -i in edit
> mode' '
> export FAKE_LINE
The behavior of "git push --force" is rather clear when it updates only
one remote ref, but running it when pushing several branches can really
be dangerous. Warn the users a bit more and give them the alternative to
push only one branch.
Signed-off-by: Matthieu Moy
---
Documentation/git-push.tx
On Mon, Jun 17, 2013 at 9:56 AM, Joel McGahen wrote:
> Should I have just changed the origin URL in the first place to point to my
> new local repo? What I did was to just add another remote with a different
> name (temp_repo). So if I do "git remote" I see origin and temp_repo. I then
> pushed
"Philip Oakley" writes:
>> + Note that `--force` applies to all the refs that are pushed,
>> + hence using `git push --all --force`, or `git push --force`
>> + with `push.default` set to `matching` may override refs other
>> + than the current branch (including local refs
From: "Matthieu Moy"
Sent: Monday, June 17, 2013 12:09 PM
Junio C Hamano writes:
+* `matching` - push the refspec ":". In other words, push all
+ branches having the same name in both ends, even if it means
+ non-fast-forward updates. This is for those who prepare all the
+ branches into
On Mon, Jun 17, 2013 at 11:39:44AM -0400, Joel McGahen wrote:
> I have a question about GIT remote repos. Here is my scenario.
>
> 1. Work client has a repo (origin, branch of master).
> 2. Due to contractual issues I need to host a remote copy of this repo that
> my developers can utilize while
Thanks William. You response is much appreciated.
Should I have just changed the origin URL in the first place to point to my new
local repo? What I did was to just add another remote with a different name
(temp_repo). So if I do "git remote" I see origin and temp_repo. I then pushed
to "temp_
On Mon, Jun 17, 2013 at 8:39 AM, Joel McGahen wrote:
> What I need to understand is how to
> a) Connect my developer's VM local repos to the new remote repo I created so
> they can continue to work.
> b) Once the contractual issues are resolved reconnect the developer's local
> repos back to the
I have a question about GIT remote repos. Here is my scenario.
1. Work client has a repo (origin, branch of master).
2. Due to contractual issues I need to host a remote copy of this repo that my
developers can utilize while we get the contractual issues resolved as
development must continue.
3
Johannes Sixt writes:
> Am 6/17/2013 15:57, schrieb Mathieu Liénard--Mayor:
>> Le 2013-06-17 15:54, Peter Krefting a écrit :
>>> Mathieu Liénard--Mayor:
>>>
Actually, at first I dealt with it this way:
status_printf_ln(s, color,
_("Splitting %s while rebasing b
Olivier, did you upload your hacked version anywhere?
I also need something like this.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Antoine Pelisse writes:
> So here is a more thorough description of the option:
> - real changes are interesting
OK, I think I can understand it.
> - blank lines that are close enough (less than context size) to
> interesting changes are considered interesting (recursive definition)
OK.
>
Junio C Hamano writes:
> Wouldn't it make more sense to see if the given pattern matches a
> tail substring of the ref, instead of using the hardcoded "strip
> refs/heads/, refs/tags or refs/, and then match once" logic? That
> way, --refs=origin/* can find refs/remotes/origin/master by running
Namhyung Kim writes:
> In its current form, when an user wants to filter specific ref using
> --refs option, she needs to give something like --refs=refs/tags/v1.*.
>
> This is not intuitive as users might think it's enough to give just
> actual tag name part like --refs=v1.*.
I do not think "Us
Am 6/17/2013 15:57, schrieb Mathieu Liénard--Mayor:
> Le 2013-06-17 15:54, Peter Krefting a écrit :
>> Mathieu Liénard--Mayor:
>>
>>> Actually, at first I dealt with it this way:
>>>
>>> status_printf_ln(s, color,
>>> _("Splitting %s while rebasing branch '%s' on '%s'."),
>>>
Hello,
I made a small script for easier rebasing of development branches. It
is useful in case you are developing in multiple (private) branches
and you want to rebase your branches onto upstream often.
You can find it here:
https://github.com/dankeder/git-rebranch
How it works:
1. Define the
Matthieu Moy writes:
> But then the place to warn loudly is the doc for --force. What about
> this?
Sounds sensible. I am not sure if "--all" is all that common to be
singled out, though. "I always push these out" refspecs, like
[remote "origin"]
push = refs/heads/mast
Thomas Rast writes:
> Conveniently enough we have seen both already ;-) Andrew's version for
> commit.c could use a bit of refactorization, since it inserts the same
> code in two places, but then it's about the same complexity as the
> change for rebase.
>
> I'm not sure it's worth arguing abou
Le 2013-06-17 15:54, Peter Krefting a écrit :
Mathieu Liénard--Mayor:
Actually, at first I dealt with it this way:
status_printf_ln(s, color,
_("Splitting %s while rebasing branch '%s' on
'%s'."),
stopped_sha ? stopped_sha : _("a commit"),
..
Mathieu Liénard--Mayor:
Actually, at first I dealt with it this way:
status_printf_ln(s, color,
_("Splitting %s while rebasing branch '%s' on '%s'."),
stopped_sha ? stopped_sha : _("a commit"),
);
Would this be more suitable for translators
On Mon, 17 Jun 2013 17:47:07 +0400
Konstantin Khomoutov wrote:
> > For Below issue , O/S is Windows7.
> > 1.Iam getting error attached when cloning of repository is done:
>
> What error?
Okay, the Microsoft Word document with two screenshots has been
scrubbed by the list software but passed thr
On Mon, 17 Jun 2013 13:28:30 +
wrote:
> For Below issue , O/S is Windows7.
[...]
> 1.Iam getting error attached when cloning of repository is done:
What error?
> 2.Also, when file is tried to be added,it gives error below:
>
> $ git add *
> fatal: unable to stat
> 'src/development_architec
On Mon, Jun 17, 2013 at 01:28:30PM +, justin.sathyanat...@accenture.com
wrote:
> 1.Iam getting error attached when cloning of repository is done:
What error?
> 2.Also, when file is tried to be added,it gives error below:
>
> $ git add *
> fatal: unable to stat
> 'src/development_architectu
Le 2013-06-17 15:10, Peter Krefting a écrit :
Mathieu Lienard--Mayor:
+ /*
+* If the file stopped-sha does not exist
+* we go back to the old output saying "a commit"
+* instead of providing the commit's SHA1.
+*/
+ if (!stopped_sha) {
+
It was missed in the option list while mentioned from the general
description. Add it for completeness.
Signed-off-by: Namhyung Kim
---
Documentation/git-config.txt |9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index
Hi,
For Below issue , O/S is Windows7.
Regards,
Justin,
---
Sun Certified Ente
Mathieu Lienard--Mayor:
+ /*
+* If the file stopped-sha does not exist
+* we go back to the old output saying "a commit"
+* instead of providing the commit's SHA1.
+*/
+ if (!stopped_sha) {
+ stopped_sha = "a commit";
+ must
Hi,
[I rarely do reviews on this list, so feel free to ignore this.]
On 17 June 2013 13:10, Mathieu Lienard--Mayor
wrote:
> diff --git a/wt-status.c b/wt-status.c
> index bf84a86..5f5cddf 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -885,8 +885,19 @@ static void show_rebase_in_progress(st
When in the middle of a rebase, it can be annoying to go in .git
in order to find the SHA1 of the commit where the rebase stopped.
git-status now includes this information in its default output.
With this new information, the message is now shorter, to avoid
too long lines.
The new message looks
Junio C Hamano writes:
>> +* `matching` - push the refspec ":". In other words, push all
>> + branches having the same name in both ends, even if it means
>> + non-fast-forward updates. This is for those who prepare all the
>> + branches into a publishable shape and then push them out with a
1 - 100 of 113 matches
Mail list logo
