Ah, answering my own question
I can see git svn reset does exactly what I need.
jon.
On Mon, Mar 18, 2013 at 4:03 PM, Jon Seymour jon.seym...@gmail.com wrote:
G'day,
I managed to lose sync between the git-svn repo that I am using to
track an svn repo. In particular, the git-svn repo
On Sun, Mar 17, 2013 at 10:03:37PM -0600, zero modulo wrote:
$ LDFLAGS=-L/sandbox/builds/lib CPPFLAGS=-I/sandbox/builds/include
./configure --prefix=$PREFIX
$ make
[…]
/sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function
`dlfcn_globallookup':
dso_dlfcn.c:(.text+0x1b): undefined
[+cc Ingo and Jonathan, as this revisits the open-code hashcmp thread
referenced below]
On Sun, Mar 17, 2013 at 01:13:56PM -0700, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
This env comes from jc/sha1-lookup in 2008 (merge commit e9f9d4f), 5
years ago. I wonder if
Jeff King wrote:
I don't think you can avoid the 3-step problem and retain the safety in
the general case. Forgetting implementation details for a minute, you
have either a 1-step system:
1. Fetch and start using config from the remote.
which is subject to fetching and executing
On 3/18/13 12:35 AM, Junio C Hamano wrote:
Rob Hoelz r...@hoelz.ro writes:
git push currently doesn't consider pushInsteadOf when
using pushurl; this tests and fixes that.
If you use pushurl with an alias that has a pushInsteadOf configuration
value, Git does not take advantage of it. For
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Yes, and you would need one inotify per directory but you do not
have an infinite supply of outstanding inotify watch (wasn't the
limit like 8k per a single uid or something?), so the daemon must be
prepared to say I'll
On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano gits...@pobox.com wrote:
Daniel Stenberg dan...@haxx.se writes:
On Sun, 17 Mar 2013, Antoine Pelisse wrote:
With redirects taken into account, I can't think of any really good way
around avoiding this init...
Is there any way for curl to
On Sun, Mar 17, 2013 at 01:01:44PM -0700, Junio C Hamano wrote:
+ * All references in the file that can be peeled are peeled.
+ * Inversely (and this is more important, any references in the
A missing closing paren after more important. Also the e-mail
quote reveals there is
On Mon, Mar 18, 2013 at 02:30:23PM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
I don't think you can avoid the 3-step problem and retain the safety in
the general case. Forgetting implementation details for a minute, you
have either a 1-step system:
1. Fetch and start using
[Re-titled, as we are off-topic from the original patch series]
On Sun, Mar 17, 2013 at 05:38:59PM +0100, René Scharfe wrote:
Am 17.03.2013 06:40, schrieb Jeff King:
We do have the capability to roll out to one or a few of our servers
(the granularity is not 0.2%, but it is still small). I'm
On Mon, Mar 18, 2013 at 11:38 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Sun, Mar 17, 2013 at 11:27 PM, Junio C Hamano gits...@pobox.com wrote:
Daniel Stenberg dan...@haxx.se writes:
On Sun, 17 Mar 2013, Antoine Pelisse wrote:
With redirects taken into account, I can't think of any
On Sun, Mar 17, 2013 at 08:21:13PM +0700, Nguyen Thai Ngoc Duy wrote:
On Thu, Jan 31, 2013 at 6:06 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
space/time trade-off.
I'm closer to my requirement. I have found gitweb simply provide a GUI for
history check
and code comparison. And the git itself is good enough to do the ACL stuff with
hooks.
I already have the following code to deploy the push into its work-tree
===
#!/bin/bash
perf reports memcpy at the the 6th position [1] in git status -uno
using index v4, and strbuf_remove() in expand_name_field() accounts
for 25% of that. What we need here is a simple string cut and a
cheaper strbuf_setlen() should be enough. After this change, memcpy
drops down to the 13th position
Hi,
This series follows up a previous discussion with Junio and Jeff [1].
It attempts to support the triangular workflow, where the remote
you're fetching from is not the same as the remote you're pushing to.
`remote.name.pushurl` has already been discussed, and deemed as a
poor solution to the
A small segment where handle_config() parses the branch.remote
configuration variable can be simplified using git_config_string().
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
remote.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index
This new configuration variable defines the default remote to push to,
and overrides `branch.name.remote` for all branches. It is useful
in the typical triangular-workflow setup, where the remote you're
fetching from is different from the remote you're pushing to.
Signed-off-by: Ramkumar
This new configuration variable overrides `remote.pushdefault` and
`branch.name.remote` for pushes. In a typical triangular-workflow
setup, you would want to set `remote.pushdefault` to specify the
remote to push to for all branches, and use this option to override it
for a specific branch.
Currently, do_push() in push.c calls remote_get(), which gets the
configured remote for fetching and pushing. Replace this call with a
call to pushremote_get() instead, a new function that will return the
remote configured specifically for pushing. This function tries to
work with the string
Interesting. 'Implementing sitewide pessimistic locking with p4 typemap',
http://www.perforce.com/perforce/doc.current/manuals/p4sag/03_superuser.htm
l seems to suggest this is all that's needed. I believe we're using the
default configuration, the exclusive lock on all files behaviour was
Hi Peff,
On Thu, Mar 14, 2013 at 03:39:14AM -0400, Jeff King wrote:
On Thu, Mar 14, 2013 at 03:10:46AM -0400, Jeff King wrote:
I looked into this a little. The first sticking point is that
git_config_with_options needs to support the alternate source. Here's a
sketch of what I think the
On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
I've put off implementing remote.default corresponding to
remote.pushdefault, as Jeff suggested in [1], because it's currently
not an itch; apart from the obvious symmetry, I don't know what
purpose it serves: why would
Jeff King wrote:
On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
Documentation/config.txt | 23 ---
builtin/push.c | 2 +-
remote.c | 60
+++-
remote.h | 1 +
4
On Mon, Mar 18, 2013 at 06:46:13PM +0530, Ramkumar Ramachandra wrote:
+struct remote *remote_get(const char *name)
+{
+ int name_given = 0;
+
+ read_config();
+ if (name)
+ name_given = 1;
+ else {
+ name = default_remote_name;
+
On Mon, Mar 18, 2013 at 07:58:23PM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
Documentation/config.txt | 23 ---
builtin/push.c | 2 +-
remote.c | 60
Jeff King wrote:
On Mon, Mar 18, 2013 at 06:46:13PM +0530, Ramkumar Ramachandra wrote:
+struct remote *remote_get(const char *name)
+{
+ int name_given = 0;
+
+ read_config();
+ if (name)
+ name_given = 1;
+ else {
+ name = default_remote_name;
+
On Mon, Mar 18, 2013 at 08:26:46PM +0530, Ramkumar Ramachandra wrote:
Can we get rid of this duplication by having remote_get_1 take a
service-specific default argument? And then each service calls it like:
struct remote *remote_get(const char *name)
{
read_config();
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
and ACK for the whole series, once Junio's points are addressed.
Regarding Junio's readability suggestion: I agree that his versions are
a bit more readable, albeit at the expense of having to
On Mon, Mar 18, 2013 at 1:29 AM, Konstantin Khomoutov
kostix+...@007spb.ru wrote:
FYI, I've already tried to answer this exact question [1] with no
comments from the OP.
1. http://serverfault.com/a/488604/118848
It is I who posted that question. :P
I haven't made any comments yet because
On 13-03-18 10:25 AM, Jeff King wrote:
On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote:
I've put off implementing remote.default corresponding to
remote.pushdefault, as Jeff suggested in [1], because it's currently
not an itch; apart from the obvious symmetry, I don't
Jeff King p...@peff.net writes:
Here's the re-roll.
Above reasoning (elided) look sensible. Thanks; will replace.
--
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
Jeff King p...@peff.net writes:
By the way, looking at that made me think for a few minutes about
hashcmp, and I was surprised to find that we use an open-coded
comparison loop. That dates back to this thread by Ingo:
http://article.gmane.org/gmane.comp.version-control.git/172286
I could
On Mon, Mar 18, 2013 at 09:44:20AM -0700, Junio C Hamano wrote:
FWIW, I am getting something like this on my
$ grep 'model name' /proc/cpuinfo | uniq -c
4 model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz
The same rev-list --objects --all /dev/null, best of five:
On Mon, Mar 18, 2013 at 10:28:59PM +0530, Ramkumar Ramachandra wrote:
This has irritated me for a long time. I often end up doing:
$ git push master:master +pu:pu
Me too.
Is there a reason for the remote not being optional, or are we just
waiting for a patch? The only problem I can
Jeff King p...@peff.net writes:
On Mon, Mar 18, 2013 at 09:44:20AM -0700, Junio C Hamano wrote:
FWIW, I am getting something like this on my
$ grep 'model name' /proc/cpuinfo | uniq -c
4 model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz
The same rev-list --objects
On Mon, Mar 18, 2013 at 10:08:11AM -0700, Junio C Hamano wrote:
Just for fun, here is a totally unrelated comparison, both with
current master, compiled with -O2 and running on the same box.
[without GIT_USE_LOOKUP]
real0m39.906s
real0m40.020s
real0m40.022s
real0m40.027s
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
perf reports memcpy at the the 6th position [1] in git status -uno
using index v4, and strbuf_remove() in expand_name_field() accounts
for 25% of that. What we need here is a simple string cut and a
cheaper strbuf_setlen() should be enough.
Jeff King p...@peff.net writes:
- blame-tree; re-rolled from my submission last year to build on top
- diff --max-depth; this is a requirement to do blame-tree efficiently
Both look mildly interesting, especially after the magic pathspec
settles the latter may be a good addition.
-
On Fri, Mar 15, 2013 at 01:06:42PM +0700, Nguyễn Thái Ngọc Duy wrote:
This passes the pathspec, more or less unmodified, to
git-add--interactive. The command itself does not process pathspec. It
simply passes the pathspec to other builtin commands. So if all those
commands support pathspec,
Jeff King p...@peff.net writes:
I do not see anything obviously wrong in it, though I did not walk
through all of the ofs calculation to look for any clever speedups.
However, I think it is clear from the other timings and Ingo's thread
that glibc 2.11's memcmp does not perform very well on
Ramkumar Ramachandra artag...@gmail.com writes:
I usually use `git fetch`, inspect state, and then merge/ rebase
accordingly. Unfortunately, this is very sub-optimal as I can
automate this 80% of the time. I want to be able to decide what to do
on a repository-specific basis, and hence
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
I usually use `git fetch`, inspect state, and then merge/ rebase
accordingly. Unfortunately, this is very sub-optimal as I can
automate this 80% of the time. I want to be able to decide what to do
on a
This patch series addresses several bugs and performance issues in .gitignore
processing that came up in the inotify discussion.
Also available here:
https://github.com/kblees/git/tree/kb/improve-git-status-ignored
git pull git://github.com/kblees/git.git kb/improve-git-status-ignored
Patches
'git-status --ignored' drops ignored directories if they contain untracked
files in an untracked sub directory.
Fix it by getting exact (recursive) excluded status in treat_directory.
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 9 +
'git-status --ignored' lists both the ignored directory and the ignored
files if the files are in a tracked sub directory.
When recursing into sub directories in read_directory_recursive, pass on
the check_only parameter so that we don't accidentally add the files.
Signed-off-by: Karsten Blees
'git-status --ignored' lists ignored tracked directories without any
ignored files if a tracked file happens to match an exclude pattern.
Always exclude tracked files.
Signed-off-by: Karsten Blees bl...@dcon.de
---
dir.c | 11 ---
t/t7061-wtstatus-ignore.sh | 24
The is_excluded and is_path_excluded APIs are very similar, except for a
few noteworthy differences:
is_excluded doesn't handle ignored directories, results for paths within
ignored directories are incorrect. This is probably based on the premise
that recursive directory scans should stop at
Signed-off-by: Karsten Blees bl...@dcon.de
---
builtin/add.c | 5 +---
builtin/check-ignore.c | 6 +---
builtin/ls-files.c | 15 +++---
dir.c | 79 --
dir.h | 16 ++
unpack-trees.c
Checking if a file is in the index is much faster (hashtable lookup) than
checking if the file is excluded (linear search over exclude patterns).
Skip is_excluded checks for files: move the cache_name_exists check from
treat_file to treat_one_path and return early if the file is tracked.
This
'git-status --ignored' lists empty untracked directories as ignored, even
though they don't have any ignored files.
When checking if a directory is already listed as untracked (i.e. shouldn't
be listed as ignored as well), don't assume that the dirctory has only
ignored files if it doesn't have
Am 12.03.2013 17:22, schrieb Junio C Hamano:
Phil Hord phil.h...@gmail.com writes:
I think this would be clearer if 'git deinit' said
rm 'submodule/*'
or maybe
Removed workdir for 'submodule'
Is it just me?
The latter may probably be better.
Hmm, it doesn't really remove
On Sun, 17 Mar 2013 16:35:59 -0700
Junio C Hamano gits...@pobox.com wrote:
Rob Hoelz r...@hoelz.ro writes:
git push currently doesn't consider pushInsteadOf when
using pushurl; this tests and fixes that.
If you use pushurl with an alias that has a pushInsteadOf
configuration value,
git push currently doesn't consider pushInsteadOf when
using pushurl; this test tests that.
If you use pushurl with an alias that has a pushInsteadOf configuration
value, Git does not take advantage of it. For example:
[url git://github.com/]
insteadOf = github:
[url
Am 12.03.2013 17:01, schrieb Phil Hord:
On Sat, Mar 9, 2013 at 1:18 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 05.03.2013 22:17, schrieb Phil Hord:
On Tue, Mar 5, 2013 at 3:51 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 05.03.2013 19:34, schrieb Junio C Hamano:
Eric Cousineau
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We have been scheduling each cycle to last 8-10 weeks, but at the
end of 1.8.2 cycle we already have quite a many topics in flight. I
am
Windows probably isn’t the most popular platform for Git developers ☺, but here
goes…
On Windows with an NTFS volume with Deduplication enabled, Git believes that
deduplicated files are symlinks. It then fails to be able to do anything with
the file. This can be repro-ed by creating an NTFS
Thanks, just a quick review before I find some time do take a
deeper look.
Am 14.03.2013 07:30, schrieb Eric Cousineau:
From 59fb432e17a1aae9de26bbaaca7f09cc7f03b471 Mon Sep 17 00:00:00 2001
From: Eric Cousineau eacousin...@gmail.com
Date: Thu, 14 Mar 2013 01:19:53 -0500
Subject: [PATCH]
On Mon, Mar 18, 2013 at 4:28 PM, Karsten Blees karsten.bl...@gmail.com wrote:
When checking if a directory is already listed as untracked (i.e. shouldn't
be listed as ignored as well), don't assume that the dirctory has only
s/dirctory/directory/
ignored files if it doesn't have untracked
On Mon, Mar 18, 2013 at 4:29 PM, Karsten Blees karsten.bl...@gmail.com wrote:
Directories could also be excluded by exclude patterns specified on the
command line or .git/info/exclude, so we cannot simply skip prep_exclude
entirely if there's no .gitignore file name
On Mon, Mar 18, 2013 at 9:16 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
remote.c: simply a bit of code using git_config_string()
s/simply/simplify/
A small segment where handle_config() parses the branch.remote
configuration variable can be simplified using git_config_string().
On Mon, Mar 18, 2013 at 9:16 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
branch.name.remote::
- When in branch name, it tells 'git fetch' and 'git push' which
- remote to fetch from/push to. It defaults to `origin` if no remote is
- configured. `origin` is also used
On Mon, Mar 18, 2013 at 9:16 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
- If no remote is configured, or if you are not on any branch,
- it defaults to `origin` for fetching and `remote.pushdefault`
- for pushing.
+ The remote to push to, for the current branch,
Configuration from test_config does not last beyond the end of the
current test assertion, making each test easier to think about in
isolation.
This changes the meaning of some of the tests. For example, currently
push with insteadOf passes even if the line setting
url.$TRASH.pushInsteadOf is
When it is unclear which command from a test has failed, usual
practice these days is to debug by running the test again with sh -x
instead of relying on debugging 'echo' statements.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
t/t5516-fetch-push.sh | 15 ---
1 file changed,
Jens Lehmann jens.lehm...@web.de writes:
Am 12.03.2013 17:22, schrieb Junio C Hamano:
Phil Hord phil.h...@gmail.com writes:
I think this would be clearer if 'git deinit' said
rm 'submodule/*'
or maybe
Removed workdir for 'submodule'
Is it just me?
The latter may probably
Jonathan Nieder jrnie...@gmail.com writes:
Test nits:
...
Hope that helps,
Jonathan Nieder (3):
push test: use test_config where appropriate
push test: simplify check of push result
push test: rely on -chaining instead of 'if bad; then echo Oops; fi'
Are these supposed to be
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Test nits:
...
Hope that helps,
Jonathan Nieder (3):
push test: use test_config where appropriate
push test: simplify check of push result
push test: rely on -chaining instead of 'if bad; then echo Oops; fi'
Are
On Tue, Mar 19, 2013 at 1:26 AM, John Keeping j...@keeping.me.uk wrote:
On Fri, Mar 15, 2013 at 01:06:42PM +0700, Nguyễn Thái Ngọc Duy wrote:
This passes the pathspec, more or less unmodified, to
git-add--interactive. The command itself does not process pathspec. It
simply passes the pathspec
On Mon, Mar 18, 2013 at 5:24 AM, Joydeep Bakshi
joydeep.bak...@infoservices.in wrote:
I'm closer to my requirement. I have found gitweb simply provide a GUI for
history check
and code comparison. And the git itself is good enough to do the ACL stuff
with hooks.
I already have the
Hi,
Jeff King wrote:
The
config option added by this patch gives them such an option.
I suspect the need for this config option is a sign that the warning
is too eager. After all, the whole idea of the change being safe is
that it
Currently warn_pathless_add() is only called directly by cmd_add(),
but that is about to change. Move its definition higher in the file
and pass the --update or --all option name used in its message
through globals instead of function arguments to make it easier to
call without passing values
Make warn_pathless_add() print its warning the first time it is called
and do nothing if called again. This will make it easier to show the
warning on the fly when a relevant condition is detected without
risking showing it multiple times when multiple such conditions hold.
Signed-off-by:
A common workflow in large projects is to chdir into a subdirectory of
interest and only do work there:
cd src
vi foo.c
make test
git add -u
git commit
The upcoming change to 'git add -u' behavior would not affect such a
workflow: when the only changes
In the spirit of the recent similar change for 'git add -u', avoid
pestering users that restrict their attention to a subdirectory and
will not be affected by the coming change in the behavior of pathless
'git add -A'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/add.c | 21
Karsten Blees karsten.bl...@gmail.com writes:
This patch series addresses several bugs and performance issues in
.gitignore processing that came up in the inotify discussion.
Thanks.
How does this interact with the nd/read-directory-recursive-optim
topic that has been cooking for a while?
On Mon, Mar 18, 2013 at 08:44:15PM -0700, Jonathan Nieder wrote:
The
config option added by this patch gives them such an option.
I suspect the need for this config option is a sign that the warning
is too eager. After all, the
Jonathan Nieder jrnie...@gmail.com writes:
A common workflow in large projects is to chdir into a subdirectory of
interest and only do work there:
cd src
vi foo.c
make test
git add -u
git commit
The upcoming change to 'git add -u' behavior would not affect
On Tue, Mar 19, 2013 at 11:08 AM, Junio C Hamano gits...@pobox.com wrote:
Karsten Blees karsten.bl...@gmail.com writes:
This patch series addresses several bugs and performance issues in
.gitignore processing that came up in the inotify discussion.
Thanks.
How does this interact with the
Junio C Hamano wrote:
The implemenation appears to run an extra diff_files() in addition
to the one we already have to run in order to implement the add -u
to collect modified/deleted paths. Is that the best we can do?
I am wondering if we can special case the no-pathspec case to have
Junio C Hamano wrote:
The implemenation appears to run an extra diff_files() in addition
to the one we already have to run in order to implement the add -u
to collect modified/deleted paths. Is that the best we can do?
At least the following should be squashed in to avoid wasted effort in
On Tue, Mar 19, 2013 at 11:25 AM, Junio C Hamano gits...@pobox.com wrote:
I am wondering if we can special case the no-pathspec case to have
add_files_to_cache() call underlying run_diff_files() without any
pathspec, inspect the paths that are modified and/or deleted in the
update_callback,
Duy Nguyen wrote:
My concern is run full-tree diff can be expensive on large repos (one
of the reasons the user may choose to work from within a
subdirectory). We can exit as soon as we find a difference outside
$prefix. But in case we find nothing, we need to diff the whole
worktree.
Yes.
82 matches
Mail list logo
