On Feb 24, 2015, at 21:13, Junio C Hamano wrote:
"Kyle J. McKay" writes:
I can designate ;-), but I do not think I'd be the right person to
maintain or long-term-support it. Are you volunteering to oversee
the "LTS team"?
I could not promise a team of more than one member. And that would
On Wed, Feb 25, 2015 at 10:04 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Feb 25, 2015 at 6:37 AM, Stefan Beller wrote:
>>> I can understand, that we maybe want to just provide one generic
>>> "version 2" of the protocol which is an allrounder not doing bad in
>>> all of these as
On Wed, Feb 25, 2015 at 10:04:16PM -0500, Jeff King wrote:
> Another variant of this would for gettext.c to provide a git_setlocale
> that just wraps setlocale (and does nothing when NO_GETTEXT is given).
This doesn't _quite_ work. In addition to the function, we have to have
LC_MESSAGES defined.
On Wed, Feb 25, 2015 at 02:52:26PM -0800, Junio C Hamano wrote:
> This is now in 'master', but I wonder if people are getting
> compilation errors because of this change. I do.
I usually compile with NO_GETTEXT, but if I stop doing so, I see the
problem, too.
> I really do not like a conditiona
Yi EungJun writes:
> From: Yi EungJun
>
> Add an Accept-Language header which indicates the user's preferred
> languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
> ...
> Signed-off-by: Yi EungJun
> ---
Yikes.
This is now in 'master', but I wonder if people are getting
compilatio
Junio C Hamano writes:
> Looking at how we collect information on normal objects, it may make
> more sense to model this after sha1_loose_object_info(), with a
> tweak to struct object_info datatype, and integrate it into
> sha1_object_info_extended() may make more sense, perhaps along the
> line
On Wed, Feb 25, 2015 at 6:08 AM, Karthik Nayak wrote:
> cat-file: add --literally option.
Style: drop terminating period.
> Add --literally option which when used with -t option
> gives the type of the object given, irrelevant of the type
> and its contents.
Confusing: "gives the type [...] irr
I had written a longer review but was interrupted for a several hours,
and upon returning found that David and Junio covered many of the same
issues or overrode comments I was making, so the below review is pared
down quite a bit. Junio's proposed approach negates all of the below
review comments,
Jeff King writes:
> But we can also do that with a hash table, or an auxiliary sorted array.
> And sure enough, that's exactly what the rename_dst array is.
> ...
> which I think is a pretty simple and sane fix.
Yeah, good observation.
> So to go forward, I'm happy to prepare a patch, but I'd l
On Tue, Feb 24, 2015 at 09:00:20PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > 3. The sort order check is wrong. :-/ It needs to take into account
> > git's magic "if it's a tree, pretend it has '/' after it" rule.
> > That's not too hard for a single tree (fsck.c:verify_o
Karthik Nayak writes:
> +int sha1_object_type_literally(const unsigned char *sha1, char *type)
> +{
> + int status = 0;
> + unsigned long mapsize;
> + void *map;
> + git_zstream stream;
> + char hdr[32];
> + int i;
> +
> + map = map_sha1_file(sha1, &mapsize);
> + i
> On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil)
> wrote:
>
>> On Feb 19, 2015, at 3:35 PM, brian m. carlson
>> wrote:
>>
>> On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote:
>>> I just built from ‘master’, on FreeBSD 9.3:
>>>
>>> cd ~/src
>>> git clone https://g
On Feb 25, 2015, at 07:07, Nico Schlömer wrote:
Thanks Kyle for the patch! I applied it and ran
```
git svn clone https://geuz.org/svn/gmsh/trunk
```
Unfortunately, I'm still getting
```
[...]
r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
error closing pipe: Bad file des
On 02/25/2015 02:02 AM, Junio C Hamano wrote:
> The latest maintenance release Git v2.3.1 is now available at
> the usual places.
>
> The tarballs are found at:
>
> https://www.kernel.org/pub/software/scm/git/
>
> The following public repositories all have a copy of the 'v2.3.1'
> tag and th
On Thu, 2015-02-26 at 01:29 +0530, karthik nayak wrote:
>
> On 02/25/2015 11:52 PM, David Turner wrote:
> > On Wed, 2015-02-25 at 16:37 +0530, Karthik Nayak wrote:
> >> + unsigned long mapsize;
> >> ...
> >> + map = map_sha1_file(sha1, &mapsize);
> >
> > I know this is a pre-existing issue, but
Nico Schlömer wrote:
> Thanks Kyle for the patch! I applied it and ran
> ```
> git svn clone https://geuz.org/svn/gmsh/trunk
> ```
> Unfortunately, I'm still getting
> ```
> [...]
> r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
> error closing pipe: Bad file descriptor at
On 02/25/2015 11:52 PM, David Turner wrote:
On Wed, 2015-02-25 at 16:37 +0530, Karthik Nayak wrote:
+ unsigned long mapsize;
...
+ map = map_sha1_file(sha1, &mapsize);
I know this is a pre-existing issue, but I'm not sure "unsigned long" is
the right type here. Shouldn't it be a
I have specific case which you can use to improve git.
My example:
I have 2 branches - master, implement_button.
Branch implement_button add some button with few style.css and fonts files.
Both branches have same git ignore file where all fonts and css folders with
files ignored.
The point:
Now
Junio C Hamano wrote:
> Ryuichi Kokubo writes:
>
> > git svn uses POSIX::strftime('%s', $sec, $min, ...) to make unix epoch time.
> > But lowercase %s formatting character is a GNU extention. This causes
> > problem
> > in git svn fetch --localtime on non-glibc systems, such as msys or cygwin.
On Wed, Feb 25, 2015 at 11:01:22AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > So I think _if_ using "diff" attributes is enough for this purpose, then
> > there is no code to be written. But if somebody wants to draw a
> > distinction between the uses (I want to diff "foo" files, bu
Hi again,
On 19 January 2015 at 00:11, Adam Spiers wrote:
> I'm pleased to announce this is ready for testing; here are more
> details along with a short screencast demonstration:
>
> http://blog.adamspiers.org/2015/01/19/git-deps/
I just quickly made another screencast demo of this tool, th
Jeff King writes:
> So I think _if_ using "diff" attributes is enough for this purpose, then
> there is no code to be written. But if somebody wants to draw a
> distinction between the uses (I want to diff "foo" files, but never see
> them in grep) then we could introduce a "grep" attribute (wit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Thanks a lot good to know that and that's true little hard to do bc even
if track always the latest version some repositories change so fast
and will be needed some kind od eg. snapshot of user repository by
auto script eg once at 12-24h and that res
On Wed, Feb 25, 2015 at 10:33:53AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > If it's an attribute of the file, and not the request, maybe
> > gitattributes would be a better fit. You can already do this with:
> >
> > *.foo -diff
> >
> > in your .gitattributes file, though that _al
Ryuichi Kokubo writes:
> git svn uses POSIX::strftime('%s', $sec, $min, ...) to make unix epoch time.
> But lowercase %s formatting character is a GNU extention. This causes problem
> in git svn fetch --localtime on non-glibc systems, such as msys or cygwin.
> Using Time::Local::timelocal($sec, $
Jeff King writes:
> If it's an attribute of the file, and not the request, maybe
> gitattributes would be a better fit. You can already do this with:
>
> *.foo -diff
>
> in your .gitattributes file, though that _also_ marks the files as "not
> for diffing", which may not be desired. There's not
On Wed, 2015-02-25 at 16:37 +0530, Karthik Nayak wrote:
> + unsigned long mapsize;
> ...
> + map = map_sha1_file(sha1, &mapsize);
I know this is a pre-existing issue, but I'm not sure "unsigned long" is
the right type here. Shouldn't it be a size_t?
> + if (!map)
> + re
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 24.02.2015 19:29:
>> Michael J Gruber writes:
>>
Hmm, wouldn't it introduce a grave regression for users who
explicitly ask to clean crufty messages up (by setting their own
commit.cleanup configuration) if you uncondi
Duy Nguyen writes:
> On Wed, Feb 25, 2015 at 6:37 AM, Stefan Beller wrote:
>> I can understand, that we maybe want to just provide one generic
>> "version 2" of the protocol which is an allrounder not doing bad in
>> all of these aspects, but I can see usecases of having the desire to
>> replace
git svn uses POSIX::strftime('%s', $sec, $min, ...) to make unix epoch time.
But lowercase %s formatting character is a GNU extention. This causes problem
in git svn fetch --localtime on non-glibc systems, such as msys or cygwin.
Using Time::Local::timelocal($sec, $min, ...) fixes it.
Signed-off-b
On Wed, Feb 25, 2015 at 08:46:37PM +0700, Duy Nguyen wrote:
> On Wed, Feb 25, 2015 at 7:23 PM, Noel Grandin wrote:
> > What would be nice is a per-user/repo config setting that excludes certain
> > files and paths from the 'git grep' search.
> >
> > Does this sound reasonable/acceptable?
>
> The
On Tue, Feb 24, 2015 at 5:41 AM, samt wrote:
> The platform is Windows server 2008
> Git version is 1.9.5.msysgit.0
>
> I have a repository and I want EVERYTHING in the repository to be checked
> out into the workspace EXCEPT one directory. I have a machine with git
> version 1.7.8.msysgit.0 and
On Wed, Feb 25, 2015 at 7:23 PM, Noel Grandin wrote:
> What would be nice is a per-user/repo config setting that excludes certain
> files and paths from the 'git grep' search.
>
> Does this sound reasonable/acceptable?
There is no config setting to do that, but since v1.9.5 you can use
':!' or ':
On Tue, 2015-02-24 at 10:29 -0800, Junio C Hamano wrote:
> Hmm, but if it does not, wouldn't that countermand the wish of the
> user who explicitly asked to clean crufty messages up by setting
> their own commit.cleanup configuration?
IMHO it's just wrong behaviour if the commit messages of peopl
I am stanley Clarke a private lender located in USA.I can help you with a loan
you are looking for @ 3% interest rate,For Urgent Response Email:
stanleyclarkel...@gmail.com
stanley Clarke.
Email: stanleyclarkel...@gmail.com
Telephone:(781)-369-5127
--
To unsubscribe from this list: send the line
On Wed, Feb 25, 2015 at 6:37 AM, Stefan Beller wrote:
> I can understand, that we maybe want to just provide one generic
> "version 2" of the protocol which is an allrounder not doing bad in
> all of these aspects, but I can see usecases of having the desire to
> replace the wire protocol by your
Hi
In our repo (LibreOffice) we have various test files which tend to show up on
'grit grep',
which just generate noise because
(a) they have lots of common keywords that one might search for in them
and
(b) they have very little in the way of linebreaks
So they tend to generate a lot of noise
Hi Matthieu,
On 2015-02-25 11:25, Matthieu Moy wrote:
> - Original Message -
>> On 2015-02-24 13:28, Jeff King wrote:
>> > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
>> >
>> >> > Thanks! No rush, as we are not even accepted yet, but you can create a
>> >> > profi
Hi Duy,
On 2015-02-25 11:02, Duy Nguyen wrote:
> On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy
> wrote:
>> To get an idea, I counted the lines of code written by the student I
>> mentored last year:
>>
>> $ git log --author tanay...@gmail.com -p | diffstat -s
>> 43 files changed, 1225 insertions
On Sat, Feb 21, 2015 at 11:01 AM, Duy Nguyen wrote:
> I wonder how efficient rsync is for transferring these refs: the
> client generates a "file" containing all refs, the server does the
> same with their refs, then the client rsync their file to the server..
> The changes between the server and
sha1_object_type_literally takes a sha value and
gives the type of the given loose object, used by
git cat-file -t --literally.
Signed-off-by: Karthik Nayak
---
cache.h | 1 +
sha1_file.c | 27 +++
2 files changed, 28 insertions(+)
diff --git a/cache.h b/cache.h
ind
Add --literally option which when used with -t option
gives the type of the object given, irrelevant of the type
and its contents.
Signed-off-by: Karthik Nayak
---
builtin/cat-file.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/builtin/
These changes introduce a "--literally" option to "cat-file" to
allow us to read the type of any loose object, mostly the ones
created using the "--literally" option of "hash-object".
For now it works with the "-t" option as :
git cat-object -t --literally
Can be made to work with "-e" and
On Tue, Feb 24, 2015 at 9:23 AM, J. R. Westmoreland wrote:
> Hi
>
> I hope it is okay to ask such a question here.
>
> I cloned the current source tree and tried to build it and I get the
> following error.
> Could someone tell me why and if there is an easy way to fix it?
If you aren't opposed
- Original Message -
> Hi Peff,
>
> On 2015-02-24 13:28, Jeff King wrote:
> > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
> >
> >> > Thanks! No rush, as we are not even accepted yet, but you can create a
> >> > profile at:
> >> >
> >> > http://google-melange.com
On Mon, Feb 23, 2015 at 8:53 PM, Michael J Gruber
wrote:
> Junio C Hamano venit, vidit, dixit 22.02.2015 22:41:
>
>> [Stalled]
>>
>> * nd/list-files (2015-02-09) 21 commits
>> . t3080: tests for git-list-files
>> . list-files: -M aka diff-cached
>> . list-files -F: show submodules with the new
I believe I have been able to track down this problem and implement a
fix. Please report back if this patch fixes the problem for you.
-Kyle
-- 8< --
Subject: [PATCH] Git::SVN::Fetcher: avoid premature 'svn_hash' temp file closure
Since b19138b (git-svn: Make it incrementally faster by minimizi
On Wed, Feb 25, 2015 at 9:44 AM, Johannes Schindelin
wrote:
> Hi Matthieu,
>
> On 2015-02-25 00:56, Matthieu Moy wrote:
>> Johannes Schindelin writes:
>>
>>> On 2015-02-24 19:25, Junio C Hamano wrote:
On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
wrote:
> About the proposal:
>
On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy
wrote:
> To get an idea, I counted the lines of code written by the student I
> mentored last year:
>
> $ git log --author tanay...@gmail.com -p | diffstat -s
> 43 files changed, 1225 insertions(+), 367 deletions(-)
>
> I would consider this GSoC as "
--
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
Junio C Hamano venit, vidit, dixit 24.02.2015 19:29:
> Michael J Gruber writes:
>
>>> Hmm, wouldn't it introduce a grave regression for users who
>>> explicitly ask to clean crufty messages up (by setting their own
>>> commit.cleanup configuration) if you unconditionally force
>>> "--cleanup=verb
Le 24/02/2015 21:32, Junio C Hamano a écrit :
>> - explicitly put "y/n" in the message. Translaters should be warned to
>> let "y/n",
> This may be suboptimal from the end-user's point of view, but it is
> the least risky of breaking anything.
>
> And it is way better than the status quo.
>
>
I ca
Johannes Schindelin writes:
>>> Done: https://github.com/git/git.github.io/pull/12
>>
>> Thanks, merged.
>
> I opened another PR, based on Mathieu's advice.
Thanks, merged.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
Hi Peff,
On 2015-02-24 13:28, Jeff King wrote:
> On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
>
>> > Thanks! No rush, as we are not even accepted yet, but you can create a
>> > profile at:
>> >
>> > http://google-melange.com
>> >
>> > and ask to join the "git" project as
Stefan Beller venit, vidit, dixit 25.02.2015 01:34:
> On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy
> wrote:
>> Johannes Schindelin writes:
>>
>>> Hi Junio,
>>>
>>> On 2015-02-24 19:25, Junio C Hamano wrote:
On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
wrote:
> About the proposal:
Hi Matthieu,
On 2015-02-25 00:56, Matthieu Moy wrote:
> Johannes Schindelin writes:
>
>> On 2015-02-24 19:25, Junio C Hamano wrote:
>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
>>> wrote:
About the proposal:
The idea of this project is to dive into the Git source code and
On 25.02.2015 01:47, Stefan Beller wrote:
2. Get people thinking about what they would like to talk about. In
past GitTogethers, it's been a mix of people with prepared things
to talk about, group discussions of areas, and general kibitzing.
We can be spontaneous on the day
57 matches
Mail list logo
