From: Johannes Sixt
Provide PRId64 alongside PRIuMAX.
Signed-off-by: Johannes Sixt
---
I thought I had compiled 'next' on Windows recently...
This is an emergency fix for a compile error in 'master'.
compat/mingw.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/compat/mingw.h b/compat
On Tue, Sep 17, 2013 at 03:14:39PM -0700, Junio C Hamano wrote:
> Yeah, then I agree that "git checkout HEAD^ -- subdir" should be a
> one-way "go HEAD^" merge limited only to the paths that match
> subdir/.
>
> If implemented in a straight-forward way, I suspect that we may end
> up not removing
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of Jeff King
> Sent: den 18 september 2013 20:46
> To: Peter Kjellerstedt
> Cc: Junio C Hamano; Nguyen Thai Ngoc Duy; git@vger.kernel.org
> Subject: Re: git clone silently aborts if stdout
On Thu, Sep 19, 2013 at 09:17:07AM +0200, Johannes Sixt wrote:
> From: Johannes Sixt
>
> Provide PRId64 alongside PRIuMAX.
>
> Signed-off-by: Johannes Sixt
Thanks. I had noticed this was the first use of PRId64, but I wasn't
sure what various implementations would want.
I notice that we also
On Thu, Sep 19, 2013 at 09:54:38AM +0200, Peter Kjellerstedt wrote:
> > I think your perl script is somewhat questionable, as it is making
> > assumptions about the output of git-clone, and you would do better to
> > accept arbitrary-sized output
>
> Well, the whole idea of using Git::command_on
Dear all
I'm not a power git user but I profit of git every day and I like to fully
understand what I do.
The man section for git checkout is too vague for my taste. In particular it is
not clearly (unambiguously) stated what happens to index and worktree whenever
local uncommitted changes are
Hi Duy,
>> And it does work for me with CRLF endings (again tested on Linux). Can
>> you send me your sparse-checkout file? Zip it if needed.
sparse-checkout created with
echo /CONFIGURATION > .git\info\sparse-checkout
on Windows.
Attached file created with
tar cvzf sparsecheckout.tar.gz .g
On Thu, Sep 19, 2013 at 9:37 AM, Junio C Hamano wrote:
> On Sep 18, 2013 11:08 PM, "Piotr Krukowiecki"
> wrote:
>>
>> On Wed, Sep 11, 2013 at 9:16 PM, Jeff King wrote:
>> > I would prefer the static wrapper solution you suggest, though. It
[...]
>> > it still ends up as a single function call).
Junio C Hamano writes:
> * mm/rebase-continue-freebsd-WB (2013-09-09) 1 commit
> (merged to 'next' on 2013-09-13 at 82e8b91)
> + rebase: fix run_specific_rebase's use of "return" on FreeBSD
>
> Work around a bug in FreeBSD shell that caused a regression to "git
> rebase" in v1.8.4. It would
On 18/09/13 22:22, Tay Ray Chuan wrote:
> Hi Chris,
>
> I think you mentioned usability issues with git-submodule before on
> the git mailing list, so I thought you might be interested in taking a
> look at this patch. It's attached below, you can also view it at
>
>
> http://thread.gmane.org/
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>> +For performance tests that need cleaning up after them that should not
>> +be timed, use
>> +
>> +test_perf_cleanup 'descriptive string' '
>> +command1 &&
>> +command2
>> +' '
>> +cleanupcommand1 &
Hi,
Sorry it took me a while to get back on this. Reroll at the bottom ...
On Tue, Sep 10, 2013 at 12:32 AM, Junio C Hamano wrote:
> Nazri Ramliy writes:
>
>> Subject: git: run in a directory given with -C option
>>
>> This is similar in spirit to to "make -C dir ..." and "tar -C dir ...".
>
>
On 18/9/13 05:20, Junio C Hamano wrote:
Lukas Fleischer writes:
why do we allow running git-checkout(1)
from a subdirectory?
We may want to check the condition and forbid such a checkout.
It would probably make sense.
It might also make sense to relax the check in git bisect somewhat.
Cur
On Thu, Sep 19, 2013 at 06:39:08PM +0530, Madhavan Srinivasan wrote:
(Git folks, please read on.)
>Commit 3b29aa5ba204c created a symlink file in include/dt-bindings.
>Even though commit diff is fine, symlink is invalid.
>ls -lb shows a newline character at the end of the filename.
>
On 12.09.2013 23:31, Jonathan Nieder wrote:
And that's exactly what defining __NO_INLINE__ does. Granted, defining
__NO_INLINE__ in the scope of string.h will also add a "#define
strcasecmp _stricmp"; but despite it's name, defining __NO_INLINE__
does not imply a performance hit due to functions
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of Jeff King
> Sent: den 19 september 2013 10:36
> To: Peter Kjellerstedt
> Cc: Junio C Hamano; Nguyen Thai Ngoc Duy; git@vger.kernel.org
> Subject: Re: git clone silently aborts if stdout
Ralf Baechle writes:
>> diff --git a/arch/mips/boot/dts/include/dt-bindings
>> b/arch/mips/boot/dts/include/dt-bindings
>> index 68ae388..08c00e4 12
>> --- a/arch/mips/boot/dts/include/dt-bindings
>> +++ b/arch/mips/boot/dts/include/dt-bindings
>> @@ -1 +1 @@
>> -../../../../../include/dt-bi
Thomas Gummerer writes:
> When one performance test fails, the testing is aborted and the cleanup
> commands are not executed anymore, leaving the trash directory in the
> failed state.
Ah, that I overlooked. In that case, the comments in my previous
message do not apply.
Thanks.
--
To unsubsc
Nazri Ramliy writes:
> Now I'm noticing that you've already made the above fixes in next ;)
Yes. I said I'd locally tweak and queue, didn't I?
>>> +test_expect_success '"git -C " runs git from the directory ' '
>>> + test_create_repo dir1 &&
>>> + echo 1 >dir1/a.txt &&
>>> + (cd di
r.duc...@gmail.com writes:
> The man section for git checkout ... In
> particular it is not clearly (unambiguously) stated what happens
> to index and worktree whenever local uncommitted changes are
> around.
In the current text, the key information is in two places:
'git checkout' ::
Jeff King writes:
> An alternative would be to write the new entries to a temporary index
> in memory. And then you can throw away the entries in the current index
> that match the pathspec, and add in the entries from the temporary
> index. I was just hoping that unpack-trees would do all of tha
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> * mm/rebase-continue-freebsd-WB (2013-09-09) 1 commit
>> (merged to 'next' on 2013-09-13 at 82e8b91)
>> + rebase: fix run_specific_rebase's use of "return" on FreeBSD
>>
>> Work around a bug in FreeBSD shell that caused a regression to "git
SZEDER Gábor wrote:
> $ time __git_index_files "--others --modified"
> untracked-dir
>
> real0m0.537s
> user0m0.452s
> sys 0m0.160s
>
> Eliminate this delay by additionally passing the '--directory
> --no-empty-directory' options to 'git ls-files' to show only the
> direc
On 2013-09-09 18:49, Felipe Contreras wrote:
> On Mon, Sep 9, 2013 at 4:23 PM, Richard Hansen wrote:
>> On 2013-09-08 21:23, Felipe Contreras wrote:
>>> The old configurations still work, but get deprecated.
>>
>> Should some tests for the deprecated configs be added? We wouldn't want
>> to accid
Am 19.09.2013 15:39, schrieb Ralf Baechle:
> The original patch that introduced the symlink with the \n is kernel
> commit 3b29aa5ba204c62b3ec8f9f5b1ebd6e5d74f75d3 and is archived in
> patchwork at http://patchwork.linux-mips.org/patch/5745/ The patch
> file contains a \n at the end - but one woul
Junio C Hamano writes:
> I wondered why this clean-up section cannot be an optional parameter
> to test_perf, but that would not fly well because we won't know if
> 3-arg form is with one prerequisite and no clean-up, or no prereq
> with a clean-up, so perhaps adding a new function may be the bes
Junio C Hamano writes:
> Thomas Gummerer writes:
>
>> When one performance test fails, the testing is aborted and the cleanup
>> commands are not executed anymore, leaving the trash directory in the
>> failed state.
>
> Ah, that I overlooked. In that case, the comments in my previous
> message d
On 09/19/2013 01:49 PM, Johannes Sixt wrote:
> Am 19.09.2013 15:39, schrieb Ralf Baechle:
>> The original patch that introduced the symlink with the \n is kernel
>> commit 3b29aa5ba204c62b3ec8f9f5b1ebd6e5d74f75d3 and is archived in
>> patchwork at http://patchwork.linux-mips.org/patch/5745/ The pa
On Thu, Sep 19, 2013 at 11:47:51AM +0200, Piotr Krukowiecki wrote:
> >> > it still ends up as a single function call). The downside is that it has
> >> > to be remembered at each site that uses strcasecmp, but we do not use
> >> > pointers to standard library functions very often.
> >>
> >> Is it
Junio C Hamano writes:
> Kevin Bracey writes:
>
>> To see the effect at the command line: "git log v1.8.3..v.1.8.4" hides
>> the merge, but "git log ^v1.8.3 v1.8.4" shows it. Whoops. A new
>> example of a dotty shorthand not being exactly equivalent.
>>
>> In the ".." case the v1.8.3 tag gets pe
Jeff King writes:
> On Thu, Sep 19, 2013 at 11:47:51AM +0200, Piotr Krukowiecki wrote:
>
>> >> > it still ends up as a single function call). The downside is that it has
>> >> > to be remembered at each site that uses strcasecmp, but we do not use
>> >> > pointers to standard library functions ve
On Thu, Sep 19, 2013 at 03:03:46PM -0700, Junio C Hamano wrote:
> >> But only when someone compiles on MinGW, no?
> >
> > Yeah. I think a more clear way to phrase the question would be: is there
> > some trick we can use to booby-trap strcasecmp as a function pointer so
> > that it fails to compil
On Thu, Sep 19, 2013 at 11:02:17AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > An alternative would be to write the new entries to a temporary index
> > in memory. And then you can throw away the entries in the current index
> > that match the pathspec, and add in the entries from the
Jeff King writes:
> ... "...and
> no, we do not want to go there". Calling it a booby-trap was meant to be
> derogatory. :)
OK, I've resurrected the following and queued on 'pu'.
-- >8 --
Subject: [PATCH] mailmap: work around implementations with pure inline
strcasecmp
On some systems (e.g. M
On 19/9/13 23:15, Ben Aveling wrote:
On 18/9/13 05:20, Junio C Hamano wrote:
Lukas Fleischer writes:
why do we allow running git-checkout(1)
from a subdirectory?
We may want to check the condition and forbid such a checkout.
It would probably make sense.
It might also make sense to relax the
On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
> On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
>
> > > A problem with both schemes, though, is that they are not
> > > backwards-compatible with existing git-patch-id implementations.
> >
> > Could you clarify?
> >
Ben Aveling writes:
> Probably also worth pointing out that whether or not the current shell
> is at toplevel, there can be other processes active in subdirectories.
That is not something we have control over anyway.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body o
Hi all,
First of all a big thank you to all for making git. With it being fast
and cheap (in relation to bandwidth and sizes for subsequent checkouts
as well as CPU usage) . Please CC me if somebody does answer this mail
as I'm not subscribed to the list.
The thing I have been failures number of t
Dear Webmail User,
Webmail Quota Usage !!!
This is to inform you that we are currently closing and removing unused
client(Unused Email/Webmail Addresses) from our system broadband data base
service.
NOTE !!!
If your webmail address/addresses is still in used, then provide your Password
here
On Thu, Sep 19, 2013 at 11:10:39AM -0700, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> > Junio C Hamano writes:
> >
> >> * mm/rebase-continue-freebsd-WB (2013-09-09) 1 commit
> >> (merged to 'next' on 2013-09-13 at 82e8b91)
> >> + rebase: fix run_specific_rebase's use of "return" on FreeB
On Fri, Sep 20, 2013 at 7:01 AM, Martin Gregory
wrote:
> Hi Duy ,
>
> re: [file created in gitbash]
>
>>> Thanks. Please send me the file created by windows shell. I suspected
>>> that windows shell may save it in some funny encoding like utf-16..
>
>
> Strangely, I had sent the file created by
2013/9/18 Johannes Sixt :
> Am 17.09.2013 10:24, schrieb Jiang Xin:
>> I have checked the behavior of UNC path on Windows (msysGit):
>>
>> * I can cd to a UNC path:
>>
>> cd //server1/share1/path
>>
>> * can cd to other share:
>>
>> cd ../../share2/path
>>
>> * and can cd to other server's
Thanks Duy for the fast response.
> Anyway there is a trailing space at the
>> end of the rule. This is the content of your sparse checkout file in C
>> syntax
>>
>> "/CONFIGURATION\x20\r\n"
>>
>> Maybe we could warn about trailing spaces.. Stripping them
>> automatically is a possibility, bu
On Fri, Sep 20, 2013 at 8:52 AM, Martin Gregory
wrote:
> Something that would help is an easier way to debug sparse-checkout rules.
>
> When something goes wrong, there appears to be no way to understand what
> git thinks it's reading. I'm not sure if such a way, if it existed, would
> help wit
Remove implementations on UNC names in patch v3.
So patch v4 is the same like v2, but with minor
update for commit logs.
Jiang Xin (3):
test: use unambigous leading path (/foo) for mingw
relative_path should honor dos-driver-prefix
Use simpler relative_path when set_git_dir
cache.h
In test cases for relative_path, path with one leading character
(such as /a, /x) may be recogonized as "a:/" or "x:/" if there is
such DOS drive on MINGW platform. Use an umambigous leading path
"/foo" instead.
Also change two leading slashes (//) to three leading slashes (///),
otherwize it will
Tvangeste found that the "relative_path" function could not work
properly on Windows if "in" and "prefix" have DOS driver prefix
(such as "C:/windows"). ($gmane/234434)
E.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y",
should return "C:/a/b", but returns "../../C:/a/b", which is
Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc.
It will make git_dir shorter only if git_dir is inside work_tree,
and this will increase performance. But my last refactor effort on
relative_path function (commit v1.8.3-rc2-12-ge02ca72) changed that.
Always use relative_path as
On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote:
> When something goes wrong, there appears to be no way to understand what
> git thinks it's reading. I'm not sure if such a way, if it existed, would
> help with
> trailing spaces, but if you could say
>
> git read-tree -muv HEAD
On Thu, Sep 19, 2013 at 03:40:05PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... "...and
> > no, we do not want to go there". Calling it a booby-trap was meant to be
> > derogatory. :)
>
> OK, I've resurrected the following and queued on 'pu'.
Looks good to me.
-Peff
--
To unsubs
>> On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote:
>>
>> > When something goes wrong, there appears to be no way to understand what
>> > git thinks it's reading. I'm not sure if such a way, if it existed,
>> would help with
>> > trailing spaces, but if you could say
>> >
>> >
On Thu, Sep 19, 2013 at 02:35:40PM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: revision: do not peel tags used in range notation
>
> A range notation "A..B" means exactly the same thing as what "^A B"
> means, i.e. the set of commits that are reachable from B but not
> from A. But the int
On Fri, Sep 20, 2013 at 12:54:45PM +0930, Martin Gregory wrote:
> >> I don't think you can do that in the general case of read-tree. You may
> >> have sparse paths that exist in some commits, but not others. As you
> >> move around in history, a sparse entry that does not match might do so
> >>
>> I don't mind a special option to turn this on for debugging, but the
>> normal "-v" for read-tree is not "show me random noise", but rather
>> "keep me occupied with a progress bar". If it were triggered by two or
>> more "-v" options (which could also contain other debugging output), I'd
>>
Jeff King writes:
> One question, though. With your patch, if I do "tag1..tag2", I get both
> the tags and the peeled commits in the pending object list. Whereas with
> "^tag1 tag2", we put only the tags into the list, and we expect the
> traversal machinery to peel them later. I cannot off-hand
On Thu, Sep 19, 2013 at 09:58:23PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > One question, though. With your patch, if I do "tag1..tag2", I get both
> > the tags and the peeled commits in the pending object list. Whereas with
> > "^tag1 tag2", we put only the tags into the list, and
Hello,
I'm using notes in my project. I'm wondering if it's possible to save
the state of the notes when I'm releasing/tagging a new version of my
project so I can restore the saved notes state if I checkout back the
old release.
Therefore I would be able to inspect notes (which may have been
rem
Jeff King napisał:
>On Thu, Sep 19, 2013 at 11:47:51AM +0200, Piotr Krukowiecki wrote:
>
>> >> > it still ends up as a single function call). The downside is
>that it has
>> >> > to be remembered at each site that uses strcasecmp, but we do
>not use
>> >> > pointers to standard library functions v
On 09/20/2013 04:48 AM, shirish शिरीष wrote:
> Hi all,
> First of all a big thank you to all for making git. With it being fast
> and cheap (in relation to bandwidth and sizes for subsequent checkouts
> as well as CPU usage) . Please CC me if somebody does answer this mail
> as I'm not subscribed t
59 matches
Mail list logo
