I'm currently working on a git project( vwf - virtualworldframework ), and we
need to get a couple of files from another repository( threes ). We've forked
threejs into our repository, but I need to be able to grab only those few files
that I need. I thought I wanted to do a sub-tree merge, bu
If it's dependent on eval "`dircolors`", it suggests it might be
dependent on the size of the environment. Maybe try with FOO=`perl -e
'print "x"x1000'` for various values of 1000...
Jeff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.
On Mon, Mar 11, 2013 at 09:03:42PM -0400, Andrew Wong wrote:
> On 03/11/13 21:01, Jeff King wrote:
> > From "git help config":
> >
> > core.trustctime
> > If false, the ctime differences between the index and the working
> > tree are ignored; useful when the inode change time is regularl
On 03/11/13 21:01, Jeff King wrote:
> From "git help config":
>
> core.trustctime
> If false, the ctime differences between the index and the working
> tree are ignored; useful when the inode change time is regularly
> modified by something outside Git (file system crawlers and some
>
On 03/11/13 20:29, Max Horn wrote:
> sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist
>
> -> this exits revisiond, and prevents launchd from respawning it. After that,
> the problem is gone, on several attempts. And once I reactivate revisions,
> the problem reoccurs.
On Tue, Mar 12, 2013 at 01:29:45AM +0100, Max Horn wrote:
> So it seems pretty clear what the cause of this is. Now I still need
> to figure out why it affects that particular repository and not
> others. But at this point I guess it is safe to say that Apple's
> auto-crap-magic revisiond is the r
On 11/03/2013 05:03, Junio C Hamano wrote:
Hmm, I feel more confused than convinced after reading the above
three times. Perhaps that is because I am too used to the way how
"git" potty itself behaves, especially the part that "git help git"
is the way to ask "git" (the first token on the comman
On Mon, Mar 11, 2013 at 8:29 PM, Max Horn wrote:
[snip]
>
> sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist
>
> -> this exits revisiond, and prevents launchd from respawning it. After that,
> the problem is gone, on several attempts. And once I reactivate revisions,
On 11.03.2013, at 23:54, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> Looking at the git config man page to check what each of my config settings
>> does, I discovered "trustctime". And adding
>> trustctime = false
>> to .git/config made the rebase work, every single time. Huh.
>>
>
On 11.03.2013, at 23:54, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> Looking at the git config man page to check what each of my config settings
>> does, I discovered "trustctime". And adding
>> trustctime = false
>> to .git/config made the rebase work, every single time. Huh.
>>
>
On 3/11/13, Max Horn wrote:
> Looking at the git config man page to check what each of my config settings
> does, I discovered "trustctime". And adding
> trustctime = false
> to .git/config made the rebase work, every single time. Huh.
>
>
> Adding this to the fact that a clone works fine, I
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>> * If the file ~/git-shell-commands/no-interactive-login exists,
>>run no-interactive-login to let the server say what it likes,
>>then hang up.
[...]
> If "no-interactive-login" doesn't have execute permissions, we'll get
> an error
On 11.03.2013, at 23:10, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> PS: Just as a side note, I should mention that I have done tons of rebases
>> on various repositories on this very machine: same hard drive, same file
>> system; the git version of course has changed over time, but as I
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The final will be tagged in a few days; we have enough material for
post 1.8.2 cycle already, and it will be a busy few weeks towards
the end of
On 11.03.2013, at 22:34, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> So I tried this:
>>
>> git rebase branches/stable-4.6 # ... which leads to the error
>> git ls-files -m
>>
>> but got nothing. Perhaps you had something else in mind, though, but I am
>> not quite sure what... sorr
Hi there,
We have been attempting to move our smallish SVN repository for our
Open Source project (ww.exist-db.org) from SourceForge over to GitHub
and it is not going well at all.
We started with svn2git as recommended by GitHub and that didnt work,
we are not on to using 'git svn' directly. If
On 3/11/13, Max Horn wrote:
> PS: Just as a side note, I should mention that I have done tons of rebases
> on various repositories on this very machine: same hard drive, same file
> system; the git version of course has changed over time, but as I already
> described, I can reproduce the same issu
From: Miklós Fazekas
The generic chdir() helper sets the PWD environment
variable, as that is what is used by p4 to know its
current working directory. Normally the shell would
do this, but in git-p4, we must do it by hand.
However, when the path contains a symbolic link,
os.getcwd() will retur
"Philip Oakley" writes:
> From: "Junio C Hamano"
>> Matthieu Moy writes:
>>
>>> See 'git help git' for general help about Git.
>>>
>>> to the output of "git help"?
>> ...
>> That sounds like a good direction to go in.
>
> My earlier attempt, and Junio's reply
> http://thread.gmane.org/gmane.c
This test fails when the p4 client root includes
a symlink. It complains:
Path /vol/bar/projects/foo/... is not under client root /p/foo
and dumps a traceback.
Signed-off-by: Pete Wyckoff
---
t/t9808-git-p4-chdir.sh | 27 +++
1 file changed, 27 insertions(+)
diff
This adds a test for the fix in bf1d68f (git-p4: use absolute
directory for PWD env var, 2011-12-09). It is necessary to
set PWD to an absolute path so that p4 can find files referenced
by non-absolute paths, like the value of the P4CONFIG environment
variable.
P4 does not open files directly; it
Update from v1:
* add SYMLINKS prerequisite to the new symlink test
Thanks Hannes.
Miklós pointed out in
http://thread.gmane.org/gmane.comp.version-control.git/214915
that when the p4 client root included a symlink, bad things
happen. It is fixable, but inconvenient, to use an absolu
On 3/11/13, Max Horn wrote:
> So I tried this:
>
> git rebase branches/stable-4.6 # ... which leads to the error
> git ls-files -m
>
> but got nothing. Perhaps you had something else in mind, though, but I am
> not quite sure what... sorry for being dense, but if you let me know what
> exactl
PS: Just as a side note, I should mention that I have done tons of rebases on
various repositories on this very machine: same hard drive, same file system;
the git version of course has changed over time, but as I already described, I
can reproduce the same issue with older git versions.
All I
On 11.03.2013, at 20:15, Andrew Wong wrote:
> On 3/10/13, Max Horn wrote:
>> I did run
>>
>> touch lib/*.* src/*.* && git update-index --refresh && git diff-files
>>
>> a couple dozen times (the "problematic" files where in src/ and lib), but
>> nothing happened. I just re-checked, and the re
From: "Junio C Hamano"
Sent: Monday, March 11, 2013 7:02 PM
Matthieu Moy writes:
Kevin Bracey writes:
Two significant usability flaws here:
- If using man, "man git" to side-step "git help" is obvious. But
if
trying to use help.format=web, how to get the root html page? My
techniq
Make the command line use the narrower synopsis layout that the man page
has used since commit 68e4b55.
Signed-off-by: Kevin Bracey
---
git.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index d33f9b3..2a98624 100644
--- a/git.c
+++ b/git.c
@@ -6,10 +6,10
On 11/03/2013 21:58, Junio C Hamano wrote:
Kevin Bracey writes:
Re-ordered option list in command-line usage to match the manual page.
Also makes it less than 80-characters wide.
Thanks (s/Re-ordered/reorder/ and s/makes/make/, though).
Got it. But I'm going to reword it, to follow the hist
Allow merge of two commits that are contained in each other and do the
same rewind. The rewind is calculated using the commit recorded in the
merge base of the superproject.
Signed-off-by: Heiko Voigt
---
On Sun, Mar 10, 2013 at 06:09:53PM +0100, Heiko Voigt wrote:
> On Sat, Mar 09, 2013 at 06:4
Kevin Bracey writes:
> Re-ordered option list in command-line usage to match the manual page.
> Also makes it less than 80-characters wide.
Thanks (s/Re-ordered/reorder/ and s/makes/make/, though).
Is git.c the only one whose "-h" output does not match the manual
synopsis?
>
> Signed-off-by: K
Re-ordered option list in command-line usage to match the manual page.
Also makes it less than 80-characters wide.
Signed-off-by: Kevin Bracey
---
git.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index d33f9b3..2a98624 100644
--- a/git.c
+++ b/git.c
@@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/03/2013 16:37, Matthieu Moy ha scritto:
> [...]
> I could reproduce with ~/.zshrc containing just:
>
> --
> fpath=(${HOME}/usr/etc/zsh ${fpath})
>
> autoload -Uz compinit
> compinit
>
> eval "`dircol
Jeff King wrote:
> On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
>> wrote:
>> > Hi,
>> >
>> > I have this itch where I want to share my remotes config between
>> > machines. In my fork, I should be able to specify
On 3/10/13, Max Horn wrote:
> I did run
>
> touch lib/*.* src/*.* && git update-index --refresh && git diff-files
>
> a couple dozen times (the "problematic" files where in src/ and lib), but
> nothing happened. I just re-checked, and the rebase still fails in the same
> why...
>
> Perhaps I sho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/03/2013 19:09, Junio C Hamano ha scritto:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> Ahh, thanks for reminding me of this. You are right; these two
>>> functions are broken when the user has CDPATH set, I think.
>>>
>>> Here is
Matthieu Moy writes:
> Kevin Bracey writes:
>
>> Two significant usability flaws here:
>> - If using man, "man git" to side-step "git help" is obvious. But if
>>trying to use help.format=web, how to get the root html page? My
>>technique was "git help XXX" and click the "git(1) suite" l
On Mon, 2013-03-11 at 11:09 -0700, Junio C Hamano wrote:
> So strictly speaking there is no reason for an extra subshell here,
> but writing this in the way the patch does makes our intention
> crystal clear, I think.
If you're concerned about the extra processing of the new shell you can
use {} i
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Ahh, thanks for reminding me of this. You are right; these two
>> functions are broken when the user has CDPATH set, I think.
>>
>> Here is a reroll.
>
> Thanks. Even nicer that the previous since the CDPATH implied the
> subshell anyway.
Actu
Junio C Hamano writes:
> Ahh, thanks for reminding me of this. You are right; these two
> functions are broken when the user has CDPATH set, I think.
>
> Here is a reroll.
Thanks. Even nicer that the previous since the CDPATH implied the
subshell anyway.
--
Matthieu Moy
http://www-verimag.ima
Manlio Perillo writes:
> Yes, I was plainning to send another patch to fix this (and your other
> suggestion regarding the CDPATH environment variable, if I remember
> correctly),...
Ahh, thanks for reminding me of this. You are right; these two
functions are broken when the user has CDPATH set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/03/2013 18:01, Junio C Hamano ha scritto:
> [...]
> Having to restrict to the common subset means that whenever bash
> adds new and useful features that this script could take advantage
> of to improve the user experience, they cannot be employed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/03/2013 17:17, Junio C Hamano ha scritto:
> Matthieu Moy writes:
>
>> The function-wide redirection used for __git_ls_files_helper and
>> __git_diff_index_helper work only with bash. Using ZSH, trying to
>> complete an inexistant directory gave
On Mon, Mar 11, 2013 at 01:47:03AM +0530, Ramkumar Ramachandra wrote:
> git operations are slow on repositories with lots of files, and lots
> of tiny filesystem calls like lstat(), getdents(), open() are
> reposible for this. On the linux-2.6 repository, for instance, the
> numbers for "git statu
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> So here is an updated based on your patch.
>
> Perfect, thanks.
>
>> The correct thing to do in the longer term may be to stop dot-sourcing
>> the source meant for bash into zsh, but this patch should suffice as
>> a band-aid in the meantime.
>
Michał Janiszewski writes:
> Hmm, indeed it works. Sorry for the confusion then (and a bit mistaken
> commands, but you got them correct).
> I wasn't aware of the -r option.
I think what tripped you was that "git branch" deals with branch
names, and not refnames (which is the underlying but lowe
Junio C Hamano writes:
> So here is an updated based on your patch.
Perfect, thanks.
> The correct thing to do in the longer term may be to stop dot-sourcing
> the source meant for bash into zsh, but this patch should suffice as
> a band-aid in the meantime.
I disagree with this particular par
On Sat, Mar 09, 2013 at 07:18:48PM +0100, Jens Lehmann wrote:
> Am 05.03.2013 22:17, schrieb Phil Hord:
> > In a shell, it usually goes like this:
> >
> >git submodule foreach --recursive '${cmd}'
> >{30-ish}
> >
> > It'd be easier if I could just include a switch for this, and maybe
> >
Junio C Hamano writes:
> After all, I was right when I said that some implementations may get
> it wrong and we shouldn't use the construct X-<.
>
>> These two instances seem to be the only ones in the file.
>>
>> I'm not sure whether the 2>/dev/null would be needed for the command
>> on the RHS
Hmm, indeed it works. Sorry for the confusion then (and a bit mistaken
commands, but you got them correct).
I wasn't aware of the -r option.
On Mon, Mar 11, 2013 at 5:29 PM, Junio C Hamano wrote:
> Michał Janiszewski writes:
>
>> Hi,
>> I think I've found a bug in git or at least a use case that
Michał Janiszewski writes:
> Hi,
> I think I've found a bug in git or at least a use case that is not handled.
> In few words it can be described like this: if you push a remote
> branch to another remote, which is bare repository, you cannot remove
> that branch from said bare repository.
> Here
Matthieu Moy writes:
> The function-wide redirection used for __git_ls_files_helper and
> __git_diff_index_helper work only with bash. Using ZSH, trying to
> complete an inexistant directory gave this:
>
> git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory:
> no-such-dir
Matthieu Moy writes:
> When the commands give an actual output (e.g. when ran with -v), the
> output is visually mixed with the warning. The newline makes the actual
> output more visible.
>
> Signed-off-by: Matthieu Moy
> ---
It would have been easier to immediately understand what is going on
Thomas Rast student.ethz.ch> writes:
>
> Vadim Zeitlin zeitlins.org> writes:
>
> > Lawrence Mitchell gmx.li> writes:
> >
> >> Vadim Zeitlin wrote:
> >>
> >> [...]
> >>
> >> > git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all
> >>
> >> git rev-list lists by default in
Manlio Perillo writes:
> I have the same system, but I can't reproduce the problem.
> What is the content of your .zshrc file?
I could reproduce with ~/.zshrc containing just:
--
fpath=(${HOME}/usr/etc/zsh ${fpath})
autoload -Uz compinit
compinit
ev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/03/2013 13:30, Matthieu Moy ha scritto:
> Hi,
>
> Since the recent update to bash completion, I often get a segmentation
> fault from ZSH. This is most likely a bug in ZSH, but it would be cool
> to avoid triggering it from Git.
>
> [...]
> moy
The hunt continues.. (and thanks everyone for suggestions). Now
is_excluded() (and exclude machinery) is no longer the hot spot in
read_directory. index_name_exists is the new star:
function time (in seconds)
treat_leading_path: 0.000
read_directory: 0.289
+treat_o
Dmitry Ilin venit, vidit, dixit 11.03.2013 12:30:
> I tried this command and I got following result:
>
> trace: built-in: git 'show' 'a1bffde'
> trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k
> '\''abcde'\'' 2> /dev/null || cat'
> trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-2
Michael Haggerty alum.mit.edu> writes:
>
> On 03/11/2013 12:45 PM, Vadim Zeitlin wrote:
> > [...]
> > The first thing I'd like to do is to replace all references to subversion
> > revision numbers in the commit messages with the corresponding git commit
> > SHA1s. [...] I have a couple of dozen
On 03/11/2013 12:45 PM, Vadim Zeitlin wrote:
> [...]
> The first thing I'd like to do is to replace all references to subversion
> revision numbers in the commit messages with the corresponding git commit
> SHA1s. [...] I have a couple of dozens of errors which happen
> because the file .git-rewri
Vadim Zeitlin writes:
> Lawrence Mitchell gmx.li> writes:
>
>> Vadim Zeitlin wrote:
>>
>> [...]
>>
>> > git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all
>>
>> git rev-list lists by default in chronological order. Do you
>> want to pass --topo-order as one of the rev-l
Hi,
Since the recent update to bash completion, I often get a segmentation
fault from ZSH. This is most likely a bug in ZSH, but it would be cool
to avoid triggering it from Git.
Steps to reproduce:
moy@anie:/tmp$$ git init zsh
Initialized empty Git repository in /tmp/zsh/.git/
moy@anie:/tmp$$ c
Lawrence Mitchell gmx.li> writes:
> Vadim Zeitlin wrote:
>
> [...]
>
> > git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all
>
> git rev-list lists by default in chronological order. Do you
> want to pass --topo-order as one of the rev-list options?
Thanks, this looked
The function-wide redirection used for __git_ls_files_helper and
__git_diff_index_helper work only with bash. Using ZSH, trying to
complete an inexistant directory gave this:
git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory:
no-such-dir/
Signed-off-by: Matthieu Moy
--
Vadim Zeitlin wrote:
[...]
> git filter-branch --msg-filter svnmsg2git --tag-name-filter cat -- --all
git rev-list lists by default in chronological order. Do you
want to pass --topo-order as one of the rev-list options?
[...]
Lawrence
--
Lawrence Mitchell
--
To unsubscribe from this list:
Hello,
I'm in the process of converting an existing svn repository to git. The
first step was a standard "git svn clone" that went successfully (after
taking 15 hours to complete). However I don't want to stop there and would
like massage the repository a little before making it publicly availab
On Mon, Mar 11, 2013 at 5:03 AM, Junio C Hamano wrote:
> Paul Campbell writes:
>
>> From: bibendi
>>
>> For each subtree listed in .gittrees perform a push or a pull.
>>
>> Signed-off-by: Paul Campbell
>>
>> Conflicts:
>> contrib/subtree/git-subtree.sh
>
> The "Conflicts:" part is totally
I tried this command and I got following result:
trace: built-in: git 'show' 'a1bffde'
trace: run_command: 'openssl enc -d -base64 -aes-256-ecb -k
'\''abcde'\'' 2> /dev/null || cat'
trace: exec: 'sh' '-c' 'openssl enc -d -base64 -aes-256-ecb -k
'\''abcde'\'' 2> /dev/null || cat' 'openssl enc -d
Dmitry Ilin writes:
> I mean that our filter doesn't work with 'git show' and I need to
> enable it for this command.
>
> This is part of my git config file:
>
> [filter "openssl"]
>smudge = openssl enc -d -base64 -aes-256-ecb -k 'abcde' 2>
> /dev/null || cat
>clean = openssl enc -base64
I mean that our filter doesn't work with 'git show' and I need to enable
it for this command.
This is part of my git config file:
[filter "openssl"]
smudge = openssl enc -d -base64 -aes-256-ecb -k 'abcde' 2> /dev/null
|| cat
clean = openssl enc -base64 -aes-256-ecb -S '12345' -k 'abcde'
Dmitry Ilin writes:
> Hello!
>
> Most of GUI for Git using 'git show' command to show differences
> between versions. For example: WebStorm IDE. But for now there is no
> way to specify text conversion command in git config for 'show' as it
> done for 'diff'.
Do you mean, to enable it, or to dis
Hello!
Most of GUI for Git using 'git show' command to show differences between
versions. For example: WebStorm IDE. But for now there is no way to
specify text conversion command in git config for 'show' as it done for
'diff'. It makes problems when we dealing with encrypted repositories.
I
Kevin Bracey writes:
> Two significant usability flaws here:
> - If using man, "man git" to side-step "git help" is obvious. But if
>trying to use help.format=web, how to get the root html page? My
>technique was "git help XXX" and click the "git(1) suite" link at the
>bottom. "git h
When the commands give an actual output (e.g. when ran with -v), the
output is visually mixed with the warning. The newline makes the actual
output more visible.
Signed-off-by: Matthieu Moy
---
builtin/add.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/add.c b/buil
We originally thought the transition would need a period where "git add
[-u|-A]" without pathspec would be forbidden, but the warning is big
enough to scare people and teach them not to use it (or, if so, to
understand the consequences).
Signed-off-by: Matthieu Moy
---
builtin/add.c | 6 +++---
Junio C Hamano writes:
> So let's squash these two steps into one and keep that in 'next'
> until 2.0 ships.
OK, then we may update the comment describing the plan (for people
digging in the code to find out what the plan is). Small patch serie
follows with this (will probably give conflict with
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> 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,
76 matches
Mail list logo
