Am 2/12/2014 17:48, schrieb Jeff King:
> On Wed, Feb 12, 2014 at 03:49:24PM +0100, Erik Faye-Lund wrote:
>
>> It seems the author of a201c20b41a2f0725977bcb89a2a66135d776ba2
>> assumes __BYTE_ORDER was guaranteed to always be defined, probably
>> fooled by the following check:
>>
>> #if !defined(_
On 02/12/2014 08:49 PM, Jeff King wrote:
> When the tree-walker runs into an error, it just calls
> die(), and the message is always "corrupt tree file".
> However, we are actually covering several cases here; let's
> give the user a hint about what happened.
>
> Let's also avoid using the word "c
Am 2/12/2014 20:30, schrieb Stefan Zager:
> On Wed, Feb 12, 2014 at 11:22 AM, Karsten Blees
> wrote:
>> Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
>>> ReOpenFile, that's fantastic. Thanks a lot!
>>
>> ...but should be loaded dynamically via GetProcAddress, or are we ready to
>> drop XP support
Mike Hommey writes:
> On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
>> Stefan Zager writes:
>>
>> > On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup wrote:
>> >
>> >> Really, give the above patch a try. I am taking longer to finish it
>> >> than anticipated (with a lot due to
David Kastrup writes:
> Again, that's with an SSD and ext4 filesystem on GNU/Linux, and there
> are no improvements in system time (I/O) except for patch 4 of the
> series which helps perhaps 20% or so.
>
> So the benefits of the patch will come into play mostly for big, bad
> files on Windows: o
On Tue, Feb 11, 2014 at 11:38:09AM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >> - Branch rename breaks local downstream branches
> >>http://article.gmane.org/gmane.comp.version-control.git/241228
> >
> > If you have a branch B that builds on A, if
Johannes Sixt writes:
> Am 2/12/2014 20:30, schrieb Stefan Zager:
>> On Wed, Feb 12, 2014 at 11:22 AM, Karsten Blees
>> wrote:
>>> Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
ReOpenFile, that's fantastic. Thanks a lot!
>>>
>>> ...but should be loaded dynamically via GetProcAddress, or are
On Tue, Feb 11, 2014 at 10:57:22AM -0800, Junio C Hamano wrote:
> > - git stash doesn't use --index as default
> >http://article.gmane.org/gmane.comp.version-control.git/235892
>
> I tend to think "git stash" was designed to work this way from day
> one.
Right. The thing that bothers me is
On 13/02/14 10:55, Robert Dailey wrote:
> I have the following alias defined:
> sync = "!f() { cbr=$(git rev-parse --abbrev-ref HEAD); git co $1 &&
> git pull && git co $cbr && git rebase $1; }; f"
>
> The goal is to basically update a local branch which tracks a branch
> on a remote, and then reb
On Thu, Feb 06, 2014 at 10:51:54AM +0100, Matthieu Moy wrote:
> > Some of Matthieu's students worked on it a few years ago but didn't finish.
>
> Right. There was still quite some work to do, but this is most likely
> too small for a GSoC project. But that could be a part of it. I'm not
> sure ho
Hi,
for files that contain windows line endings in a repository with
core.autocrlf=input, git blame will show lines as "Not Committed Yet",
even though they were not modified.
Example:
--
git init
git config core.autocrlf false
echo "foo" > a
unix2dos a
git add a
git commit -m "initial commi
The Google Summer of Code application process is upon us. We have about
34 hours until the deadline (2014-02-14T19:00 UTC) . That's not very
much time, but I know some people have been thinking about projects for
a while, so I have hope that we can put together an ideas page.
What we need immediat
On Thu, Feb 13, 2014 at 9:50 AM, Jeff King wrote:
> On Thu, Feb 06, 2014 at 10:51:54AM +0100, Matthieu Moy wrote:
>
>> > Some of Matthieu's students worked on it a few years ago but didn't finish.
>>
>> Right. There was still quite some work to do, but this is most likely
>> too small for a GSoC p
On Thu, Feb 13, 2014 at 07:04:02AM +0100, David Kastrup wrote:
> Mike Hommey writes:
>
> > On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
> >> Stefan Zager writes:
> >>
> >> > On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup wrote:
> >> >
> >> >> Really, give the above patch a t
On Thu, Feb 13, 2014 at 06:34:39PM +0900, Mike Hommey wrote:
> On Thu, Feb 13, 2014 at 07:04:02AM +0100, David Kastrup wrote:
> > Mike Hommey writes:
> >
> > > On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
> > >> Stefan Zager writes:
> > >>
> > >> > On Wed, Feb 12, 2014 at 10:5
Christian Couder writes:
> On Thu, Feb 13, 2014 at 9:50 AM, Jeff King wrote:
>
>> I think Google leaves it up to us to decide. I'd be OK with a project
>> made of multiple small tasks, as I think it would be an interesting
>> experiment. I'd rather not do all of them like that, though. And
>> b
Signed-off-by: Michael J Gruber
---
Just a few things I spotted while trying to keep myself informed :)
Documentation/RelNotes/1.9.txt | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/Documentation/RelNotes/1.9.txt b/Documentation/RelNote
I CAN HELP YOU WITH THE LOAN YOU NEED AT 3% INTEREST RATE. CONTACT US
AT:-ryanwrightfinance...@gmail.com
--
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
start_httpd is supposed to be at the beginning of the test file, not
the middle of it. The "test_seq" line in "no shallow lines.." test is
updated to compensate missing refs that are there in t5537, but not in
the new t5539.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On Thu, Feb 13, 2014 at 8:22 AM
On Fri, Feb 07, 2014 at 09:48:52PM +0400, Kirill Smelkov wrote:
> instead of allocating it all the time for every subtree in
> __diff_tree_sha1, let's allocate it once in diff_tree_sha1, and then all
> callee just use it in stacking style, without memory allocations.
>
> This should be faster, and
Here go combine-diff speedup patches in form of first reworking diff
tree-walker to work in general case - when a commit have several parents, not
only one - we are traversing all 1+nparent trees in parallel.
Then we are taking advantage of the new diff tree-walker for speeding up
combine-diff, wh
As was recently shown (c839f1bd "combine-diff: optimize
combine_diff_path sets intersection"), combine-diff runs very slowly. In
that commit we optimized paths sets intersection, but that accounted
only for ~ 25% of the slowness, and as my tracing showed, for linux.git
v3.10..v3.11, for merges a lo
Previously diff_tree(), which is now named __diff_tree_sha1(), was
generating diff_filepair(s) for two trees t1 and t2, and that was
usually used for a commit as t1=HEAD~, and t2=HEAD - i.e. to see changes
a commit introduces.
In Git, however, we have fundamentally built flexibility in that a
comm
On Wed, Feb 12, 2014 at 09:25:51AM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Kirill Smelkov writes:
> >
> >> Sorry for the confusion. Could you please do the following:
> >>
> >> Patches should be applied over to ks/tree-diff-walk
> >> (74aa4a18). Before applying the patches, p
Kirill Smelkov writes:
> +static void show_path(struct strbuf *base, struct diff_options *opt,
> + struct tree_desc *t1, struct tree_desc *t2)
> {
> unsigned mode;
> const char *path;
> - const unsigned char *sha1 = tree_entry_extract(desc, &path, &mode);
> -
On Thu, Feb 13, 2014 at 09:43:27AM -0800, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > +static void show_path(struct strbuf *base, struct diff_options *opt,
> > + struct tree_desc *t1, struct tree_desc *t2)
> > {
> > unsigned mode;
> > const char *path;
> > - co
Even when having specified a format string for-each-ref still prints a
newline after printing each ref according to the format. This breaks
splitting the output on newlines, for example.
Signed-off-by: Øystein Walle
---
I was somewhat surprised by this behaviour; I expected to be in full control
Øystein Walle gmail.com> writes:
>
> splitting the output on newlines, for example.
>
Ugh, I mean on null bytes, naturally.
Øsse.
--
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.kerne
Hi,
I'm wondering why there is no execution of the pre-commit hook when
rebasing.
When I do a rebase of N commits (say, 3 or so) onto another branch,
each of the rebased commits gets "recommitted" to the branch, am I
right?
If yes, wouldn't it make sense to run the pre-commit hook after each
app
On Thu, Feb 13, 2014 at 12:27 AM, Johannes Sixt wrote:
> Am 2/12/2014 20:30, schrieb Stefan Zager:
>> On Wed, Feb 12, 2014 at 11:22 AM, Karsten Blees
>> wrote:
>>> Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
ReOpenFile, that's fantastic. Thanks a lot!
>>>
>>> ...but should be loaded dynami
Karsten Blees gmail.com> writes:
>
> Am 12.02.2014 19:37, schrieb Erik Faye-Lund:
> > On Wed, Feb 12, 2014 at 7:34 PM, Stefan Zager google.com>
wrote:
> >> On Wed, Feb 12, 2014 at 10:27 AM, Erik Faye-Lund
gmail.com> wrote:
> >>> On Wed, Feb 12, 2014 at 7:20 PM, Stefan Zager google.com>
wro
Thanks for reviewing.
as you wrote, diff content may not be utf8 at all. and we don't know that the
user's terminal watns is utf8.
I think your trying utf8 decode and fall back approach is better than my patch,
and do work well.
is using "$@" for catching error like the patch below?
According to
Junio C Hamano writes:
> Jeff King writes:
>
>> test_normalize_tristate GIT_TEST_DAEMON
>
> Heh, great minds think alike. This is what I am playing with,
> without committing (because I do like your "ask config if this is a
> kind of various boolean 'false' representations, which I haven't
>
Kirill Smelkov writes:
> + /* until we go to it next round, .next holds how many bytes we
> + * allocated (for faster realloc - we don't need copying old
> data).
> + */
> + p->next = (struct combine_diff_path *)alloclen;
I am getting this here:
Kirill Smelkov writes:
> + if (need_generic_pathscan) {
> + /* NOTE generic case also handles --stat, as it computes
> + * diff(sha1,parent_i) for all i to do the job, specifically
> + * for parent0.
> + */
> + paths = find_paths_
Øystein Walle writes:
> On to the patch itself: I contemplated putting '\n' in the default format and
> removing it if -n was given, which would get rid of the need to pass an exta
> argument to show_ref(). But that means we would need to *insert it* when a
> format is given and -n is not...
I w
Nguyễn Thái Ngọc Duy writes:
> start_httpd is supposed to be at the beginning of the test file, not
> the middle of it. The "test_seq" line in "no shallow lines.." test is
> updated to compensate missing refs that are there in t5537, but not in
> the new t5539.
>
> Signed-off-by: Nguyễn Thái Ngọ
Michael J Gruber writes:
> Signed-off-by: Michael J Gruber
> ---
> Just a few things I spotted while trying to keep myself informed :)
Thanks. Very much appreciated.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More maj
Jeff King writes:
> - somebody to be the backup admin (I am assuming I'll be the primary
> admin, but as always, if somebody else wants to...)
I can be backup, if Shawn doesn't want it.
> - ideas ideas ideas
Here's my moonshot:
--- 8< ---
Replace object loading/writing layer by libgit
The latest maintenance release Git v1.8.5.5 is now available at
the usual places. Hopefully this will be the last update to the
1.8.5.x series.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
7bb4ea883b1f8f6f7f927035f85e8e2
Thomas Rast writes:
> Downside: not listing "code merged" as a goal may not make the project
> as shiny, neither for Git nor for the student.
I'd actually view that as an upside. This sounds like a good first
step for a feasibility study that is really necessary.
I wonder why the handling of st
Am 13.02.2014 19:38, schrieb Zachary Turner:
> The only reason ReOpenFile is necessary at
> all is because some code somewhere is mixing read-styles against the same
> fd.
>
I don't understand...ReadFile with OVERLAPPED parameter doesn't modify the
HANDLE's file position, so you should be abl
On Thu, Feb 13, 2014 at 2:51 PM, Karsten Blees wrote:
> Am 13.02.2014 19:38, schrieb Zachary Turner:
>
>> The only reason ReOpenFile is necessary at
>> all is because some code somewhere is mixing read-styles against the same
>> fd.
>>
>
> I don't understand...ReadFile with OVERLAPPED parameter do
To elaborate a little bit more, you can verify with a sample program
that ReadFile with OVERLAPPED does in fact modify the HANDLE's file
position. The documentation doesn't actually state one way or
another. My original attempt at a patch didn't have the ReOpenFile,
and we experienced regular re
I uploaded a new patch; a few comments inline below...
On Wed, Feb 12, 2014 at 1:19 PM, Junio C Hamano wrote:
> sza...@chromium.org writes:
>
> Also I'd suggest s/pack_data_fn/collect_pack_data/ or something.
> "_fn" may be a good suffix for typedef'ed typename used in a
> callback function, but
Jeff King wrote:
> - ideas ideas ideas
I'll throw in a few ideas from half-finished work.
1. Speed up git-rebase--am.sh
Currently, git-rebase--am.sh is really slow because it dumps each
patch to a file using git-format-patch, and picks it up to apply
subsequently using git-am. Find a way to sp
This is a first step in making the codebase thread-safe. By and
large, the operations which might benefit from threading are those
that work with pack files (e.g., checkout, blame), so the focus of
this patch is stop leaking the global list of pack files outside of
sha1_file.c.
The next step will
My team is starting to use the --skip-worktree flag on files to allow them to
keep modified files in their working directories. Ideally, they'd like an
option for "git-stash" to apply to skip-worktree files, just as it can
(optionally) be applied to untracked files, so that skip-worktree files
Junio C Hamano writes:
> Thomas Rast writes:
>
>> Downside: not listing "code merged" as a goal may not make the project
>> as shiny, neither for Git nor for the student.
>
> I'd actually view that as an upside. This sounds like a good first
> step for a feasibility study that is really necessar
49 matches
Mail list logo