Torsten Bögershausen tbo...@web.de 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_ENVIRONMENT
On Thu, Mar 07, 2013 at 11:54:18PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net 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
On 08.03.13 09:15, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de 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
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
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
Jan Pešta jan.pe...@certicon.cz 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
Eric Wong normalper...@yhbt.net 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
A few suggestions on the release notes (you may safely ignore)
Junio C Hamano gits...@pobox.com 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
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 --cat-blob-fd=3 3backchannel
git-fast-import crashes with:
fatal: Empty path component found in input
fast-import: dumping
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 ekker...@gmail.com wrote:
The page http://git-scm.com/book/ru/
Введение-Первоначальная-настройка-Git contains incorrect link next
Now this link to the page
On Fri, Mar 8, 2013 at 3:15 PM, Junio C Hamano gits...@pobox.com 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
On Thu, Mar 7, 2013 at 1:09 AM, Junio C Hamano gits...@pobox.com 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
On Thu, Mar 7, 2013 at 2:16 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+static void wt_status_get_detached_from(struct wt_status_state *state)
+{
+ struct grab_1st_switch_cbdata cb;
+ struct commit *commit;
+ unsigned char
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:
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: send
On 3/8/13, Max Horn m...@quendi.de 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
Eric Wong normalper...@yhbt.net writes:
Eric Wong normalper...@yhbt.net 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.
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 commit. What
Jeremy Rosen jeremy.ro...@openwide.fr 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 jeremy.ro...@openwide.fr writes:
506,513c506,507
case $2 in
*\**) # Avoid pulling in multiple branches
die '$2' contains a wildcard
;;
*:*) # Don't create a local branch for
Am 08.03.2013 um 16:32 schrieb Andrew Wong andrew.k...@gmail.com:
On 3/8/13, Max Horn m...@quendi.de 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
Matthieu Moy matthieu@grenoble-inp.fr 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
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr 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/
--
Duy Nguyen pclo...@gmail.com writes:
On Thu, Mar 7, 2013 at 1:09 AM, Junio C Hamano gits...@pobox.com 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
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 g...@cryptocrack.de
---
bundle.c | 8
1 file
On 3/8/13, Max Horn m...@quendi.de 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
Am 08.03.2013 um 19:02 schrieb Andrew Wong andrew.k...@gmail.com:
On 3/8/13, Max Horn m...@quendi.de 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
On 3/8/13, Max Horn m...@quendi.de 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
Hi Junio,
On 03/07/2013 06:33 PM, Junio C Hamano wrote:
Eric Chamberland eric.chamberl...@giref.ulaval.ca 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
Francis Moreau francis.m...@gmail.com 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
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 Seward et
On Fri, Mar 8, 2013 at 4:30 AM, Jeff King p...@peff.net 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
On Fri, Mar 08, 2013 at 04:39:02PM -0500, Eric Sunshine wrote:
On Fri, Mar 8, 2013 at 4:30 AM, Jeff King p...@peff.net 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,
Duy Nguyen pclo...@gmail.com 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
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 gits...@pobox.com
---
refs.c | 59 ++-
1 file
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,
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: moving
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
Jeff King p...@peff.net 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 p...@peff.net wrote:
The GIT_PREFIX variable is set based on our location within
the working tree. It should therefore be cleared whenever
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
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.
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)
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
user
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
Thor Andreas Rognan thor.rog...@gmail.com 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
$
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 with shorter
Junio C Hamano gits...@pobox.com writes:
Thor Andreas Rognan thor.rog...@gmail.com 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
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
57 matches
Mail list logo
