* Re: [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Alex Riesen @ 2008-10-23 18:36 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, spearce, dpotapov, git
In-Reply-To: <81b0412b0810230607sfea05ddm62bd03f837fc922e@mail.gmail.com>
Err... It should be: "Only update the cygwin-related configuration
during stat auto-setup".
^ permalink raw reply
* RE: git performance
From: Daniel Barkalow @ 2008-10-23 18:31 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
On Wed, 22 Oct 2008, Edward Ned Harvey wrote:
> Out of curiosity, what are they talking about, when they say "git is
> fast?" Just the fact that it's all local disk, or is there more to it
> than that? I could see - git would probably outperform perforce for
> versioning of large files (let's say iso files) to benefit from
> sustained local disk IO, while perforce would probably outperform
> anything I can think of, operating on thousands of tiny files, because
> it will never walk the tree.
It shouldn't be too hard to make git work like perforce with respect to
walking the tree. git keeps an index of the stat() info it saw when it
last looked at files, and only looks at the contents of files whose stat()
info has changed. In order to have it work like perforce, it would just
need to have a flag in the stat() info index for "don't even bother",
which it would use for files that aren't "open"; for files with this flag,
the check for index freshness would always say it's fresh without looking
at the filesystem. Then you'd just have a config option to check out files
as "not open" (and not writeable), and have a "git open" program that
would chmod files and get their real stat info.
Of course, git is tuned for cases where the modify/build/test cycle
requires stat() (or worse) on every file.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git archive
From: Deskin Miller @ 2008-10-23 18:21 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: kenneth johansson, git
In-Reply-To: <fcaeb9bf0810230833i3953a5abt2d2ba6ca1b751754@mail.gmail.com>
On Thu, Oct 23, 2008 at 10:33:31PM +0700, Nguyen Thai Ngoc Duy wrote:
> On 10/22/08, Deskin Miller <deskinm@umich.edu> wrote:
> > On Wed, Oct 22, 2008 at 08:42:01AM +0000, kenneth johansson wrote:
> > > I was going to make a tar of the latest stable linux kernel.
> > > Done it before but now I got a strange problem.
> > >
> > > >git archive --format=tar v2.6.27.2
> > > fatal: Not a valid object name
> >
> >
> > I had the same thing happen to me, while trying to make an archive of Git.
> > Were you perchance working in a bare repository, as I was? I spent some time
> > looking at it and I think git archive sets up the environment in the wrong
> > order, though of course I never finished a patch so I'm going from memory:
> >
> > After looking at the code again, I think the issue is that git_config is called
> > in builtin-archive.c:cmd_archive before setup_git_directory is called in
> > archive.c:write_archive. The former ends up setting GIT_DIR to be '.git' even
> > if you're in a bare repository. My coding skills weren't up to fixing it
> > easily; moving setup_git_directory before git_config in builtin-archive caused
> > last test of t5000 to fail: GIT_DIR=some/nonexistent/path git archive --list
> > should still display the archive formats.
>
> The problem affects some other commands as well. I tried the following
> patch, ran "make test" and discovered "git mailinfo", "git
> verify-pack", "git hash-object" and "git unpack-file". A bandage patch
> is at the end of this mail. Solution is as Jeff suggested: call
> setup_git_directory_gently() early.
Nice work. The patches look like they're on the right track (to me at least).
I'm not sure though what you want to ultimately submit as a patch; I'd suggest
both, squashed into one, since the check seems like something we'd reasonably
want no matter what.
Few comments spread around below; also, can we see some testcases for
regression? Or, does the first patch preclude the need for testcases?
Deskin Miller
> ---<---
> diff --git a/environment.c b/environment.c
> index 0693cd9..00ed640 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -49,14 +49,18 @@ static char *work_tree;
>
> static const char *git_dir;
> static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;
> +int git_dir_discovered;
Should this be 'int git_dir_discovered = 0;' ?
> static void setup_git_env(void)
> {
> git_dir = getenv(GIT_DIR_ENVIRONMENT);
> if (!git_dir)
> git_dir = read_gitfile_gently(DEFAULT_GIT_DIR_ENVIRONMENT);
> - if (!git_dir)
> + if (!git_dir) {
> + if (!git_dir_discovered)
> + die("Internal error: .git must be relocated at cwd by setup_git_*");
> git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
> + }
> git_object_dir = getenv(DB_ENVIRONMENT);
> if (!git_object_dir) {
> git_object_dir = xmalloc(strlen(git_dir) + 9);
> diff --git a/setup.c b/setup.c
> index 78a8041..d404c21 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -368,6 +368,7 @@ const char *read_gitfile_gently(const char *path)
> * We cannot decide in this function whether we are in the work tree or
> * not, since the config can only be read _after_ this function was called.
> */
> +extern int git_dir_discovered;
> const char *setup_git_directory_gently(int *nongit_ok)
> {
> const char *work_tree_env = getenv(GIT_WORK_TREE_ENVIRONMENT);
> @@ -472,6 +473,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
> }
> chdir("..");
> }
> + /* It is safe to call setup_git_env() now */
> + git_dir_discovered = 1;
>
> inside_git_dir = 0;
> if (!work_tree_env)
> ---<---
>
>
> Bandage patch:
>
> ---<---
> diff --git a/builtin-archive.c b/builtin-archive.c
> index 432ce2a..5ea0a12 100644
> --- a/builtin-archive.c
> +++ b/builtin-archive.c
> @@ -110,7 +110,9 @@ static const char *extract_remote_arg(int *ac,
> const char **av)
> int cmd_archive(int argc, const char **argv, const char *prefix)
> {
> const char *remote = NULL;
> + int nongit;
>
> + prefix = setup_git_directory_gently(&nongit);
Here and elsewhere, the 'nongit' variable isn't used.
setup_git_directory_gently can be passed a NULL pointer, why not do that?
> git_config(git_default_config, NULL);
>
> remote = extract_remote_arg(&argc, argv);
> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> index e890f7a..5d401fb 100644
> --- a/builtin-mailinfo.c
> +++ b/builtin-mailinfo.c
> @@ -916,10 +916,9 @@ static const char mailinfo_usage[] =
> int cmd_mailinfo(int argc, const char **argv, const char *prefix)
> {
> const char *def_charset;
> + int nongit;
>
> - /* NEEDSWORK: might want to do the optional .git/ directory
> - * discovery
> - */
> + prefix = setup_git_directory_gently(&nongit);
Same 'nongit' issue.
> git_config(git_default_config, NULL);
>
> def_charset = (git_commit_encoding ? git_commit_encoding : "utf-8");
> diff --git a/builtin-verify-pack.c b/builtin-verify-pack.c
> index 25a29f1..35a4eb2 100644
> --- a/builtin-verify-pack.c
> +++ b/builtin-verify-pack.c
> @@ -115,7 +115,9 @@ int cmd_verify_pack(int argc, const char **argv,
> const char *prefix)
> int verbose = 0;
> int no_more_options = 0;
> int nothing_done = 1;
> + int nongit;
>
> + prefix = setup_git_directory_gently(&nongit);
Same 'nongit' issue.
> git_config(git_default_config, NULL);
> while (1 < argc) {
> if (!no_more_options && argv[1][0] == '-') {
> diff --git a/hash-object.c b/hash-object.c
> index 20937ff..a52b6be 100644
> --- a/hash-object.c
> +++ b/hash-object.c
> @@ -78,19 +78,20 @@ int main(int argc, const char **argv)
> const char *prefix = NULL;
> int prefix_length = -1;
> const char *errstr = NULL;
> + int nongit;
>
> type = blob_type;
>
> - git_config(git_default_config, NULL);
> -
> argc = parse_options(argc, argv, hash_object_options, hash_object_usage, 0);
>
> - if (write_object) {
> - prefix = setup_git_directory();
> - prefix_length = prefix ? strlen(prefix) : 0;
> - if (vpath && prefix)
> - vpath = prefix_filename(prefix, prefix_length, vpath);
> - }
> + prefix = setup_git_directory_gently(&nongit);
> + git_config(git_default_config, NULL);
> + prefix_length = prefix ? strlen(prefix) : 0;
> + if (vpath && prefix)
> + vpath = prefix_filename(prefix, prefix_length, vpath);
> +
> + if (write_object && nongit)
> + die("Git repository required");
I'd move this check up to just after setup_git_directory_gently.
> if (stdin_paths) {
> if (hashstdin)
> diff --git a/unpack-file.c b/unpack-file.c
> index bcdc8bb..1a58d72 100644
> --- a/unpack-file.c
> +++ b/unpack-file.c
> @@ -27,10 +27,10 @@ int main(int argc, char **argv)
>
> if (argc != 2)
> usage("git-unpack-file <sha1>");
> + setup_git_directory();
> if (get_sha1(argv[1], sha1))
> die("Not a valid object name %s", argv[1]);
>
> - setup_git_directory();
> git_config(git_default_config, NULL);
>
> puts(create_temp_file(sha1));
> ---<---
> --
> Duy
^ permalink raw reply
* Re: How to push to http(s) repository with authentication?
From: Josef Wolf @ 2008-10-23 17:53 UTC (permalink / raw)
To: git
In-Reply-To: <20081020182502.GH9707@raven.wolf.lan>
On Mon, Oct 20, 2008 at 08:25:02PM +0200, Josef Wolf wrote:
> I have set up a repository as described in
>
> http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
>
> over SSL with basic authentication. DAV access works fine with konqueror,
> cadaver and and curl, using this .curlrc:
> [ ... ]
Is nobody interested in this topic? Or am I in the wrong list?
^ permalink raw reply
* [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-23 17:22 UTC (permalink / raw)
To: git
In-Reply-To: <gdok16$vh2$1@ger.gmane.org>
I decided to give the simpler GIT_DIR approach another go.
The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
.file.git/ to track file's history. .file.git/info/excludes is
initialized to the very strong '*' pattern to ensure that things such
as git status etc only consider the actually tracked file.
The obvious advantage over the previous implementation is that we
don't rely on fragile and non-portable hardlinks. The disadvantage
is that something really bad can happen if a command fails to obey
GIT_DIR or GIT_WORK_TREE correctly.
Command delegation is made a little smarter:
zit somecommand file [args...]
gets delegated to
git somecommand [args...]
with GIT_DIR=.file.git and GIT_WORK_TREE="`pwd`", which works
surprisingly well. To prevent stupid expressions such as zit add file
file or zit commit file file, add and commit put the filename back at
the end of the parameter list.
Commands that seem to work correctly so far are init, add, log,
status, diff, remote, push, pull, and even rebase -i.
Commands that definitely need some work are rm (should it just remove
the .file.git/ dir?) and mv (hairy: we would need to rename .file.git
to .newname.git too, but rollbacks are likely to break things).
The only new command introduced by zit is zit list, which lists all
zit-tracked files in the current directory, currently in a very
braindead way (e.g. I'd like it to display the proper status, such as
C M or whatever; suggestions welcome).
On the TODO list is also some smart way to guess which file we're
talking about when no file is specified. Basically, the idea is to
check if there's only one tracked file, or only one changed tracked
file, and allow a missing file option in that case.
As usual, comments suggestions and critiques welcome.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC PATCH 4/5] pack-objects: avoid reading uninitalized data
From: Nicolas Pitre @ 2008-10-23 16:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081023153329.GC10804@coredump.intra.peff.net>
On Thu, 23 Oct 2008, Jeff King wrote:
> On Wed, Oct 22, 2008 at 09:11:16PM -0400, Nicolas Pitre wrote:
>
> > > for (;;) {
> > > - struct object_entry *entry = *list++;
> > > + struct object_entry *entry;
> > > struct unpacked *n = array + idx;
> > > int j, max_depth, best_base = -1;
> > >
> > > @@ -1384,6 +1384,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
> > > progress_unlock();
> > > break;
> > > }
> >
> > ---> Please preserve the empty line here so the previous code
> > chunk still appears logically separate.
> >
> > > + entry = *list++;
> > > (*list_size)--;
> > > if (!entry->preferred_base) {
> > > (*processed)++;
>
> Er, there was no empty line there (or else there would have been a '-'
> line in the diff).
Oh, right. I'm confused.
Nevermind...
Nicolas
^ permalink raw reply
* Re: git performance
From: Jeff King @ 2008-10-23 16:39 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
On Wed, Oct 22, 2008 at 05:55:14PM -0400, Edward Ned Harvey wrote:
> I'm talking about 40-50,000 files, on multi-user production linux,
> which means the cache is never warm, except when I'm benchmarking.
Well, if you have a cold cache it's going to take longer. :) You should
probably benchmark if you want to know exactly how long.
> Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st"
> takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me,
Wow, that is awful. For comparison, "git status" from a cold on the
kernel repo takes me 17 seconds. From a warm cache, less than half a
second.
Yes, the cold cache case would probably be better with inotify, but
compared to svn, that's screaming fast. I haven't used perforce. If your
bottleneck really is stat'ing the tree, then yes, something that avoided
that might perform better (but weigh that particular optimization
against other things which might be slower).
> Out of curiosity, what are they talking about, when they say "git is
> fast?"
Well, there are the numbers above. When comparing to SVN or (god forbid)
CVS, there are order of magnitude speedups for most common operations.
> Just the fact that it's all local disk, or is there more to it
> than that? I could see - git would probably outperform perforce for
The things that generally make git fast are:
- using a compact on-disk structure (including zlib and aggressive
delta-finding) to keep your cache warm (and when it's not warm, to
get data off the disk as quickly as possible)
- the content-addressable nature of objects means we can just look at
the data we need to solve a problem. For example,
getting the history between point A and point B is "O(the number of
commits between A and B)", _not_ "O(the size of the repo)".
Viewing a log without generating diffs is "O(the number of
commits)", not "O(some combination of the number of commits and the
number of files in each commit)". Diffing two points in history is
"O(the size of the differences between the two points)" and is
totally independent of the number of commits between the two points.
- most operations are streamable. "git log >/dev/null" on the kernel
repo (about 90,000 commits) takes 8.5 seconds on my box. But it
starts generating output immediately, so it _feels_ instant, and the
rest of the data is generated while I read the first commit in my
pager.
-Peff
^ permalink raw reply
* Re: git archive
From: Nguyen Thai Ngoc Duy @ 2008-10-23 15:33 UTC (permalink / raw)
To: Deskin Miller; +Cc: kenneth johansson, git
In-Reply-To: <20081022130829.GC2015@riemann.deskinm.fdns.net>
On 10/22/08, Deskin Miller <deskinm@umich.edu> wrote:
> On Wed, Oct 22, 2008 at 08:42:01AM +0000, kenneth johansson wrote:
> > I was going to make a tar of the latest stable linux kernel.
> > Done it before but now I got a strange problem.
> >
> > >git archive --format=tar v2.6.27.2
> > fatal: Not a valid object name
>
>
> I had the same thing happen to me, while trying to make an archive of Git.
> Were you perchance working in a bare repository, as I was? I spent some time
> looking at it and I think git archive sets up the environment in the wrong
> order, though of course I never finished a patch so I'm going from memory:
>
> After looking at the code again, I think the issue is that git_config is called
> in builtin-archive.c:cmd_archive before setup_git_directory is called in
> archive.c:write_archive. The former ends up setting GIT_DIR to be '.git' even
> if you're in a bare repository. My coding skills weren't up to fixing it
> easily; moving setup_git_directory before git_config in builtin-archive caused
> last test of t5000 to fail: GIT_DIR=some/nonexistent/path git archive --list
> should still display the archive formats.
The problem affects some other commands as well. I tried the following
patch, ran "make test" and discovered "git mailinfo", "git
verify-pack", "git hash-object" and "git unpack-file". A bandage patch
is at the end of this mail. Solution is as Jeff suggested: call
setup_git_directory_gently() early.
---<---
diff --git a/environment.c b/environment.c
index 0693cd9..00ed640 100644
--- a/environment.c
+++ b/environment.c
@@ -49,14 +49,18 @@ static char *work_tree;
static const char *git_dir;
static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;
+int git_dir_discovered;
static void setup_git_env(void)
{
git_dir = getenv(GIT_DIR_ENVIRONMENT);
if (!git_dir)
git_dir = read_gitfile_gently(DEFAULT_GIT_DIR_ENVIRONMENT);
- if (!git_dir)
+ if (!git_dir) {
+ if (!git_dir_discovered)
+ die("Internal error: .git must be relocated at cwd by setup_git_*");
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
+ }
git_object_dir = getenv(DB_ENVIRONMENT);
if (!git_object_dir) {
git_object_dir = xmalloc(strlen(git_dir) + 9);
diff --git a/setup.c b/setup.c
index 78a8041..d404c21 100644
--- a/setup.c
+++ b/setup.c
@@ -368,6 +368,7 @@ const char *read_gitfile_gently(const char *path)
* We cannot decide in this function whether we are in the work tree or
* not, since the config can only be read _after_ this function was called.
*/
+extern int git_dir_discovered;
const char *setup_git_directory_gently(int *nongit_ok)
{
const char *work_tree_env = getenv(GIT_WORK_TREE_ENVIRONMENT);
@@ -472,6 +473,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
}
chdir("..");
}
+ /* It is safe to call setup_git_env() now */
+ git_dir_discovered = 1;
inside_git_dir = 0;
if (!work_tree_env)
---<---
Bandage patch:
---<---
diff --git a/builtin-archive.c b/builtin-archive.c
index 432ce2a..5ea0a12 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -110,7 +110,9 @@ static const char *extract_remote_arg(int *ac,
const char **av)
int cmd_archive(int argc, const char **argv, const char *prefix)
{
const char *remote = NULL;
+ int nongit;
+ prefix = setup_git_directory_gently(&nongit);
git_config(git_default_config, NULL);
remote = extract_remote_arg(&argc, argv);
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index e890f7a..5d401fb 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -916,10 +916,9 @@ static const char mailinfo_usage[] =
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
const char *def_charset;
+ int nongit;
- /* NEEDSWORK: might want to do the optional .git/ directory
- * discovery
- */
+ prefix = setup_git_directory_gently(&nongit);
git_config(git_default_config, NULL);
def_charset = (git_commit_encoding ? git_commit_encoding : "utf-8");
diff --git a/builtin-verify-pack.c b/builtin-verify-pack.c
index 25a29f1..35a4eb2 100644
--- a/builtin-verify-pack.c
+++ b/builtin-verify-pack.c
@@ -115,7 +115,9 @@ int cmd_verify_pack(int argc, const char **argv,
const char *prefix)
int verbose = 0;
int no_more_options = 0;
int nothing_done = 1;
+ int nongit;
+ prefix = setup_git_directory_gently(&nongit);
git_config(git_default_config, NULL);
while (1 < argc) {
if (!no_more_options && argv[1][0] == '-') {
diff --git a/hash-object.c b/hash-object.c
index 20937ff..a52b6be 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -78,19 +78,20 @@ int main(int argc, const char **argv)
const char *prefix = NULL;
int prefix_length = -1;
const char *errstr = NULL;
+ int nongit;
type = blob_type;
- git_config(git_default_config, NULL);
-
argc = parse_options(argc, argv, hash_object_options, hash_object_usage, 0);
- if (write_object) {
- prefix = setup_git_directory();
- prefix_length = prefix ? strlen(prefix) : 0;
- if (vpath && prefix)
- vpath = prefix_filename(prefix, prefix_length, vpath);
- }
+ prefix = setup_git_directory_gently(&nongit);
+ git_config(git_default_config, NULL);
+ prefix_length = prefix ? strlen(prefix) : 0;
+ if (vpath && prefix)
+ vpath = prefix_filename(prefix, prefix_length, vpath);
+
+ if (write_object && nongit)
+ die("Git repository required");
if (stdin_paths) {
if (hashstdin)
diff --git a/unpack-file.c b/unpack-file.c
index bcdc8bb..1a58d72 100644
--- a/unpack-file.c
+++ b/unpack-file.c
@@ -27,10 +27,10 @@ int main(int argc, char **argv)
if (argc != 2)
usage("git-unpack-file <sha1>");
+ setup_git_directory();
if (get_sha1(argv[1], sha1))
die("Not a valid object name %s", argv[1]);
- setup_git_directory();
git_config(git_default_config, NULL);
puts(create_temp_file(sha1));
---<---
--
Duy
^ permalink raw reply related
* Re: [RFC PATCH 4/5] pack-objects: avoid reading uninitalized data
From: Jeff King @ 2008-10-23 15:33 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810222107540.26244@xanadu.home>
On Wed, Oct 22, 2008 at 09:11:16PM -0400, Nicolas Pitre wrote:
> > for (;;) {
> > - struct object_entry *entry = *list++;
> > + struct object_entry *entry;
> > struct unpacked *n = array + idx;
> > int j, max_depth, best_base = -1;
> >
> > @@ -1384,6 +1384,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
> > progress_unlock();
> > break;
> > }
>
> ---> Please preserve the empty line here so the previous code
> chunk still appears logically separate.
>
> > + entry = *list++;
> > (*list_size)--;
> > if (!entry->preferred_base) {
> > (*processed)++;
Er, there was no empty line there (or else there would have been a '-'
line in the diff). I am happy to add it, like:
if (!*list_size) {
progress_unlock();
break;
}
entry = *list++;
(*list_size)--;
if (!entry->preferred_base)
...
if you like, but the current version seems to format it as one stanza
inside of the progress_lock/progress_unlock. Look at the version in
'master' to see what I mean.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 1/5] add valgrind support in test scripts
From: Jeff King @ 2008-10-23 15:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v7i80tber.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 22, 2008 at 05:14:52PM -0700, Junio C Hamano wrote:
> > I wonder if it would not be better to scrap the t/valgrind/ directory and
> > regenerate it everytime you run a test manually; I'd use "ln" instead of
> > "cp", and also parse command-list.txt to catch really all of them (even if
> > a dashed form is used for a builtin by mistake).
>
> Going one step further, I wonder if this approach can also be used to
> catch such a mistake. Install a dashed form that records the fact that it
> was called when it shouldn't, and by whom.
I think that makes sense, though it is somewhat orthogonal to valgrind.
Do we want to always set up such a fake path? It could actually be even
simpler than a wrapper; just stop adding the build directory to the
PATH, and instead have a pseudo-installation directory with the bin and
exec-path directories set up appropriately. This would more closely
model the actual installation.
I think there are actually several classes of dashed commands we need to
differentiate:
1. dashed commands which get installed in bin; these should be allowed
2. dashed commands which don't get installed in bin; these should be
flagged as an error
3. dashed commands in exec-path which are stand-alone C programs. These
should be run under valgrind.
4. dashed commands in exec-path which are scripts. These do get run,
but should not be run under valgrind.
5. dashed commands in exec-path which are builtins. These should never
get run by our test scripts, since they are "legacy" links for people
who want to put the exec-path in their PATH
Right now we always point PATH at the build directory, which has
everything. So we can't easily differentiate between '1' and '2'. I used
the $(PROGRAMS) variable in the Makefile to find '3' (as opposed to '4'
and '5').
-Peff
^ permalink raw reply
* Re: [RFC PATCH 1/5] add valgrind support in test scripts
From: Jeff King @ 2008-10-23 15:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810230008430.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Thu, Oct 23, 2008 at 12:13:47AM +0200, Johannes Schindelin wrote:
> I wonder if it would not be better to scrap the t/valgrind/ directory and
> regenerate it everytime you run a test manually;
Yeah, I mentioned that in my 0/5 cover letter. The problem is where to
put it that won't impact test results, but also allow running multiple
tests simultaneously. I'm going to try sticking it in .git/valgrind in
the trash directory, which presumably won't affect any tests.
> I'd use "ln" instead of "cp"
I specifically stayed away from 'ln' for Windows portability. It looks
like for builtins, we do "ln || ln -s || cp". We can probably do the
same here.
I also failed to use git$X in the fake path, which would probably be
necessary for Windows.
> and also parse command-list.txt to catch really all of them (even if
> a dashed form is used for a builtin by mistake).
That is a little bit trickier. I don't actually want to intercept
git-am, for example, since I have no interest in running valgrind on the
shell. But it is do-able; I will give details in my response to Junio's
suggestion.
> Otherwise: good work, I like it!
Thanks.
-Peff
^ permalink raw reply
* Re: Verifying the whole repository
From: Shawn O. Pearce @ 2008-10-23 14:28 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <b2cdc9f30810230659n15f44f64l571a0df3dbe104d9@mail.gmail.com>
Alex Bennee <kernel-hacker@bennee.com> wrote:
> As git is fundamentally hash based it's a lot easier to determine the
> health of the repository but I wonder if it's possible for silent
> corruption to creep in which won't be noticed until you try and
> checkout a historical commit of the tree. I notice there is a
> git-verify-pack command that checks the pack files are OK. Do any of
> the other commands implicitly ensure all objects in the repo are
> correct and valid? git-gc?
As David pointed out, git fsck can be used to verify all of the
hashes, but git-gc also does a quick sanity check using a CRC code
when it copies data from one pack to another pack.
Unlike CVS Git has a write-once, read-many mentality, so with
the exception of git gc (err, actually the git repack it calls)
git never modifies an existing file. That really helps to reduce
the risk of corruption.
If you never do a gc or fsck operation (but still use say commit
or push into the repository) then yes, silent corruption can still
sneak up on you in the form of disk block corruption.
> Are there any other parts of the .git metadata that are crucial or is
> it enough to say if all objects and packs match their hashes you have
> all the information you may need to recover an arbitrary revision of
> the repo?
Don't forget about the loose objects under .git/objects/?? but
otherwise yes, you just need the object data. The refs under
.git/refs are also useful, but the tips can be recovered if the
refs space is lost by "git fsck --unreachable".
--
Shawn.
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-23 14:21 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0810230651j1c02de13j61238c97661c32e9@mail.gmail.com>
On Thu, Oct 23, 2008 at 3:51 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>> On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> > On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>> >> The principle is extremely simple: when you choose to start tracking a
>> >> file with Zit,
>> >>
>> >> zit track file
>> >>
>> >> Zit will create a directory .zit.file to hold a git repository
>> >> tracking the single file .zit.file/file, which is just a hard link to
>> >> file.
>> >
>> > Why not use one .zit repo and track each file on each own branch?.
>>
>>
>> So your proposal is to have a single .zit repo which is actually a git
>> repo and where each additional tracked file becomes its own branch,
>> and zit would take care of switching from branch to branch when zit
>> commands are called?
>
> I don't know if switching is necessary. With one file per pranch, the
> index is even not necessary.
[...]
> The history should be linear. Git (or zit) repository is just a
> container for git branches. Each branch contains only one file. Moving
> a file history is equivalent to "git push" + "git branch -D".
> Something like this (not tested):
>
> cd dst
> git init
> cd src
> git push dst local-branch:remote-branch
> git branch -D local-branch
> git gc
Looks a little too clumsy for my taste. Also, I don't like the idea of
having to enforce linear history for files, or getting rid of the
index. I would like zit to be as lightweight a wrapper for git as
possible, retaining the whole functionality.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Verifying the whole repository
From: Alex Bennee @ 2008-10-23 14:14 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20810230705l20339a1dj87b855bf3321f796@mail.gmail.com>
On Thu, Oct 23, 2008 at 3:05 PM, David Symonds <dsymonds@gmail.com> wrote:
> On Thu, Oct 23, 2008 at 6:59 AM, Alex Bennee <kernel-hacker@bennee.com> wrote:
>> Do any of
>> the other commands implicitly ensure all objects in the repo are
>> correct and valid? git-gc?
>
> Try: git fsck --full --strict
Ahh, I forgot that git was written by a filesystem guy ;-)
Thanks.
--
Alex, homepage: http://www.bennee.com/~alex/
^ permalink raw reply
* Re: Verifying the whole repository
From: David Symonds @ 2008-10-23 14:05 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <b2cdc9f30810230659n15f44f64l571a0df3dbe104d9@mail.gmail.com>
On Thu, Oct 23, 2008 at 6:59 AM, Alex Bennee <kernel-hacker@bennee.com> wrote:
> As git is fundamentally hash based it's a lot easier to determine the
> health of the repository but I wonder if it's possible for silent
> corruption to creep in which won't be noticed until you try and
> checkout a historical commit of the tree. I notice there is a
> git-verify-pack command that checks the pack files are OK. Do any of
> the other commands implicitly ensure all objects in the repo are
> correct and valid? git-gc?
Try: git fsck --full --strict
Dave.
^ permalink raw reply
* Verifying the whole repository
From: Alex Bennee @ 2008-10-23 13:59 UTC (permalink / raw)
To: git
Hi,
While I was debugging a crash in parsecvs while converting our CVS
repository I discovered it was because one of the CVS files had become
corrupted (truncated). This is a problem I've had before with RCS
based files which are prone to silent corruption that you won't notice
until you try and checkout an old revision of the file.
As git is fundamentally hash based it's a lot easier to determine the
health of the repository but I wonder if it's possible for silent
corruption to creep in which won't be noticed until you try and
checkout a historical commit of the tree. I notice there is a
git-verify-pack command that checks the pack files are OK. Do any of
the other commands implicitly ensure all objects in the repo are
correct and valid? git-gc?
Are there any other parts of the .git metadata that are crucial or is
it enough to say if all objects and packs match their hashes you have
all the information you may need to recover an arbitrary revision of
the repo?
--
Alex, homepage: http://www.bennee.com/~alex/
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Nguyen Thai Ngoc Duy @ 2008-10-23 13:51 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0810230633r9970a50mbb4ecf3a855c3a21@mail.gmail.com>
On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> >> The principle is extremely simple: when you choose to start tracking a
> >> file with Zit,
> >>
> >> zit track file
> >>
> >> Zit will create a directory .zit.file to hold a git repository
> >> tracking the single file .zit.file/file, which is just a hard link to
> >> file.
> >
> > Why not use one .zit repo and track each file on each own branch?.
>
>
> So your proposal is to have a single .zit repo which is actually a git
> repo and where each additional tracked file becomes its own branch,
> and zit would take care of switching from branch to branch when zit
> commands are called?
I don't know if switching is necessary. With one file per pranch, the
index is even not necessary.
> I think this solution would have a number of problems, apart from
> being generally quite messy. First of all, moving a file and its
> history somewhere else means toying around with the history of a much
> wider repo, whereas the current approach would mean just moving the
> .zit.file dir together with the file (modulo hardlinks). Non-linear
> histories for a single file would be more complex to handle, too. And
> publishing just the history of one file would be damn complex.
The history should be linear. Git (or zit) repository is just a
container for git branches. Each branch contains only one file. Moving
a file history is equivalent to "git push" + "git branch -D".
Something like this (not tested):
cd dst
git init
cd src
git push dst local-branch:remote-branch
git branch -D local-branch
git gc
> --
> Giuseppe "Oblomov" Bilotta
>
--
Duy
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-23 13:33 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0810230550t54813c09m3b1984f065732c0@mail.gmail.com>
On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>> The principle is extremely simple: when you choose to start tracking a
>> file with Zit,
>>
>> zit track file
>>
>> Zit will create a directory .zit.file to hold a git repository
>> tracking the single file .zit.file/file, which is just a hard link to
>> file.
>
> Why not use one .zit repo and track each file on each own branch?.
So your proposal is to have a single .zit repo which is actually a git
repo and where each additional tracked file becomes its own branch,
and zit would take care of switching from branch to branch when zit
commands are called?
I think this solution would have a number of problems, apart from
being generally quite messy. First of all, moving a file and its
history somewhere else means toying around with the history of a much
wider repo, whereas the current approach would mean just moving the
.zit.file dir together with the file (modulo hardlinks). Non-linear
histories for a single file would be more complex to handle, too. And
publishing just the history of one file would be damn complex.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-23 13:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <49007623.1060606@viscovery.net>
On Thu, Oct 23, 2008 at 3:03 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Giuseppe Bilotta schrieb:
>> Zit will create a directory .zit.file to hold a git repository
>> tracking the single file .zit.file/file, which is just a hard link to
>> file.
>
> git breaks hard links, mind you! (Just in case you check out older
> versions and you wonder why your "real" file is not updated).
>
> But there's a recent patch by Dscho floating around that takes care of the
> hard link case.
I feared that the hardlink choice was not the best one. I would
definitely prefer finding a solution that didn't depend on hardlinks:
not only there would be no worry about breaking them, it'd also be
more portable.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Alex Riesen @ 2008-10-23 13:07 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, spearce, dpotapov, git
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
Otherwise the other global settings which were already read and set up will
be overwritten because the auto-setup code can be called really late in
game. For instance, t3901-i18n-patch and --encoding=something of revision
argument parser are actually broken at the moment. The parser
(handle_revision_opt) sets git_log_output_encoding, which is also updated
(or in this case - overwritten) in the default config handler.
The code still has the problem if someone loads the configuration,
sets trust_executable_bit according to other conditions (a future
command-line option, perhaps) and than causes the init_stat call.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
compat/cygwin.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
2008/10/13 Mark Levedahl <mlevedahl@gmail.com>:
> static int git_cygwin_config(const char *var, const char *value, void *cb)
> {
> - if (!strcmp(var, "core.ignorecygwinfstricks"))
> - native_stat = git_config_bool(var, value);
> - return 0;
> + if (!strcmp(var, "core.ignorecygwinfstricks")) {
> + native_stat = git_config_bool(var, value);
> + return 0;
> + }
> + return git_default_config(var, value, cb);
> }
This actually breaks t3901-i18n-patch (and --encoding=something of
revision argument parser). The parser (handle_revision_opt) sets
git_log_output_encoding, which is also updated (or in this case - overwritten)
in the default config handler.
[-- Attachment #2: 0001-Only-update-the-cygwin-related-configuration-during.patch --]
[-- Type: application/xxxxx, Size: 1669 bytes --]
^ permalink raw reply
* Re: git performance
From: Nguyen Thai Ngoc Duy @ 2008-10-23 13:04 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, Edward Ned Harvey, git
In-Reply-To: <49002B27.50201@op5.se>
On 10/23/08, Andreas Ericsson <ae@op5.se> wrote:
> Jakub Narebski wrote:
>
> > "Edward Ned Harvey" <git@nedharvey.com> writes:
> >
> >
> > > I see things all over the Internet saying git is fast. I'm
> > > currently struggling with poor svn performance and poor attitude of
> > > svn developers, so I'd like to consider switching to git. A quick
> > > question first.
> > >
> > > The core of the performance problem I'm facing is the need to "walk
> > > the tree" for many thousand files. Every time I do "svn update" or
> > > "svn status" the svn client must stat every file to check for local
> > > modifications (a coffee cup or a beer worth of stats). In essence,
> > > this is unavoidable if there is no mechanism to constantly monitor
> > > filesystem activity during normal operations. Analogous to
> > > filesystem journaling.
> > >
> > > So - I didn't see anything out there saying "git is fast because it
> > > uses inotify" or anything like that. Perhaps git would not help me
> > > at all? Because git still needs to stat all the files in the tree?
> > >
> >
> > http://git.or.cz/gitwiki/GitBenchmarks
> >
> > While it should be possible to use 'assume unchanged' bit together
> > with inotify / icron, it is not something tha is done; IIRC Mercurial
> > had Linux-only InotifyPlugin...
> >
> >
>
> Well, inotify() is Linux specific, so it'd be quite hard to support on
> another platform. Emulating it with a billion stat() calls feels rather
> like a disk (and I/O performance) killer.
There is "filemon" on Windows, which monitors file access. I don't
know how it impacts performance though. A quick search revealed kqueue
for FreeBSD/Mac OSX.
--
Duy
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Johannes Sixt @ 2008-10-23 13:03 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdok16$vh2$1@ger.gmane.org>
Giuseppe Bilotta schrieb:
> Zit will create a directory .zit.file to hold a git repository
> tracking the single file .zit.file/file, which is just a hard link to
> file.
git breaks hard links, mind you! (Just in case you check out older
versions and you wonder why your "real" file is not updated).
But there's a recent patch by Dscho floating around that takes care of the
hard link case.
-- Hannes
^ permalink raw reply
* [PATCH] Implement git remote rename
From: Miklos Vajna @ 2008-10-23 12:56 UTC (permalink / raw)
To: Jeff King; +Cc: Brandon Casey, Junio C Hamano, git
In-Reply-To: <20081023035213.GA8396@coredump.intra.peff.net>
The new rename subcommand does the followings:
1) Renames the remote.foo configuration section to remote.bar
2) Updates the remote.bar.fetch refspecs
3) Updates the branch.*.remote settings
4) Renames the tracking branches.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Oct 22, 2008 at 11:52:14PM -0400, Jeff King <peff@peff.net> wrote:
> I can't help but notice that the word "rename" appears all over the
> commit description and in the code, but not in the user interface.
> Maybe
> "rename" would be a better name for the command instead of (or in
> addition to) "mv"?
I called it "mv" because of "rm" (it is not "remove") and
git-mv/git-add, but I don't think it's a problem if it's called
"rename". Here is an updated patch.
The function name is still "mv" because of rename(2).
Documentation/git-remote.txt | 6 ++
builtin-remote.c | 106 ++++++++++++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 14 ++++++
3 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index bb99810..7b227b3 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git remote' [-v | --verbose]
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote rename' <old> <new>
'git remote rm' <name>
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
@@ -61,6 +62,11 @@ only makes sense in bare repositories. If a remote uses mirror
mode, furthermore, `git push` will always behave as if `\--mirror`
was passed.
+'rename'::
+
+Rename the remote named <old> to <new>. All remote tracking branches and
+configuration settings for the remote are updated.
+
'rm'::
Remove the remote named <name>. All remote tracking branches and
diff --git a/builtin-remote.c b/builtin-remote.c
index 6b3325d..106d6f6 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -10,6 +10,7 @@
static const char * const builtin_remote_usage[] = {
"git remote",
"git remote add <name> <url>",
+ "git remote rename <old> <new>",
"git remote rm <name>",
"git remote show <name>",
"git remote prune <name>",
@@ -329,6 +330,109 @@ static int add_branch_for_removal(const char *refname,
return 0;
}
+struct rename_info {
+ const char *old;
+ const char *new;
+ struct string_list *remote_branches;
+};
+
+static int read_remote_branches(const char *refname,
+ const unsigned char *sha1, int flags, void *cb_data)
+{
+ struct rename_info *rename = cb_data;
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(&buf, "refs/remotes/%s", rename->old);
+ if(!prefixcmp(refname, buf.buf))
+ string_list_append(xstrdup(refname), rename->remote_branches);
+
+ return 0;
+}
+
+static int mv(int argc, const char **argv)
+{
+ struct option options[] = {
+ OPT_END()
+ };
+ struct remote *oldremote, *newremote;
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
+ struct string_list remote_branches = { NULL, 0, 0, 0 };
+ struct rename_info rename;
+ int i;
+
+ if (argc != 3)
+ usage_with_options(builtin_remote_usage, options);
+
+ rename.old = argv[1];
+ rename.new = argv[2];
+ rename.remote_branches = &remote_branches;
+
+ oldremote = remote_get(rename.old);
+ if (!oldremote)
+ die("No such remote: %s", rename.old);
+
+ newremote = remote_get(rename.new);
+ if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
+ die("remote %s already exists.", rename.new);
+
+ strbuf_addf(&buf, "refs/heads/test:refs/remotes/%s/test", rename.new);
+ if (!valid_fetch_refspec(buf.buf))
+ die("'%s' is not a valid remote name", rename.new);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s", rename.old);
+ strbuf_addf(&buf2, "remote.%s", rename.new);
+ if (git_config_rename_section(buf.buf, buf2.buf) < 1)
+ return error("Could not rename config section '%s' to '%s'",
+ buf.buf, buf2.buf);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", rename.new);
+ if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
+ return error("Could not remove config section '%s'", buf.buf);
+ for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
+ char *ptr;
+
+ strbuf_reset(&buf2);
+ strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
+ ptr = strstr(buf2.buf, rename.old);
+ if (ptr)
+ strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
+ rename.new, strlen(rename.new));
+ if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
+ return error("Could not append '%s'", buf.buf);
+ }
+
+ read_branches();
+ for (i = 0; i < branch_list.nr; i++) {
+ struct string_list_item *item = branch_list.items + i;
+ struct branch_info *info = item->util;
+ if (info->remote && !strcmp(info->remote, rename.old)) {
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "branch.%s.remote", item->string);
+ if (git_config_set(buf.buf, rename.new)) {
+ return error("Could not set '%s'", buf.buf);
+ }
+ }
+ }
+
+ for_each_ref(read_remote_branches, &rename);
+ for (i = 0; i < remote_branches.nr; i++) {
+ struct string_list_item *item = remote_branches.items + i;
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, item->string);
+ strbuf_splice(&buf, strlen("refs/remotes/"), strlen(rename.old),
+ rename.new, strlen(rename.new));
+ strbuf_reset(&buf2);
+ strbuf_addf(&buf2, "remote: renamed %s to %s",
+ item->string, buf.buf);
+ if (rename_ref(item->string, buf.buf, buf2.buf))
+ die("renaming '%s' failed", item->string);
+ }
+
+ return 0;
+}
+
static int remove_branches(struct string_list *branches)
{
int i, result = 0;
@@ -696,6 +800,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = show_all();
else if (!strcmp(argv[0], "add"))
result = add(argc, argv);
+ else if (!strcmp(argv[0], "rename"))
+ result = mv(argc, argv);
else if (!strcmp(argv[0], "rm"))
result = rm(argc, argv);
else if (!strcmp(argv[0], "show"))
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c449663..58bd7bf 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -324,4 +324,18 @@ test_expect_success 'reject adding remote with an invalid name' '
'
+# The first three tests if the config is properly updated, the last one
+# checks if the branches are renamed.
+
+test_expect_success 'rename a remote' '
+
+ git clone one four &&
+ (cd four &&
+ git remote rename origin upstream &&
+ git remote show |grep -q upstream &&
+ git config remote.upstream.fetch |grep -q upstream &&
+ test $(git config branch.master.remote) = "upstream" &&
+ git for-each-ref|grep -q refs/remotes/upstream)
+
+'
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: Tip: avoiding net overhead using git over sshfs
From: Johannes Sixt @ 2008-10-23 12:54 UTC (permalink / raw)
To: Felipe Carvalho Oliveira; +Cc: Michael J Gruber, Matthieu Moy, git
In-Reply-To: <a2075f4c0810230451lefff6ffnc283f4078eff9f9c@mail.gmail.com>
Felipe Carvalho Oliveira schrieb:
> On Thu, Oct 23, 2008 at 7:00 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> I think you'd better work locally, and push to the sshfs directory
>> from time to time. Then, you'd both have working tree and .git locally
>> and fast, while keeping the safety of replicating to your ssh server.
>
> I can't use git-push as I explained before.
> I use git as a deployment tool in this case.
> I work locallly and use git-pull to sync my local repo and the
> "production"(server).
> Git works better than a manual (S)FTP sync.
Then how about this: You keep your repository local, and you also hack
locally. When it's time to push your changes to the production server, you
do this:
$ GIT_INDEX_FILE=.git/index.published \
GIT_WORK_TREE=/sshfs-mount/on/production/server \
git reset --hard
This will update only files that changed since you did this the last time.
Disclaimer: I didn't try this myself.
-- Hannes
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Nguyen Thai Ngoc Duy @ 2008-10-23 12:50 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdok16$vh2$1@ger.gmane.org>
On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> The principle is extremely simple: when you choose to start tracking a
> file with Zit,
>
> zit track file
>
> Zit will create a directory .zit.file to hold a git repository
> tracking the single file .zit.file/file, which is just a hard link to
> file.
Why not use one .zit repo and track each file on each own branch?.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox