* Re: Sporadic BSOD with msys git?
From: Peter Harris @ 2009-01-29 14:36 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20090129115442.6ce311f8@crow>
On Thu, Jan 29, 2009 at 6:54 AM, Mark Burton wrote:
>
> I occasionally have to use Windows (XP under VMWare) and thought I would try
> out msysgit so I installed the recent version (1.6.1). For what I was
> wanting to use it for, it worked OK.
>
> However, I then started getting crashes when using the Windows explorer. I would
> click on a folder to look at its contents and, whammo, Windows would crash. It
> just happened every now and again, not all the time.
msysgit does not install any drivers, so it cannot possibly be the
cause of any BSOD.
> Has anyone else seen this?
It's usually bad hardware or a bad driver. (VMWare is virtual
hardware, so buggy versions count as "bad hardware")
Either of the above can cause problems that appear and disappear based
on unrelated factors, which makes them hard to track down. But if it's
a BSOD, the root cause is not msysgit.
Peter Harris
^ permalink raw reply
* Re: git clone --bare doesn't create refs/heads/*?
From: Tay Ray Chuan @ 2009-01-29 14:36 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090129142657.GG21473@genesis.frugalware.org>
Hmm, no, --mirror adds extra remote tracking information.
Quoting the git-clone man page:
"...the branch heads at the remote are copied directly..."
which is to say, git clone --bare isn't doing what it's supposed to do.
that said, i'm not too sure about this, hence this thread.
On Thu, Jan 29, 2009 at 10:26 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Jan 29, 2009 at 10:06:39PM +0800, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> afaik, a bare repository is just a copy of the .git folder of the
>> cloned repository. why isn't any of its branches copied too?
>
> Maybe you're searching for git clone --mirror and not git clone --bare?
>
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git clone --bare doesn't create refs/heads/*?
From: Miklos Vajna @ 2009-01-29 14:40 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901290636m5b472499mdf614841a06ec978@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
[ Please don't top-post. ]
On Thu, Jan 29, 2009 at 10:36:26PM +0800, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Hmm, no, --mirror adds extra remote tracking information.
>
> Quoting the git-clone man page:
>
> "...the branch heads at the remote are copied directly..."
>
> which is to say, git clone --bare isn't doing what it's supposed to do.
>
> that said, i'm not too sure about this, hence this thread.
Ah, packed refs. :)
See man git-pack-refs, git clone uses it to pack refs after a clone.
They are still in the 'packed-refs' file.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Sporadic BSOD with msys git?
From: Mark Burton @ 2009-01-29 14:41 UTC (permalink / raw)
To: git
In-Reply-To: <20090129115442.6ce311f8@crow>
Hi,
Thanks for the responses.
The crash is in the XP guest, not the host (the host is a Linux box).
The XP image is quite old and has had quite a lot of stuff
installed/un-installed over time so I will try again using a fresh XP VM
updated with all the latest M$ fixes.
Cheers,
Mark
^ permalink raw reply
* Re: git clone --bare doesn't create refs/heads/*?
From: Tay Ray Chuan @ 2009-01-29 14:48 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090129144036.GH21473@genesis.frugalware.org>
On Thu, Jan 29, 2009 at 10:40 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> [ Please don't top-post. ]
Oops.
> Ah, packed refs. :)
>
> See man git-pack-refs, git clone uses it to pack refs after a clone.
> They are still in the 'packed-refs' file.
Thanks, that does clears things up.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-29 14:54 UTC (permalink / raw)
To: Mark Adler
Cc: Linus Torvalds, Jean-loup Gailly, Mark Brown, Jeff King,
Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901291510520.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 29 Jan 2009, Johannes Schindelin wrote:
> On Wed, 28 Jan 2009, Mark Adler wrote:
>
> > On Jan 28, 2009, at 3:27 PM, Johannes Schindelin wrote:
> > >On Wed, 28 Jan 2009, Mark Adler wrote:
> > > >2. Can someone send me the input and the 58 bytes of output from this
> > > > case?
> > >
> > >I did better than that already...
> > >http://article.gmane.org/gmane.comp.version-control.git/107391
> >
> > Johannes,
> >
> > Thanks for the input and code. When I run it, the byte in question at
> > offset 51 is 0x2c. The output decompresses fine and the result matches
> > the input. If I change the 0x2c to anything else, decompression fails.
> > The 58 bytes are below.
> >
> > Can you also send me the 58 bytes of output that you get when you run it?
>
> I get exactly the same 58 bytes. Together with the fact that the 52nd
> byte is actually required to be 0x2c, I think that maybe valgrind is
> having problems to track that this byte was correctly initialized.
>
> BTW did you have any chance to test the code with valgrind on your
> machine? It might be related to this here platform (x86_64).
Now, things get interesting.
Of course, I made sure that I had the newest zlib installed before
mentioning publically that I found a strange valgrind issue.
But I did not build it from source myself; I installed what Ubuntu Gutsy
Gibbon had to offer me.
Now that I tried to investigate further by compiling zlib from source,
instrumenting it with various valgrind-specific code to find out what is
actually happening, I cannot reproduce anymore!
So I searched for the sources that Ubuntu provides, and I _still_ cannot
reproduce.
So I'll just go for the easy solution, install plain straightforward
zlib-1.2.3 (as opposed to zlib_1.2.3.3.dfsg-12ubuntu1), and apologise to
y'all for all the bruhaha.
Ciao,
Dscho
P.S.: Note that there is still something fishy going on, as Ubuntu's zlib
generates the deflated stream correctly. But that will have to be
investigated by someone with substantially more time on her hands than me.
^ permalink raw reply
* [PATCH v2] http-push: refactor request url creation
From: Tay Ray Chuan @ 2009-01-29 14:59 UTC (permalink / raw)
To: git, Junio C Hamano
Currently, functions that deal with objects on the remote repository have to allocate and
do strcpys to generate the URL.
This patch saves them this trouble, by providing two functions, "append_remote_object_url"
and "get_remote_object_url".
Both generate a URL, with either the object's 2-digit hex directory (eg. /objects/a1/), or
the complete object location (eg. /objects/a1/b2).
However, they differ in that "append_remote_object_url" appends this URL to a strbuf, while
"get_remote_object_url" wraps around the former and returns the URL directly in char*.
Users usually would use "get_remote_object_url", but may find "append_remote_object_url"
useful if they require further string operations on the URL.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Junio C Hamano <gitster@pobox.com>
---
* renamed only_two_digit_postfix in original patch to only_two_digit_prefix
* rebased and generated on master (5dc1308)
* updated with Junio's changes (if (...) and fix memory leak)
* updated with Junio's double interface
* added back use of temporary string "url" in "start_fetch_loose"
* rebased and generated on master (a34a9db)
http-push.c | 62 +++++++++++++++++++++++-----------------------------------
1 files changed, 25 insertions(+), 37 deletions(-)
diff --git a/http-push.c b/http-push.c
index 59037df..816e658 100644
--- a/http-push.c
+++ b/http-push.c
@@ -209,6 +209,20 @@ static struct curl_slist *get_dav_token_headers(struct remote_lock *lock, enum d
return dav_headers;
}
+static void append_remote_object_url(struct strbuf *buf, const char *url, const char *hex, int only_two_digit_prefix)
+{
+ strbuf_addf(buf, "%sobjects/%.*s/", url, 2, hex);
+ if (!only_two_digit_prefix)
+ strbuf_addf(buf, "%s", hex+2);
+}
+
+static char *get_remote_object_url(const char *url, const char *hex, int only_two_digit_prefix)
+{
+ struct strbuf buf = STRBUF_INIT;
+ append_remote_object_url(&buf, url, hex, only_two_digit_prefix);
+ return strbuf_detach(&buf, NULL);
+}
+
static void finish_request(struct transfer_request *request);
static void release_request(struct transfer_request *request);
@@ -255,7 +269,6 @@ static void start_fetch_loose(struct transfer_request *request)
char *filename;
char prevfile[PATH_MAX];
char *url;
- char *posn;
int prevlocal;
unsigned char prev_buf[PREV_BUF_SIZE];
ssize_t prev_read = 0;
@@ -305,17 +318,8 @@ static void start_fetch_loose(struct transfer_request *request)
git_SHA1_Init(&request->c);
- url = xmalloc(strlen(remote->url) + 50);
- request->url = xmalloc(strlen(remote->url) + 50);
- strcpy(url, remote->url);
- posn = url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- *(posn++) = '/';
- strcpy(posn, hex + 2);
- strcpy(request->url, url);
+ url = get_remote_object_url(remote->url, hex, 0);
+ request->url = xstrdup(url);
/* If a previous temp file is present, process what was already
fetched. */
@@ -388,16 +392,8 @@ static void start_mkcol(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- char *posn;
- request->url = xmalloc(strlen(remote->url) + 13);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- strcpy(posn, "/");
+ request->url = get_remote_object_url(remote->url, hex, 1);
slot = get_active_slot();
slot->callback_func = process_response;
@@ -512,7 +508,7 @@ static void start_put(struct transfer_request *request)
{
char *hex = sha1_to_hex(request->obj->sha1);
struct active_request_slot *slot;
- char *posn;
+ struct strbuf buf = STRBUF_INIT;
enum object_type type;
char hdr[50];
void *unpacked;
@@ -551,21 +547,13 @@ static void start_put(struct transfer_request *request)
request->buffer.buf.len = stream.total_out;
- request->url = xmalloc(strlen(remote->url) +
- strlen(request->lock->token) + 51);
- strcpy(request->url, remote->url);
- posn = request->url + strlen(remote->url);
- strcpy(posn, "objects/");
- posn += 8;
- memcpy(posn, hex, 2);
- posn += 2;
- *(posn++) = '/';
- strcpy(posn, hex + 2);
- request->dest = xmalloc(strlen(request->url) + 14);
- sprintf(request->dest, "Destination: %s", request->url);
- posn += 38;
- *(posn++) = '_';
- strcpy(posn, request->lock->token);
+ strbuf_addstr(&buf, "Destination: ");
+ append_remote_object_url(&buf, remote->url, hex, 0);
+ request->dest = strbuf_detach(&buf, NULL);
+
+ append_remote_object_url(&buf, remote->url, hex, 0);
+ strbuf_addstr(&buf, request->lock->token);
+ request->url = strbuf_detach(&buf, NULL);
slot = get_active_slot();
slot->callback_func = process_response;
--
1.6.1.1.241.gc53a6.dirty
^ permalink raw reply related
* Re: [PATCH v2] http-push: refactor request url creation
From: Johannes Schindelin @ 2009-01-29 15:10 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Junio C Hamano
In-Reply-To: <4981C43B.9030409@gmail.com>
Hi,
On Thu, 29 Jan 2009, Tay Ray Chuan wrote:
> Currently, functions that deal with objects on the remote repository have to
> allocate and
> do strcpys to generate the URL.
That is a funny way to wrap the commit message :-)
> +static void append_remote_object_url(struct strbuf *buf, const char *url,
> const char *hex, int only_two_digit_prefix)
Here, you still have a corrupt patch. Which might be helped by wrapping
the overly long line in the first place?
Ciao,
Dscho
^ permalink raw reply
* [PATCH,v2] git-bundle(1): add no references required simplest case
From: jidanni @ 2009-01-29 15:32 UTC (permalink / raw)
To: gitster; +Cc: mdl123, spearce, git
In-Reply-To: <7vljsx6dzi.fsf@gitster.siamese.dyndns.org>
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Words totally by Junio C Hamano.
Documentation/git-bundle.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..42c2abc 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -164,6 +164,22 @@ $ git pull bundle
would treat it as if it is talking with a remote side over the
network.
+A complete bundle is one that does not require you to have any
+prerequisite object for you to extract its contents. Not only you
+can fetch/pull from a bundle, you can clone from a complete bundle
+as if it was a remote repository, like this:
+
+----------------
+$ git clone /home/me/tmp/file.bdl mine.git
+----------------
+
+This will define a remote called "origin" in the resulting
+repository that lets you fetch and pull from the bundle, just
+like the previous example lets you do with the remote called
+"bundle", and from then on you can fetch/pull to update the
+resulting mine.git repository after replacing the bundle you store
+at /home/me/tmp/file.bdl with incremental updates.
+
Author
------
Written by Mark Levedahl <mdl123@verizon.net>
--
1.6.0.6
^ permalink raw reply related
* Appropriateness of git for digital video production versioning
From: Charles Earl @ 2009-01-29 15:36 UTC (permalink / raw)
To: git
Hi,
Are there past instances of git having been adapted to support version
control of digital media production workflow?
I'm evaluating CMS and versioning systems for the backend of a SaaS
for digital media production workflow.
The bulk of content stored is binary data -- there have been posts on
this about integration of various binary diff implemetations with git.
The versioning of metadata, scripts, project structure seems to argue
for applicability of system such as git -- these fit the paradigm of
traditional scm.
Example content is from media production suites such as Adobe After
Effects/Premier: video, compositions, etc.
I'd also like the object storage to be in S3/Amazon BlockStore or
similar remote stores.
Charles
^ permalink raw reply
* how to clean up remote/ref
From: bill lam @ 2009-01-29 15:42 UTC (permalink / raw)
To: git
When I migrated from svn to git, I keep updating svn repo and also
added a dummy git repo, Now the GIT_DIR/config look likes
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = http://localhost/svn/project2/
fetch = :refs/remotes/trunk
[remote "origin"]
url = http://bl@localhost/git-repo/project/
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Now I feel I don't need update the svn repo (actually it was inactive
for more than 1 year after a few updates). Also I no longer want to
use http protocol to remote git repo.
It said the HEAD is different that orgin/master
$ git checkout master
Switched to branch "master"
Your branch and 'origin/master' have diverged,
and have 71 and 24 different commit(s) each, respectively.
How do it
1. remove any reference to the svn repo [svn-remote "svn"]
2. remove reference to the http [remote "origin"]
3. setup a new empty git as the new remote repos
thanks
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩277 柳中庸 征人怨
歲歲金河復玉關 朝朝馬策與刀環 三春白雪歸青塚 萬里黃河繞黑山
^ permalink raw reply
* Re: Appropriateness of git for digital video production versioning
From: Shawn O. Pearce @ 2009-01-29 15:45 UTC (permalink / raw)
To: Charles Earl; +Cc: git
In-Reply-To: <8c4a72800901290736p4952e53byddca243f300dd8af@mail.gmail.com>
Charles Earl <charles.cearl@gmail.com> wrote:
> Are there past instances of git having been adapted to support version
> control of digital media production workflow?
You are going to run into scaling problems. Git works under the
assumption that it can malloc() at least 2 complete copies of a
file at once, in the same process.
Last time I mucked around with digital media production, the volume
of data in a video file was *huge*. Its workable on modern systems
with terabyte disk arrays and so forth, but modern systems still
can't afford the 100 GB of RAM necessary to allow Git to malloc()
up two blocks of a single 40 GB video file.
Also, since clients pretty much grab the entire repository when they
clone it for working access, its going to suck down the entire media
archive, *all* versions. That could be well into the hundreds of
TB range and may never complete.
> The bulk of content stored is binary data -- there have been posts on
> this about integration of various binary diff implemetations with git.
You mention later about using S3 or BlockStore to hold the binary
content. Maybe the large binary data should be stored in S3, and
the Git repository just holds the metadata and scripts, including
scripts to perform downloads/uploads through S3.
> The versioning of metadata, scripts, project structure seems to argue
> for applicability of system such as git -- these fit the paradigm of
> traditional scm.
Yea, that's more typical of what Git was designed and built to store.
> Example content is from media production suites such as Adobe After
> Effects/Premier: video, compositions, etc.
> I'd also like the object storage to be in S3/Amazon BlockStore or
> similar remote stores.
My suggestion?
Use Git for your metadata and scripts. Include a few scripts that
can download the large media files from S3 when they are needed,
and upload new versions when they are modified.
If you want to store versions over time of the files, sha1sum
the media file and use that as the key name in the S3 bucket,
and store the output of sha1sum into a file within Git. E.g. a
".media" text file just listing out sha1sum and path names:
ceba7222551c722836564535697947e8a9b3e7ce big_file.mpg
75c8f5ecb97ec67c1ec949b16c72e6ba1361a528 other_file.mpg
and use a simple script to edit/read that file, accessing S3 as
necessary for the operations.
--
Shawn.
^ permalink raw reply
* Re: Appropriateness of git for digital video production versioning
From: Pau Garcia i Quiles @ 2009-01-29 15:48 UTC (permalink / raw)
To: Charles Earl; +Cc: git
In-Reply-To: <8c4a72800901290736p4952e53byddca243f300dd8af@mail.gmail.com>
Hello,
Git is not the appropriate tool. What about using a filesystem with
versioning support? tux3, btrfs, ZFS and NILFS may work for you.
On Thu, Jan 29, 2009 at 4:36 PM, Charles Earl <charles.cearl@gmail.com> wrote:
> Hi,
> Are there past instances of git having been adapted to support version
> control of digital media production workflow?
> I'm evaluating CMS and versioning systems for the backend of a SaaS
> for digital media production workflow.
> The bulk of content stored is binary data -- there have been posts on
> this about integration of various binary diff implemetations with git.
> The versioning of metadata, scripts, project structure seems to argue
> for applicability of system such as git -- these fit the paradigm of
> traditional scm.
> Example content is from media production suites such as Adobe After
> Effects/Premier: video, compositions, etc.
> I'd also like the object storage to be in S3/Amazon BlockStore or
> similar remote stores.
> Charles
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Brian Gernhardt @ 2009-01-29 16:00 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
The call to "git reset --hard B1" failed on case-insensitive file
systems (such as the default settings for HFS+) because there was both
a tag "B1" and a file "b1". Adding "--" to the command makes it
clear that we mean commit B1.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
t/t3411-rebase-preserve-around-merges.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index 6533505..e544451 100755
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -24,7 +24,7 @@ test_expect_success 'setup' '
test_commit A1 &&
test_commit B1 &&
test_commit C1 &&
- git reset --hard B1 &&
+ git reset --hard B1 -- &&
test_commit D1 &&
test_merge E1 C1 &&
test_commit F1
--
1.6.1.2.418.gd79e6.dirty
^ permalink raw reply related
* Re: [PATCH] contrib: add 'git bpush' to push to bundles
From: Santi Béjar @ 2009-01-29 16:05 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20090120064732.GA14580@glandium.org>
2009/1/20 Mike Hommey <mh@glandium.org>:
> On Tue, Jan 20, 2009 at 12:46:31AM +0100, Santi Béjar wrote:
>> 'git bpush' updates the branches in a bundle, while adding the objects
>> necessary to complete the given branches. Basically, it is a 'git
>> push' for bundles.
>
> I think it'd be better to improve git-push to support that, instead of
> adding yet another git command.
Yes, I also think it'd be better if git-push supports it, but this is
not a trivial task, and my script works now. So I think it makes sense
to add it to the *contrib* directory.
Santi
^ permalink raw reply
* Re: [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Johannes Schindelin @ 2009-01-29 16:13 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Junio C Hamano
In-Reply-To: <1233244816-67565-1-git-send-email-benji@silverinsanity.com>
Hi,
On Thu, 29 Jan 2009, Brian Gernhardt wrote:
> The call to "git reset --hard B1" failed on case-insensitive file
> systems (such as the default settings for HFS+) because there was both
> a tag "B1" and a file "b1". Adding "--" to the command makes it
> clear that we mean commit B1.
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Sigh.
ACK and thanks,
Dscho
^ permalink raw reply
* Re: diff settings
From: Ted Pavlic @ 2009-01-29 16:26 UTC (permalink / raw)
To: Keith Cascio; +Cc: Teemu Likonen, git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <497D1AB7.7000208@tedpavlic.com>
> This task is pretty easy in Mercurial because Mercurial porcelains are
> implemented as modules that are all executed through the central "hg"
> command. This isn't the case with git.
(on the other hand, having a "[defaults]" section that only applies when
commands are called via "git" might be nice. That way you can use the
"git-CMD" when you want to use CMD without the "[defaults]"... perhaps?)
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* [PATCH] Fix 'git diff --no-index' with a non-existing symlink target
From: Johannes Schindelin @ 2009-01-29 16:30 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <cover.1233246616u.git.johannes.schindelin@gmx.de>
When trying to find out mode changes, we should not access the symlink
targets using stat(); instead we use lstat() so that the diff does
not fail trying to find a non-existing symlink target.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
diff-no-index.c | 2 +-
t/t4011-diff-symlink.sh | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 60ed174..0dbd9da 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -40,7 +40,7 @@ static int get_mode(const char *path, int *mode)
*mode = 0;
else if (!strcmp(path, "-"))
*mode = create_ce_mode(0666);
- else if (stat(path, &st))
+ else if (lstat(path, &st))
return error("Could not access '%s'", path);
else
*mode = st.st_mode;
diff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh
index 02efeca..9055c8b 100755
--- a/t/t4011-diff-symlink.sh
+++ b/t/t4011-diff-symlink.sh
@@ -82,4 +82,11 @@ test_expect_success \
git diff-index -M -p $tree > current &&
compare_diff_patch current expected'
+test_expect_success \
+ 'diff symlinks with non-existing targets' \
+ 'ln -s narf pinky &&
+ ln -s take\ over brain &&
+ test_must_fail git diff --no-index pinky brain > output 2> output.err &&
+ grep narf output &&
+ ! grep error output.err'
test_done
--
1.6.1.2.531.g6f52
^ permalink raw reply related
* Re: diff settings
From: Johannes Schindelin @ 2009-01-29 16:33 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Keith Cascio, Teemu Likonen, git, Junio C Hamano
In-Reply-To: <4981D8AD.6000000@tedpavlic.com>
Hi,
On Thu, 29 Jan 2009, Ted Pavlic wrote:
> > This task is pretty easy in Mercurial because Mercurial porcelains are
> > implemented as modules that are all executed through the central "hg"
> > command. This isn't the case with git.
>
> (on the other hand, having a "[defaults]" section that only applies when
> commands are called via "git" might be nice. That way you can use the
> "git-CMD" when you want to use CMD without the "[defaults]"... perhaps?)
Nope, the dash form is deprecated, and once y'all out there finally do not
write it any more, we can start thinking about _not_ hardlinking the
builtins to their dashed form anymore.
Believe it or not, we already have a distinction between what is called
from scripts vs from humans: plumbing vs porcelain. So you can set the
defaults for porcelain as much as you want, but please leave plumbing
alone.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Junio C Hamano @ 2009-01-29 17:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git List, Brian Gernhardt
In-Reply-To: <1233244816-67565-1-git-send-email-benji@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> The call to "git reset --hard B1" failed on case-insensitive file
> systems (such as the default settings for HFS+) because there was both
> a tag "B1" and a file "b1". Adding "--" to the command makes it
> clear that we mean commit B1.
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> ---
> t/t3411-rebase-preserve-around-merges.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
> index 6533505..e544451 100755
> --- a/t/t3411-rebase-preserve-around-merges.sh
> +++ b/t/t3411-rebase-preserve-around-merges.sh
> @@ -24,7 +24,7 @@ test_expect_success 'setup' '
> test_commit A1 &&
> test_commit B1 &&
> test_commit C1 &&
> - git reset --hard B1 &&
> + git reset --hard B1 -- &&
> test_commit D1 &&
> test_merge E1 C1 &&
> test_commit F1
It is not just B1 that is ambiguous, even though that is the only
ambiguous one this particular test uses.
If we really wanted to care about case-folding file systems, shouldn't we
make test_commit shell function a bit more than the downcasing? How about
this patch instead?
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git c/t/test-lib.sh w/t/test-lib.sh
index c1839f7..8066c25 100644
--- c/t/test-lib.sh
+++ w/t/test-lib.sh
@@ -201,7 +201,7 @@ test_tick () {
# Both <file> and <contents> default to <message>.
test_commit () {
- file=${2:-$(echo "$1" | tr 'A-Z' 'a-z')}
+ file=${2:-$(echo "$1" | tr 'A-Z' 'a-z').t}
echo "${3-$1}" > "$file" &&
git add "$file" &&
test_tick &&
^ permalink raw reply related
* Re: [PATCH v2] http-push: refactor request url creation
From: Junio C Hamano @ 2009-01-29 17:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tay Ray Chuan, git
In-Reply-To: <alpine.DEB.1.00.0901291608330.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 29 Jan 2009, Tay Ray Chuan wrote:
>
>> Currently, functions that deal with objects on the remote repository have to
>> allocate and
>> do strcpys to generate the URL.
>
> That is a funny way to wrap the commit message :-)
That's format=flowed in action, isn't it?
^ permalink raw reply
* Re: [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Johannes Schindelin @ 2009-01-29 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Brian Gernhardt
In-Reply-To: <7vocxqf2sf.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 29 Jan 2009, Junio C Hamano wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
> > The call to "git reset --hard B1" failed on case-insensitive file
> > systems (such as the default settings for HFS+) because there was both
> > a tag "B1" and a file "b1". Adding "--" to the command makes it
> > clear that we mean commit B1.
> >
> > Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> > ---
> > t/t3411-rebase-preserve-around-merges.sh | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
> > index 6533505..e544451 100755
> > --- a/t/t3411-rebase-preserve-around-merges.sh
> > +++ b/t/t3411-rebase-preserve-around-merges.sh
> > @@ -24,7 +24,7 @@ test_expect_success 'setup' '
> > test_commit A1 &&
> > test_commit B1 &&
> > test_commit C1 &&
> > - git reset --hard B1 &&
> > + git reset --hard B1 -- &&
> > test_commit D1 &&
> > test_merge E1 C1 &&
> > test_commit F1
>
> It is not just B1 that is ambiguous, even though that is the only
> ambiguous one this particular test uses.
>
> If we really wanted to care about case-folding file systems, shouldn't we
> make test_commit shell function a bit more than the downcasing? How about
> this patch instead?
>
> t/test-lib.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git c/t/test-lib.sh w/t/test-lib.sh
> index c1839f7..8066c25 100644
> --- c/t/test-lib.sh
> +++ w/t/test-lib.sh
> @@ -201,7 +201,7 @@ test_tick () {
> # Both <file> and <contents> default to <message>.
>
> test_commit () {
> - file=${2:-$(echo "$1" | tr 'A-Z' 'a-z')}
> + file=${2:-$(echo "$1" | tr 'A-Z' 'a-z').t}
Or
file=${2:-$1.file}
but I was not quite sure about the impact; I might have checked for
specific filenames.
Brian, if you would have the time to go through the tests if an automatic
filename was used, that would be smashing! (We cannot just run the tests
and look at the failures, as absence of files could be tested; I don't
remember, debugging zlib/valgrind currently turns my brain into tatties.)
Ciao,
Dscho
^ permalink raw reply
* [EGIT] Blame functionality update
From: Manuel Woelker @ 2009-01-29 17:35 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git
Hi folks,
quick update about the state of blame functionality in my egit branch
at http://github.com/manuel-woelker/egit/tree/blame
Screen shot here: http://docs.google.com/View?docid=df5rvczr_3f46vd2ds
- Diff support: I changed the IDiff as suggested to work on raw bytes
and IntList's. I also yanked the Diff implementation from wicket and
adapted it for use in jgit. The diff stuff now lives in its own
package. I also added some basic tests to see if plugged diff
implementations conform to the required expectations.
- log support: I added an OriginWalk in the new log package that
traces ancestry of a file though history (including renames and
copying). This might also be neat for the history page, which does not
seem to follow renames at the moment (think "log -C -M"). This is just
a rough sketch atm. Copies are disabled right now, cause the
performance is abysmal, and the current implementation tries to trace
the ancestry of empty lines back to the triassic period. So this could
definitely be optimized. The OriginWalk itself uses RevObject (as
suggested) so it should be a little faster. The implementation
currently traces the different strands of ancestry quite naively,
possibly parsing commits multiple times. This could be improved to a
single pass walk, but this makes the algorithm a little less
straight-forward and I haven't gotten around to that.
- As a result of the the OriginWalk mentioned above, the blame
implementation has been refactored slightly, while still keeping the
basic structure.
- I hooked up the blame functionality to the UI which was easier than
anticipated. I am quite pleased with the result (see screen shot
above). The only thing that proved a little tricky was history and
annotation ruler selection listener notifying each other recursively.
For now I stopped the stack overflow by detecting that recursive call.
If anyone got a better solution just give me a shout.
Feedback, comments and criticism are welcome as always.
Cheers
- Manuel
^ permalink raw reply
* Force commit date
From: Zabre @ 2009-01-29 18:30 UTC (permalink / raw)
To: git
Hi all,
Some time ago, I used to make 7zip backups of my project directory to keep
an history of my changes. (I've kept all of them in separated 7z files) I
was then living in darkness. (Even though I tried svn but was somehow not
happy with it) Now I've found the light, and git is the best tool around
(along with Hg I guess).
I am learning git at the moment and I would like to restore all my 7zipped
backups one after the other, use meld to apply each change in the code +
directory structure and then git to commit each of them, chronologically, to
finally obtain a complete git history of my changes (I even have "commit
commentaries" in a special text file, yes I tried to do things properly with
basic tools.)
This should be feasible, but what would be very cool in this very special
case is if I could force the commit date to reflect the real date each
"commit" (read : "zip") was done with my old method in last year, and not
the date of my convertion to git.
If it is not, that's not a big deal, but I'd really like to know how to do
this, and have my different projects on a git history. (I even have one or
two "secondary branches")
There might be an option I am not aware of.
(I have seen on this forum / mailing list some people playing with dates but
it was the case of mailboxes and "git am")
http://n2.nabble.com/how-to-force-a-commit-date-matching-info-from-a-mbox---td2200613.html
Remember I'm a beginner trying to learn git, so please bear with me.
Thank you!
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240539.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Force commit date
From: Sverre Rabbelier @ 2009-01-29 18:37 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233253817209-2240539.post@n2.nabble.com>
On Thu, Jan 29, 2009 at 19:30, Zabre <427@free.fr> wrote:
> There might be an option I am not aware of.
Indeed, try 'import-tars.perl' in the /contrib directory of git.git :).
--
Cheers,
Sverre Rabbelier
^ 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