* Re: (beginner) git rm
From: Junio C Hamano @ 2009-01-28 21:29 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233175322729-2234796.post@n2.nabble.com>
Zabre <427@free.fr> writes:
> Björn Steinbrink wrote:
>>
>> The "git checkout -- d.txt" is also a valid command, but that restores
>> the file from the index.
>>
>> git checkout -- paths
>> ==> Copy "paths" from the index to the working tree
>>
>> git checkout <tree-ish> -- paths
>> ==> Copy "paths" from the tree-ish to the index and working tree
>>
>> So, for "rm d.txt", a plain "git checkout -- d.txt" would also do the
>> trick, as d.txt is still in the index. But your "git rm d.txt" also
>> removed the file from the index, and thus that checkout does nothing.
>> But "git checkout HEAD -- d.txt" works, as it gets the file from HEAD
>> and puts it into the index and working tree.
>
> This is enlightening, thank you very much!
> (I knew I would love git more and more)
>
> Oh just one (probably stupid) thing : <tree-ish> does represent a directory
> being the root of a tree of folders (which has been added to the index),
> does it?
Yeah, it typically is a commit object.
Björn said "Copy", but the operation really is like checking out a book
from a library and "checkout" is a good word for it. "I do not like what
I have in my work tree, and I'd like to replace it with a fresh one taken
out of the index (or, out of that commit)".
^ permalink raw reply
* Re: [PATCH v2] Makefile: Make 'configure --with-expat=path' actually work
From: Junio C Hamano @ 2009-01-28 21:30 UTC (permalink / raw)
To: Serge van den Boom; +Cc: git
In-Reply-To: <alpine.BSF.2.00.0901282120240.74552@toad.stack.nl>
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC v1 3/6] cleanup of write_entry() in entry.c
From: Junio C Hamano @ 2009-01-28 21:31 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <1233004637-15112-4-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> The switch-cases for S_IFREG and S_IFLNK was so similar that it will
> be better to do some cleanup and use the common parts of it.
>
> Also fold the longest lines such that no line is longer then 80 chars
> or so.
>
> And the entry.c file should now be clean for 'gcc -Wextra' warnings.
>
> Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
> ---
>
> If people do not like this approach I can be willing to drop it from
> this patch-series, but then I get some source code duplication from
> the next patch (4/6).
Merging of the two similar codepaths looked good from a cursory reading,
but if you have doubts about one patch, it usually is easier for other
people to work with you if the series is reordered to have it near the
end, iow, undisputably good ones first.
> - return error("git checkout-index: unable to read sha1 file of %s (%s)",
> - path, sha1_to_hex(ce->sha1));
> + return error("git checkout-index: "\
> + "unable to read sha1 file of %s (%s)",
> + path, sha1_to_hex(ce->sha1));
You lost greppability when somebody calls for help saying "I am getting an
error message that says 'git checkout-index: unable to read sha1 file'".
^ permalink raw reply
* Re: [PATCH] diff.c: output correct index lines for a split diff
From: Junio C Hamano @ 2009-01-28 21:32 UTC (permalink / raw)
To: Jeff King; +Cc: Pixel, git
In-Reply-To: <20090126090712.GA12648@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jan 26, 2009 at 12:33:56AM -0800, Junio C Hamano wrote:
>
>> This moves the code to generate metainfo lines around, so that two
>> independent sets of metainfo lines are used for the split halves.
>
> The patch and the generated output look correct to me, so
>
> Acked-by: Jeff King <peff@peff.net>
>
>> I did not include your new test script here; perhaps we can add it to an
>> existing typechange diff/apply test, like t4114?
>
> I think it makes sense to add to t4114. Please squash in the test below.
Thanks.
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Junio C Hamano @ 2009-01-28 21:32 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git, Peter Simons
In-Reply-To: <878wow7sgx.fsf@write-only.cryp.to>
Peter Simons <simons@cryp.to> writes:
> Hi Alexandre,
>
> > diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> > index 3c37d0d..e314c44 100644
> > --- a/contrib/emacs/git.el
> > +++ b/contrib/emacs/git.el
> > @@ -1331,6 +1331,7 @@ Return the list of files that haven't been handled."
> > (log-edit-diff-function . git-log-edit-diff)) buffer)
> > (log-edit 'git-do-commit nil 'git-log-edit-files buffer))
> > (setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
> > + (setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
> > (setq buffer-file-coding-system coding-system)
> > (re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
>
> that patch has the desired effect (tested with GNU Emacs 22.3.1 and
> GIT 1.6.1). Thank you very much.
>
> Now, I'd be hugely in favor of applying that change to the repository
> so that future versions of GIT have it.
Alexandre?
^ permalink raw reply
* Re: [PATCHv2 0/6] gitweb: feed metadata enhancements
From: Jakub Narebski @ 2009-01-28 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git
In-Reply-To: <7vskn3m9l1.fsf@gitster.siamese.dyndns.org>
On Wed, 28 Jan 2009, Junio C Hamano wrote:
> This is independent from your other topic on PATH_INFO, right?
Yes, it is independent on adding BASE for PATH_INFO.
> I am aware that other one is being polished between you and Jakub,
The code (in BASE for PATH_INFO) looks now good, only commit
message might be further improved.
> but is anobody doing anything on this one, or is it already polished enough?
I think it is good, but I do not use web feeds (Atom and RSS)
from gitweb myself, therefore I don't feel competent to tell
if it is good enough. With exception of last one there are
quite simple and feel good; the last one is a bit more involved,
but I think also good (it would be nice to say in commit
message that HTTP::Date can be found in perl-libwww-perl).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv2 0/6] gitweb: feed metadata enhancements
From: Giuseppe Bilotta @ 2009-01-28 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vskn3m9l1.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 28, 2009 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> This is independent from your other topic on PATH_INFO, right? I am aware
> that other one is being polished between you and Jakub, but is anobody
> doing anything on this one, or is it already polished enough?
Yes it's a totally independent topic. For what it's worth, this series
is running on ruby-rbot.org gitweb and it fixed a bunch of rss polling
related issues we were having with the bot we use to watch it.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv2 0/6] gitweb: feed metadata enhancements
From: Junio C Hamano @ 2009-01-28 22:03 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <cb7bb73a0901281357w52aa275i1a734b171396dd58@mail.gmail.com>
Ok, let's apply it directly to 'master', then.
Thanks.
^ permalink raw reply
* Re: "malloc failed"
From: David Abrahams @ 2009-01-28 21:53 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090128050225.GA18546@coredump.intra.peff.net>
On Wed, 28 Jan 2009 00:02:25 -0500, Jeff King <peff@peff.net> wrote:
> On Tue, Jan 27, 2009 at 10:04:42AM -0500, David Abrahams wrote:
>
>> I've been abusing Git for a purpose it wasn't intended to serve:
>> archiving a large number of files with many duplicates and
>> near-duplicates. Every once in a while, when trying to do something
>> really big, it tells me "malloc failed" and bails out (I think it's
>> during "git add" but because of the way I issued the commands I can't
>> tell: it could have been a commit or a gc). This is on a 64-bit linux
>> machine with 8G of ram and plenty of swap space, so I'm surprised.
>>
>> Git is doing an amazing job at archiving and compressing all this stuff
>> I'm putting in it, but I have to do it a wee bit at a time or it craps
>> out. Bug?
>
> How big is the repository? How big are the biggest files? I have a
> 3.5G repo with files ranging from a few bytes to about 180M. I've never
> run into malloc problems or gone into swap on my measly 1G box.
> How does your dataset compare?
I'll try to do some research. Gotta go pick up my boy now...
> As others have mentioned, git wasn't really designed specifically for
> those sorts of numbers, but in the interests of performance, I find git
> is usually pretty careful about not keeping too much useless stuff in
> memory at one time. And the fact that you can perform the same
> operation a little bit at a time and achieve success implies to me there
> might be a leak or some silly behavior that can be fixed.
>
> It would help a lot if we knew the operation that was causing the
> problem. Can you try to isolate the failed command next time it happens?
root@recovery:/olympic/deuce/review# ulimit -v
unlimited
root@recovery:/olympic/deuce/review# git add hydra.bak/home-dave
fatal: Out of memory, malloc failed
The process never even gets close to my total installed RAM size, much less
my whole VM space size.
--
David Abrahams
Boostpro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: (beginner) git rm
From: Björn Steinbrink @ 2009-01-28 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Zabre, git
In-Reply-To: <7vab9bm85b.fsf@gitster.siamese.dyndns.org>
[Zabre, please keep the Cc: list when replying]
On 2009.01.28 13:29:36 -0800, Junio C Hamano wrote:
> Zabre <427@free.fr> writes:
> > Björn Steinbrink wrote:
> >>
> >> The "git checkout -- d.txt" is also a valid command, but that restores
> >> the file from the index.
> >>
> >> git checkout -- paths
> >> ==> Copy "paths" from the index to the working tree
> >>
> >> git checkout <tree-ish> -- paths
> >> ==> Copy "paths" from the tree-ish to the index and working tree
> >>
> >> So, for "rm d.txt", a plain "git checkout -- d.txt" would also do the
> >> trick, as d.txt is still in the index. But your "git rm d.txt" also
> >> removed the file from the index, and thus that checkout does nothing.
> >> But "git checkout HEAD -- d.txt" works, as it gets the file from HEAD
> >> and puts it into the index and working tree.
> >
> > This is enlightening, thank you very much!
> > (I knew I would love git more and more)
> >
> > Oh just one (probably stupid) thing : <tree-ish> does represent a directory
> > being the root of a tree of folders (which has been added to the index),
> > does it?
>
> Yeah, it typically is a commit object.
>
> Björn said "Copy", but the operation really is like checking out a book
> from a library and "checkout" is a good word for it. "I do not like what
> I have in my work tree, and I'd like to replace it with a fresh one taken
> out of the index (or, out of that commit)".
With "checkout", I'm still a bit unsure about which term to use, because
of the behaviour you get with, for example, "git checkout HEAD --
directory". It always just adds or replaces files, but never removes
them. So it's not really like taking the old directory out of the repo
and using that instead. For example:
git rm dir/old_file
echo 123 > dir/new_file
git add dir/new_file
git checkout HEAD -- dir
That won't remove dir/new_file from the index (and of course it won't
drop it from the working tree). That's the one thing where "git checkout
HEAD -- dir" differs from "git reset HEAD -- dir && git checkout --
dir". IIRC we've talked about that on #git a few months ago, but I don't
recall what conclusions we came up with.
It would probably be better to say that checkout only works with the
blobs (because the index doesn't have entries for trees, right?) that
exist in the given tree-ish. And thus it doesn't remove entries from the
index. But that feels a bit convoluted. :-/
Björn
^ permalink raw reply
* Re: "malloc failed"
From: Pau Garcia i Quiles @ 2009-01-28 22:16 UTC (permalink / raw)
To: Jeff King; +Cc: David Abrahams, git
In-Reply-To: <20090128050225.GA18546@coredump.intra.peff.net>
On Wed, Jan 28, 2009 at 6:02 AM, Jeff King <peff@peff.net> wrote:
> How big is the repository? How big are the biggest files? I have a
> 3.5G repo with files ranging from a few bytes to about 180M. I've never
> run into malloc problems or gone into swap on my measly 1G box.
> How does your dataset compare?
I also have malloc problems but only on Windows, on Linux it works fine.
My case: I have a 500 MB repository with a 1GB working tree, with
binary files ranging from 100KB to 50MB and a few thousand source
files.
I have two branches ('master' and 'cmake') and the latter has suffered
a huge hierarchy reorganization.
When I merge 'master' in 'cmake', if I use the 'subtree' strategy, it
works fine. If I use any other strategy, after a couple of minutes I
receive a "malloc failed" and the tree is all messed up. As I said, on
Linux it works fine, so maybe it's a Windows-specific problem.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* [PATCH] http-push: refactor request url creation
From: Tay Ray Chuan @ 2009-01-28 22:19 UTC (permalink / raw)
To: git, Johannes Schindelin, 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.
PS. In "start_fetch_loose", the variable "url" which is passed to "curl_easy_setopt" is removed, and in its place "request->url" is used. This is safe, since curl strdup's it.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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
* rebased and generated on master (297f6a5)
http-push.c | 64 +++++++++++++++++++++++-----------------------------------
1 files changed, 25 insertions(+), 39 deletions(-)
diff --git a/http-push.c b/http-push.c
index 59037df..6511d19 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);
@@ -254,8 +268,6 @@ static void start_fetch_loose(struct transfer_request *request)
char *hex = sha1_to_hex(request->obj->sha1);
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 +317,7 @@ 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);
+ request->url = get_remote_object_url(remote->url, hex, 0);
/* If a previous temp file is present, process what was already
fetched. */
@@ -359,7 +361,7 @@ static void start_fetch_loose(struct transfer_request *request)
curl_easy_setopt(slot->curl, CURLOPT_FILE, request);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_sha1_file);
curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, request->errorstr);
- curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, no_pragma_header);
/* If we have successfully processed data from a previous fetch
@@ -388,16 +390,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 +506,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 +545,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.251.g0dfa1
^ permalink raw reply related
* [PATCH] add -u: do not fail to resolve a path as deleted
From: Junio C Hamano @ 2009-01-28 22:28 UTC (permalink / raw)
To: git
After you resolve a conflicted merge to remove the path, "git add -u"
failed to record the removal. Instead it errored out by saying that the
removed path is not found in the work tree, but that is what the user
wanted to do and failing it is illogical.
This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
read-cache.c | 5 +++++
t/t2200-add-update.sh | 20 +++++++++++++++++++-
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index b1475ff..ddc0586 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1574,6 +1574,11 @@ static void update_callback(struct diff_queue_struct *q,
default:
die("unexpected diff status %c", p->status);
case DIFF_STATUS_UNMERGED:
+ /*
+ * diff-files gives U followed by the work tree state
+ * such as M or D, so we can ignore this.
+ */
+ continue;
case DIFF_STATUS_MODIFIED:
case DIFF_STATUS_TYPE_CHANGED:
if (add_file_to_index(&the_index, path, data->flags)) {
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index cd9231c..e917a01 100755
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
@@ -12,7 +12,7 @@ and issues a git add -u with path limiting on "dir" to add
only the updates to dir/sub.
Also tested are "git add -u" without limiting, and "git add -u"
-without contents changes.'
+without contents changes, and other conditions'
. ./test-lib.sh
@@ -128,4 +128,22 @@ test_expect_success 'add -n -u should not add but just report' '
'
+test_expect_success 'add -u resolves unmerged paths' '
+ git reset --hard &&
+ one=$(echo 1 | git hash-object -w --stdin) &&
+ two=$(echo 2 | git hash-object -w --stdin) &&
+ three=$(echo 3 | git hash-object -w --stdin) &&
+ for path in path1 path2
+ do
+ echo "100644 $one 1 $path"
+ echo "100644 $two 2 $path"
+ echo "100644 $three 3 $path"
+ done |
+ git update-index --index-info &&
+ echo 4 >path1 &&
+ git add -u &&
+ test 1 = "$(git ls-files path1 path2 | wc -l)"
+'
+
test_done
+
--
1.6.1.1.278.g6a817
^ permalink raw reply related
* Re: (beginner) git rm
From: Junio C Hamano @ 2009-01-28 22:33 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Zabre, git
In-Reply-To: <20090128221355.GE7503@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> With "checkout", I'm still a bit unsure about which term to use, because
> of the behaviour you get with, for example, "git checkout HEAD --
> directory".
> ...
> It would probably be better to say that checkout only works with the
> blobs (because the index doesn't have entries for trees, right?).
True, it is not just "checkout". There is no such thing as "directory" in
git UI, in that sense.
When you say:
git checkout [<tree-ish>] -- pathspec
you may be using the same string as the name of an existing directory, but
that does not change the fact that you are giving a pathspec pattern to
specify the set of paths in the index (or in the <tree-ish>) that matches
the pathspec.
^ permalink raw reply
* Re: [PATCH] http-push: refactor request url creation
From: Junio C Hamano @ 2009-01-28 22:51 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Johannes Schindelin
In-Reply-To: <4980D9FF.7020307@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> 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.
>
> PS. In "start_fetch_loose", the variable "url" which is passed to "curl_easy_setopt" is removed, and in its place "request->url" is used. This is safe, since curl strdup's it.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Acked-by: Junio C Hamano <gitster@pobox.com>
What's with these loooooooooooooooooooooooooooooong lines?
I thought at least you did not have these overlong lines in your earlier
attempts, and Dscho may have acked one of those, but I doubt he would give
his Ack to this one. I certainly wouldn't Ack it myself.
By the way, aren't you sending format="flowed"? Please don't. It damages
whitespaces.
Daniel Stenberg did a research on the safety of your "since curl stdrup's
it" claim, and found that it unsafe for earlier versions of the library
before 7.17.0.
It seems that we earlier found out that anything older than 7.16 were not
usable for git-http-push (see Release Notes for 1.5.4), but 7.16 is still
older than 7.17, so either we declare you _must_ have 7.17 or newer to use
http-push, or keep an extra copy around and free it later like the
original code does.
Even Debian is at 7.18.2 these days, so requiring 7.17 or newer may not be
an issue in practice, but there are people who keep running things on
older distros with proven stability (and known features limitation).
The refactoring looked sane otherwise, but I think we would want to opt
for safety by keeping an extra string around.
Thanks.
^ permalink raw reply
* Re: [PATCH] http-push: refactor request url creation
From: Johannes Schindelin @ 2009-01-28 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git
In-Reply-To: <7vvdrzjb80.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 28 Jan 2009, Junio C Hamano wrote:
> I thought at least you did not have these overlong lines in your earlier
> attempts, and Dscho may have acked one of those, but I doubt he would
> give his Ack to this one. I certainly wouldn't Ack it myself.
My understanding is that the ACK is sent to the mailing list by the Acker
and in response to the particular patch she is Acking.
> The refactoring looked sane otherwise, but I think we would want to opt
> for safety by keeping an extra string around.
Yep. Better safe 'n sorry.
Ciao,
Dscho
^ permalink raw reply
* [StGit PATCH] Check for local changes with "goto"
From: Catalin Marinas @ 2009-01-28 23:13 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
This is done by default, unless the --keep option is passed, for
consistency with the "pop" command. The index is checked in the
Transaction.run() function so that other commands could benefit from
this feature (off by default).
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/goto.py | 8 ++++++--
stgit/lib/transaction.py | 7 ++++++-
t/t2300-refresh-subdir.sh | 2 +-
t/t2800-goto-subdir.sh | 4 ++--
t/t3000-dirty-merge.sh | 2 +-
5 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/stgit/commands/goto.py b/stgit/commands/goto.py
index 60a917e..7c5ad39 100644
--- a/stgit/commands/goto.py
+++ b/stgit/commands/goto.py
@@ -18,6 +18,7 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
from stgit.commands import common
from stgit.lib import transaction
from stgit import argparse
+from stgit.argparse import opt
help = 'Push or pop patches to the given one'
kind = 'stack'
@@ -27,7 +28,10 @@ Push/pop patches to/from the stack until the one given on the command
line becomes current."""
args = [argparse.other_applied_patches, argparse.unapplied_patches]
-options = []
+options = [
+ opt('-k', '--keep', action = 'store_true',
+ short = 'Keep the local changes')
+]
directory = common.DirectoryHasRepositoryLib()
@@ -52,4 +56,4 @@ def func(parser, options, args):
raise common.CmdException('Cannot goto a hidden patch')
else:
raise common.CmdException('Patch "%s" does not exist' % patch)
- return trans.run(iw)
+ return trans.run(iw, check_clean = not options.keep)
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index 54de127..2b8f2de 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -183,13 +183,18 @@ class StackTransaction(object):
self.__checkout(self.__stack.head.data.tree, iw,
allow_bad_head = True)
def run(self, iw = None, set_head = True, allow_bad_head = False,
- print_current_patch = True):
+ print_current_patch = True, check_clean = False):
"""Execute the transaction. Will either succeed, or fail (with an
exception) and do nothing."""
self.__check_consistency()
log.log_external_mods(self.__stack)
new_head = self.head
+ # Check for not clean index
+ if check_clean and iw and not iw.index.is_clean():
+ self.__halt('Repository not clean. Use "refresh" or '
+ '"status --reset"')
+
# Set branch head.
if set_head:
if iw:
diff --git a/t/t2300-refresh-subdir.sh b/t/t2300-refresh-subdir.sh
index d731a11..89c95db 100755
--- a/t/t2300-refresh-subdir.sh
+++ b/t/t2300-refresh-subdir.sh
@@ -65,7 +65,7 @@ test_expect_success 'refresh -u -p <subdir>' '
test_expect_success 'refresh an unapplied patch' '
stg refresh -u &&
- stg goto p0 &&
+ stg goto --keep p0 &&
test "$(stg status)" = "M foo.txt" &&
stg refresh -p p1 &&
test "$(stg status)" = "" &&
diff --git a/t/t2800-goto-subdir.sh b/t/t2800-goto-subdir.sh
index 28b8292..855972b 100755
--- a/t/t2800-goto-subdir.sh
+++ b/t/t2800-goto-subdir.sh
@@ -25,7 +25,7 @@ cat > expected2.txt <<EOF
bar
EOF
test_expect_success 'Goto in subdirectory (just pop)' '
- (cd foo && stg goto p1) &&
+ (cd foo && stg goto --keep p1) &&
cat foo/bar > actual.txt &&
test_cmp expected1.txt actual.txt &&
ls foo > actual.txt &&
@@ -48,7 +48,7 @@ cat > expected2.txt <<EOF
bar
EOF
test_expect_success 'Goto in subdirectory (conflicting push)' '
- (cd foo && stg goto p3) ;
+ (cd foo && stg goto --keep p3) ;
[ $? -eq 3 ] &&
cat foo/bar > actual.txt &&
test_cmp expected1.txt actual.txt &&
diff --git a/t/t3000-dirty-merge.sh b/t/t3000-dirty-merge.sh
index f0f79d5..419d86e 100755
--- a/t/t3000-dirty-merge.sh
+++ b/t/t3000-dirty-merge.sh
@@ -26,7 +26,7 @@ test_expect_success 'Push with dirty worktree' '
echo 4 > a &&
[ "$(echo $(stg series --applied --noprefix))" = "p1" ] &&
[ "$(echo $(stg series --unapplied --noprefix))" = "p2" ] &&
- conflict stg goto p2 &&
+ conflict stg goto --keep p2 &&
[ "$(echo $(stg series --applied --noprefix))" = "p1" ] &&
[ "$(echo $(stg series --unapplied --noprefix))" = "p2" ] &&
[ "$(echo $(cat a))" = "4" ]
^ permalink raw reply related
* Re: How to install and use a custom merge driver
From: Alec Clews @ 2009-01-28 23:04 UTC (permalink / raw)
To: git
In-Reply-To: <20090128061848.GA19165@coredump.intra.peff.net>
Jeff King <peff <at> peff.net> writes:
> On Wed, Jan 28, 2009 at 02:10:18PM +1100, Alec Clews wrote:
>
> > Setup:
> >
> > I have set up my ..git/info/gitattributes as follows
> >
> > * merge=overwrite
>
> Your setup looks right, except that the correct file is
> ".git/info/attributes".
Thanks Jeff
I fixed that problem -- however it did not make any difference.
Is there someway to enable logging to see how git is making this choice?
- Alec
^ permalink raw reply
* Re: Valgrind updates
From: Mark Adler @ 2009-01-28 23:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Jean-loup Gailly, Mark Brown, Jeff King,
Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0901271006060.3123@localhost.localdomain>
On Jan 27, 2009, at 10:55 AM, Linus Torvalds wrote:
> and valgrind complains that the "write_buffer()" call will touch an
> uninitialized byte (just one byte, and in the _middle_ of the
> buffer, no
> less):
Linus,
That is definitely not deflate's intentional use of uninitialized
bytes that is noted in the zlib FAQ. This is something else.
> Maybe the zlib people can tell us that we're idiots and the above is
> buggy, but maybe there is a real bug in zlib.
I can't speak to the idiot part, but your usage of deflate is not
buggy. (At least assuming that NULL is all zeros for the compiler in
use.)
If this is all correct, it sounds like a serious bug in deflate. If
so, it would have to be a very sneaky bug to not have been discovered
over the last decade or so of deflate usage on who knows how many
zettabytes of data. The deflate code has remained largely unchanged
in that time, and there really isn't anything unusual about your usage.
I have some questions:
1. Is this problem reproducible on more than one machine?
2. Can someone send me the input and the 58 bytes of output from this
case?
3. Did you try decompressing the 58 bytes?
4. For the detection of an "uninitialized byte", if for example an
uninitialized byte is copied to another location, is that location
then also considered uninitialized? Or does uninitialized mean that
that location has really never been written to?
5. Would the access of uninitialized bytes by deflate have been
detected? Since I don't see a mention of uninitialized access before
the write_buffer(), does that mean that deflate never did such a thing
itself?
Mark
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-28 23:27 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: <69A01114-27BB-4239-8FD8-C35D1306CE25@alumni.caltech.edu>
Hi,
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
Maybe it did not go through correctly.
Unfortunately, I was sick today and could not do any proper work, so I
could not even test the suggestions Julian gave me.
The easiest test, though, should be to set the byte at offset 51 to
something bogus and see if inflate() still groks it.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] builtin-apply.c: do not set bogus mode in check_preimage() for deleted path
From: Junio C Hamano @ 2009-01-28 23:27 UTC (permalink / raw)
To: git; +Cc: Don Zickus, Alexander Potashev
If it is deleted, it is deleted. Do not set the current mode to it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This updates 1f7903a (builtin-apply: prevent non-explicit permission
changes, 2009-01-02). It should not change the behaviour in the normal
case, because we do not explicitly check the final mode of a deletion
patch. We do check the deletion patch creates an empty result, and we
might want to fix that someday, and at that point the existing code
will break.
Also I suspect this codepath has been broken the use case 7a07841
(git-apply: handle a patch that touches the same path more than once
better, 2008-06-27) wanted to support, and if that is the case, this
would fix it.
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index b415daf..1e7f917 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2453,7 +2453,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
if (st_mode != patch->old_mode)
fprintf(stderr, "warning: %s has type %o, expected %o\n",
old_name, st_mode, patch->old_mode);
- if (!patch->new_mode)
+ if (!patch->new_mode && !patch->is_delete)
patch->new_mode = st_mode;
return 0;
--
1.6.1.1.278.g6a817
^ permalink raw reply related
* Re: How to install and use a custom merge driver
From: Alec Clews @ 2009-01-28 23:31 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20090128T230123-889@post.gmane.org>
Alec Clews <alecclews <at> gmail.com> writes:
> Is there someway to enable logging to see how git is making this choice?
Found the answer to my question.
GIT_MERGE_VERBOSITY=5
GIT_TRACE=true
Which results in
+ git merge --stat del2
trace: built-in: git 'merge' '--stat' 'del2'
Merging:
38f3eb9 Accepting delivery del1
virtual del2
found 1 common ancestor(s):
af9dc93 Creating empty staging repo
Auto-merging src/main.c
CONFLICT (add/add): Merge conflict in src/main.c
Automatic merge failed; fix conflicts and then commit the result.
So I'm none the wiser :-(. Any suggestions from wiser people than I?
Thanks
-Alec
^ permalink raw reply
* Re: [PATCH] add -u: do not fail to resolve a path as deleted
From: Junio C Hamano @ 2009-01-28 23:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vbptrkqvb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> After you resolve a conflicted merge to remove the path, "git add -u"
> failed to record the removal. Instead it errored out by saying that the
> removed path is not found in the work tree, but that is what the user
> wanted to do and failing it is illogical.
>
> This fixes it.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> read-cache.c | 5 +++++
> t/t2200-add-update.sh | 20 +++++++++++++++++++-
> 2 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index b1475ff..ddc0586 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1574,6 +1574,11 @@ static void update_callback(struct diff_queue_struct *q,
> default:
> die("unexpected diff status %c", p->status);
> case DIFF_STATUS_UNMERGED:
> + /*
> + * diff-files gives U followed by the work tree state
> + * such as M or D, so we can ignore this.
> + */
> + continue;
This is wrong; breaks t3702.
^ permalink raw reply
* Re: "malloc failed"
From: David Abrahams @ 2009-01-29 0:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <c26bbb3fe074f6f6e0634a4ae8611239@206.71.190.141>
on Wed Jan 28 2009, David Abrahams <dave-AT-boostpro.com> wrote:
> On Wed, 28 Jan 2009 00:02:25 -0500, Jeff King <peff@peff.net> wrote:
>> On Tue, Jan 27, 2009 at 10:04:42AM -0500, David Abrahams wrote:
>>
>>> I've been abusing Git for a purpose it wasn't intended to serve:
>>> archiving a large number of files with many duplicates and
>>> near-duplicates. Every once in a while, when trying to do something
>>> really big, it tells me "malloc failed" and bails out (I think it's
>>> during "git add" but because of the way I issued the commands I can't
>>> tell: it could have been a commit or a gc). This is on a 64-bit linux
>>> machine with 8G of ram and plenty of swap space, so I'm surprised.
>>>
>>> Git is doing an amazing job at archiving and compressing all this stuff
>>> I'm putting in it, but I have to do it a wee bit at a time or it craps
>>> out. Bug?
>>
>> How big is the repository? How big are the biggest files? I have a
>> 3.5G repo with files ranging from a few bytes to about 180M. I've never
>> run into malloc problems or gone into swap on my measly 1G box.
>> How does your dataset compare?
>
> I'll try to do some research. Gotta go pick up my boy now...
Well, moving the 2.6G .dar backup binary out of the fileset seems to
have helped a little, not surprisingly :-P
I don't know whether anyone on this list should care about that failure
given the level of abuse I'm inflicting on Git, but keep in mind that
the system *does* have 8G of memory. Conclude what you will from that,
I suppose!
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: [PATCH] add -u: do not fail to resolve a path as deleted
From: Junio C Hamano @ 2009-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <7viqnzj9ay.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> This is wrong; breaks t3702.
Ugh; that is a bogus test. Please disregard.
^ 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