On 2015-07-02 16.00, Thomas Vieten wrote:
[]
> see the file attachend to the end of this message
Thanks for the info
>
>> It may be, that you need to "nornalize" your repo:
>>
> in principle we know all this.
> What is remarkable that we are able to checkout a version of master which is
> not consi
Hi Phillip,
Thanks for review!
2015-07-05 15:21 GMT+02:00 Phillip Sz :
>> #: help.c:214
>> msgid "git commands available from elsewhere on your $PATH"
>> msgstr "Vorhandene Git-Kommandos irgendwo in Ihrem $PATH"
>>
>
> What do you think about "Git-Kommandos sind anderwo verfügbar in Ihrem
> $P
On Sun, Jul 5, 2015 at 6:35 PM, Thomas Ferris Nicolaisen
wrote:
> On Mon, Jul 6, 2015 at 12:01 AM, Eric Sunshine
> wrote:
>> Unfortunately, the non-ASCII characters
>> in Duy's name got corrupted, and the botch is present in the patch I
>> sent. Sorry. Not sure how that happened. Can you fix it
On Mon, Jul 6, 2015 at 12:01 AM, Eric Sunshine wrote:
> Unfortunately, the non-ASCII characters
> in Duy's name got corrupted, and the botch is present in the patch I
> sent. Sorry. Not sure how that happened. Can you fix it locally?
Fixed [1].
[1]
https://github.com/git/git.github.io/commit/b5
On Sun, Jul 5, 2015 at 5:13 PM, Christian Couder
wrote:
> On Sun, Jul 5, 2015 at 9:11 PM, Eric Sunshine wrote:
>> On Sun, Jul 05, 2015 at 01:13:57PM +0200, Christian Couder wrote:
>>> A draft of Git Rev News edition 5 is available here:
>>> https://github.com/git/git.github.io/blob/master/rev_new
Отправлено с iPhone
On Sun, Jul 5, 2015 at 9:11 PM, Eric Sunshine wrote:
> On Sun, Jul 05, 2015 at 01:13:57PM +0200, Christian Couder wrote:
>> A draft of Git Rev News edition 5 is available here:
>> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-5.md
>> Everyone is welcome to contribute in
On Sun, Jul 05, 2015 at 01:13:57PM +0200, Christian Couder wrote:
> A draft of Git Rev News edition 5 is available here:
> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-5.md
> Everyone is welcome to contribute in any section...
I'm not familiar with the criteria for deci
Hi,
On 2015-07-03 18:24, Stefan Beller wrote:
> On Thu, Jul 2, 2015 at 11:16 AM, Paul Tan wrote:
>> Increase test coverage of git-am.sh to help prevent regressions that could
>> arise
>> from the rewrite of git-am.sh to C. This patch series, along with
>> pt/am-foreign, improved test coverage as
On Thu, Jul 2, 2015 at 10:35 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Add the '--points-at' option provided by 'ref-filter'. The
>> option lets the user to list only refs which pertain to the
>> given object.
>
> You are using "pertain to" (here, in git-for-each-ref.txt and in the
> d
Hi Paul,
On 2015-07-02 20:16, Paul Tan wrote:
> diff --git a/t/t4150-am.sh b/t/t4150-am.sh
> index dd6fe81..62b678c 100755
> --- a/t/t4150-am.sh
> +++ b/t/t4150-am.sh
> @@ -275,6 +275,48 @@ test_expect_success 'am with failing pre-applypatch
> hook' '
> test_cmp_rev first HEAD
> '
>
> +
Hi Paul,
On 2015-07-02 20:16, Paul Tan wrote:
> diff --git a/t/t4150-am.sh b/t/t4150-am.sh
> index 3f54bdf..0a19136 100755
> --- a/t/t4150-am.sh
> +++ b/t/t4150-am.sh
> @@ -154,6 +154,17 @@ test_expect_success 'am applies patch correctly' '
> test "$(git rev-parse second^)" = "$(git rev-par
Hi,
On 2015-07-05 15:07, Jeff King wrote:
> On Sat, Jul 04, 2015 at 07:39:04PM -0400, Chris Jones wrote:
>
>> Make git filter-branch output a useful error message when a single
>> commit is given instead of a range. Currently, when given a command
>> like git filter-branch --msg-filter 'echo "TE
Hi,
> #: dir.c:1945
> msgid "Untracked cache is disabled on this system."
> -msgstr ""
> +msgstr "Cache für unversionierten Dateien ist auf diesem System deaktiviert."
I think it should be "Cache für unversionierte Dateien ist auf diesem
System deaktiviert."
> #: help.c:214
> msgid "git comm
On Sat, Jul 04, 2015 at 07:39:04PM -0400, Chris Jones wrote:
> Make git filter-branch output a useful error message when a single
> commit is given instead of a range. Currently, when given a command
> like git filter-branch --msg-filter 'echo "TEST"' -- abc123, it will
> give the message "Which
Hi,
A draft of Git Rev News edition 5 is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-5.md
Everyone is welcome to contribute in any section, like Junio and
Matthieu already did, either by editing the
above page on GitHub and sending a pull request, or
The only change is a bugfix: the SMTP mailer was not working with
Python 2.4.
Signed-off-by: Matthieu Moy
---
I just fixed the title line (1.1.0 -> 1.1.0).
contrib/hooks/multimail/CHANGES | 5 +
contrib/hooks/multimail/README | 2 +-
contrib/hooks/multimail/README.Git
On Fri, Jul 3, 2015 at 11:19 PM, Duy Nguyen wrote:
> On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine wrote:
>> One of git-worktree's roles is to populate the new worktree, much like
>> git-checkout, and thus, for convenience, ought to support several of the
>> same shortcuts. Toward this goal, add
On Fri, Jul 3, 2015 at 10:45 PM, Duy Nguyen wrote:
> On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine wrote:
>> Given "git checkout --to HEAD~1", the new worktree's HEAD should
>> begin life at the current branch's HEAD~1, however, it actually ends up
>> at HEAD~2. The happens because:
>>
>> 1.
On Fri, Jul 3, 2015 at 10:53 PM, Duy Nguyen wrote:
> On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine wrote:
>> COMMANDS
>>
>> +add ::
>> +
>> +Check out `` into a separate working directory, ``, creating
>> +`` if necessary. The new working directory is linked to the current
>> +reposit
On Fri, Jul 3, 2015 at 10:41 PM, Duy Nguyen wrote:
> On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine wrote:
>> +git-worktree could provide more automation for tasks currently
>> +performed manually or via other commands, such as:
>> +
>> +- `add` to create a new linked worktree
>> +- `remove` to re
On Fri, Jul 3, 2015 at 11:04 PM, Duy Nguyen wrote:
> On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine wrote:
>> Now that "git worktree add" has achieved user-facing feature-parity with
>> "git checkout --to", retire the latter.
>>
>> Move the actual linked worktree creation functionality,
>> prepare
When c6458e60 (index-pack: kill union delta_base to save memory,
2015-04-18) attempted to reduce the memory footprint of index-pack,
one of the key thing it did was to keep track of ref-deltas and
ofs-deltas separately.
In fix_unresolved_deltas(), however it forgot that it now wants to
look only a
rebase learned to stash changes when it encounters a dirty work tree, but
git pull --rebase does not.
Only verify if the working tree is dirty when rebase.autostash is not
enabled.
Signed-off-by: Kevin Daudt
Helped-by: Paul Tan
---
git-pull.sh | 3 ++-
t/t5520-pull.sh | 11 +++
2
Duy Nguyen writes:
>>> @@ -1282,28 +1344,25 @@ static void fix_unresolved_deltas(struct sha1file
>>> *f, int nr_unresolved)
>>>* resolving deltas in the same order as their position in the pack.
>>>*/
>>> sorted_by_pos = xmalloc(nr_unresolved * sizeof(*sorted_by_pos));
>>>
On Wed, Jun 17, 2015 at 08:36:34AM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > - require_clean_work_tree "pull with rebase" "Please commit or
> > stash them."
> > + if [ $(git config --bool --get rebase.autostash || echo false)
> > = false ]
>
> Style (use of [
Make git filter-branch output a useful error message when a single
commit is given instead of a range. Currently, when given a command
like git filter-branch --msg-filter 'echo "TEST"' -- abc123, it will
give the message "Which ref do you want to rewrite?". Instead, what
is needed is a range of c
27 matches
Mail list logo
