On Mon, Sep 07, 2015 at 02:11:15PM +0200, Ævar Arnfjörð Bjarmason wrote:
> This turned out to be a pretty trivial filesystem error.
> refs/heads/master wasn't readable by the backup process, but some
> other stuff in refs/heads and objects/* was.
>
> [...]
>
> I wanted to check if this was a regre
On Mon, Sep 07, 2015 at 02:51:42PM -0300, Renato Botelho wrote:
> Default variables used to build are set using = on Makefile, (e.g. CC,
> INSTALL, CFLAGS, …). GNU make overwrite these values if it’s passed as
> an argument (make CC=clang) and it works as expected.
>
> Default method of passing a
On Sat, Sep 05, 2015 at 09:56:27PM -0700, Junio C Hamano wrote:
> +static void am_signoff(struct strbuf *sb)
> +{
> + char *cp;
> + struct strbuf mine = STRBUF_INIT;
> +
> + /* Does it end with our own sign-off? */
> + strbuf_addf(&mine, "\n%s%s\n",
> + sign_off_hea
On Sun, Sep 06, 2015 at 10:24:12AM -0700, Junio C Hamano wrote:
> >> + /* Does it end with our own sign-off? */
> >> + strbuf_addf(&mine, "\n%s%s\n",
> >> + sign_off_header,
> >> + fmt_name(getenv("GIT_COMMITTER_NAME"),
> >> +
On Tue, Sep 08, 2015 at 09:30:09AM +0800, Levin Du wrote:
> Take kernel source code for example:
>
> # Clone the kernel to A and B
> $ git --version
> git version 2.3.2
> $ git clone --bare ../kernel/ A
> $ git clone --bare ../kernel/ B
OK, two repos with the same source.
> # Create the orpha
On Mon, Sep 7, 2015 at 7:35 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Mon, Sep 7, 2015 at 12:03 PM, Junio C Hamano wrote:
diff --git a/builtin/tag.c b/builtin/tag.c
index 9fa1400..f55dfda 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -43,8 +43,8 @@ stat
On 09/07/15 21:55, Jeff King wrote:
On Mon, Sep 07, 2015 at 06:37:29PM -0700, Raymond Jennings wrote:
Please see https://bugs.gentoo.org/show_bug.cgi?id=559920 for further
details.
Files *should* have a single blank line at the end, because a line should
always have a newline at the end.
I'm
On Mon, Sep 07, 2015 at 09:05:41AM +0800, Levin Du wrote:
> > Instead, the object transfer is optimized by comparing what commits
> > each side has and sending trees and blobs that are reachable from
> > the commits that the receiving side does not have.
>
> The sender A sends all the commits tha
On Mon, Sep 07, 2015 at 06:37:29PM -0700, Raymond Jennings wrote:
> Please see https://bugs.gentoo.org/show_bug.cgi?id=559920 for further
> details.
>
> Files *should* have a single blank line at the end, because a line should
> always have a newline at the end.
I'm not sure I follow. Lines shou
On 7 September 2015 at 13:21, wrote:
> From: Lars Schneider
>
> One thing I don't like about the current implementation is that I don't see a
> way to test the "git-p4.pushLargeFiles" config. I could start a git lfs server
> locally but that seems a bit too much, no?
Perhaps add a trivial large
Please see https://bugs.gentoo.org/show_bug.cgi?id=559920 for further
details.
Files *should* have a single blank line at the end, because a line
should always have a newline at the end.
Adding a newline to the end of a file whose last line doesn't have one
should be legal...as long as you d
I consider 'git push' need further optimization.
Take kernel source code for example:
# Clone the kernel to A and B
$ git --version
git version 2.3.2
$ git clone --bare ../kernel/ A
$ git clone --bare ../kernel/ B
# Create the orphan commit and check
$ cd A
$ git branch test
Switched to a new
Several Repositories I'm interested in, e.g. MINGW-PACKAGES@GITHUB,
contain multiple "products." Usually, I'm only interested in one or two.
I want to have a local repo with, e.g. iodbc from MinGW-Packages as
sub-moules. I don't even need to keep local content for many of the
other included pr
On 07/09/15 22:13, Jens Lehmann wrote:
> Am 07.09.2015 um 01:43 schrieb Eric Sunshine:
>> On Sun, Sep 6, 2015 at 6:08 PM, Anders Ro
>> wrote:
>>> On 04/09/15 07:02, Eric Sunshine wrote:
On Wed, Sep 2, 2015 at 7:34 PM, Anders Ro
wrote:
> git-submodule.sh: pin submodule when branch na
Commit d835dbb9 ("gitk: Add a "Copy commit summary" command",
2015-08-13) in the upstream gitk repo added a new context menu entry.
Therefore, the line numbers of the entries below the new one need to be
adjusted when their text or state is changed.
Signed-off-by: Beat Bolli
Cc: Paul Mackerras
-
On Mon, Sep 7, 2015 at 9:52 AM, Gábor Bernát wrote:
> From: Gabor Bernat
>
> adds seconds progress and estimated seconds time if getting the current
> timestamp is supported by the date +%s command
>
> Signed-off-by: Gabor Bernat
> ---
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
>
Am 07.09.2015 um 01:43 schrieb Eric Sunshine:
On Sun, Sep 6, 2015 at 6:08 PM, Anders Ro wrote:
On 04/09/15 07:02, Eric Sunshine wrote:
On Wed, Sep 2, 2015 at 7:34 PM, Anders Ro wrote:
git-submodule.sh: pin submodule when branch name is '@'
Setting branch name to '@' for a submodule will dis
On Sat, Sep 5, 2015 at 3:39 PM, John Keeping wrote:
> It may be useful to run git-interpret-trailers without needing to be in
> a repository.
Yeah, it looks like it works fine outside a repo.
Tested-by: Christian Couder
Thanks,
Christian.
--
To unsubscribe from this list: send the line "unsubs
On Sat, Sep 5, 2015 at 9:39 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> To salvage "interpret-trailers" needs a lot more, as we are
>> realizing that the definition that led to its external design does
>> not match the way users use footers in the real world. This affects
>> the inte
On Mon, Sep 7, 2015 at 1:40 AM, Eric Sunshine wrote:
> On Sat, Sep 5, 2015 at 2:52 PM, Karthik Nayak wrote:
>> Implement an `align` atom which left-, middle-, or right-aligns the
>> content between %(align:...) and %(end).
>>
>> It is followed by `:,`, where the `` is
>> either left, right or mid
On Mon, Sep 7, 2015 at 1:22 AM, Eric Sunshine wrote:
> On Sat, Sep 5, 2015 at 2:52 PM, Karthik Nayak wrote:
>> Introduce match_atom_name() which helps in checking if a particular
>> atom is the atom we're looking for and if it has a value attached to
>> it or not.
>>
>> Use it instead of starts_w
Default variables used to build are set using = on Makefile, (e.g. CC, INSTALL,
CFLAGS, …). GNU make overwrite these values if it’s passed as an argument (make
CC=clang) and it works as expected.
Default method of passing arguments for make operations on FreeBSD ports tree
is using environment
Hi.
**To not apply big patches, I will supply links to public repository
Lets start
1. git clone https://github.com/KES777/Plack
2. git show ed485bf75a6
Nothing interesting. Usual merge conflict while merge branch
'feature/doc_contribute' to 'master'
But I was interested by this part:
my
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
The cover letter talks about "local clone", and in this entire
series, I saw new tests only for the local case, but doesn't this
and the next change also affect the case where a Git daemon or a
upload-pack process is serv
Nguyễn Thái Ngọc Duy writes:
> Noticed-by: Bjørnar Snoksrud
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/clone.c | 6 --
> t/t2025-worktree-add.sh | 5 +
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 578d
Am 07.09.2015 um 17:34 schrieb Ævar Arnfjörð Bjarmason:
> On Mon, Sep 7, 2015 at 5:07 PM, Olaf Hering wrote:
>> https://github.com/libguestfs/libguestfs/commit/0306c98d319d189281af3c15101c8d343e400f13
>
> This is an interesting approach, but wouldn't help with git-send-email
> in particular, it'
On Mon, Sep 7, 2015 at 5:07 PM, Olaf Hering wrote:
> "git send-email --f" lacks --find-renames and others. Is the list
> of possible options maintained manually?
Yes, see contrib/completion/git-completion.bash.
There's no code for send-email there, you (or someone) could submit a patch! :)
> Pe
"git send-email --f" lacks --find-renames and others. Is the list
of possible options maintained manually? Perhaps this should be
automated by placing the long strings in an ELF section, then filling
variables like $__git_format_patch_options from such ELF section.
An example how this was done in l
Karthik Nayak writes:
> On Mon, Sep 7, 2015 at 12:03 PM, Junio C Hamano wrote:
>>> diff --git a/builtin/tag.c b/builtin/tag.c
>>> index 9fa1400..f55dfda 100644
>>> --- a/builtin/tag.c
>>> +++ b/builtin/tag.c
>>> @@ -43,8 +43,8 @@ static int list_tags(struct ref_filter *filter, struct
>>> ref_so
On Mon, Sep 7, 2015 at 12:03 PM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> diff --git a/Documentation/git-for-each-ref.txt
>> b/Documentation/git-for-each-ref.txt
>> index d039f40..c5154bb 100644
>> --- a/Documentation/git-for-each-ref.txt
>> +++ b/Documentation/git-for-each-ref.txt
>>
From: Gabor Bernat
adds seconds progress and estimated seconds time if getting the current
timestamp is supported by the date +%s command
Signed-off-by: Gabor Bernat
---
I've submitted this first to this list as a feature request, however
in the meantime with the help of Jeff King , Junio C
Ha
On 07/09/15 13:31, Gábor Bernát wrote:
> From: Gabor Bernat
>
> adds seconds progress and estimated seconds time if getting the current
> timestamp is supported by the date %+s command
s/%+s/+%s/
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
From: Lars Schneider
If read_pipe crashes then the caller can inspect the error and handle
it appropriately.
Signed-off-by: Lars Schneider
---
git-p4.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 073f87b..36a4bcb 100755
--- a/git-p4.py
+
From: Lars Schneider
A P4 repository can get into a state where it contains a file with file
type UTF16 that does not not contain valid UTF16 characters. If git-p4
attempts to retrieve the file as UTF16 from P4 then the process crashes
with a "Translation of file content failed" error.
Fix this
From: Lars Schneider
Hi,
this patch fixes the P4 "Translation of file content failed" error. Unfortuantly
I was not able to generate a P4 test repository to reproduce the error with a
test case.
An Internet search shows that this error happens in the wild:
https://stackoverflow.com/questions/51
From: Gabor Bernat
adds seconds progress and estimated seconds time if getting the current
timestamp is supported by the date %+s command
Signed-off-by: Gabor Bernat
---
I've submitted this first to this list as a feature request, however
in the meantime with the help of Jeff King , Junio C
Ha
From: Lars Schneider
Signed-off-by: Lars Schneider
---
git-p4.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/git-p4.py b/git-p4.py
index 40ad4ae..90d3b90 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -638,6 +638,8 @@ def gitConfigList(key):
if not _gitConfig.has_key(key):
s
From: Lars Schneider
The functions “gitConfig” and “gitConfigBool” are almost identical. Make
“gitConfig” more generic by adding an optional type specifier. Use the type
specifier “—bool” with “gitConfig” to implement “gitConfigBool. This prepares
the implementation of other type specifiers su
From: Lars Schneider
Add example implementation including test cases for the large file
system using Git LFS.
Pushing files to the Git LFS server is not tested.
Signed-off-by: Lars Schneider
---
Documentation/git-p4.txt | 4 +-
git-p4.py| 52 ++
t/t9823-git-p4-lfs.s
From: Lars Schneider
Diff to v2:
* add proper commit messages
* split commits into generic large file system and GitLFS implementation
* improve docs, mention clean/smduge filter and add example for clean checkout
* fix spelling
* add option to push large files to server
* use ValueError for gitC
From: Lars Schneider
Add a git config reader for integer variables. Please note that the git config
implementation automatically supports k, m, and g suffixes.
Signed-off-by: Lars Schneider
---
git-p4.py | 11 +++
1 file changed, 11 insertions(+)
diff --git a/git-p4.py b/git-p4.py
in
From: Lars Schneider
Perforce repositories can contain large (binary) files. Migrating these
repositories to Git generates very large local clones. External storage
systems such as Git LFS [1], Git Fat [2], or Git Media [2] try to
address this problem.
Add a generic mechanism to detect large fil
We have a process to back up our Git repositories at work, this
started alerting because it wasn't getting the same refs as the
remote.
This turned out to be a pretty trivial filesystem error.
refs/heads/master wasn't readable by the backup process, but some
other stuff in refs/heads and objects/*
On Fri, Sep 04, 2015 at 04:08:06PM -0700, Junio C Hamano wrote:
> Alexey Shumkin writes:
>
> > Some repositories may have spaces in their paths. Currently `git-subtree`
> > raises an error in such cases.
> > Also, `git-subtree` currently does not have tests for its 'push' command.
> > Following p
sigo venit, vidit, dixit 05.09.2015 14:22:
> I've found really "little bug" with dots in the git output.
>
> $ git push
> Everything up-to-date
>
> git pull
> Already up-to-date.
>
> Could all phrases contain dots? :)
>
In this case, also both messages mean the same but are phrased
differently
45 matches
Mail list logo
