Am 7/2/2013 0:50, schrieb Alexey Shumkin:
> On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
>> Am 6/26/2013 12:19, schrieb Alexey Shumkin:
>>> test_expect_success 'setup complex body' '
>>> git config i18n.commitencoding iso8859-1 &&
>>> echo change2 >foo && git commit -a -F
On Tue, Jul 2, 2013 at 2:24 AM, Jeff King wrote:
> When we call find_common to start finding common ancestors
> with the remote side of a fetch, the first thing we do is
> insert the tip of each ref into our rev_list linked list. We
> keep the list sorted the whole time with
> commit_list_insert_b
Hi,
for my Linux-kernel build-script I am searching for a reliable check
of getting the ***latest*** version.
This could be 'v3.x.y-stable' or 'v3.x.y-rcX'.
'git tag' seems to be fast, but not reliable.
'git log --oneline' is slow, but does the job.
For getting v3.x.y-stable this seems to work..
Hello,
Sorry for the late reply.
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> You should use ${var:+if_set_to_nonempty_use_this} here.
>> ...
>> So munging it manually with sloppy "sed" script is simply wrong.
>
> Perhaps something like this on top of your patch squashed in?
>
> The e
Merge strategy and its options can be specified in `git rebase`,
but with `--interactive`, they were completely ignored.
Signed-off-by: Arnaud Fontaine
---
git-rebase--interactive.sh| 21 -
t/t3404-rebase-interactive.sh | 11 +++
2 files changed, 27 insertions(+),
On Mon, Jul 1, 2013 at 2:39 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
>> new file mode 100755
>> index 000..9007bae
>> --- /dev/null
>> +++ b/contrib/contacts/git-contacts
>> @@ -0,0 +1,121 @@
>> +#!/usr/b
On 07/01/2013 09:54 PM, Miklos Vajna wrote:
> This has multiple benefits: with more than one of {"--ff", "--no-ff",
> "--ff-only"} respects the last option; also the command-line option to
> always take precedence over the config file option.
>
> Signed-off-by: Miklos Vajna
> ---
>
> On Mon, Jul
Sedat Dilek wrote:
> for my Linux-kernel build-script I am searching for a reliable check
> of getting the ***latest*** version.
$ git describe HEAD
If you want a sorted list of tags,
$ git for-each-ref --sort=taggerdate --format="%(refname:short)" refs/tags
Are you looking for something el
On Mon, Jul 1, 2013 at 2:50 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> Accept multiple patch files rather than only one. For example:
>>
>> % git contacts feature/*.patch
>>
>> Signed-off-by: Eric Sunshine
>
>> @@ -93,6 +96,7 @@ sub commits_from_patch {
>> while (<$f>) {
>>
On 2013-05-24 01:23, Alois Mahdal wrote:
[...]
When I use `git log --follow file` all is OK, but once I add
`--reverse` to it, it no longer follows the file beyond renames.
This makes it hard to query for when the file was really added,
which I was trying to achieve with
$ git -1 --reverse
On Mon, Jul 1, 2013 at 1:00 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> No attempt is made to answer Junio's v9 review[5], as I lack sufficient
>> insight with '-C' options to be able to respond properly.
>
> I just wanted to see if we want to allow the end user of this script
> to spe
fs/tags | grep ^'v3.[0-9]*' | tail -1
v3.10
$ git for-each-ref --sort=taggerdate --format="%(refname:short)"
refs/tags | grep ^'next-[0-9]*' | tail -1
next-20130702
Another question if I may ask:
Sometimes I need to bisect a previous Linux-Next version.
What I a
On 07/01/2013 11:58 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> My understanding is that we are waiting on two things:
>>
>> 1. Consensus from the community. I would characterize the feedback on
>> the mailing list as limited in quantity but strongly positive [1-4] and
>> I think t
Alois Mahdal wrote:
> This [has been reported][1] to this list about half a year ago
> but with no response so I'm not even sure if it's been
> acknowledged as bug.
Yes, this is a bug. However, it is not at all easy to fix; so I would
recommend that you contribute a documentation patch/ failing
On Fri, May 24, 2013 at 01:23:24AM +0200, Alois Mahdal wrote:
> Hello!
>
> This [has been reported][1] to this list about half a year ago
> but with no response so I'm not even sure if it's been
> acknowledged as bug.
>
> [1]: http://marc.info/?l=git&m=135215709307126&q=raw
>
> When I use `gi
On 07/02/2013 05:02 AM, Martin Fick wrote:
> I have often reported problems with git fetch when there are
> many refs in a repo, and I have been pleasantly surprised
> how many problems I reported were so quickly fixed. :) With
> time, others have created various synthetic test cases to
> ensur
On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
> On Fri, May 24, 2013 at 01:23:24AM +0200, Alois Mahdal wrote:
> > Hello!
> >
> > This [has been reported][1] to this list about half a year ago
> > but with no response so I'm not even sure if it's been
> > acknowledged as bug.
> >
Lukas Fleischer writes:
> On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
[...]
>> $ git log --oneline --follow builtin/clone.c | wc -l
>> 125
>> $ git log --oneline --follow --reverse builtin/clone.c | wc -l
>> 3
>
> I just wanted to point out that it works fine whe
On 02/07/13 04:48, Junio C Hamano wrote:
> Chris Packham writes:
>
>> +!*)
>> +command="$(expr "$update_module" : '!\(.*\)')"
>
> command=${command#!}
>
Thanks, expr was my attempt to avoid using a ${command:1} bash-ism. v3
on it's way.
--
Users can set submodule.$name.update to '!command' which will cause
'command' to be run instead of checkout/merge/rebase. This allows the
user some finer grained control over how the update is done. The primary
motivation for this was interoperability with stgit however being able
to intercept the
On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote:
> Lukas Fleischer writes:
>
> > On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
> [...]
> >> $ git log --oneline --follow builtin/clone.c | wc -l
> >> 125
> >> $ git log --oneline --follow --reverse builtin/clo
so fetch all tags:
$ git fetch --tags
and decide what to do with them later:
$ git merge next-20130628
In the process, next-20130628 hasn't changed: you can still use it as a
bisect endpoint.
> If I have all -next tags merged-in, I will get always today's 'next-
ext-20130628
>
> In the process, next-20130628 hasn't changed: you can still use it as a
> bisect endpoint.
>
>> If I have all -next tags merged-in, I will get always today's
>> 'next-20130702'.
>> Due to my poor git skillz I do this manually for git-b
Am 5/24/2013 1:23, schrieb Alois Mahdal:
> ...query for when the file was really added,
> which I was trying to achieve with
>
> $ git -1 --reverse --follow several_times_renamed_file
Assuming you meant 'git log -1 ...' or similar. It won't do what you think
it would do because:
* -1 is a re
On Mon, Jul 1, 2013 at 11:56 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> On Tue, May 21, 2013 at 5:35 PM, Junio C Hamano wrote:
>>> ... I think we can go either way, and the above "I think this is
>>> being rerolld" was primarily keeping the options open.
>>
>> You're right. No point in
Check us out at!
http://www.apollobayrealestate.com.au/onlinegirls.html
--
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
Check us out at!
http://www.apollobayrealestate.com.au/onlinegirls.html
--
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
This has multiple benefits: with more than one of {"--ff", "--no-ff",
"--ff-only"} respects the last option; also the command-line option to
always take precedence over the config file option.
Signed-off-by: Miklos Vajna
---
builtin/merge.c | 55 +
On 2013-07-01 00.56, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> I testet "rj/cygwin-remove-cheating-lstat" with the "socket pipe" on top:
>> no hanging.
>>
>> Then I run "rj/cygwin-remove-cheating-lstat" without "socket pipe",
>> (or in other words git.git/pu):
>> No hanging.
>
>
There are often parent pages logically above the gitweb projects
list, e.g. home pages of the organization and department that host
the gitweb server. This change allows you to include links to those
pages in gitweb's breadcrumb trail.
Signed-off-by: Tony Finch
---
Documentation/gitweb.conf.txt
Kyle McKay writes:
> Do you feel that it's important to accept these alternate URL versions
> that are not listed on the project page:
>
> 1) Optional trailing '/'
> 2) For the ssh scp form, optional leading '/'
3) Optional trailing .git
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Ke
Am 02.07.2013 12:12, schrieb Chris Packham:
> Users can set submodule.$name.update to '!command' which will cause
> 'command' to be run instead of checkout/merge/rebase. This allows the
> user some finer grained control over how the update is done. The primary
> motivation for this was interoperab
On Tuesday, July 02, 2013 03:24:14 am Michael Haggerty
wrote:
> > git rev-list HEAD | for nn in $(seq 0 100) ; do for c
> > in $(seq 0 1) ; do read sha ; echo $sha
> > refs/c/$nn/$c$nn ; done ; done > .git/packed-refs
>
> I believe this generates a packed-refs file that is not
> sorted lexic
Fredrik Gustafsson writes:
> This was actually a bit tricky. When I changed
> git clone $depth
> to
> git clone "$depth"
>
> git clone dies with the error "too many arguments".
... when $depth is empty.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942
Signed-off-by: Michal Sojka
---
contrib/emacs/git-blame.el | 17 +
1 file changed, 17 insertions(+)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 573f408..5c8933e 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -110,8 +110,
Hi all,
following are a few fixes and enhancements to Emacs' git-blame-mode
(contrib/emacs/git-blame.el).
Michal Sojka (4):
git-blame.el: Fix buffer local declaration
git-blame.el: Make all line prefixes to have the same length
git-blame.el: Allow displaying author/commit times
git-blame.
git-blame-cache was declared buffer-local two times and
git-blame-idle-timer is global. The intended meaning was probably to make
git-blame-idle-timer buffer-local.
Signed-off-by: Michal Sojka
---
contrib/emacs/git-blame.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cont
Now, the format resembles more the default format of `git blame`.
Signed-off-by: Michal Sojka
---
contrib/emacs/git-blame.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 5c8933e..74b1486 100644
--- a/contrib/ema
Without this patch, the beginning of git-blame.el in emacs buffer looks
like this (note the Messige-ID line):
b52ba1 :;; Authors:David Kågedal
b52ba1 :;; Created:31 Jan 2007
28389d :;; Message-ID: <87iren2vqx.fsf@morpheus.local>
b52ba1 :;; License:GPL
b52ba1 :;; Keywords: gi
On Tuesday, July 02, 2013 12:11:49 am Jeff King wrote:
> Here are my patches to deal with Martin's pathological
> case, split out for easy reading. I took a few timings
> to show that the results of the 3rd patch are noticeable
> even with 50,000 unique refs (which is still a lot, but
> something t
Sending again because the first one bounced.
Am 02.07.2013 03:39, schrieb Fredrik Gustafsson:
> When a submodule is clone, clone it width the --depth flag. This is useful
> when the submodule(s) are huge and you're not really interested in anything
> but the latest commit.
>
> Tests are added and
On Mon, Jul 1, 2013 at 10:01 PM, Jeff King wrote:
> On Tue, Jul 02, 2013 at 12:41:51AM -0400, Jeff King wrote:
>
>> I replicated your test setup, and the problem is that we have many
>> common objects on both sides during the ref negotiation. So we end up in
>> rev_list_push for each one, which ha
Add the --depth option to the add and update commands of "git submodule",
which is then passed on to the clone command. This is useful when the
submodule(s) are huge and you're not really interested in anything but
the latest commit.
Tests are added and to make --depth work the path for test "setu
Stefan Näwe writes:
>> While I wasn't paying much attention to this, I vaguely recall that
>> people pointed out that using a fresh clone every time may not be
>> what you want to do in the first place, and I happen to agree with
>> them (and that is why I am not very much interested in this topi
Eric Sunshine writes:
>> The author name and email can be grabbed from the "blame" output
>> without doing this (and the result may be more robust), but you
>> would need to read from the log message anyway, so I think this is
>> OK.
>>
>> Note that the names and emails in blame output are saniti
Michael Haggerty writes:
> You allow --no-ff-only but ignore it, which I think is incorrect. In
>
> git merge --ff-only --no-ff-only [...]
>
> , the --no-ff-only should presumably cancel the effect of the previous
> --ff-only (i.e., be equivalent to "--ff").
Ideally, if we were starting fro
Michael Haggerty writes:
> I have a logistical question: git-multimail doesn't have its own mailing
> list, and GitHub doesn't offer one. I was thinking about setting up a
> Google group, but a few people at GitMerge suggested that I instead
> direct discussion of git-multimail to the main Git m
Fredrik Gustafsson writes:
> git clone dies with the error "too many arguments". This was solved with
> changing
> depth=$5
> to
> depth="$5"
>
> which I don't understand since variable assignment doesn't expand $5 and
> therefore
> "" should not be needed, AFAIK. Any comments on this?
A red h
On Tue, Jul 2, 2013 at 2:32 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>>> The author name and email can be grabbed from the "blame" output
>>> without doing this (and the result may be more robust), but you
>>> would need to read from the log message anyway, so I think this is
>>> OK.
>
Thomas Rast writes:
> Lukas Fleischer writes:
>
>> On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
> [...]
>>> $ git log --oneline --follow builtin/clone.c | wc -l
>>> 125
>>> $ git log --oneline --follow --reverse builtin/clone.c | wc -l
>>> 3
>>
>> I just wanted t
Hi,
I figured that we should quickly read through git-multimail and give
it an on-list review. Hopefully, it'll educate the list about what
this is, and help improve the script itself.
Sources: https://github.com/mhagger/git-multimail
git_multimail.py wrote:
> #! /usr/bin/env python2
Do all di
Alexey Shumkin writes:
> v8 of this patch series includes the following changes against v7:
Oops, isn't this already in 'next'? In that case, please feed
incremental updates on top of the patches that are already queued as
improvements and fixes.
Thanks.
--
To unsubscribe from this list: send
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to do this currently, is it planned, or
would it be deemed useful en
On Tue, Jul 02, 2013 at 12:37:13PM -0700, Ed Hutchins wrote:
> I realize that branch names are ephemeral repo-specific things, but it
> would be really useful to be able to determine what branch a commit
> was authored from (as a hint to ancestry graph layout tools, for
> example). Is there any way
Ed Hutchins writes:
> I realize that branch names are ephemeral repo-specific things, but it
> would be really useful to be able to determine what branch a commit
> was authored from (as a hint to ancestry graph layout tools, for
> example).
Hmm. I think the current thinking so far is that it i
Miklos Vajna writes:
>> if (fast_forward == FF_ONLY)
>> fast_forward = FF_ALLOW;
>
> Do we really want --no-ff-only? I would rather just disable it, see the
> updated patch.
Sounds sane.
>> I'm no options guru, but I think it would be possible to implement --ff
>> and --no-ff withou
On Tue, Jul 2, 2013 at 9:37 PM, Ed Hutchins wrote:
> I realize that branch names are ephemeral repo-specific things, but it
> would be really useful to be able to determine what branch a commit
> was authored from (as a hint to ancestry graph layout tools, for
> example). Is there any way to do th
I'm not sure I follow how it could be actively harmful? I would think
the "author branch"
nomenclature (as opposed to just calling it "branch") along with clear
documentation
that these values are just captures of the particular state the commit
was authored
from would more than assuage any potenti
When using git fetch --prune, git will remove any branches from
remotes/origin/ that have inconsistent case in folder names.
This issue has been verified in versions 1.7.10.2, 1.7.11.1 and 1.8.3.2.
I've described the reproduction steps here as I carried them out, and
listed the plaforms I used to
On Wed, Jul 03, 2013 at 12:53:39AM +0530, Ramkumar Ramachandra wrote:
> > class CommandError(Exception):
> > def __init__(self, cmd, retcode):
> > self.cmd = cmd
> > self.retcode = retcode
> > Exception.__init__(
> > self,
> > 'Command "%s" failed
Consider these two scenarios.
1. If you are collaborating with others and you have arranged with
the participants to rewind a shared branch, you would do
something like this:
$ git fetch origin branch
... fetch everything so that we won't lose anything ...
$ git chec
Am 02.07.2013 20:08, schrieb Fredrik Gustafsson:
> Add the --depth option to the add and update commands of "git submodule",
> which is then passed on to the clone command. This is useful when the
> submodule(s) are huge and you're not really interested in anything but
> the latest commit.
>
> Tes
On Fri, Jun 28, 2013 at 03:41:34PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> >> Here, "git pull . branch1" is merely saying "I want to integrate
> >> the work on my current branch with that of branch1" without saying
> >> how that integration wants to happen.
> >
> > The change that
John Keeping wrote:
> I have to say that I don't think this is a particularly useful review,
> you seem to have skipped huge portions of the code and spent a lot of
> time making us read your thought process rather than providing
> constructive feedback. What feedback there is mostly seems to be
>
Add the --depth option to the add and update commands of "git submodule",
which is then passed on to the clone command. This is useful when the
submodule(s) are huge and you're not really interested in anything but
the latest commit.
Tests are added and some indention adjustments were made to conf
Ramkumar Ramachandra writes:
>> def get(self, name, default=''):
>> try:
>> values = self._split(read_git_output(
>> ['config', '--get', '--null', '%s.%s' % (self.section,
>> name)],
>> env=self.env, keepends=True,
>>
From: Benoit Person
For now, git-remote-mediawiki is only a remote-helper. This patch adds a new
toolset script in which we will be able to build new tools for
git-remote-mediawiki.
This toolset uses a subcommand-mechanism to launch the proper action. For now
only the 'help' subcommand is implem
From: Benoit Person
In the current state, a user of git-remote-mediawiki can edit the markup text
locally, but has to push to the remote wiki to see how the page is rendererd.
Add a new 'git mw preview' command that allows rendering the markup text on
the remote wiki without actually pushing any
From: Benoit Person
For now, Git::Mediawiki contains nothing.
This first patch moves some of git-remote-mediawiki.perl's factorisable code
into Git::Mediawiki. In the same time, it removes the side effects of that code
and renames the fucntions and constants moved to expose a better API.
Signed
From: Benoit Person
The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.
changes from v6:
- Rewrite of bin-wrapper/git in 3/7
- Update wrap-for-bin.sh and make bin-wrappers chainable it
removes the nee
From: Benoit Person
For now, bin-wrappers (based on wrap-for-bin.sh) redefine some
environnement variables (like $GITPERLLIB). If we want to chain to
those scripts and define one of those variables before, our changes
will be overwritten.
This patch simply makes the bin-wrappers prepend their mo
From: Benoit Person
Until now, if git-remote-mediawiki was not installed, the test suite
copied it to the toplevel directory. This solution pollutes the
directory with untracked files. Plus, we would need to copy the new
git-mw.perl file to test it too.
Signed-off-by: Benoit Person
Signed-off-b
From: Benoit Person
The introduction of the Git::Mediawiki package makes it impossible to test,
without installation, git-remote-mediawiki and git-mw.
Using a git bin-wrapper enables us to define proper $GITPERLLIB to force the
use of the developement version of the Git::Mediawiki package, bypas
From: Benoit Person
Currently, the mw-to-git project contains only a remote helper
(git-remote-mediawiki.perl). To improve the user experience while
working with mediawiki remotes, new tools, designed for such cases,
should be created. To achieve this goal, the project needs a way to
share code b
On Tue, Jul 2, 2013 at 10:57 PM, Junio C Hamano wrote:
[...]
> (2) Add --compare-and-swap=dst:expect parameters, e.g.
>
> $ git push --cas=master:deadbabecafe --cas=next:cafebabe ":"
>
> This removes the "reservation" I expressed against (1) above
> (i.e. we are doing a "matc
benoit.per...@ensimag.fr writes:
> From: Benoit Person
>
> Currently, the mw-to-git project contains only a remote helper
> (git-remote-mediawiki.perl). To improve the user experience while
> working with mediawiki remotes, new tools, designed for such cases,
> should be created.
The above is to
benoit.per...@ensimag.fr writes:
> From: Benoit Person
>
> For now, bin-wrappers (based on wrap-for-bin.sh) redefine some
> environnement variables (like $GITPERLLIB). If we want to chain to
> those scripts and define one of those variables before, our changes
> will be overwritten.
>
> This patc
benoit.per...@ensimag.fr writes:
> +GIT_ROOT_DIR=../../..
> +GIT_EXEC_PATH=$(cd "$(dirname "$0")" && cd ${GIT_ROOT_DIR} && pwd)
> +
> +GITPERLLIB="$GIT_EXEC_PATH"'/contrib/mw-to-git:'"$GITPERLLIB"
The same comment on ':' applies here.
> +PATH="$GIT_EXEC_PATH"'/contrib/mw-to-git:'"$PATH"
But not
> Do we want to add that ':' unconditionally? Could GITPERLLIB be
> empty?
For now, GITPERLLIB is only used in that kind of statements:
use lib (split(/:/, $ENV{GITPERLLIB} || ... ));
The trailing ':' does not really matter, split will ignore it.
With the current codebase, I think it's nicer to
On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann wrote:
> Am 02.07.2013 12:12, schrieb Chris Packham:
>> --- a/Documentation/git-submodule.txt
>> +++ b/Documentation/git-submodule.txt
>> @@ -159,7 +159,9 @@ update::
>> This will make the submodules HEAD be detached unless `--rebase` or
>>
From: Brandon Casey
When pushing, each ref in the local repository must be paired with a
ref advertised by the remote server. Currently, this is performed by
first applying the refspec to the local ref to transform the local ref
into the name of the remote ref, and then performing a linear searc
On 07/02/2013 09:23 PM, Ramkumar Ramachandra wrote:
> I figured that we should quickly read through git-multimail and give
> it an on-list review. Hopefully, it'll educate the list about what
> this is, and help improve the script itself.
Wonderful, thanks!
> Sources: https://github.com/mhagger/
On Jul 2, 2013, at 09:55, Andreas Schwab wrote:
Kyle McKay writes:
Do you feel that it's important to accept these alternate URL
versions
that are not listed on the project page:
1) Optional trailing '/'
2) For the ssh scp form, optional leading '/'
3) Optional trailing .git
Thank you fo
On Tue, Jul 02, 2013 at 04:53:48PM -0700, Brandon Casey wrote:
> From: Brandon Casey
>
> When pushing, each ref in the local repository must be paired with a
> ref advertised by the remote server. Currently, this is performed by
> first applying the refspec to the local ref to transform the loc
On Wed, Jul 3, 2013 at 12:55 AM, Johan Herland wrote:
> I assume that in most cases the expected value of the remote ref would
> equal the current value of the corresponding remote-tracking ref in
> the user's repo, so why not use that as the default expected value?
> E.g.:
>
> $ git config push
Am 03.07.2013 01:26, schrieb Chris Packham:
> On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann wrote:
>> Am 02.07.2013 12:12, schrieb Chris Packham:
>>> --- a/Documentation/git-submodule.txt
>>> +++ b/Documentation/git-submodule.txt
>>> @@ -159,7 +159,9 @@ update::
>>> This will make the submodu
86 matches
Mail list logo
