Tested on Gentoo and OpenSUSE 13.1, both x86-64
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On Wed, Apr 1, 2015 at 2:14 AM, Jonathan Nieder wrote:
> Jeff King wrote:
>
>> No tests, as we would need to be able to write to "/" to do
>> so.
>
> t1509-root-worktree.sh is supposed to test the repo
On Thu, Apr 2, 2015 at 3:56 AM, Max Kirillov wrote:
> On Tue, Mar 31, 2015 at 07:14:39PM +0700, Nguyễn Thái Ngọc Duy wrote:
>> The general principle is like in the last mail: .git/config is for
>> both shared and private keys of main worktree (i.e. nothing is
>> changed from today). .git/workt
On Fri, Apr 03, 2015 at 05:08:57PM +0700, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t1509/prepare-chroot.sh b/t/t1509/prepare-chroot.sh
> index 6269117..c61afbf 100755
> --- a/t/t1509/prepare-chroot.sh
> +++ b/t/t1509/prepare-chroot.sh
> @@ -14,25 +14,42 @@ xmkdir() {
>
> R="$1"
>
> +[ "$U
On Fri, Apr 3, 2015 at 7:01 PM, Jeff King wrote:
> Aside from the nits above, I did get it to run t1509 with this. I can't
> say I'm incredibly excited about the whole thing, if only because it is
> clear that nobody is going to run it regularly (so regressions will
> likely go unnoticed, which is
On Tue, Mar 31, 2015 at 10:22 PM, Joey Hess wrote:
> After being surprised that git-ls-files expands pathspecs, here's a patch
> that would have saved me.
> ---
> Documentation/git-ls-files.txt | 9 +
> Documentation/git-ls-tree.txt | 8
ls-tree only supports straight file or di
On Tue, Mar 31, 2015 at 10:22 PM, Joey Hess wrote:
> After being surprised that git-ls-files expands pathspecs, here's a patch
> that would have saved me.
> ---
> Documentation/git-ls-files.txt | 9 +
> Documentation/git-ls-tree.txt | 8
> 2 files changed, 9 insertions(+), 8 del
For diff --cc, paths fitering used to select only paths which have
changed in all parents, while diffing itself output hunks which are
changed in as few as 2 parents.
Fix intersect_paths() to add paths which have at least 2 changed
parents. In this new functionality does not require special treatm
Fixes:
* test renamed and commit message rewritten, so that
it mentions 3-parent merge rather than other uses
* test: fix && chaining and do at new line
* use postincrement in C code
Max Kirillov (4):
t4059: test 'diff --cc' with a change from only few parents
combine-diff.c: refactor: extra
Signed-off-by: Max Kirillov
---
combine-diff.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 8eb7278..a236bb5 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -22,6 +22,28 @@ static int co
If `git diff --cc` is used with 2 or more parents, then
it shows all hunks which have changed compared to at least 2 parents.
Which is reasonable, because those places are likely places for
conflicts, and it should be displayed how they were resolved.
But, preliminary path filtering passes a path o
On Thu, Apr 02, 2015 at 01:55:58PM -0700, Junio C Hamano wrote:
> So I'll give a preliminary nitpicks first ;-)
Thank you; fixed the issues you mentioned.
>> + test_seq 11 | sed -e "s/^7/7change1/" -e "s/^11/11change2/" -e
>> "s/^2/2change2/" >long/only2 &&
>> +git add long/only2 &&
>
> Patc
Looks like there is no exact specification what `diff -c` and
`diff --cc` should output. Considering this it is not reasonable to
hardcode any specific output in test. Rather, it should verify that file
selection behaves the same as hunk selection.
Rewrite test so that it makes sure that a "short"
On 04/03/2015 12:38 AM, Junio C Hamano wrote:
Karthik Nayak writes:
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object which is
created using 'git hash-object --literally'. This is
because these objects are usually of unknown types.
Te
On Thu, Apr 02, 2015 at 05:13:10PM -0400, Jeff King wrote:
> On Thu, Apr 02, 2015 at 11:34:09PM +0300, Max Kirillov wrote:
>
>> For diff --cc, paths fitering used to select only paths which have
>> changed in all parents, while diffing itself output hunks which are
>> changed in as few as 2 parent
The test for handling of failure when trying to move a file
that is locked by another client was not quite correct - it
failed early on because the target file in the move already
existed.
The test now fails because git-p4 does not properly detect
that p4 has rejected the move, and instead just cr
This is a followup series to Blair's patch to fix filetype detection on files
opened exclusively. It updates the git-p4 unit tests to catchup with that
fix, fixing a couple of small bugs in the original tests.
Holloway, Blair (1):
git-p4: fix filetype detection on files opened exclusively
Luke
From: "Holloway, Blair"
If a Perforce server is configured to automatically set +l (exclusive lock) on
add of certain file types, git p4 submit will fail during getP4OpenedType, as
the regex doesn't expect the trailing '*exclusive*' from p4 opened:
//depot/file.png#1 - add default change (binary
Test script t9816-git-p4-locked.sh test #4 tests for
adding a file that is locked by Perforce automatially.
This is currently not supported by git-p4 and so is
expected to fail.
However, a small typo meant it always failed, even with
a fixed git-p4. Fix the typo to resolve this.
Signed-off-by: Lu
The add-new-file and copy-existing-file tests from
t9816-git-p4-locked.sh now pass. Update the test
case accordingly.
Signed-off-by: Luke Diamand
---
t/t9816-git-p4-locked.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9816-git-p4-locked.sh b/t/t9816-git-p4-locked.
On Fri, Apr 3, 2015 at 2:53 PM, Luke Diamand wrote:
> Test script t9816-git-p4-locked.sh test #4 tests for
> adding a file that is locked by Perforce automatially.
s/automatially/automatically/
> This is currently not supported by git-p4 and so is
> expected to fail.
>
> However, a small typo me
On Wed, Apr 1, 2015 at 9:19 AM, Matthieu Moy
wrote:
> Hi,
>
> Latest news from the google summer of code: students have completed their
> proposals. We have 2 proposals for "convert scripts to builtins", and 4 for
> "unify git branch, git tag and git for-each-ref" (plus some out-of-scope
> prop
On Fri, Apr 3, 2015 at 2:53 PM, Luke Diamand wrote:
> The add-new-file and copy-existing-file tests from
> t9816-git-p4-locked.sh now pass. Update the test
> case accordingly.
This patch should be folded into patch 3/4, shouldn't it?
> Signed-off-by: Luke Diamand
> ---
> t/t9816-git-p4-locked.
On Wed, Apr 01, 2015 at 06:19:00PM +0200, Matthieu Moy wrote:
> Latest news from the google summer of code: students have completed
> their proposals. We have 2 proposals for "convert scripts to
> builtins", and 4 for "unify git branch, git tag and git for-each-ref"
> (plus some out-of-scope propo
Torsten Bögershausen writes:
> This makes my think that it is
> a) non-standard to have the extra colon
> b) The error message could be better
For that, perhaps
-ssh: Could not resolve hostname :: nodename nor servname provided, or not
known
+ssh: Could not resolve hostname ":": nodena
On Fri, Apr 03, 2015 at 02:01:55PM -0700, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
> > This makes my think that it is
> > a) non-standard to have the extra colon
> > b) The error message could be better
>
> For that, perhaps
>
> -ssh: Could not resolve hostname :: nodename no
I discovered what appears to be a bug with the handling of utf16 type files
when cloning from P4. It appears that it always fetches the content of the
latest version rather than getting the revision specified in the changelist
being processed. This patch is an attempt to resolve that by format
git-p4 always fetches the latest revision of UTF16
files from P4 rather than the revision at the commit being sync'd.
The print command should, instead, specify the revision number from the
commit in question using the file#revision syntax.
The file#revision syntax is preferable over file@changel
On Sun, 22 Mar 2015 18:56:52 +0100, Ævar Arnfjörð Bjarmason
wrote:
> However perhaps an interesting generalization of this would be
> something like a post-clone hook, obviously you couldn't store that in
> .git/hooks/ like other githooks(5) since there's no repo yet, but
> having it configured v
Ævar Arnfjörð Bjarmason writes:
> As others have indicated here this feature is really specific to a
> single lint-like use-case and doesn't belong in clone as a built-in
> feature.
>
> However perhaps an interesting generalization of this would be
> something like a post-clone hook, obviously yo
"Kyle J. McKay" writes:
> On Apr 2, 2015, at 15:09, Junio C Hamano wrote:
>
>> * jc/show-branch (2014-03-24) 5 commits
>> - show-branch: use commit slab to represent bitflags of arbitrary
>> width
>> - show-branch.c: remove "all_mask"
>> - show-branch.c: abstract out "flags" operation
>> - show-b
On Apr 2, 2015, at 17:02, Torsten Bögershausen wrote:
On 2015-04-02 21.35, Jeff King wrote:
On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:
Ah, understand. Here's my project URL for 'remote "origin"' with a
more meaningful representation of their internal FQDN:
url
Why is it impossible to free struct lock_files? I understand that they
become part of a linked list, and that there's an atexit handler that
goes over that list. But couldn't we just remove them from the linked
list and then free them? Even if we couldn't free all lock_files, maybe
we could free
On Fri, Apr 3, 2015 at 5:13 PM, Daniel Bingham wrote:
> git-p4 always fetches the latest revision of UTF16
> files from P4 rather than the revision at the commit being sync'd.
>
> The print command should, instead, specify the revision number from the
> commit in question using the file#revision s
On Thu, Apr 02, 2015 at 06:59:50PM -0700, Kyle J. McKay wrote:
> It should work as well as the original did for any 1-byte encoding. That
> is, if it's not valid UTF-8 it should pass through unchanged and any single
> byte encoding should just work. But, as you point out, multibyte encodings
> o
Eric Sunshine writes:
> On Fri, Apr 3, 2015 at 2:53 PM, Luke Diamand wrote:
>> The add-new-file and copy-existing-file tests from
>> t9816-git-p4-locked.sh now pass. Update the test
>> case accordingly.
>
> This patch should be folded into patch 3/4, shouldn't it?
If the fix and tests were done
On Wed, Apr 01, 2015 at 10:16:22AM -0700, Junio C Hamano wrote:
> David Aguilar writes:
>
> > Would generalizing "status" to have a more gittish syntax make
> > you feel less torn?
>
> One of my early draft responses included a one whose punch line was
> "Why limit the comparison to HEAD and HEA
David Turner writes:
> Why is it impossible to free struct lock_files? I understand that they
> become part of a linked list, and that there's an atexit handler that
> goes over that list. But couldn't we just remove them from the linked
> list and then free them?
I suspect that the code is w
On Fri, Apr 03, 2015 at 02:57:48PM -0700, David Aguilar wrote:
> > But I discarded it as a useless suggestion before writing it down,
> > primarily because I couldn't come up with an explanation _why_ being
> > able to say "git status --relative-to=next Makefile" is useful when
> > on the 'master'
On Fri, Apr 03, 2015 at 11:19:24AM +0900, Yi, EungJun wrote:
> > I timed this one versus the existing diff-highlight. It's about 7%
> > slower. That's not great, but is acceptable to me. The String::Multibyte
> > version was a lot faster, which was nice (but I'm still unclear on
> > _why_).
>
> I
When the input is UTF-8 and Perl is operating on bytes instead of
characters, a diff that changes one multibyte character to another
that shares an initial byte sequence will result in a broken diff
display as the common byte sequence prefix will be separated from
the rest of the bytes in the multi
On Apr 3, 2015, at 15:08, Jeff King wrote:
Doing:
diff --git a/contrib/diff-highlight/diff-highlight b/contrib/diff-
highlight/diff-highlight
index 08c88bb..1c4b599 100755
--- a/contrib/diff-highlight/diff-highlight
+++ b/contrib/diff-highlight/diff-highlight
@@ -165,7 +165,7 @@ sub highlight_
systemd supports git-daemon's existing --inetd mode as well.
v2: actually test...
v3: make optional, switch to libsystemd
shawn@zephyr:~/git/git$ ldd /lib/x86_64-linux-gnu/libsystemd.so.0
linux-vdso.so.1 (0x7ffeba7ec000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x
2015-04-02 15:56 GMT-06:00 Junio C Hamano :
> Thanks, but please no more _("string") changes for the rest of the
> cycle, as that would impact i18n folks who will be starting from
> tagged -rc releases.
>
> Please hold them off, and resend them after 2.4.0 final.
I thought that during a code freez
[Daniel: Your HTML-formatted response probably did not make it to the
Git mailing list since only plain text is accepted. Also, please
respond inline on this list rather than top-posting.]
On Fri, Apr 3, 2015 at 5:54 PM, Domain Admin wrote:
> I think the context of the patch doesn't make this cle
*note* I tried to send this to the list earlier but forgot to set the
mode to plain-text so it got rejected. Resending. Apologies for any
duplicates.
I think the context of the patch doesn't make this clear, but if you
look at git-p4.py in this spot you'll see that this is in a block that
begins
On Fri, Apr 3, 2015 at 6:30 PM, Shawn Landden wrote:
> systemd supports git-daemon's existing --inetd mode as well.
>
> v2: actually test...
> v3: make optional, switch to libsystemd
Every issue raised by my review[1] of v2 still applies to v3, so I
won't bother repeating them here, however, ther
2015-02-18 12:27 GMT-07:00 Martin d'Anjou :
> It appears I have uncovered inconsistent behaviour in gitk. Looks like
> a bug. I have a picture here:
> https://docs.google.com/document/d/19TTzGD94B9EEIrVU5mRMjfJFvF5Ar3MlPblRJfP5OdQ/edit?usp=sharing
>
> Essentially, when I hit shift-F5, it sometimes
On Fri, Apr 3, 2015 at 3:47 PM, Alex Henrie wrote:
> 2015-04-02 15:56 GMT-06:00 Junio C Hamano :
>> Thanks, but please no more _("string") changes for the rest of the
>> cycle, as that would impact i18n folks who will be starting from
>> tagged -rc releases.
>>
>> Please hold them off, and resend
Thanks for keeping me in the loop!
I have two thoughts on handling input:
As a coder I want to know exactly what's going on in my code. If I've given
erroneous input I'd like to know about it in the most useful and quickest way,
never glossed over, liberally accepted, nor fixed for me even if t
On Fri, 2015-04-03 at 15:01 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Why is it impossible to free struct lock_files? I understand that they
> > become part of a linked list, and that there's an atexit handler that
> > goes over that list. But couldn't we just remove them from t
Helped-by: Eric Sunshine
Signed-off-by: Koosha Khajehmoogahi
---
t/t4202-log.sh | 84 ++
1 file changed, 84 insertions(+)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1b2e981..ceaaf4e 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
Helped-by: Eric Sunshine
Signed-off-by: Koosha Khajehmoogahi
---
contrib/completion/git-completion.bash | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index fbe5972..a75d7f5 10064
From: Junio C Hamano
revision: add a new option 'merges=' with
possible values of 'only', 'show' and 'hide'.
The option is used when showing the list of commits.
The value 'only' lists only merges. The value 'show'
is the default behavior which shows the commits as well
as merges and the value 'h
Helped-by: Eric Sunshine
Signed-off-by: Koosha Khajehmoogahi
---
Documentation/git-log.txt | 3 +++
Documentation/rev-list-options.txt | 18 +++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 18
From: Junio C Hamano
[kk: wrote commit message]
Helped-by: Eris Sunshine
Signed-off-by: Koosha Khajehmoogahi
---
builtin/log.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..c7a7aad 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -36,6
On 15-04-03 07:05 PM, Alex Henrie wrote:
2015-02-18 12:27 GMT-07:00 Martin d'Anjou :
It appears I have uncovered inconsistent behaviour in gitk. Looks like
a bug. I have a picture here:
https://docs.google.com/document/d/19TTzGD94B9EEIrVU5mRMjfJFvF5Ar3MlPblRJfP5OdQ/edit?usp=sharing
Essentially,
systemd supports git-daemon's existing --inetd mode as well.
Signed-off-by: Shawn Landden
---
Documentation/git-daemon.txt | 41 +++-
Makefile | 14 --
daemon.c | 45 ++
systemd supports git-daemon's existing --inetd mode as well.
Signed-off-by: Shawn Landden
---
Documentation/git-daemon.txt | 41 +++-
Makefile | 10 ++
daemon.c | 45 ++--
On 04/03/2015 02:05 AM, Junio C Hamano wrote:
When merged to 'pu', this seems to break at least 5309 and 5300
tests (there might be others, but I didn't check).
There was a problem with packed object types. I have it fixed, will send
a re-roll.
--
To unsubscribe from this list: send the li
Changes made :
* Fixed the problem with packed types, which failed a few tests.
* Misspelled email.
Thanks for the suggestions and comments on version 6.
--
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
Update sha1_loose_object_info() to optionally allow it to read
from a loose object file of unknown/bogus type; as the function
usually returns the type of the object it read in the form of enum
for known types, add an optional "typename" field to receive the
name of the type in textual form and a f
Signed-off-by: Karthik Nayak
---
Documentation/git-cat-file.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index f6a16f4..8bac7bd 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-f
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object which is
created using 'git hash-object --literally'. This is
because these objects are usually of unknown types.
Teach git cat-file a '--literally' option where it prints
the type or size of
Signed-off-by: Karthik Nayak
---
t/t1006-cat-file.sh | 27 +++
1 file changed, 27 insertions(+)
diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index ab36b1e..5b74044 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -47,6 +47,18 @@ $content"
te
64 matches
Mail list logo
