Доброго дня,
будь ласка, просимо переглянути наш сайт,
якщо це не важко для вас,
http://schoolsite.pp.ua/ - будь ласка, відкрийте його для перегляду однієї-двох
сторінок,
і на будь-якій сторінці один раз натисніть на рекламний банер, який вам
найбільш цікавий,
це Ваша допомога, щоб ми могли запл
Using git 2.6.1
In git command line usage, Please mark optional, the man page
is correct.
$ git worktree add
usage: git worktree add []
or: git worktree prune []
-f, --force checkout even if already checked
out in other worktree
-bcreate a new branch
-B
On Sat, Oct 17, 2015 at 6:33 PM, Jaap Droogers wrote:
> Hi,
Hi Jaap,
> In the last sentence of page
> http://www.git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository I
> found a dead link to page
> http://www.git-scm.com/book/en/v2/1-git-server/_git_on_the_server
> (this dead link also app
On Sat, Oct 17, 2015 at 4:18 PM, Torsten Bögershausen wrote:
> Make it possible to show the line endings of files.
> Files which are staged and/or files in the working tree:
>
> git ls-files --eol-staged
> git ls-files --eol-worktree
>
> Both will show an output like this:
>
> emptyempty_file
On Fri, Oct 16, 2015 at 11:16 AM, Tobias Klauser wrote:
> Implement the --count-lines options for git stripspace [...]
>
> This will make it easier to port git-rebase--interactive.sh to C later
> on.
Is there any application beyond git-rebase--interactive where a
--count-lines options is expected
Karthik Nayak writes:
> So I did poke around a little. I think I missed this out on the
> original commit (b7cc53e92c806b73e14b03f60c17b7c29e52b4a4).
>
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 977a18c..2c5a9f1 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -49,6 +49,7 @@ stat
Tobias Klauser writes:
> On 2015-10-16 at 19:29:35 +0200, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> >> - if (mode == INVAL)
>> >> - usage(usage_msg);
>> >
>> > When given "git stripspace -s blorg", we used to set mode to INVAL
>> > and then showed the correct usage. But we
Make it possible to show the line endings of files.
Files which are staged and/or files in the working tree:
git ls-files --eol-staged
git ls-files --eol-worktree
Both will show an output like this:
emptyempty_file
bin binary_file_or_with_cr_handled_as_binary
txt-crlf text_file_with_crl
In b7cc53e92c806b73e14b03f60c17b7c29e52b4a4 we port tag.c to use
ref-filter APIs for filtering and printing refs. But that commit
missed out on setting 'filter->with_commit_tag_algo' which would
ensure the correct algorithm is used for the '--contains' option.
As reported by Jerry Snitselaar, this
On Sat, Oct 17, 2015 at 9:28 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Could you Squash that in, Junio?
>
> The guilty commit is in master, so you'll need a new commit to fix the
> old one. Can you send a patch with a proper commit message (referencing
> b7cc53e92c806b73e14b03f60c17b7c
Karthik Nayak writes:
> Could you Squash that in, Junio?
The guilty commit is in master, so you'll need a new commit to fix the
old one. Can you send a patch with a proper commit message (referencing
b7cc53e92c806b73e14b03f60c17b7c29e52b4a4)?
We should both have catched this earlier (by review
2015-10-12 14:30 GMT+08:00 Aleksey Komarov :
> Hi all!
>
> I'm sorry if the letter came twice. I have troubles with my post client.
>
> I want to organize my repository so its submodules would be located at the
> root
> of repository. I'm trying to create .gitignore to ignore all files and don't
>
Hi Junio,
Please pull the following into the maint branch. It includes l10n
updates in Russian which missed the update window for 2.6.
The following changes since commit 8d530c4d64ffcc853889f7b385f554d53db375ed:
Git 2.6-rc3 (2015-09-21 13:26:13 -0700)
are available in the git repository at:
Hi,
In the last sentence of page
http://www.git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository I
found a dead link to page
http://www.git-scm.com/book/en/v2/1-git-server/_git_on_the_server
(this dead link also appears on the paragraph "Cloning an Existing
Repository", half a screen above t
On 2015-10-16 at 19:35:49 +0200, Junio C Hamano wrote:
> Tobias Klauser writes:
>
> >> So this is your output code, which gives only the number of lines
> >> without the cleaned up result.
> >
> > This should better be a simple printf("%zu\n", lines) I guess?
>
> I think we actively avoid using
On 2015-10-16 at 19:07:34 +0200, Junio C Hamano wrote:
> Tobias Klauser writes:
>
> > Use parse-options to parse command-line options instead of a
> > hand-crafted implementation.
> >
> > This is a preparatory patch to simplify the introduction of the
> > --count-lines option in a follow-up patc
On 2015-10-16 at 19:29:35 +0200, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> - if (mode == INVAL)
> >> - usage(usage_msg);
> >
> > When given "git stripspace -s blorg", we used to set mode to INVAL
> > and then showed the correct usage. But we no longer have a check
> > that
On 2015-10-16 at 18:41:31 +0200, Junio C Hamano wrote:
> Tobias Klauser writes:
>
> Be consistent with the subjects, please.
>
> > strbuf: make stripspace() part of strbuf
>
> s/make/make/ ;-)
>
> > stripspace: Use parse-options for command-line parsing
>
> s/Use/use/
>
> > stripspace
On 2015-10-16 at 18:54:45 +0200, Matthieu Moy
wrote:
> Tobias Klauser writes:
>
> > - Split patch 2/3 into two patches: patch 2/4 switches git stripspace
> > to use parse-options and patch 3/4 introduces the new option.
>
> Much better now.
>
> > - Implement line counting in cmd_strip
On Sat Oct 17 15, Karthik Nayak wrote:
On Sat, Oct 17, 2015 at 3:37 AM, Jerry Snitselaar wrote:
Is this known and being looked into? I've seen a jump from 12 seconds
to over 9 minutes with running git tag --contains on my kernel repo.
This wasn't known, thanks for bringing it up.
snits ~/
20 matches
Mail list logo
