* Re: Test that every revision builds before pushing changes?
From: Daniel Pittman @ 2009-03-26 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <49CB39E5.5060000@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Daniel Pittman wrote:
>>
>> I would like to ensure that my commits are fully bisectable before I
>> commit them to an upstream repository, at least to the limits of an
>> automatic tool for testing them.
>>
>> 'git bisect run' is similar: it can automatically locate the breaking in
>> a test suite, for example, but that doesn't help me in the case of three
>> commits, A (good), B (bad) and C (good, fixing B).
>>
>> I would much rather, in this case, use rebase to fix B so that it, too,
>> builds before I push the changes and pollute a public repository with a
>> broken changeset — and make bisect that much harder to use in future.
>
> You can do that, but it requires manual work too. The trick is to make
> the release branch immutable on the public repository and use topic
> branches with per-developer namespaces. The per-developer namespace
> thing is actually important, as it leaves the freedom to rewind and
> recreate topics to the developers (which shared branches do not).
>
> The manual step comes at merge-time; Someone has to be responsible for
> merging all the topics that are to be included in the release branch
> and make sure it builds and passes all tests after each merge.
Ah. You have not quite grasped what I was looking for: I was after a
tool to help automate that step, rather than a workflow around it.
For example, the responsible person for that testing could use the
hypothetical (until someone tells me where to find it):
git test public..test make test
Which would then effectively wrap:
for each revision between public and private:
git checkout revision
make test
# report if that fails, allow fixing the commit or whatever
# then 'git test continue' to carry on...
That turn the process from a manual one to an automated one: it runs
that command for every revision until it fails, or until they all pass.
Regards,
Daniel
^ permalink raw reply
* Re: [PATCH TopGit] hooks/pre-commit.sh: fix bashism
From: Marc Kleine-Budde @ 2009-03-26 9:29 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Bert Wesarg, Petr Baudis, git, martin f krafft, Marc Kleine-Budde
In-Reply-To: <20090326090009.GA7570@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
Uwe Kleine-König wrote:
> This was introduced in fcb488d51e72c7414f9beb40ad06bf529b8b38dc.
> A similar fix was suggested by martin f krafft, too.
Works here on ubuntu bin /bin/sh is a link to /bin/dash
> Reported-by: Bert Wesarg <bert.wesarg@googlemail.com>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ---
> Hello,
>
> this should fix the issue now.
>
> If I don't get negative feed back I will push this change later today.
> I'm open for acks, too.
>
> Best regards and thanks
> Uwe
>
> hooks/pre-commit.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hooks/pre-commit.sh b/hooks/pre-commit.sh
> index a12cfa6..9d677e9 100644
> --- a/hooks/pre-commit.sh
> +++ b/hooks/pre-commit.sh
> @@ -20,7 +20,7 @@ tg_util
> if head_=$(git symbolic-ref -q HEAD); then
> case "$head_" in
> refs/heads/*)
> - git rev-parse -q --verify "${head_/#refs\/heads/refs\/top-bases}" >/dev/null || exit 0;;
> + git rev-parse -q --verify "refs/top-bases${head_#refs/heads}" >/dev/null || exit 0;;
> *)
> exit 0;;
> esac
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Linux Solutions for Science and Industry | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* [PATCH] Grammar fix for "git merge" man page
From: Wincent Colaiuta @ 2009-03-26 9:39 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Wincent Colaiuta
In-Reply-To: <20090326022006.GB5835@coredump.intra.peff.net>
As spotted by the eagle eyes of Jeff King.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/git-merge.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 427ad90..c04ae73 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -40,7 +40,7 @@ include::merge-options.txt[]
include::merge-strategies.txt[]
-If you tried a merge which resulted in a complex conflicts and
+If you tried a merge which resulted in complex conflicts and
want to start over, you can recover with 'git-reset'.
CONFIGURATION
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH 1/8] Documentation: move callouts.xsl to manpage-{base,normal}.xsl
From: Jeff King @ 2009-03-26 9:40 UTC (permalink / raw)
To: Chris Johnsen; +Cc: git, Junio C Hamano
In-Reply-To: <B1EF04D8-8423-4794-BEFF-908C1B3DEC31@pobox.com>
On Tue, Mar 24, 2009 at 02:36:52PM -0500, Chris Johnsen wrote:
> Thank you for looking at these. I will incorporate your feedback and
> resend in a couple of days.
Great, thanks.
> I used -C -M in some early diffs to make sure it would "compress" like
> that, but I failed to do so for the final send-email.
FWIW, I just set diff.renames in my git repo so I don't have to remember
(the only reason not to generate renames for format-patch is if the
recipient is not using git to apply -- but it is a pretty safe
assumption that people here are using git).
-Peff
^ permalink raw reply
* Re: [PATCH 3/8] Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff
From: Jeff King @ 2009-03-26 9:43 UTC (permalink / raw)
To: Chris Johnsen; +Cc: git, Junio C Hamano
In-Reply-To: <B70DE0F1-8CDA-46FC-9EF8-41B0FAC39631@pobox.com>
On Tue, Mar 24, 2009 at 02:48:52PM -0500, Chris Johnsen wrote:
> I am not opposed to providing more version-specific controls, but I am not
> sure which versions are important enough to justify their own variables.
> Are you indicating that 1.73 is important enough because it was a "return
> to sanity" after 1.72?
No, mainly because it is what is shipped in the last version of Debian,
which means it is a major enough version that there will be a lot of
people using it.
But let's just start with adding the tweakable knobs (which your series
is already doing), and see in what ways they need to be tweaked for
popular platforms before going overboard.
-Peff
^ permalink raw reply
* Re: [BUG?] How to make a shared/restricted repo?
From: Johan Herland @ 2009-03-26 9:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <49CB3FA0.8030408@viscovery.net>
On Thursday 26 March 2009, Johannes Sixt wrote:
> You certainly meant to use the curr_*_name variants in the chmod lines,
> no?
Oops. Yes. My bad.
> This effectively undoes 33b65030, but that is not so good: On Windows
> we cannot rename read-only files.
What about this: Add a "mode" argument to move_temp_to_file(), used to
pass in the 0444, and then within move_temp_to_file() we can do the
chmod(foo, 0444) _after_ renaming the file, but _before_ calling
adjust_shared_perm().
Something like this on top of Junio's patch:
----------------------->8-------------8<-------------------
diff --git a/cache.h b/cache.h
index 9cf5a13..9b28b98 100644
--- a/cache.h
+++ b/cache.h
@@ -652,7 +652,8 @@ extern int do_check_packed_object_crc;
extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned long size, const char *type);
-extern int move_temp_to_file(const char *tmpfile, const char *filename);
+/* Set mode to -1 if you don't want to explicitly change the file mode */
+extern int finalize_temp_file(const char *tmpfile, const char *filename, int mode);
extern int has_sha1_pack(const unsigned char *sha1);
extern int has_sha1_file(const unsigned char *sha1);
diff --git a/fast-import.c b/fast-import.c
index beeac0d..a5556e9 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -902,9 +902,6 @@ static char *keep_pack(char *curr_index_name)
static const char *keep_msg = "fast-import";
int keep_fd;
- chmod(pack_data->pack_name, 0444);
- chmod(curr_index_name, 0444);
-
keep_fd = odb_pack_keep(name, sizeof(name), pack_data->sha1);
if (keep_fd < 0)
die("cannot create keep file");
@@ -914,12 +911,12 @@ static char *keep_pack(char *curr_index_name)
snprintf(name, sizeof(name), "%s/pack/pack-%s.pack",
get_object_directory(), sha1_to_hex(pack_data->sha1));
- if (move_temp_to_file(pack_data->pack_name, name))
+ if (finalize_temp_file(pack_data->pack_name, name, 0444))
die("cannot store pack file");
snprintf(name, sizeof(name), "%s/pack/pack-%s.idx",
get_object_directory(), sha1_to_hex(pack_data->sha1));
- if (move_temp_to_file(curr_index_name, name))
+ if (finalize_temp_file(curr_index_name, name, 0444))
die("cannot store index file");
return name;
}
diff --git a/http-push.c b/http-push.c
index 6ce5a1d..5be6600 100644
--- a/http-push.c
+++ b/http-push.c
@@ -748,7 +748,6 @@ static void finish_request(struct transfer_request *request)
aborted = 1;
}
} else if (request->state == RUN_FETCH_LOOSE) {
- fchmod(request->local_fileno, 0444);
close(request->local_fileno); request->local_fileno = -1;
if (request->curl_result != CURLE_OK &&
@@ -769,9 +768,10 @@ static void finish_request(struct transfer_request *request)
unlink(request->tmpfile);
} else {
request->rename =
- move_temp_to_file(
+ finalize_temp_file(
request->tmpfile,
- request->filename);
+ request->filename,
+ 0444);
if (request->rename == 0) {
request->obj->flags |= (LOCAL | REMOTE);
}
@@ -794,8 +794,9 @@ static void finish_request(struct transfer_request *request)
fclose(request->local_stream);
request->local_stream = NULL;
- if (!move_temp_to_file(request->tmpfile,
- request->filename)) {
+ if (!finalize_temp_file(request->tmpfile,
+ request->filename,
+ -1)) {
target = (struct packed_git *)request->userData;
target->pack_size = pack_size;
lst = &repo->packs;
@@ -1007,7 +1008,7 @@ static int fetch_index(unsigned char *sha1)
free(url);
fclose(indexfile);
- return move_temp_to_file(tmpfile, filename);
+ return finalize_temp_file(tmpfile, filename, -1);
}
static int setup_index(unsigned char *sha1)
diff --git a/http-walker.c b/http-walker.c
index 0dbad3c..7da78e1 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -231,7 +231,6 @@ static void finish_object_request(struct object_request *obj_req)
{
struct stat st;
- fchmod(obj_req->local, 0444);
close(obj_req->local); obj_req->local = -1;
if (obj_req->http_code == 416) {
@@ -254,7 +253,7 @@ static void finish_object_request(struct object_request *obj_req)
return;
}
obj_req->rename =
- move_temp_to_file(obj_req->tmpfile, obj_req->filename);
+ finalize_temp_file(obj_req->tmpfile, obj_req->filename, 0444);
if (obj_req->rename == 0)
walker_say(obj_req->walker, "got %s\n", sha1_to_hex(obj_req->sha1));
@@ -429,7 +428,7 @@ static int fetch_index(struct walker *walker, struct alt_base *repo, unsigned ch
fclose(indexfile);
- return move_temp_to_file(tmpfile, filename);
+ return finalize_temp_file(tmpfile, filename, -1);
}
static int setup_index(struct walker *walker, struct alt_base *repo, unsigned char *sha1)
@@ -788,7 +787,7 @@ static int fetch_pack(struct walker *walker, struct alt_base *repo, unsigned cha
target->pack_size = ftell(packfile);
fclose(packfile);
- ret = move_temp_to_file(tmpfile, filename);
+ ret = finalize_temp_file(tmpfile, filename, -1);
if (ret)
return ret;
diff --git a/index-pack.c b/index-pack.c
index 7546822..237acd1 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -821,10 +821,9 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
get_object_directory(), sha1_to_hex(sha1));
final_pack_name = name;
}
- if (move_temp_to_file(curr_pack_name, final_pack_name))
+ if (finalize_temp_file(curr_pack_name, final_pack_name, 0444))
die("cannot store pack file");
- }
- if (from_stdin)
+ } else if (from_stdin)
chmod(final_pack_name, 0444);
if (final_index_name != curr_index_name) {
@@ -833,10 +832,10 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
get_object_directory(), sha1_to_hex(sha1));
final_index_name = name;
}
- if (move_temp_to_file(curr_index_name, final_index_name))
+ if (finalize_temp_file(curr_index_name, final_index_name, 0444))
die("cannot store index file");
- }
- chmod(final_index_name, 0444);
+ } else
+ chmod(final_index_name, 0444);
if (!from_stdin) {
printf("%s\n", sha1_to_hex(sha1));
diff --git a/sha1_file.c b/sha1_file.c
index 12e0dfd..3c611f4 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2215,13 +2215,8 @@ static void write_sha1_file_prepare(const void *buf, unsigned long len,
git_SHA1_Final(sha1, &c);
}
-/*
- * Move the just written object into its final resting place.
- * NEEDSWORK: this should be renamed to finalize_temp_file() as
- * "moving" is only a part of what it does, when no patch between
- * master to pu changes the call sites of this function.
- */
-int move_temp_to_file(const char *tmpfile, const char *filename)
+/* Move the just written object into its final resting place. */
+int finalize_temp_file(const char *tmpfile, const char *filename, int mode)
{
int ret = 0;
@@ -2252,8 +2247,10 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
/* FIXME!!! Collision check here ? */
}
+ if (mode > 0 && chmod(filename, mode))
+ return error("unable to set permission %04o on '%s'", mode, filename);
if (adjust_shared_perm(filename))
- return error("unable to set permission to '%s'", filename);
+ return error("unable to adjust permission on '%s'", filename);
return 0;
}
@@ -2278,7 +2275,6 @@ static void close_sha1_file(int fd)
{
if (fsync_object_files)
fsync_or_die(fd, "sha1 file");
- fchmod(fd, 0444);
if (close(fd) != 0)
die("error when closing sha1 file (%s)", strerror(errno));
}
@@ -2386,7 +2382,7 @@ static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
tmpfile, strerror(errno));
}
- return move_temp_to_file(tmpfile, filename);
+ return finalize_temp_file(tmpfile, filename, 0444);
}
int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *returnsha1)
----------------------->8-------------8<-------------------
In the above patch, I've passed mode == -1 to finalize_temp_file() from all
callsites where there was no corresponding (f)chmod(foo, 0444). However,
after looking at the context (these are all either packs or loose objects),
I'm wondering if we shouldn't pass mode == 0444 for all of these. At which
point we could replace the above patch with this much simpler version:
----------------------->8-------------8<-------------------
diff --git a/fast-import.c b/fast-import.c
index beeac0d..1df3e86 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -902,9 +902,6 @@ static char *keep_pack(char *curr_index_name)
static const char *keep_msg = "fast-import";
int keep_fd;
- chmod(pack_data->pack_name, 0444);
- chmod(curr_index_name, 0444);
-
keep_fd = odb_pack_keep(name, sizeof(name), pack_data->sha1);
if (keep_fd < 0)
die("cannot create keep file");
diff --git a/http-push.c b/http-push.c
index 6ce5a1d..e465b20 100644
--- a/http-push.c
+++ b/http-push.c
@@ -748,7 +748,6 @@ static void finish_request(struct transfer_request *request)
aborted = 1;
}
} else if (request->state == RUN_FETCH_LOOSE) {
- fchmod(request->local_fileno, 0444);
close(request->local_fileno); request->local_fileno = -1;
if (request->curl_result != CURLE_OK &&
diff --git a/http-walker.c b/http-walker.c
index 0dbad3c..c5a3ea3 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -231,7 +231,6 @@ static void finish_object_request(struct object_request *obj_req)
{
struct stat st;
- fchmod(obj_req->local, 0444);
close(obj_req->local); obj_req->local = -1;
if (obj_req->http_code == 416) {
diff --git a/index-pack.c b/index-pack.c
index 7546822..6e93ee6 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -823,8 +823,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
}
if (move_temp_to_file(curr_pack_name, final_pack_name))
die("cannot store pack file");
- }
- if (from_stdin)
+ } else if (from_stdin)
chmod(final_pack_name, 0444);
if (final_index_name != curr_index_name) {
@@ -835,8 +834,8 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
}
if (move_temp_to_file(curr_index_name, final_index_name))
die("cannot store index file");
- }
- chmod(final_index_name, 0444);
+ } else
+ chmod(final_index_name, 0444);
if (!from_stdin) {
printf("%s\n", sha1_to_hex(sha1));
diff --git a/sha1_file.c b/sha1_file.c
index 12e0dfd..87ac53b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2252,7 +2252,7 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
/* FIXME!!! Collision check here ? */
}
- if (adjust_shared_perm(filename))
+ if (chmod(filename, 0444) || adjust_shared_perm(filename))
return error("unable to set permission to '%s'", filename);
return 0;
}
@@ -2278,7 +2278,6 @@ static void close_sha1_file(int fd)
{
if (fsync_object_files)
fsync_or_die(fd, "sha1 file");
- fchmod(fd, 0444);
if (close(fd) != 0)
die("error when closing sha1 file (%s)", strerror(errno));
}
----------------------->8-------------8<-------------------
(We could also add an optional "mode" argument to adjust_shared_perm(), to
get rid of the double chmod().)
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply related
* Re: Test that every revision builds before pushing changes?
From: Andreas Ericsson @ 2009-03-26 9:46 UTC (permalink / raw)
To: Daniel Pittman; +Cc: git
In-Reply-To: <87ljqs7ioz.fsf@rimspace.net>
Daniel Pittman wrote:
> Andreas Ericsson <ae@op5.se> writes:
>> Daniel Pittman wrote:
>>> I would like to ensure that my commits are fully bisectable before I
>>> commit them to an upstream repository, at least to the limits of an
>>> automatic tool for testing them.
>>>
>>> 'git bisect run' is similar: it can automatically locate the breaking in
>>> a test suite, for example, but that doesn't help me in the case of three
>>> commits, A (good), B (bad) and C (good, fixing B).
>>>
>>> I would much rather, in this case, use rebase to fix B so that it, too,
>>> builds before I push the changes and pollute a public repository with a
>>> broken changeset — and make bisect that much harder to use in future.
>> You can do that, but it requires manual work too. The trick is to make
>> the release branch immutable on the public repository and use topic
>> branches with per-developer namespaces. The per-developer namespace
>> thing is actually important, as it leaves the freedom to rewind and
>> recreate topics to the developers (which shared branches do not).
>>
>> The manual step comes at merge-time; Someone has to be responsible for
>> merging all the topics that are to be included in the release branch
>> and make sure it builds and passes all tests after each merge.
>
> Ah. You have not quite grasped what I was looking for: I was after a
> tool to help automate that step, rather than a workflow around it.
>
Oh right. Sorry, I'm stuck in continuous-integration land where people
tend to want the server to take care of such things.
> For example, the responsible person for that testing could use the
> hypothetical (until someone tells me where to find it):
>
> git test public..test make test
>
> Which would then effectively wrap:
>
> for each revision between public and private:
> git checkout revision
> make test
> # report if that fails, allow fixing the commit or whatever
> # then 'git test continue' to carry on...
>
> That turn the process from a manual one to an automated one: it runs
> that command for every revision until it fails, or until they all pass.
>
Something like this?
--%<--%<--
#!/bin/sh
git stash
revspec="$1"
shift
for rev in $(git rev-list "$revspec"); do
git checkout $rev
"$@" || break
done
--%<--%<--
Run it as such:
./git-test.sh public..test make test
Adding support for "continue" in there shouldn't be hard, since
you'd just replace the first rev with the first parent of the
last tested revision, although if you want to fix up a commit
in the middle, you'd have to manually rebase the other ones
onto the newly created commit (again, not very hard but I'll
leave both as an exercise to you).
It doesn't handle merges very nicely, btw, but I guess this
should be run prior to merging anyways.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Question: Is it possible to host a writable git repo over both http and ssh?
From: Rogan Dawes @ 2009-03-26 9:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jeff King, Mike Gaffney, Shawn O. Pearce, git
In-Reply-To: <200903260618.33019.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> torsdag 26 mars 2009 05:56:51 skrev Jeff King <peff@peff.net>:
>> On Wed, Mar 25, 2009 at 11:55:29PM -0500, Mike Gaffney wrote:
>>
>>> I'm actually trying to take what Sean did with gerrit and extract a
>>> full Java/MinaSSHD based server that doesn't require a real user
>>> account and is configurable by spring. So yes, I'm using JGit on the
>>> server.
>> Ah. In that case, I don't know whether JGit respects all hooks. You
>> should ask Shawn (Shawn, we are talking about a post-update to run
>> update-server-info). :)
>
> Arguably it should. but it doesn't. Then there is a question as to what
> format those hooks should be. Shell scripts would run into platform
> issues and jgit based stuff should have as little as possible of that, but
> a similar mechanism should exist.
>
> -- robin
>
Maybe support executing scripts via Bean Scripting Framework?
That would allow scripts to be written in any of the supported
languages, as long as the appropriate interpreter is present.
e.g. BeanShell, Groovy, Jython, etc
See http://jakarta.apache.org/bsf/
If you define an interface for each hook, the scripts could implement
the interface, and execute that way.
Here is an example, mishmashed from
<http://www.beanshell.org/examples/actionhandler.html> and
<http://jvm-languages.com/wiki/Bean_Scripting_Framework#Interacting_with_Complex_Objects>:
======8x===== Java code =========
public class BSFFileUtils
{
public Object evalFile (BSFManager manager, File file)
throws IOException
{
String fileName = file.getPath();
String language = manager.getLangFromFilename(fileName);
String code = extractFileContents(file);
return manager.eval(language, fileName, 0, 0, code);
}
private String extractFileContents (File file)
throws IOException
{
StringBuffer buf = new StringBuffer();
BufferedReader r = new BufferedReader(new FileReader(file));
try {
int len;
char[] chars = new char[8192];
while ((len = r.read(chars, 0, chars.length)) != -1) {
buf.append(chars, 0, len);
}
return buf.toString();
} finally {
r.close();
}
}
}
public static void main (String[] args)
{
String directory = args[0];
File file = new File("actionHandler.bsh");
BSFManager manager = new BSFManager();
ActionListener listener = (ActionListener)
BSFFileUtils.evalFile(manager, file);
JButton button = new JButton("MyButton");
button.addActionListener(listener);
JFrame f = new JFrame();
f.getContentPane().add( button );
f.show();
}
======8x===== BeanShell code ========= actionHandler.bsh
import java.awt.event.ActionListener;
actionPerformed( e ) {
print("Button Pressed: " + e);
}
return (ActionListener)this;
======8x==============================
Having said all this, it is probably worth implementing
update-server-info in Java, so as to avoid having to shell out to
perform this action, and keep it all platform-independent.
Rogan
^ permalink raw reply
* Re: Test that every revision builds before pushing changes?
From: Jeff King @ 2009-03-26 9:49 UTC (permalink / raw)
To: Daniel Pittman; +Cc: git
In-Reply-To: <87ljqs7ioz.fsf@rimspace.net>
On Thu, Mar 26, 2009 at 08:10:52PM +1100, Daniel Pittman wrote:
> For example, the responsible person for that testing could use the
> hypothetical (until someone tells me where to find it):
>
> git test public..test make test
>
> Which would then effectively wrap:
>
> for each revision between public and private:
> git checkout revision
> make test
> # report if that fails, allow fixing the commit or whatever
> # then 'git test continue' to carry on...
>
> That turn the process from a manual one to an automated one: it runs
> that command for every revision until it fails, or until they all pass.
I don't think such a script exists. There are continuous integration
systems that support git, but I don't know if they actually check every
commit.
-Peff
^ permalink raw reply
* [PATCH v3] init: support --import to add all files and commit right after init
From: Nguyễn Thái Ngọc Duy @ 2009-03-26 9:49 UTC (permalink / raw)
To: git, Johannes Schindelin, Jeff King; +Cc: Nguyễn Thái Ngọc Duy
This is equivalent to "git init;git add .;git commit -q -m blah".
I find myself doing that too many times, hence this shortcut.
In future, --fast-import support would also be nice if the import
directory has a lot of files.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Hopefully I don't make any mistake this time. -m will not take any argument
for two reasons:
- optional argument for short options does not appear anywhere in git AFAIK.
let's not make parse-opt migration more difficult with -mfoo or -m=foo
- you want it short, so make it short :) if you want your own message, you
probably won't mind typing a few more: --import=blah
Documentation/git-init.txt | 17 ++++++++++++++++-
builtin-init-db.c | 44 ++++++++++++++++++++++++++++++++++++++++----
t/t0001-init.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 100 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 71749c0..52bc34a 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -8,7 +8,8 @@ git-init - Create an empty git repository or reinitialize an existing one
SYNOPSIS
--------
-'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
+'git init' [-q | --quiet] [--bare] [--template=<template_directory>]
+ [--shared[=<permissions>]] [-m | --import[=<message>]]
OPTIONS
@@ -68,6 +69,20 @@ By default, the configuration flag receive.denyNonFastForwards is enabled
in shared repositories, so that you cannot force a non fast-forwarding push
into it.
+-m::
+--import[=<message>]::
+
+Commit everything to the newly initialized repository. This is equivalent to:
+
+----------------
+$ git init
+$ git add .
+$ git commit -q -m <message>
+----------------
+
+If `-m` is used or no message is given to `--import`, "Initial commit" will be used.
+This option does not work with `--bare` nor already initialized repository.
+
--
diff --git a/builtin-init-db.c b/builtin-init-db.c
index ee3911f..c787909 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -6,6 +6,7 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
+#include "run-command.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
@@ -19,6 +20,7 @@
static int init_is_bare_repository = 0;
static int init_shared_repository = -1;
+static int reinit;
static void safe_create_dir(const char *dir, int share)
{
@@ -279,7 +281,7 @@ int init_db(const char *template_dir, unsigned int flags)
{
const char *sha1_dir;
char *path;
- int len, reinit;
+ int len;
safe_create_dir(get_git_dir(), 0);
@@ -363,8 +365,29 @@ static int guess_repository_type(const char *git_dir)
return 1;
}
+static int import_files(const char *import_message)
+{
+ const char *args[6];
+ int i = 0;
+ int ret;
+
+ args[i++] = "add";
+ args[i++] = ".";
+ args[i] = NULL;
+ ret = run_command_v_opt(args, RUN_GIT_CMD);
+ if (ret)
+ return ret;
+ i = 0;
+ args[i++] = "commit";
+ args[i++] = "-q";
+ args[i++] = "-m";
+ args[i++] = import_message;
+ args[i] = NULL;
+ return run_command_v_opt(args, RUN_GIT_CMD);
+}
+
static const char init_db_usage[] =
-"git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]]";
+"git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]] [-m|--import[=<message>]]";
/*
* If you want to, you can share the DB area with any number of branches.
@@ -377,7 +400,8 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
const char *git_dir;
const char *template_dir = NULL;
unsigned int flags = 0;
- int i;
+ const char *import_message = NULL;
+ int ret, i;
for (i = 1; i < argc; i++, argv++) {
const char *arg = argv[1];
@@ -392,12 +416,19 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
init_shared_repository = PERM_GROUP;
else if (!prefixcmp(arg, "--shared="))
init_shared_repository = git_config_perm("arg", arg+9);
+ else if (!strcmp(arg, "--import") || !strcmp(arg, "-m"))
+ import_message = "Initial commit";
+ else if (!prefixcmp(arg, "--import="))
+ import_message = arg+9;
else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
flags |= INIT_DB_QUIET;
else
usage(init_db_usage);
}
+ if (import_message && is_bare_repository_cfg == 1)
+ die("--import does not work with --bare");
+
/*
* GIT_WORK_TREE makes sense only in conjunction with GIT_DIR
* without --bare. Catch the error early.
@@ -440,5 +471,10 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
set_git_dir(make_absolute_path(git_dir));
- return init_db(template_dir, flags);
+ ret = init_db(template_dir, flags);
+ if (ret || !import_message)
+ return ret;
+ if (reinit)
+ die("--import does not work with already initialized repository");
+ return import_files(import_message);
}
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 5ac0a27..b8e8bfc 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -199,4 +199,48 @@ test_expect_success 'init honors global core.sharedRepository' '
x`git config -f shared-honor-global/.git/config core.sharedRepository`
'
+test_expect_success 'init --import does not work with --bare' '
+ (
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ mkdir init-import-bare.git &&
+ cd init-import-bare.git &&
+ ! git init --bare --import
+ )
+
+'
+
+test_expect_success 'init --import no message' '
+ (
+ test_tick
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ mkdir init-import-nomsg &&
+ cd init-import-nomsg &&
+ touch foo bar &&
+ git init --import &&
+ test "$(git rev-parse HEAD)" = 4ff955458fd61a7b5d798b81e28c9249e8ebb5df
+ )
+'
+
+test_expect_success 'init --import=msg' '
+ (
+ test_tick
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ mkdir init-import &&
+ cd init-import &&
+ touch foo bar &&
+ git init --import=test &&
+ test "$(git rev-parse HEAD)" = 758aa5a579e42200a6fd4e4964c7e1dc1875d67d
+ )
+'
+
+test_expect_success 'init --import on already init(ed) should fail' '
+ (
+ test_tick
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ cd init-import &&
+ ! git init --import=testagain &&
+ test "$(git rev-parse HEAD)" = 758aa5a579e42200a6fd4e4964c7e1dc1875d67d
+ )
+'
+
test_done
--
1.6.1.446.gc7851
^ permalink raw reply related
* Re: [PATCH v3] init: support --import to add all files and commit right after init
From: Jeff King @ 2009-03-26 9:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <1238060943-4694-1-git-send-email-pclouds@gmail.com>
On Thu, Mar 26, 2009 at 08:49:03PM +1100, Nguyễn Thái Ngọc Duy wrote:
> This is equivalent to "git init;git add .;git commit -q -m blah".
> I find myself doing that too many times, hence this shortcut.
This version looks OK to me, but I have a few comments:
> Hopefully I don't make any mistake this time. -m will not take any argument
> for two reasons:
>
> - optional argument for short options does not appear anywhere in git AFAIK.
> let's not make parse-opt migration more difficult with -mfoo or -m=foo
shortlog's -w has optional arguments (and is the option that spawned the
discussion that led to Pierre writing the gitcli(7) text, IIRC). So
parse-options does handle it, but you _cannot_ say "-m foo" anymore.
> +-m::
> +--import[=<message>]::
Nit: -m made sense when it specified a message. But now that it doesn't
take a message, maybe "-i" would be more appropriate?
> +If `-m` is used or no message is given to `--import`, "Initial commit" will be used.
Style nit: long line.
-Peff
^ permalink raw reply
* Re: [BUG?] How to make a shared/restricted repo?
From: Johannes Sixt @ 2009-03-26 9:58 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <200903261044.58140.johan@herland.net>
Johan Herland schrieb:
> In the above patch, I've passed mode == -1 to finalize_temp_file() from all
> callsites where there was no corresponding (f)chmod(foo, 0444). However,
> after looking at the context (these are all either packs or loose objects),
> I'm wondering if we shouldn't pass mode == 0444 for all of these. At which
> point we could replace the above patch with this much simpler version:
Indeed!
> (We could also add an optional "mode" argument to adjust_shared_perm(), to
> get rid of the double chmod().)
And I think you should do that, otherwise you have a short time window
where the permissions of a pack or loose object is less restrictive than
you want.
-- Hannes
^ permalink raw reply
* Re: Test that every revision builds before pushing changes?
From: Wincent Colaiuta @ 2009-03-26 9:59 UTC (permalink / raw)
To: Jeff King; +Cc: Daniel Pittman, git
In-Reply-To: <20090326094900.GC14292@coredump.intra.peff.net>
El 26/3/2009, a las 10:49, Jeff King escribió:
> On Thu, Mar 26, 2009 at 08:10:52PM +1100, Daniel Pittman wrote:
>
>> For example, the responsible person for that testing could use the
>> hypothetical (until someone tells me where to find it):
>>
>> git test public..test make test
>>
>> Which would then effectively wrap:
>>
>> for each revision between public and private:
>> git checkout revision
>> make test
>> # report if that fails, allow fixing the commit or whatever
>> # then 'git test continue' to carry on...
>>
>> That turn the process from a manual one to an automated one: it runs
>> that command for every revision until it fails, or until they all
>> pass.
>
> I don't think such a script exists. There are continuous integration
> systems that support git, but I don't know if they actually check
> every
> commit.
It shouldn't be too hard to put together a script that does exactly
what you want.
A couple of years ago I whipped up a simple script (see below) to test
all the commits on a topic branch before submitting them upstream.
It's designed for that specific case, and I'm neither a shell nor a
plumbing expert, but it worked for my simple workflow at least.
Cheers,
Wincent
die () {
echo "$1"
exit 1
}
git diff --quiet || die "Unstaged changes; won't start"
git diff --cached --quiet || die "Staged changes; won't start"
# parse HEAD (something like "ref: refs/heads/my_local_branch") to get
remote and merge
GIT_DIR=$(git rev-parse --git-dir)
TOPIC="$GIT_DIR/HEAD"
test -f "$TOPIC" || die "No HEAD found at '$TOPIC'"
BRANCH_REF=$(< "$TOPIC")
if [ "${BRANCH_REF%%: */*}" != "ref" ]; then
die "expected HEAD '$BRANCH_REF' to be of the form 'ref: .../...'"
fi
BRANCH=${BRANCH_REF##*/}
REMOTE=$(git config branch.$BRANCH.remote) || die "failed to get
branch.$BRANCH.remote"
MERGE=$(git config branch.$BRANCH.merge) || die "failed to get branch.
$BRANCH.merge"
MERGE=${MERGE##*/}
# remember which branch we were on prior to starting
trap 'git checkout $BRANCH' exit
# will check all commits in topic branch not present in origin
# (note: may be more appropriate to use "git merge-base" here)
echo "On branch $BRANCH"
echo "Commits to be checked:"
git rev-list --pretty=oneline HEAD ^$REMOTE/$MERGE
for COMMIT in $(git rev-list HEAD ^$REMOTE/$MERGE); do
echo "Checking $COMMIT"
git checkout $COMMIT
make clean
make test || die "Commit $COMMIT is bad (make test failed)"
done
echo "All revisions passed!"
^ permalink raw reply
* [PATCH 1/2] init: support --import to add all files and commit right after init
From: Nguyễn Thái Ngọc Duy @ 2009-03-26 10:10 UTC (permalink / raw)
To: git, Johannes Schindelin, Jeff King; +Cc: Nguyễn Thái Ngọc Duy
This is equivalent to "git init;git add .;git commit -q -m blah".
I find myself doing that too many times, hence this shortcut.
In future, --fast-import support would also be nice if the import
directory has a lot of files.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
> > +-m::
> > +--import[=<message>]::
>
> Nit: -m made sense when it specified a message. But now that it doesn't
> take a message, maybe "-i" would be more appropriate?
Makes sense.
Documentation/git-init.txt | 18 +++++++++++++++++-
builtin-init-db.c | 44 ++++++++++++++++++++++++++++++++++++++++----
t/t0001-init.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 101 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 71749c0..1df07c2 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -8,7 +8,8 @@ git-init - Create an empty git repository or reinitialize an existing one
SYNOPSIS
--------
-'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
+'git init' [-q | --quiet] [--bare] [--template=<template_directory>]
+ [--shared[=<permissions>]] [-i | --import[=<message>]]
OPTIONS
@@ -68,6 +69,21 @@ By default, the configuration flag receive.denyNonFastForwards is enabled
in shared repositories, so that you cannot force a non fast-forwarding push
into it.
+-i::
+--import[=<message>]::
+
+Commit everything to the newly initialized repository. This is equivalent to:
+
+----------------
+$ git init
+$ git add .
+$ git commit -q -m <message>
+----------------
+
+If `-i` is used or no message is given to `--import`, "Initial commit" will be
+used as the commit message.
+This option does not work with `--bare` nor already initialized repository.
+
--
diff --git a/builtin-init-db.c b/builtin-init-db.c
index ee3911f..ff6a141 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -6,6 +6,7 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
+#include "run-command.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
@@ -19,6 +20,7 @@
static int init_is_bare_repository = 0;
static int init_shared_repository = -1;
+static int reinit;
static void safe_create_dir(const char *dir, int share)
{
@@ -279,7 +281,7 @@ int init_db(const char *template_dir, unsigned int flags)
{
const char *sha1_dir;
char *path;
- int len, reinit;
+ int len;
safe_create_dir(get_git_dir(), 0);
@@ -363,8 +365,29 @@ static int guess_repository_type(const char *git_dir)
return 1;
}
+static int import_files(const char *import_message)
+{
+ const char *args[6];
+ int i = 0;
+ int ret;
+
+ args[i++] = "add";
+ args[i++] = ".";
+ args[i] = NULL;
+ ret = run_command_v_opt(args, RUN_GIT_CMD);
+ if (ret)
+ return ret;
+ i = 0;
+ args[i++] = "commit";
+ args[i++] = "-q";
+ args[i++] = "-m";
+ args[i++] = import_message;
+ args[i] = NULL;
+ return run_command_v_opt(args, RUN_GIT_CMD);
+}
+
static const char init_db_usage[] =
-"git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]]";
+"git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]] [-i|--import[=<message>]]";
/*
* If you want to, you can share the DB area with any number of branches.
@@ -377,7 +400,8 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
const char *git_dir;
const char *template_dir = NULL;
unsigned int flags = 0;
- int i;
+ const char *import_message = NULL;
+ int ret, i;
for (i = 1; i < argc; i++, argv++) {
const char *arg = argv[1];
@@ -392,12 +416,19 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
init_shared_repository = PERM_GROUP;
else if (!prefixcmp(arg, "--shared="))
init_shared_repository = git_config_perm("arg", arg+9);
+ else if (!strcmp(arg, "--import") || !strcmp(arg, "-i"))
+ import_message = "Initial commit";
+ else if (!prefixcmp(arg, "--import="))
+ import_message = arg+9;
else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
flags |= INIT_DB_QUIET;
else
usage(init_db_usage);
}
+ if (import_message && is_bare_repository_cfg == 1)
+ die("--import does not work with --bare");
+
/*
* GIT_WORK_TREE makes sense only in conjunction with GIT_DIR
* without --bare. Catch the error early.
@@ -440,5 +471,10 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
set_git_dir(make_absolute_path(git_dir));
- return init_db(template_dir, flags);
+ ret = init_db(template_dir, flags);
+ if (ret || !import_message)
+ return ret;
+ if (reinit)
+ die("--import does not work with already initialized repository");
+ return import_files(import_message);
}
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 5ac0a27..b8e8bfc 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -199,4 +199,48 @@ test_expect_success 'init honors global core.sharedRepository' '
x`git config -f shared-honor-global/.git/config core.sharedRepository`
'
+test_expect_success 'init --import does not work with --bare' '
+ (
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ mkdir init-import-bare.git &&
+ cd init-import-bare.git &&
+ ! git init --bare --import
+ )
+
+'
+
+test_expect_success 'init --import no message' '
+ (
+ test_tick
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ mkdir init-import-nomsg &&
+ cd init-import-nomsg &&
+ touch foo bar &&
+ git init --import &&
+ test "$(git rev-parse HEAD)" = 4ff955458fd61a7b5d798b81e28c9249e8ebb5df
+ )
+'
+
+test_expect_success 'init --import=msg' '
+ (
+ test_tick
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ mkdir init-import &&
+ cd init-import &&
+ touch foo bar &&
+ git init --import=test &&
+ test "$(git rev-parse HEAD)" = 758aa5a579e42200a6fd4e4964c7e1dc1875d67d
+ )
+'
+
+test_expect_success 'init --import on already init(ed) should fail' '
+ (
+ test_tick
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ cd init-import &&
+ ! git init --import=testagain &&
+ test "$(git rev-parse HEAD)" = 758aa5a579e42200a6fd4e4964c7e1dc1875d67d
+ )
+'
+
test_done
--
1.6.1.446.gc7851
^ permalink raw reply related
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Jeff King @ 2009-03-26 10:13 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <1238062203-5809-1-git-send-email-pclouds@gmail.com>
On Thu, Mar 26, 2009 at 09:10:03PM +1100, Nguyễn Thái Ngọc Duy wrote:
> This is equivalent to "git init;git add .;git commit -q -m blah".
> I find myself doing that too many times, hence this shortcut.
>
> In future, --fast-import support would also be nice if the import
> directory has a lot of files.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
This version looks good to me. Thanks.
-Peff
^ permalink raw reply
* svn clone Checksum mismatch question
From: Gilbert Liddell @ 2009-03-26 10:31 UTC (permalink / raw)
To: git
Hi,
I've just started using GIT this week, currently the project i'm working on
is held in subversion. I tested git svn clone with a small test project
(about 10 files) which worked a treat.
This morning i decided to test the clone with the full project i'm working
on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
got: e71db1010a0da06ea76d4163c452df72
Can someone help with why this error is happening? Is there an issue with
the GIT clone and large repositories?
Thanks in advance for your help,
Gilbert.
--
View this message in context: http://www.nabble.com/svn-clone-Checksum-mismatch-question-tp22719363p22719363.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [StGit PATCH] Add the --merged option to goto
From: Karl Hasselström @ 2009-03-26 11:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0903250324j9ed0ed9k2d97cbacba6a7801@mail.gmail.com>
On 2009-03-25 10:24:13 +0000, Catalin Marinas wrote:
> BTW, why don't we keep the tree information directly in the Index
> object? Since this object is modified only via its own interface, it
> can do all the checks and avoid the managing of temp_index_tree in
> the Transaction object.
I guess that might be a good idea -- it should be doable without any
extra overhead for users that don't want it.
> Yes. But it may be even better to do this in Index.
> Index.apply_treediff() would set the tree to None and read_tree or
> write_tree would set it to the corresponding tree.
We'd have to cover the other index operations too. But yes, this is
probably a good idea.
> > 3. Why are empty patches considered not merged?
>
> They would be reported as empty anyway and in general you don't
> submit empty patches for upstream merging.
Ah, duh. I was forgetting what the "merged" detection was for in the
first place.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* git fsk is reporting problems that don't exist
From: Mauro Carvalho Chehab @ 2009-03-26 11:51 UTC (permalink / raw)
To: git
git fsck (version 1.6.1.1) is reporting a nonexistent troubles on some of
my trees.
For example, those are the results for my
kernel.org /pub/scm/linux/kernel/git/mchehab/linux-2.6.git tree:
$ git fsck
missing tree 3afa5c9eace50837f3c31238102358cf67b8a1ff
missing commit 87c3a86e1c220121d0ced59d1a71e78ed9abc6dd
Both objects exist on this tree.
Also, if we run fsck with --full, those missing objects disappear:
$ git fsck --full
dangling tag b65a80a5ee7923355cbca669cead08e067fc7ada
dangling tag 6fa7003fe34e9a8a31fb91754f3c289cc045564b
dangling tag 8be00154b8e949bf4b89ac198aef9a247532ac2d
dangling tag b503092a16bdba0a418e155fe592521fc20855af
dangling tag 5eb14db1f80df4eb0ecb0976e47e8e287e3175fc
dangling tag 31cb515c75388d457c2f318a0ee9606b3527852f
dangling tag 0715562512ca6cf14c1b8f08e09d5907118deaf0
dangling tag 68185b00cf91c1c4dcc761a2f3a1631562ed52f3
dangling tag 7d4b1bcc5e7411fc9e63f610c16e5de8fe6dfde8
dangling tag 7a3862d6e9934ffe107fe7ddfbe2c63dba321793
dangling tag 1dcda2df87ba4ecc7988be7a45d01645e11c9f4c
dangling tag 8a38e7fd7a30cd44be954f9a3b062e607cec5d41
dangling tag d31ce8060b0e875179ba5ca1d40475dc2a082cc7
dangling tag 87c16e9e8bb74f14f4504305957e4346e7fc46ea
dangling tag b21232ea962bbaf0e909365f4964f6cceb2ba8ce
dangling tag 5dfd736f95b3d84a18b5bb8e50ac71f245438acf
dangling tag cb50773491b0066d0e55f31f8875d5678fa3f8ad
dangling tag 73e37758f6b500a67d918528204832cc8f256516
dangling tag 1a0bff987b27da5181f112bcc60f34d6fbb7e67e
Could this be fixed? It is very annoying to have it reporting a nonexistent
problem.
Cheers,
Mauro
^ permalink raw reply
* Re: [PATCH 01/10] refs: add "for_each_bisect_ref" function
From: Sverre Rabbelier @ 2009-03-26 12:37 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git, John Tapsell, Johannes Schindelin
In-Reply-To: <200903260848.42104.chriscool@tuxfamily.org>
Heya,
On Thu, Mar 26, 2009 at 08:48, Christian Couder <chriscool@tuxfamily.org> wrote:
> I am not a big fan of cover letters. Usually I prefer adding comments in the
> patches.
The downside of that is that it makes it harder to quickly scan the
series; now I have to go through each patch (which involves trying
finding which patch is next, as my MUA is retarded and doesn't
understand proper threading).
>> And no description of the
>> individual patches either!
>
> There is a commit message in each patch. And many of the patches are very
> small.
Hehe, my bad; the first one didn't have a commit message, which is the
one I looked at first.
> If some commit messages are not clear enough, please tell me and I will try
> to improve them ;)
The rest of the series is nicely readable, I guess I shouldn't send
whine mails before reading the entire series next time :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Improve tags
From: Etienne Vallette d'Osia @ 2009-03-26 12:48 UTC (permalink / raw)
To: git
Hi,
I search a way to track commits in function of their aim.
I tried to use branches (test, debugger, etc).
For example if I search the commits related to tests,
I can search all commits what are in branch test and not in branch debugger,
but it's boring (I need to exclude all other branches than test)
Moreover, if I remove a branch, it will complicate the search.
In addition, branches are a way to specify streams,
not a way to specify an aim for a commit.
(like in ruby a class is a method container, not a type)
So branch names are often like next, pu, dev, test, stupid-idea, etc.
They are totally useless for tracking aims.
The method used in every repositories I looked into
is to use the "aim: subject" form in their commit messages.
So search all commits related to a specific aim is equivalent
to grep "my-aim:" in commit messages.
The problem is that this method is not used in all commits
("aim - subject" or just "subject" are used too),
so I can't assume to find all commits with a such method...
And if a search a more generic form ("test"), I might find
useless commits that will pollute my results...
The last method I can find, is to use tags.
But, as CVS and many others do, tags are unique.
It is usefull for tagging a software version number,
but not for tracking.
So, we have branches, which are not stable,
tags, which are unique,
and commit messages, which are not normalized.
What can we do ?
In my mind, the good ways are to improve the commit message way,
or, better, to change the current tag concept.
One improvement could be to add a mechanism similar to "signed-off-by:"
message: add an option in git-commit to facilitate the creation of "tags"
and make sure these "tags" will be normalized...
example: `git commit -t test,debugger -m "add test for debugger"`
this will create a commit and add automatically
"test: debugger:" at begin or
"tags: test, debugger" at end of the message
(like the "signed-off-by: xxx" lines)
It's not really better this current solution,
but it's a first step to normalization.
There is still a big problem with this solution : this tags are immutable,
as they are stored inside the commit.
An other improvement would be to create new version of tags.
`git tag v1.6.3` would create a unique tag, and
`git tag --no-unique test` would create a simple tag.
(until we can change the default)
The -t option of git-commit is still possible,
but it will call the new git-tag.
Note: Theses tags may be treated like refs (git log fault-tolerance),
but they can't be stored in $GIT_DIR/refs directory,
as they reference a list a commits...
So, I see 2 solutions:
- Normalize the way to write tags but keep them into commit message:
(-) There will be 2 sorts of tags: static immutable and dynamic unique
(+) This way is totally retro-compatible
- Change the tags concept:
(-) Need to change the tag object format (ouch)
(+) More powerful
Maybe I have missed a better tool to do my job ?
Or there is a better improvement which is more simple ?
Best regards,
Etienne Vallette d'Osia
ps: I'm really sorry if my message is full of English errors...
^ permalink raw reply
* Re: branch ahead in commits but push claims all up to date
From: Björn Steinbrink @ 2009-03-26 12:48 UTC (permalink / raw)
To: John Tapsell; +Cc: Irene Ros, Daniel Barkalow, git
In-Reply-To: <43d8ce650903251905p6f9798f5u79be7dff3b118d5c@mail.gmail.com>
On 2009.03.26 02:05:21 +0000, John Tapsell wrote:
> 2009/3/25 Irene Ros <imirene@gmail.com>:
> > Thank you for the explanation, doing a git fetch actually did do the
> > trick although I still don't quite see the difference between
> > git pull origin myBranch
> > and
> > git fetch
>
> git pull origin myBranch is equivalent to two commands:
>
> git fetch
> git merge origin/myBranch
No. If that was the case, the remote tracking branches would be updated
by the "git fetch" part. And there wouldn't be a difference between the
two commands WRT the handling of remote tracking branches.
git pull origin myBranch does something like:
git fetch origin myBranch
git merge FETCH_HEAD
The remote and the refspec are passed to "git fetch" by "git pull".
So because there's an explicit refspec, the default value from the
config is not used. And because the refspec has no right side, things
get stored to FETCH_HEAD.
Björn
^ permalink raw reply
* Re: svn clone Checksum mismatch question
From: Björn Steinbrink @ 2009-03-26 13:02 UTC (permalink / raw)
To: Gilbert Liddell; +Cc: git
In-Reply-To: <22719363.post@talk.nabble.com>
On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
> This morning i decided to test the clone with the full project i'm working
> on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
> 0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
> got: e71db1010a0da06ea76d4163c452df72
>
> Can someone help with why this error is happening? Is there an issue with
> the GIT clone and large repositories?
Which git version is that? There was some bug in git-svn that caused it
to fill the disk with temporary files, without noticing that those files
get truncated when the disk is full. That was fixed in some 1.6.0.x
release IIRC.
Björn
^ permalink raw reply
* Re: Use alternate GIT servers to share traffic
From: Samuel Lucas Vaz de Mello @ 2009-03-26 13:40 UTC (permalink / raw)
To: Thomas Koch; +Cc: git
In-Reply-To: <200903252145.30226.thomas@koch.ro>
Thomas Koch wrote:
> Hi,
>
> we host a public GIT repository on our high availability company
> cluster. Cloning the repo causes a trafic volume of 326 MB. We'd like to
> avoid that much trafic while still leaving the GIT repo where it is.
>
> I could imagine the following conversation between the GIT client and
> server:
>
> Client: Wanna clone!
> Server: You're welcome. Please note, that while I serve the most current
> state, you can get objects much faster from my collegue Server
> CHEAPHOST.
> Client: Thank you. Will take all the objects I can get from CHEAPHOST
> and come back if I should need anything else!
>
> The enduser should not need to specify anything, but only the regular
> git clone EXPENSIVEHOST line.
>
> Your thoughts?
>
I have a scenario here that is (nearly) similar to what you want.
We have two development sites and we let users choose the server that is closer to them.
As all changes to these repositories are made using push, we use post-receive hooks to syncronize.
User can push no any of the servers and the changes will get replicated.
In the EXPENSIVEHOST you add the CHEAPHOST as remote and put a 'git push --mirror cheaphost' in the post-receive hook.
In the CHEAPHOST, you add EXPENSIVEHOST as remote and changes git config to make it put the references in refs/heads/* instead of refs/remotes/expensivehost/*. In the post-receive hook you add a 'git push --all expensivehost'.
Also, you need to ensure that all users can authenticate in both servers (or, in my case, I made the hook use sudo to push the updates using a special user that authenticate using ssh keys).
The drawback ares:
1) User must manually choose the closest server. (maybe some sort of round-robin DNS would do it automatically?)
2) Branch and tag deletion must be done in the EXPENSIVEHOST.
3) EXPENSIVEHOST stores the remote refs from CHEAPHOST in remotes/cheaphost/* and they are pushed back to CHEAPHOST by push --mirror. These references are not used at all, but they can cause some noise in the log message during pushes.
4) If we have two users committing to the same branch exactly at the same time in the different servers, I'm not sure about what will happen :-). As precaution, I added in CHEAPHOST a cron job that does a 'git remote update' in the repo. So, if the servers became inconsistent, it will perform a forced update from EXPENSIVEHOST to CHEAPHOST.
I have the scenario running just for a few days, so there may be some additional corner cases.
HTH,
- Samuel
^ permalink raw reply
* RE: svn clone Checksum mismatch question
From: Gilbert Liddell @ 2009-03-26 13:28 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20090326130213.GC3114@atjola.homenet>
Hi Björn,
Thanks for the reply, i'm using git version 1.6.2.msysgit.0.186.gf7512
Gilbert.
-----Original Message-----
From: Björn Steinbrink [mailto:B.Steinbrink@gmx.de]
Sent: 26 March 2009 13:02
To: Gilbert Liddell
Cc: git@vger.kernel.org
Subject: Re: svn clone Checksum mismatch question
On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
> This morning i decided to test the clone with the full project i'm working
> on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
> 0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
> got: e71db1010a0da06ea76d4163c452df72
>
> Can someone help with why this error is happening? Is there an issue with
> the GIT clone and large repositories?
Which git version is that? There was some bug in git-svn that caused it
to fill the disk with temporary files, without noticing that those files
get truncated when the disk is full. That was fixed in some 1.6.0.x
release IIRC.
Björn
Registered in Scotland
32 Fountain Drive
Inchinnan Business Park
Renfrewshire,PA4 9RF.
Company number:SC112872
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.
If you have received this e-mail in error please notify the
originator of the message. This footer also confirms that this
e-mail message has been scanned for the presence of computer viruses.
Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Total Repair Solutions.
Scanning of this message and addition of this footer is performed
by SurfControl E-mail Filter software in conjunction with
virus detection software.
^ permalink raw reply
* Re: [PATCH 1/2] Add feature release instructions to MaintNotes addendum
From: Raman Gupta @ 2009-03-26 13:51 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090326121017.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting rocketraman@fastmail.fm:
>
>> + - The 'maint' branch is updated to the new release.
>> +
>> + $ git checkout maint
>> + $ git merge master
>> +
>> + This is equivalent to deleting maint and recreating it from
>> + master, but it preserves the maint reflog.
>
> After giving a recipe that is better than an alternative, what's
> the point of describing an inferior alternative as "equivalent",
> when it is obviously not "equivalent"?
Is this better:
The resulting maint tree is equivalent to deleting maint and
recreating it from the tip of master, but merging from master
preserves the maint reflog.
Cheers,
Raman
^ 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