Torsten Bögershausen writes:
>> Doesn't this make one wonder why a separate bit and implementation
>> is necessary to say "I am not interested in untracked files" when
>> "-uno" option is already there?
> ...
> I need to admit that I wasn't aware about "git status -uno".
Not so fast. I did not
On Fri, Mar 08, 2013 at 08:44:20AM +0100, Johannes Sixt wrote:
> Am 3/8/2013 8:15, schrieb Jeff King:
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -344,6 +344,7 @@ static inline enum object_type object_type(unsigned int
> > mode)
> > #define GIT_DIR_ENVIRONMENT "GIT_DIR"
> > #define GIT_NAMESPACE
On Thu, Mar 07, 2013 at 11:54:18PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > diff --git a/cache.h b/cache.h
> > index e493563..070169a 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -344,6 +344,7 @@ static inline enum object_type object_type(unsigned int
> > mode)
> > #define G
On 08.03.13 09:15, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>>> Doesn't this make one wonder why a separate bit and implementation
>>> is necessary to say "I am not interested in untracked files" when
>>> "-uno" option is already there?
>> ...
>> I need to admit that I wasn't aware
Here's a re-roll of the GIT_IMPLICIT_WORK_TREE patch which should
address the comments in the last round. I've added an explanatory
comment near the variable definition, and added it to local_repo_env.
While doing that, I noticed some cleanup opportunities around
local_repo_env, which resulted in
We keep a static array of variables that should be cleared
when invoking a sub-process on another repo. We statically
size the array with the LOCAL_REPO_ENV_SIZE macro so that
any readers do not have to count it themselves.
As it turns out, no readers actually use the macro, and it
creates a maint
The GIT_PREFIX variable is set based on our location within
the working tree. It should therefore be cleared whenever
GIT_WORK_TREE is cleared.
In practice, this doesn't cause any bugs, because none of
the sub-programs we invoke with local_repo_env cleared
actually care about GIT_PREFIX. But this
If an explicit GIT_DIR is given without a working tree, we
implicitly assume that the current working directory should
be used as the working tree. E.g.,:
GIT_DIR=/some/repo.git git status
would compare against the cwd.
Unfortunately, we fool this rule for sub-invocations of git
by setting GIT
Jan Pešta wrote:
> Currently this is cosmetic change - the merges are ignored, becuase the
> methods
> (lookup_svn_merge, find_rev_before, find_rev_after) are failing on comparing
> text with number.
>
> See http://www.open.collab.net/community/subversion/articles/merge-info.html
> Extract:
>
Eric Wong wrote:
> will push another change for formatting existing warnings more
> consistently.
Just pushed. My master is sitting at git://git.bogomips.org/git-svn.git
commit eae6cf5aa8ae2d8a90a99bbe4aeb01c29e01fd02
Eric Wong (1):
git svn: consistent spacing after "W:" in warnin
A few suggestions on the release notes (you may safely ignore)
Junio C Hamano writes:
> In the next major release Git 2.0 (not *this* one), we will change the
> behavior of the "git push" command.
It's not entirely clear from the formatting whether this sentenece
introduces the whole "Backward
I'm importing a huge repository using svn-fe and git-fast-import.
$ cat repo.svn_dump | svn-fe 'svn+ssh://bjor...@example.com/pub/repo/'
3backchannel
git-fast-import crashes with:
fatal: Empty path component found in input
fast-import: dumping crash report to .git/fast_import_crash_10844
Cra
On Thu, Mar 07, 2013 at 12:47:36PM +0400, Konstantin Khomoutov wrote:
> On Thu, 7 Mar 2013 00:01:31 -0800 (PST)
> Aleksey Rozhkov wrote:
>
> > The page http://git-scm.com/book/ru/
> > Введение-Первоначальная-настройка-Git contains incorrect link "next"
> > Now this link to the page
> > http://g
On Fri, Mar 8, 2013 at 3:15 PM, Junio C Hamano wrote:
>> The possible options are:
>> +
>> - - 'no' - Show no untracked files
>> + - 'no' - Show no untracked files (this is fastest)
>
> There is a trade-off around the use of -uno between safety and
> performance. The default
On Thu, Mar 7, 2013 at 1:09 AM, Junio C Hamano wrote:
> I agree that saying what it is, what it does or what it is for
> upfront (i.e. "Specifies what are pushed") before how it is spelled
> is an improvement. I however think describing "If not specified"
> here was a mistake, and you are making
On Thu, Mar 7, 2013 at 2:16 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> +static void wt_status_get_detached_from(struct wt_status_state *state)
>> +{
>> + struct grab_1st_switch_cbdata cb;
>> + struct commit *commit;
>> + unsigned char sha1[20];
>> + char *ref =
A follow up:
I was able to reproduce this behavior on my Mac with multiple git versions down
to 1.6.0.6. On the other hand, I copied the whole work tree to a virtual
machine running Ubuntu, and there the issue did not occur.
All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
Hi im running arch linux and core/glibc 2.17-3
When i try to rebase with:
git clonehttps://github.com/owncloud/core.git
cd core/
git pull --rebasehttps://github.com/PatrickHeller/core.git master
I'm getting:
$ git pull --rebasehttps://github.com/PatrickHeller/core.git master
remote: Counting
Ive been tagging some commits using tortoise git , for example with "v1.0",
"v1.1" etc. In tortoise git log the tag sits alongside the commit as I expect.
But when I do a git describe it outputs the first tag along with the latest
commit. What am I doing wrong?
--
To unsubscribe from this list: s
On 3/8/13, Max Horn wrote:
> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
> journaling, not case sensitive (the default)) might be at fault. Still, this
> is quite puzzling and annoying, and so I still wonder if anybody has any
> insights on this.
When "rebase" errors out
Eric Wong writes:
> Eric Wong wrote:
>> will push another change for formatting existing warnings more
>> consistently.
>
> Just pushed. My master is sitting at git://git.bogomips.org/git-svn.git
> commit eae6cf5aa8ae2d8a90a99bbe4aeb01c29e01fd02
Thanks.
>
> Eric Wong (1):
> git
ok, attached is a patch on top of your patch that solves my particular
problem
I am not "formally submitting it" since its on top of your part and i'd
really like your input before submitting.
It solves my problem and afaict does what your fix did and what git-subtree
originally intended to do...
On Fri, 2013-03-08 at 15:16 +, John Stean wrote:
> Ive been tagging some commits using tortoise git , for example with
> "v1.0", "v1.1" etc. In tortoise git log the tag sits alongside the
> commit as I expect.
> But when I do a git describe it outputs the first tag along with the
> latest commi
Jeremy Rosen writes:
> 506,513c506,507
> < case "$2" in
> < *\**) # Avoid pulling in multiple branches
> < die "'$2' contains a wildcard"
> < ;;
> < *:*) # Don't create a local branch for the subtree
> <
- Mail original -
> Jeremy Rosen writes:
>
> > 506,513c506,507
> > < case "$2" in
> > < *\**) # Avoid pulling in multiple branches
> > < die "'$2' contains a wildcard"
> > < ;;
> > < *:*) # Don't create a local branch for t
Am 08.03.2013 um 16:32 schrieb Andrew Wong :
> On 3/8/13, Max Horn wrote:
>> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
>> journaling, not case sensitive (the default)) might be at fault. Still, this
>> is quite puzzling and annoying, and so I still wonder if anybody h
Matthieu Moy writes:
> A few suggestions on the release notes (you may safely ignore)
They both look very sensible, at least to me. Perhaps like this?
Thanks.
Documentation/RelNotes/1.8.2.txt | 60 +++-
1 file changed, 34 insertions(+), 26 deletions(-)
di
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> A few suggestions on the release notes (you may safely ignore)
>
> They both look very sensible, at least to me. Perhaps like this?
Looks good, yes.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the
Duy Nguyen writes:
> On Thu, Mar 7, 2013 at 1:09 AM, Junio C Hamano wrote:
>> I agree that saying what it is, what it does or what it is for
>> upfront (i.e. "Specifies what are pushed") before how it is spelled
>> is an improvement. I however think describing "If not specified"
>> here was a m
These slightly improve the reading flow by making it obvious that a list
follows.
Also, make the wording of both headings consistent by changing "contains
%d ref(s)" to "contains this ref"/"contains these %d refs".
Signed-off-by: Lukas Fleischer
---
bundle.c | 8
1 file changed, 4 inse
On 3/8/13, Max Horn wrote:
> I tried this a dozen times, but 'git apply' failed to fail even once. No
> surprise there, given that the patch that throws off rebase every time is
> clean and simple. I am flabbergasted :-(
Hm, what if you add in the "--index" flag? i.e.
git apply --index .git/r
Am 08.03.2013 um 19:02 schrieb Andrew Wong :
> On 3/8/13, Max Horn wrote:
>> I tried this a dozen times, but 'git apply' failed to fail even once. No
>> surprise there, given that the patch that throws off rebase every time is
>> clean and simple. I am flabbergasted :-(
>
> Hm, what if you add
On 3/8/13, Max Horn wrote:
> Same result, it works fine.
Just shooting in the dark here... I wonder if there's some background
process running in OS X that's messing with the files/directories
while rebase is working... backup, virus scan, etc? Or maybe some
programs that you're using at the same
Hi Junio,
On 03/07/2013 06:33 PM, Junio C Hamano wrote:
Eric Chamberland writes:
What you want is a way to compute, given a set of tags (or refs in
general) and a set of branches (or another set of refs in general),
find the ones in the former that none of the latter can reach. With
that, you
Hi,
Sorry for the long delay, I somehow missed your answer...
On Fri, Mar 1, 2013 at 6:46 PM, Junio C Hamano wrote:
> Francis Moreau writes:
>
>> Would it make sense to add the option --ignore-submodules (currently
>> available in git-status) to git-describe when the later is used with
>> --dir
Francis Moreau writes:
>> But when we ignore untracked paths in the superproject, we should
>> ignore untracked paths in submodule working trees consistently.
>
> yes I agree.
>
> But in the short term, could you suggest a method to workaround this
> inconsistency ?
Hrm, ... didn't I already?
On Fri, Mar 08, 2013 at 01:19:57PM +0100, Bernhard Posselt wrote:
> Using valgrind gives me:
>
> $ valgrind /usr/bin/git pull
> --rebasehttps://github.com/PatrickHeller/core.git master
> ==5995== Memcheck, a memory error detector
> ==5995== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Sewa
On Fri, Mar 8, 2013 at 4:30 AM, Jeff King wrote:
> The GIT_PREFIX variable is set based on our location within
> the working tree. It should therefore be cleared whenever
> GIT_WORK_TREE is cleared.
>
> In practice, this doesn't cause any bugs, because none of
> the sub-programs we invoke with loc
On Fri, Mar 08, 2013 at 04:39:02PM -0500, Eric Sunshine wrote:
> On Fri, Mar 8, 2013 at 4:30 AM, Jeff King wrote:
> > The GIT_PREFIX variable is set based on our location within
> > the working tree. It should therefore be cleared whenever
> > GIT_WORK_TREE is cleared.
> >
> > In practice, this d
Duy Nguyen writes:
>> It should be more like this, I would think:
>>
>> for_each_recent_reflog_ent();
>> if (!found)
>> for_each_reflog_ent();
>> if (!found)
>> return;
>
> Yes. This "recent" optimization is tricky.
Not really. What is tri
Split the logic that takes a single line of reflog entry in a strbuf
parses it and calls the callback function out of the loop into a
separate helper function.
Signed-off-by: Junio C Hamano
---
refs.c | 59 ++-
1 file changed, 30 insertions
There is no reason to use a temporary variable logfile.
---
refs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index 9f702a7..e302521 100644
--- a/refs.c
+++ b/refs.c
@@ -2320,13 +2320,11 @@ static int show_one_reflog_ent(struct strbuf *sb,
each_reflog_e
"git checkout -" is a short-hand for "git checkout @{-1}" and the
"@{nth}" notation for a negative number is to find nth previous
checkout in the reflog of the HEAD to determine the name of the
branch the user was on. We would want to find the nth most recent
reflog entry that matches "checkout: m
The for_each_reflog_ent() function yields reflog entries from the
oldest to newer, and is inefficient when we know what we are looking
for are near the newest end (e.g. "find the nth newest reflog entry
that matches 'checkout: moving from X to Y'"). To optimize for the
common case, we introduced f
Jeff King writes:
> On Fri, Mar 08, 2013 at 04:39:02PM -0500, Eric Sunshine wrote:
>
>> On Fri, Mar 8, 2013 at 4:30 AM, Jeff King wrote:
>> > The GIT_PREFIX variable is set based on our location within
>> > the working tree. It should therefore be cleared whenever
>> > GIT_WORK_TREE is cleared.
Here are two future steps to update the behaviour of "add -u/-A" run
without pathspec towards Git 2.0; the first step may probably be
optional, but it is included for completeness.
Junio C Hamano (2):
require pathspec for "git add -u/-A"
git add: -u/-A now affects the entire working tree
Doc
As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without
pathspec, 2013-01-28), "git add -u/-A" that is run without pathspec
in a subdirectory will stop working sometime before Git 2.0, to wean
users off of the old default, in preparation for adopting the new
default in Git 2.0.
Signed
As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without
pathspec, 2013-01-28), in Git 2.0, "git add -u/-A" that is run
without pathspec in a subdirectory updates all updated paths in the
entire working tree, not just the current directory and its
subdirectories.
Signed-off-by: Junio C
On 03/08/2013 10:28 PM, Jeff King wrote:
On Fri, Mar 08, 2013 at 01:19:57PM +0100, Bernhard Posselt wrote:
Using valgrind gives me:
$ valgrind /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git
master
==5995== Memcheck, a memory error detector
==5995== Copyright (C) 2002-201
I've been examining how and where str*cmp are called by
read_directory(). They are presumably where most of the time is spent.
The gain is not big, but still worth it, I think.
These are tested without nd/read-directory-recursive-optim. The saving
is probably smaller as nd/read... cuts down a big
This reduces "git status" user time by a little bit. This is the
sorted results of 10 consecutive runs of "git ls-files
--exclude-standard -o" on webkit.git, compiled with gcc -O2:
before after
user0m0.580s0m0.546s
user0m0.581s0m0.549s
user0m0.582s0m0.550s
user
Like the previous patch, this cuts down the number of str*cmp calls in
read_directory (which does _a lot_). Again sorted results on webkit.git:
before after
user0m0.546s0m0.519s
user0m0.549s0m0.521s
user0m0.550s0m0.523s
user0m0.558s0m0.532s
user0m0.
strncmp provides length information, compared to strcmp, which could
be taken advantage by the implementation. Even better, we could check
if the lengths are equal before calling strncmp, eliminating a bit of
strncmp calls.
before after
user0m0.519s0m0.489s
user0m0.521s
On Sat, Mar 09, 2013 at 01:08:32AM +0100, Bernhard Posselt wrote:
> >The problem is likely happening in a sub-command of git-pull, so
> >valgrind isn't reporting it. Can you try re-running with
> >"valgrind --trace-children=yes", or alternatively narrow down the
> >problematic command by setting G
Thor Andreas Rognan writes:
> Maybe I'm doing it wrong, or maybe it's the intended behaviour,
> but I find that a trailing whitespace after a pattern in .gitignore
> makes the pattern void with git 1.8.1.5.
I doubt we do anything clever like that.
$ git init
$ touch hello.o "hel
On 02/25/2013 11:50 AM, Michael Haggerty wrote:
> On 02/25/2013 10:54 AM, Matthieu Moy wrote:
>> [...] Works for me. One minor knit: you've included 10-characters sha1s (this
>> comes from
>>
>> self.short = read_output(['git', 'rev-parse', '--short=10', sha1])
>>
>> ), I'd find it better w
Junio C Hamano writes:
> Thor Andreas Rognan writes:
>
>> Maybe I'm doing it wrong, or maybe it's the intended behaviour,
>> but I find that a trailing whitespace after a pattern in .gitignore
>> makes the pattern void with git 1.8.1.5.
>
> I doubt we do anything clever like that.
> ...
> The us
Nguyễn Thái Ngọc Duy writes:
> strncmp provides length information, compared to strcmp, which could
> be taken advantage by the implementation. Even better, we could check
> if the lengths are equal before calling strncmp, eliminating a bit of
> strncmp calls.
I think I am a bit slower than my
58 matches
Mail list logo