On Thu, Apr 2, 2015 at 3:56 AM, Max Kirillov m...@max630.net 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).
On Fri, Apr 3, 2015 at 7:01 PM, Jeff King p...@peff.net 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
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
+[ $UID -eq 0 ]
Tested on Gentoo and OpenSUSE 13.1, both x86-64
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
On Wed, Apr 1, 2015 at 2:14 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Jeff King wrote:
No tests, as we would need to be able to write to / to do
so.
t1509-root-worktree.sh is
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
Patch is line-wrapped
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 parents.
On 04/03/2015 12:38 AM, Junio C Hamano wrote:
Karthik Nayak karthik@gmail.com 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
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
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
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:
Signed-off-by: Max Kirillov m...@max630.net
---
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
From: Holloway, Blair blair_hollo...@playstation.sony.com
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:
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:
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 l...@diamand.org
---
t/t9816-git-p4-locked.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9816-git-p4-locked.sh
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
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
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
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' branch.
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
On Sun, 22 Mar 2015 18:56:52 +0100, Ævar Arnfjörð Bjarmason ava...@gmail.com
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
Torsten Bögershausen tbo...@web.de 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
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
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
On Fri, Apr 3, 2015 at 5:13 PM, Daniel Bingham dan...@dbingham.com 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
On Fri, Apr 03, 2015 at 02:01:55PM -0700, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de 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
David Turner dtur...@twopensource.com 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
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
On Fri, Apr 3, 2015 at 2:53 PM, Luke Diamand l...@diamand.org 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
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
Eric Sunshine sunsh...@sunshineco.com writes:
On Fri, Apr 3, 2015 at 2:53 PM, Luke Diamand l...@diamand.org 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?
On Wed, Apr 1, 2015 at 9:19 AM, Matthieu Moy
matthieu@grenoble-inp.fr 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
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 proposals).
Kyle J. McKay mack...@gmail.com 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
-
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
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
On Wed, Apr 01, 2015 at 10:16:22AM -0700, Junio C Hamano wrote:
David Aguilar dav...@gmail.com 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
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 think
On Fri, Apr 3, 2015 at 2:53 PM, Luke Diamand l...@diamand.org 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 l...@diamand.org
Ævar Arnfjörð Bjarmason ava...@gmail.com 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,
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
On 15-04-03 07:05 PM, Alex Henrie wrote:
2015-02-18 12:27 GMT-07:00 Martin d'Anjou martin.danjo...@gmail.com:
It appears I have uncovered inconsistent behaviour in gitk. Looks like
a bug. I have a picture here:
On Fri, Apr 3, 2015 at 6:30 PM, Shawn Landden sh...@churchofgit.com 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
2015-02-18 12:27 GMT-07:00 Martin d'Anjou martin.danjo...@gmail.com:
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
On Fri, 2015-04-03 at 15:01 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com 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
systemd supports git-daemon's existing --inetd mode as well.
Signed-off-by: Shawn Landden sh...@churchofgit.com
---
Documentation/git-daemon.txt | 41 +++-
Makefile | 14 --
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
Signed-off-by: Karthik Nayak karthik@gmail.com
---
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
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
Signed-off-by: Karthik Nayak karthik@gmail.com
---
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
+++
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
Documentation/git-log.txt | 3 +++
Documentation/rev-list-options.txt | 18 +++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git
From: Junio C Hamano gits...@pobox.com
[kk: wrote commit message]
Helped-by: Eris Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
builtin/log.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index
systemd supports git-daemon's existing --inetd mode as well.
Signed-off-by: Shawn Landden sh...@churchofgit.com
---
Documentation/git-daemon.txt | 41 +++-
Makefile | 10 ++
daemon.c | 45
*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
[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 dan...@dbingham.com wrote:
I think the context of the patch
On Fri, Apr 3, 2015 at 3:47 PM, Alex Henrie alexhenri...@gmail.com wrote:
2015-04-02 15:56 GMT-06:00 Junio C Hamano gits...@pobox.com:
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
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
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
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
contrib/completion/git-completion.bash | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
From: Junio C Hamano gits...@pobox.com
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
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
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
2015-04-02 15:56 GMT-06:00 Junio C Hamano gits...@pobox.com:
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
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
On Tue, Mar 31, 2015 at 10:22 PM, Joey Hess jo...@joeyh.name 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
On Tue, Mar 31, 2015 at 10:22 PM, Joey Hess jo...@joeyh.name 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
64 matches
Mail list logo
