Am 3/20/2013 18:43, schrieb Jeff King:
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
Well spotted, and, right,
Use LongPathTool. If u had problem with files i suggest this software.
http://LongPathTool.com
--
View this message in context:
http://git.661346.n2.nabble.com/gitk-says-file-name-too-long-tp4632510p7580237.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from
Am 3/20/2013 18:10, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
From: Johannes Sixt j...@kdbg.org
MSYS bash considers the part /g in the sed expression s/./=/g as an
absolute path after an assignment, and mangles it to a C:/something
string. Do not attract bash's
That
[url=http://www.pndoracharmonlineshop.ca/] pandora charms[/url] is
frequently generally simply because individuals all around you all around
you in this earth are typically featuring just about every specific added
uncovers. transform whatever in the event and as well quite possibly
Am 3/20/2013 23:59, schrieb David Aguilar:
I started digging in and the @worktree_files (aka @worktree above)
is populated from the output of git diff --raw
Seeing the output filename in diff --raw implies that one of the
tests added output to the index somehow. I do not see that
On 20.03.2013, at 19:56, Matthieu Moy wrote:
stash objects are commits with 2 parents (ie. merge commits). One commit
is the HEAD you stashed from, and the other is the saved state of the
index.
...
Use git show --first-parent --name-status, it should do what you expect
Thanks a lot for
Hi,
With recent (I'm how recent exactly) versions of IO::Socket::SSL, git
send-email:1169 spits out the following warning, which originates in
Net::SMTP::SSL:
***
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
Jeff King p...@peff.net writes:
On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So maybe just run git status /dev/null?
In the background? How often would it run? I do not think a single
lockfile solves anything. It may prevent
I was fooling around with clang and noticed that it complains about the
int x = x construct under -Wall. That is IMHO a deficiency in clang,
since the idiom has a well-defined use in silencing -Wuninitialized
warnings. But I've also always been nervous about the idiom, because
it's easy to get the
In wt_status_print_change_data, we accept a change_type flag
that is meant to be either WT_STATUS_UPDATED or
WT_STATUS_CHANGED. We then switch() on this value to set
the local variable status for each case, but do not
provide a fallback default label to the switch statement.
As a result, the
This is shorter, idiomatic, and it means the compiler does
not get confused about whether our e pointer is valid,
letting us drop the e = e hack.
Signed-off-by: Jeff King p...@peff.net
---
And it fixes an instance of Linus's people do not understand pointers
from here:
In cases where the setting and access of a variable are
protected by the same conditional flag, older versions of
gcc would generate a might be used unitialized warning. We
silence the warning by initializing the variable to itself,
a hack that gcc recognizes.
Modern versions of gcc are smart
According to 47ec794, this initialization is meant to
squelch an erroneous uninitialized variable warning from gcc
4.0.1. That version is quite old at this point, and gcc 4.1
and up handle it fine, with one exception. There seems to be
a regression in gcc 4.6.3, which produces the warning;
Am 3/21/2013 12:03, schrieb Jeff King:
I was fooling around with clang and noticed that it complains about the
int x = x construct under -Wall. That is IMHO a deficiency in clang,
since the idiom has a well-defined use in silencing -Wuninitialized
warnings.
IMO, that's a myth. The construct
On Thu, Mar 21, 2013 at 12:45:37PM +0100, Johannes Sixt wrote:
Am 3/21/2013 12:03, schrieb Jeff King:
I was fooling around with clang and noticed that it complains about the
int x = x construct under -Wall. That is IMHO a deficiency in clang,
since the idiom has a well-defined use in
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
I want to compare two files in a git repository and tell which one was
introduced into the repository earlier, assuming that they're in the
same history line (by ancestry, not timestamp). The naive way to do
this is to
On Thu, Mar 21, 2013 at 05:29:39PM +0530, Ramkumar Ramachandra wrote:
This must be a trick question but the naïve way I think of is
git log --diff-filter=A -- path1 path2
Thanks, I didn't know about --diff-filter. I'll need one extra step
to figure out which commit corresponds
On Thu, Mar 21, 2013 at 08:21:30AM -0400, Jeff King wrote:
On Thu, Mar 21, 2013 at 05:29:39PM +0530, Ramkumar Ramachandra wrote:
This must be a trick question but the naïve way I think of is
git log --diff-filter=A -- path1 path2
Thanks, I didn't know about --diff-filter.
If core.preload is set to a non-zero value, every time a git command is
executed, git status will be runned in the background if the value of
core.preload is lower than the number of seconds since last run.
Please see this thread:
http://article.gmane.org/gmane.comp.version-control.git/218587
Jeff King wrote:
On Thu, Mar 21, 2013 at 08:21:30AM -0400, Jeff King wrote:
On Thu, Mar 21, 2013 at 05:29:39PM +0530, Ramkumar Ramachandra wrote:
This must be a trick question but the naïve way I think of is
git log --diff-filter=A -- path1 path2
Thanks, I didn't know
Running perlcritic with gentle severity reports six problems. The
following lists the line numbers on which the problems occur, along
with a description of the problem. This patch fixes them all.
516: Contrary to common belief, subroutine prototypes do not enable
compile-time checks for proper
Compared to the previous round at
http://thread.gmane.org/gmane.comp.version-control.git/217236
I made the following changes (numbers from v8):
[1/5] Refactor parse_loc
Based on Junio's suggestions, the refactoring is now to a new file
line-range.c that line-log.c will later use. (It
From: Bo Yang struggleyb@gmail.com
We want to use the same style of -L n,m argument for 'git log -L' as
for git-blame. Refactor the argument parsing of the range arguments
from builtin/blame.c to the (new) file that will hold the 'git log -L'
logic.
To accommodate different data structures
This new syntax finds a funcname matching /pattern/, and then takes from there
up to (but not including) the next funcname. So you can say
git log -L:main:main.c
and it will dig up the main() function and show its line-log, provided
there are no other funcnames matching 'main'.
This is a rewrite of much of Bo's work, mainly in an effort to split
it into smaller, easier to understand routines.
The algorithm is built around the struct range_set, which encodes a
series of line ranges as intervals [a,b). This is used in two
contexts:
* A set of lines we are tracking
So far log -L only used the implicit diff filtering by pathspec. If
the user specifies -M, we cannot do that, and so we simply handed the
whole diff queue (which is approximately 'git show --raw') to
diffcore_std().
Unfortunately this is very slow. We can optimize a lot if we throw
out files
From: Bo Yang struggleyb@gmail.com
The function rewrite_one is used to rewrite a single
parent of the current commit, and is used by rewrite_parents
to rewrite all the parents.
Decouple the dependence between them by making rewrite_one
a callback function that is passed to rewrite_parents.
On Thu, Mar 21, 2013 at 06:02:32PM +0530, Ramkumar Ramachandra wrote:
git log --format=%H --name-status --diff-filter=A -- path1 path2 |
grep ^A |
tail -1
Great! I just learnt about --name-status now.
You can also use --name-only, but the parsing is a little less robust.
Nit:
Johannes Sixt wrote:
Am 3/21/2013 12:03, schrieb Jeff King:
I was fooling around with clang and noticed that it complains about
the int x = x construct under -Wall. That is IMHO a deficiency in
clang, since the idiom has a well-defined use in silencing
-Wuninitialized warnings.
IMO, that's a
The documentation is in AsciiDoc format: it should be written somewhere
with links to AsciiDoc documentation so that it became easy to find
how to write documentation for Git.
Signed-off-by: Yann Droneaud ydrone...@opteya.com
---
Documentation/README | 13 +
1 file changed, 13
Joachim Schmitz wrote:
Johannes Sixt wrote:
Am 3/21/2013 12:03, schrieb Jeff King:
I was fooling around with clang and noticed that it complains about
the int x = x construct under -Wall. That is IMHO a deficiency in
clang, since the idiom has a well-defined use in silencing
-Wuninitialized
Thomas Rast tr...@student.ethz.ch writes:
I think it would actually be a somewhat interesting feature if it
interacted with GIT_PS1_SHOW*. If you use these settings (I personally
use SHOWDIRTYSTATE but not SHOWUNTRACKEDFILES), the prompt hangs while
__git_ps1 runs git-status. It should be
Jeff King p...@peff.net writes:
Git code was my introduction to it, too, and I was led to believe it was
idiomatic, so I can't speak further on that. I think it was Junio who
introduced me to it, so maybe he can shed more light on the history.
I think we picked the convention up from the
Johannes Sixt j.s...@viscovery.net writes:
Am 3/20/2013 18:43, schrieb Jeff King:
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to
On Thu, Mar 21, 2013 at 12:10 PM, Jeff King p...@peff.net wrote:
In cases where the setting and access of a variable are
protected by the same conditional flag, older versions of
gcc would generate a might be used unitialized warning. We
silence the warning by initializing the variable to
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
Git code was my introduction to it, too, and I was led to believe it was
idiomatic, so I can't speak further on that. I think it was Junio who
introduced me to it, so maybe he can shed more light on the history.
I
Ramkumar Ramachandra artag...@gmail.com writes:
diff --git a/git-send-email.perl b/git-send-email.perl
index be809e5..e974b11 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -513,7 +513,7 @@ if (@alias_files and $aliasfiletype and defined
$parse_alias{$aliasfiletype}) {
Yann Droneaud ydrone...@opteya.com writes:
The documentation is in AsciiDoc format: it should be written somewhere
with links to AsciiDoc documentation so that it became easy to find
how to write documentation for Git.
Certainly this does not deserve a *new* file to hold it.
Isn't this
On Thu, Mar 21, 2013 at 08:19:43AM -0700, Junio C Hamano wrote:
$ git grep '#define uninitialized_var' include/
include/linux/compiler-gcc.h:#define uninitialized_var(x) x = x
include/linux/compiler-intel.h:#define uninitialized_var(x) x
but they recently had a discussion,
When we read a fast-import line like:
M 100644 :1 foo.c
we point the local object_entry variable oe to the object
named by the mark :1. When the input uses the inline
construct, however, we do not have such an object_entry.
The current code is careful not to access oe in the inline
case, but
When we fail to fork, we set the failed_errno variable to
the value of errno so it is not clobbered by later syscalls.
However, we do so in a conditional, and it is hard to see
later under what conditions the variable has a valid value.
Instead of setting it only when fork fails, let's just
On 21.03.13 14:00, Leo Koppelkamm wrote:
Torsten Bögershausen added a patch for this a while ago.
It seems it only works for files, not for folders with unicode in it.
Eg. on ubuntu box:
git init
mkdir hä
touch hä/file
git add hä
git commit
Later on Mac
git clone ………
git status
#
Le 21.03.2013 16:31, Junio C Hamano a écrit :
Yann Droneaud ydrone...@opteya.com writes:
The documentation is in AsciiDoc format: it should be written
somewhere
with links to AsciiDoc documentation so that it became easy to find
how to write documentation for Git.
Certainly this does not
I found the problem:
I copied the config out of your commit message, where you wrote
core.precomposedunicode
Turns out the d is too much. It seems to work now.
Leo
On Thursday, 21 March 2013 at 17:04, Torsten Bögershausen wrote:
On 21.03.13 14:00, Leo Koppelkamm wrote:
Torsten
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
diff --git a/git-send-email.perl b/git-send-email.perl
index be809e5..e974b11 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -513,7 +513,7 @@ if (@alias_files and $aliasfiletype and defined
Duy Nguyen pclo...@gmail.com writes:
I still can't reproduce it. But I think I found a bug that
miscalculates prefix length from absolute paths. Does this fix your
test?
...
Nope, that one could cause more crashes. Try this
-- 8 --
diff --git a/setup.c b/setup.c
index 3584f22..3d8eb97
Yann Droneaud ydrone...@opteya.com writes:
There were no indication about how to write documentation
in SubmittingPatches.
I would agree that is probably the right place for it if we were to
add insns/hints.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
I still can't reproduce it. But I think I found a bug that
miscalculates prefix length from absolute paths. Does this fix your
test?
...
Nope, that one could cause more crashes. Try this
-- 8 --
diff --git
Thomas Rast tr...@student.ethz.ch writes:
+void line_log_init(struct rev_info *rev, const char *prefix, struct
string_list *args)
+{
+ struct commit *commit = NULL;
+ struct line_log_data *range;
+
+ commit = check_single_commit(rev);
+ range = parse_lines(commit, prefix,
Jeff King wrote:
Instead of using the x = x hack, let's handle the default
case in the switch() statement with a die(BUG). That tells
the compiler and any readers of the code exactly what the
function's input assumptions are.
Sounds reasonable.
We could also convert the flag to an enum,
Junio C Hamano gits...@pobox.com writes:
+MERGING TAG
+---
+
+When merging a tag (annotated or signed), Git will create a merge commit
+...
+if the tag was signed. See also linkgit:git-tag[1].
+
It would make it more helpful to readers to describe how _not_ to
create such a
In the warning message printed when rename or unmodified copy
detection was skipped due to too many files, change diff.renamelimit
to diff.renameLimit, in order to make it consistent with git
documentation, which consistently uses diff.renameLimit.
Signed-off-by: Max Nanasy max.nan...@gmail.com
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
Instead of using the x = x hack, let's handle the default
case in the switch() statement with a die(BUG). That tells
the compiler and any readers of the code exactly what the
function's input assumptions are.
Sounds reasonable.
Junio C Hamano wrote:
+Consequently a request `git merge --ff-only v1.2.3` to merge such a
+tag would fail.
+
+When you want to just integrate with the work leading to the commit
+that happens to be tagged, e.g. synchronizing with an upstream
+release point, you may not want to make an
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
+ default:
+ die(BUG: unhandled change_type %d in
wt_status_print_change_data,
+ change_type);
Micronit: s/unhandled/invalid/.
I actually think unhandled is more correct for this
Jonathan Nieder jrnie...@gmail.com writes:
Nice and clear, but doesn't this contradict b5c9f1c1b0ed (merge: do
not create a signed tag merge under --ff-only option, 2012-02-05)?
It does X-. Here is a replacement.
The --ff-only v1.2.3 will fail can be left unsaid because it would
fail (and
Yann Droneaud ydroneaud at opteya.com writes:
3) Merge options can't be overridden.
If I modify .git/config to set a merge option, for example forcing
fast-forward merge, this option cannot be overridden on command line:
(git merge --no-ff-only --no-ff) should work. The --no-ff-only
Junio C Hamano wrote:
Here is a replacement.
Looks good. Thanks for taking care of this.
--
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 http://vger.kernel.org/majordomo-info.html
Max Nanasy max.nan...@gmail.com writes:
In the warning message printed when rename or unmodified copy
detection was skipped due to too many files, change diff.renamelimit
to diff.renameLimit, in order to make it consistent with git
documentation, which consistently uses diff.renameLimit.
Jeff King wrote:
This is shorter, idiomatic, and it means the compiler does
not get confused about whether our e pointer is valid,
letting us drop the e = e hack.
Signed-off-by: Jeff King p...@peff.net
---
And it fixes an instance of Linus's people do not understand pointers
Heh. Yes,
Jeff King wrote:
And 4.3 was old enough for me to say I do not care if you can run with
-Wall -Werror or not, let alone 4.2.
Changes like this can only reveal bugs (in git or optimizers) that
were hidden before, without regressing actual runtime behavior, so for
what it's worth I like them.
I
Jeff King wrote:
We probably _don't_ want to apply this one right now.
I think we should. gcc 4.6.y warning bugs should be fixed --- there's
no need for git to work around them. And anyone affected can easily
stop using -Werror (-Werror is not meant for use by non-developers in
production).
Jeff King wrote:
Two patches to follow.
[5/4]: fast-import: clarify inline logic in file_change_m
This one is clearly a bug / missing feature in gcc's control flow
analysis, but your workaround looks reasonable.
[6/4]: run-command: always set failed_errno in start_command
Very sane.
On Thu, Mar 21, 2013 at 8:52 AM, Thomas Rast tr...@student.ethz.ch wrote:
This is a bit hacky and should really be replaced by equivalent
support in --follow, and just using that. However, in the meantime it
s/using/use/
speeds up 'log -M -L' by an order of magnitude.
--
To unsubscribe from
Junio C Hamano gits...@pobox.com writes:
Yann Droneaud ydrone...@opteya.com writes:
There were no indication about how to write documentation
in SubmittingPatches.
I would agree that is probably the right place for it if we were to
add insns/hints.
I take it back.
SubmittingPatches does
Hi,
Just a little change I made on my own.
The other part are definitely better than my version, so I propose
to merge all the patches in the thread with you as author,
putting Jonathan Nieder and myself as reviewers.
Regards
Documentation/git-merge.txt | 4 ++--
1 file changed, 2
From: Junio C Hamano gits...@pobox.com
When asking Git to merge a tag (such as a signed tag or annotated tag),
it will always create a merge commit even if fast-forward was possible.
It's like having --no-ff present on the command line.
It's a difference from the default behavior described in
Le jeudi 21 mars 2013 à 10:39 -0700, Junio C Hamano a écrit :
Yann Droneaud ydrone...@opteya.com writes:
There were no indication about how to write documentation
in SubmittingPatches.
I would agree that is probably the right place for it if we were to
add insns/hints.
But it will be
Hi,
Le jeudi 21 mars 2013 à 14:16 -0700, Junio C Hamano a écrit :
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index b1bfff6..7e4d571 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -237,6 +237,9 @@ For Python scripts:
Yann Droneaud wrote:
Anyway, having a README at the Documentation/ level could also help to
explain what to be found in this directory:
- user-manual
- howto
- technical
- RelNote
- SubmittingPatches
- CodingGuidelines
- etc.
A Documentation/README or Documentation/INDEX in the spirit
In the warning message printed when rename or unmodified copy
detection was skipped due to too many files, change diff.renamelimit
to diff.renameLimit, in order to make it consistent with git
documentation, which consistently uses diff.renameLimit.
Signed-off-by: Max Nanasy max.nan...@gmail.com
Yann Droneaud wrote:
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Yes, I think this is in good shape now.
--
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 http://vger.kernel.org/majordomo-info.html
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Quite a few topics have graduated to 'master'; they were all cooking
in 'next' during the feature-freeze from the previous cycle.
You can find
In particular, it can get called with four arguments if you happen to
be referring to a repo using the ssh:// scheme with a non-default port
number.
Signed-off-by: Dan Bornstein danf...@milk.com
---
Documentation/git.txt |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff
From: Junio C Hamano gits...@pobox.com
Sent: Thursday, March 21, 2013 11:04 PM
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
[...]
--
ชำแหละท่อน้ำเลี้ยงป่วนใต้
เมื่อวันที่ 12 มีนาคม 2556 เจ้าหน้าที่ได้จับกุมขบวนการค้ายาเสพติด พบเฮโรอีน
จำนวน 188 แท่ง น้ำหนัก 68.5 กิโลกรัม และขยายผลตามรวบชาวมาเลเซียชื่อนายเบิร์ด
เป็นผู้บงการอยู่เบื้องหลัง จากการสอบสวนนายเบิร์ด รับสารภาพว่าจะนำเฮโรอีนไปส่งที่
รัฐกลันตัน ประเทศมาเลเซีย
76 matches
Mail list logo
