ชำแหละท่อน้ำเลี้ยงป่วนใต้
เมื่อวันที่ 12 มีนาคม 2556 เจ้าหน้าที่ได้จับกุมขบวนการค้ายาเสพติด พบเฮโรอีน
จำนวน 188 แท่ง น้ำหนัก 68.5 กิโลกรัม และขยายผลตามรวบชาวมาเลเซียชื่อนายเบิร์ด
เป็นผู้บงการอยู่เบื้องหลัง จากการสอบสวนนายเบิร์ด รับสารภาพว่าจะนำเฮโรอีนไปส่งที่
รัฐกลันตัน ประเทศมาเลเซีย เฮโรอีนล
From: "Junio C Hamano"
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'.
[...]
--
[Stalled]
[...]
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
---
Documentation/git.txt |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentati
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
Yann Droneaud wrote:
> Reviewed-by: Jonathan Nieder
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
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
---
Junio C Ham
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
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:
Le jeudi 21 mars 2013 à 10:39 -0700, Junio C Hamano a écrit :
> Yann Droneaud 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 difficult
From: Junio C Hamano
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 git-merge.txt.
It sh
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 insertions(+)
Junio C Hamano writes:
> Yann Droneaud 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 not, and I do not think it sh
On Thu, Mar 21, 2013 at 8:52 AM, Thomas Rast 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 this list: send the
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 san
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:
> 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.
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
> ---
> And it fixes an instance of Linus's "people do not understand pointers"
Heh. Yes, loo
Max Nanasy 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".
>
> Signed-off-
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
Yann Droneaud 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 override
Jonathan Nieder 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 succeed) under t
Junio C Hamano wrote:
> Jonathan Nieder 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 fo
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
Jonathan Nieder 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.
>
>>
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
---
diff.c | 2
Junio C Hamano 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 merge
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
Thomas Rast 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, args);
> +
Junio C Hamano writes:
> Duy Nguyen 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/
Yann Droneaud 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 message to majord...@
Duy Nguyen 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 100
Junio C Hamano wrote:
> Ramkumar Ramachandra 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{$alias
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
Le 21.03.2013 16:31, Junio C Hamano a écrit :
Yann Droneaud 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
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
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
always
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
cas
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 disc
Yann Droneaud 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 inferrable from the top-
Ramkumar Ramachandra 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}) {
> ($sender) = exp
Junio C Hamano writes:
> Jeff King 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 conv
On Thu, Mar 21, 2013 at 12:10 PM, Jeff King 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 itself,
> a
Johannes Sixt 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 successfully run on Win
Jeff King 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 kernel folks.
Thomas Rast 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 possible to run a g
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 w
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
---
Documentation/README | 13 +
1 file changed, 13 insertions(+)
create mode
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
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.
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 tha
From: Bo Yang
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. Then
export rewrite_parent
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 (which
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'.
Signed-off-by:
From: Bo Yang
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 in blame and log -L, the
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 sti
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 a
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
>> >
>> > Tha
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
Thi
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
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 corr
Junio C Hamano wrote:
> Ramkumar Ramachandra 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 find the in
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
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 constr
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;
however
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 en
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
---
And it fixes an instance of Linus's "people do not understand pointers"
from here:
http://meta.slashdot.org/story/
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
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 th
Jeff King writes:
> On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:
>
>> Jeff King 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 simultaneous run
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
i
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
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 se
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
defini
73 matches
Mail list logo
