* Re: [PATCH/RFC] ident: check /etc/mailname if email is unknown
From: Junio C Hamano @ 2011-10-03 5:30 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Matt Kraai, Gerrit Pape, Ian Jackson, Linus Torvalds
In-Reply-To: <20111003045745.GA17604@elie>
Jonathan Nieder <jrnieder@gmail.com> writes:
> @@ -52,6 +52,8 @@ static void copy_gecos(const struct passwd *w, char *name, size_t sz)
>
> static void copy_email(const struct passwd *pw)
> {
> + FILE *mailname;
> +
> /*
> * Make up a fake email address
> * (name + '@' + hostname [+ '.' + domainname])
> @@ -61,6 +63,27 @@ static void copy_email(const struct passwd *pw)
> die("Your sysadmin must hate you!");
> memcpy(git_default_email, pw->pw_name, len);
> git_default_email[len++] = '@';
> +
> + /*
> + * The domain part comes from /etc/mailname if it is readable,
> + * or the current hostname and domain name otherwise.
> + */
> + mailname = fopen("/etc/mailname", "r");
> + if (!mailname) {
> + if (errno != ENOENT)
> + warning("cannot open /etc/mailname: %s",
> + strerror(errno));
> + } else if (fgets(git_default_email + len,
> + sizeof(git_default_email) - len, mailname)) {
> + /* success! */
> + fclose(mailname);
> + return;
> + } else {
> + if (ferror(mailname))
> + warning("cannot read /etc/mailname: %s",
> + strerror(errno));
> + fclose(mailname);
> + }
> gethostname(git_default_email + len, sizeof(git_default_email) - len);
> if (!strchr(git_default_email+len, '.')) {
> struct hostent *he = gethostbyname(git_default_email + len);
I do not think this would hurt, even though I see /etc/mailname on only
one of my boxes (i.e. Debian). For maintainability for the future,
however, I would prefer to see the above hunk separated into a helper
function to keep addition to copy_email() to the minimum, e.g.
memcpy(git_default_email, pw->pw_name, len);
git_default_email[len++] = '@';
+ if (add_mailname_host(git_default_email, len, sizeof(git_default_email)))
+ return; /* read from "/etc/mailname" (Debian) */
gethostname(git_default_email + len, sizeof(git_default_email) - len);
...
So that people who care about other distros can more easily add a single
implementation to a similar location without making copy_email() too long
to lose clarity. The fallback default logic that does gethostname() might
also want to become a separate helper function as well.
^ permalink raw reply
* Re: unable to resolve reference refs/tags/v3.1-rc8: Success
From: Larry Finger @ 2011-10-03 5:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: LKML, git
In-Reply-To: <20111003044045.GA17289@elie>
On 10/02/2011 11:40 PM, Jonathan Nieder wrote:
> Larry Finger wrote:
>
>> After applying that patch, I get
>>
>> finger@larrylap:~/linux-2.6> ~/git/git pull
>> fatal: ref refs/tags/v3.1-rc8 is corrupt: length=41, content=
>
> Great, thanks.
>
> In the short term I'd suggest just removing the corrupt
> .git/refs/tags/v3.1-rc8 file with "rm" so it can be fetched again.
> Hopefully later tonight I can prepare a real patch to fix this, though
> I wouldn't mind if someone else takes care of it first.
Thanks. That did the trick.
Larry
^ permalink raw reply
* [PATCH/RFC] ident: check /etc/mailname if email is unknown
From: Jonathan Nieder @ 2011-10-03 4:57 UTC (permalink / raw)
To: git; +Cc: Matt Kraai, Gerrit Pape, Ian Jackson, Linus Torvalds
From: Gerrit Pape <pape@smarden.org>
Before falling back to gethostname(), check /etc/mailname if
GIT_AUTHOR_EMAIL is not set in the environment or through config
files. Only fall back if /etc/mailname cannot be opened or read.
The /etc/mailname convention comes from Debian policy section 11.6
("mail transport, delivery and user agents"), though it seems more
widely useful. The lack of this support was noticed by various people
in different ways:
- Ian observed that git was choosing the address
'ian@anarres.relativity.greenend.org.uk' rather than
'ian@davenant.greenend.org.uk' as it should have done.
- Jonathan noticed that operations like "git commit" were needlessly
slow when the using a resolver that was slow to handle reverse DNS
lookups.
On the other hand, this means that if /etc/mailname is set up and the
[user] name and email configuration aren't, the committer email will
not provide a charming reminder of which machine commits were made on
any more. I think that cost is worth it.
Requested-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hi,
Debian has been using something like this patch for years now (see
<http://bugs.debian.org/448655>) but I thought it might be useful
to others, too. A similar patch visited the list three years ago:
<http://thread.gmane.org/gmane.comp.version-control.git/51800>.
Thoughts of all kinds welcome, of course.
Thanks,
Jonathan
Documentation/git-commit-tree.txt | 8 +++++++-
ident.c | 23 +++++++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index 0fdb82ee..02133d5f 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -68,7 +68,9 @@ if set:
In case (some of) these environment variables are not set, the information
is taken from the configuration items user.name and user.email, or, if not
-present, system user name and fully qualified hostname.
+present, system user name and the hostname used for outgoing mail (taken
+from `/etc/mailname` and falling back to the fully qualified hostname when
+that file does not exist).
A commit comment is read from stdin. If a changelog
entry is not provided via "<" redirection, 'git commit-tree' will just wait
@@ -90,6 +92,10 @@ Discussion
include::i18n.txt[]
+FILES
+-----
+/etc/mailname
+
SEE ALSO
--------
linkgit:git-write-tree[1]
diff --git a/ident.c b/ident.c
index 35a6f264..87f0a37e 100644
--- a/ident.c
+++ b/ident.c
@@ -52,6 +52,8 @@ static void copy_gecos(const struct passwd *w, char *name, size_t sz)
static void copy_email(const struct passwd *pw)
{
+ FILE *mailname;
+
/*
* Make up a fake email address
* (name + '@' + hostname [+ '.' + domainname])
@@ -61,6 +63,27 @@ static void copy_email(const struct passwd *pw)
die("Your sysadmin must hate you!");
memcpy(git_default_email, pw->pw_name, len);
git_default_email[len++] = '@';
+
+ /*
+ * The domain part comes from /etc/mailname if it is readable,
+ * or the current hostname and domain name otherwise.
+ */
+ mailname = fopen("/etc/mailname", "r");
+ if (!mailname) {
+ if (errno != ENOENT)
+ warning("cannot open /etc/mailname: %s",
+ strerror(errno));
+ } else if (fgets(git_default_email + len,
+ sizeof(git_default_email) - len, mailname)) {
+ /* success! */
+ fclose(mailname);
+ return;
+ } else {
+ if (ferror(mailname))
+ warning("cannot read /etc/mailname: %s",
+ strerror(errno));
+ fclose(mailname);
+ }
gethostname(git_default_email + len, sizeof(git_default_email) - len);
if (!strchr(git_default_email+len, '.')) {
struct hostent *he = gethostbyname(git_default_email + len);
--
1.7.7.rc1
^ permalink raw reply related
* Re: unable to resolve reference refs/tags/v3.1-rc8: Success
From: Jonathan Nieder @ 2011-10-03 4:40 UTC (permalink / raw)
To: Larry Finger; +Cc: LKML, git
In-Reply-To: <4E8936F4.5060506@lwfinger.net>
Larry Finger wrote:
> After applying that patch, I get
>
> finger@larrylap:~/linux-2.6> ~/git/git pull
> fatal: ref refs/tags/v3.1-rc8 is corrupt: length=41, content=
Great, thanks.
In the short term I'd suggest just removing the corrupt
.git/refs/tags/v3.1-rc8 file with "rm" so it can be fetched again.
Hopefully later tonight I can prepare a real patch to fix this, though
I wouldn't mind if someone else takes care of it first.
^ permalink raw reply
* Re: unable to resolve reference refs/tags/v3.1-rc8: Success (Re: git problem)
From: Larry Finger @ 2011-10-03 4:15 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: LKML, git
In-Reply-To: <20111003035907.GA17134@elie>
On 10/02/2011 10:59 PM, Jonathan Nieder wrote:
> Hi,
>
> Larry Finger wrote:
>
>> I had my system freeze when doing a pull from Linus's repo. Since then,
>> every pull results in the following errors:
>>
>> ~> git pull
>> error: unable to resolve reference refs/tags/v3.1-rc8: Success
>> From git://github.com/torvalds/linux
>> ! [new tag] v3.1-rc8 -> v3.1-rc8 (unable to update local ref)
>
> Could you try pulling again with
> "/path/to/git/sources/bin-wrappers/git pull" after applying this
> patch?
>
> Thanks,
>
> diff --git i/refs.c w/refs.c
> index a615043b..b15f78a4 100644
> --- i/refs.c
> +++ w/refs.c
> @@ -493,12 +493,15 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
> char *buf;
> int fd;
>
> - if (--depth< 0)
> + if (--depth< 0) {
> + errno = ELOOP;
> return NULL;
> + }
>
> git_snpath(path, sizeof(path), "%s", ref);
> /* Special case: non-existing file. */
> if (lstat(path,&st)< 0) {
> + int saved_errno = errno;
> struct ref_list *list = get_packed_refs(NULL);
> while (list) {
> if (!strcmp(ref, list->name)) {
> @@ -509,6 +512,7 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
> }
> list = list->next;
> }
> + errno = saved_errno;
> if (reading || errno != ENOENT)
> return NULL;
> hashclr(sha1);
> @@ -562,7 +566,8 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
> *flag |= REF_ISSYMREF;
> }
> if (len< 40 || get_sha1_hex(buffer, sha1))
> - return NULL;
> + die("ref %s is corrupt: length=%d, content=%.*s", ref,
> + (int) len, (int) len, buffer);
> return ref;
> }
After applying that patch, I get
finger@larrylap:~/linux-2.6> ~/git/git pull
fatal: ref refs/tags/v3.1-rc8 is corrupt: length=41, content=
Larry
^ permalink raw reply
* unable to resolve reference refs/tags/v3.1-rc8: Success (Re: git problem)
From: Jonathan Nieder @ 2011-10-03 3:59 UTC (permalink / raw)
To: Larry Finger; +Cc: LKML, git
In-Reply-To: <4E892483.7070605@lwfinger.net>
Hi,
Larry Finger wrote:
> I had my system freeze when doing a pull from Linus's repo. Since then,
> every pull results in the following errors:
>
> ~> git pull
> error: unable to resolve reference refs/tags/v3.1-rc8: Success
> From git://github.com/torvalds/linux
> ! [new tag] v3.1-rc8 -> v3.1-rc8 (unable to update local ref)
Could you try pulling again with
"/path/to/git/sources/bin-wrappers/git pull" after applying this
patch?
Thanks,
diff --git i/refs.c w/refs.c
index a615043b..b15f78a4 100644
--- i/refs.c
+++ w/refs.c
@@ -493,12 +493,15 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
char *buf;
int fd;
- if (--depth < 0)
+ if (--depth < 0) {
+ errno = ELOOP;
return NULL;
+ }
git_snpath(path, sizeof(path), "%s", ref);
/* Special case: non-existing file. */
if (lstat(path, &st) < 0) {
+ int saved_errno = errno;
struct ref_list *list = get_packed_refs(NULL);
while (list) {
if (!strcmp(ref, list->name)) {
@@ -509,6 +512,7 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
}
list = list->next;
}
+ errno = saved_errno;
if (reading || errno != ENOENT)
return NULL;
hashclr(sha1);
@@ -562,7 +566,8 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
*flag |= REF_ISSYMREF;
}
if (len < 40 || get_sha1_hex(buffer, sha1))
- return NULL;
+ die("ref %s is corrupt: length=%d, content=%.*s", ref,
+ (int) len, (int) len, buffer);
return ref;
}
^ permalink raw reply related
* Re: Branches & directories
From: Jeff King @ 2011-10-03 3:07 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Robin Rosenberg, Kyle Moffett, Michael Witten, Junio C Hamano,
Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi3bm72Rk+UYygS_bC9eh0VTPr-VQSdtBGqjgDpEzkutZw@mail.gmail.com>
On Sun, Oct 02, 2011 at 04:40:14PM -0700, Hilco Wijbenga wrote:
> That's however not the scenario that I'm talking about. I'm talking about doing
>
> git checkout branch
> git checkout master
>
> or
>
> git stash
> git stash pop
>
> In both cases all files (or at least all affected files, in case of
> git stash) get the current time as their timestamp instead of the
> timestamp they had before. This is forcing (completely unnecessary)
> rebuilds. *Nothing* has changed but I have to do a complete rebuild
> (well, I suppose I could "touch" all build artifacts and such but I'm
> sure you get the idea).
>
> I understand *why* it's happening (it's simply reusing the existing
> Git functionality) but in the scenarios above nothing has really
> changed, I should be able to pick up from where I left off, shouldn't
> I?
No. There are cases where that will fool timestamp-based tools. The
problem is that the build products are not tracked by git, and so they
are not changed when you switch branches. But the timestamps of build
products and branches are compared.
So let's imagine you have two branches, with two different versions of
foo.c, both of which use "make" to build them into foo.o. Their
timestamps are from an hour ago and two hours ago. And that git restores
those old timestamps. You do:
git checkout master
make
Now foo.c is one hour old (from master). But foo.o is only a few seconds
old (it was just created by make. Now you do:
git checkout branch
make
Now foo.c is two hours old (from branch). But foo.o is still new, so
make doesn't rebuild it, which is an error.
Or did you really mean your example literally, as in you run two
checkouts back to back, without running anything in between, and the
second checkout restores the state before the first one. In that case,
yes, it would be correct to keep the old timestamps. But this is an
optimization that can only apply in a few very specific cases. And
moreoever, how can git know when it is OK to apply that optimization? It
has no idea what commands you might have run since the last time we were
at "master".
-Peff
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-10-03 0:46 UTC (permalink / raw)
To: Michael Haggerty, Junio C Hamano
Cc: git, Christian Couder, Thomas Rast, René Scharfe,
Julian Phillips
In-Reply-To: <4E87F462.3000308@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> wrote:
>On 10/01/2011 10:41 PM, Junio C Hamano wrote:
>> Martin Fick <mfick@codeaurora.org> writes:
>>> I guess this makes sense, we invalidate the cache and have
>>> to rebuild it after every new ref is added? Perhaps a
>>> simple fix would be to move the invalidation right after all
>>> the refs are updated? Maybe write_ref_sha1 could take in a
>>> flag to tell it to not invalidate the cache so that during
>>> iterative updates it could be disabled and then run manually
>>> after the update?
>>
>I
>also have some code (not pushed) that adds some intelligence to make
>the use case
>
> repeat many times:
> check if reference exists
> add reference
Would it be possible to separate the two steps into separate loops somehow? Could it instead look like this:
> repeat many times:
> check if reference exists
> repeat many times:
> add reference
It might be difficult with the current functions to achive this, but it would allow the cache to be invalidated over and over in loop two without impacting performance since all the lookups could be done in the first loop. Of course, this would likely require checking for dups before running the first loop.
-Martin
Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-10-02 23:45 UTC (permalink / raw)
To: Matthieu Moy
Cc: Ronan Keryell, Robin Rosenberg, Kyle Moffett, Michael Witten,
Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <vpqehyvnrbj.fsf@bauges.imag.fr>
On 2 October 2011 12:09, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Ronan Keryell <Ronan.Keryell@hpc-project.com> writes:
>
>>>>>>> On Sun, 02 Oct 2011 18:57:55 +0200, Robin Rosenberg <robin.rosenberg@gmail.com> said:
>>
>> Robin> Hilco Wijbenga skrev 2011-08-22 22.10:
>> >> [...] I just wish there was at least an option to keep the
>> >> timestamp (and possibly other such things). Even Subversion can
>> >> do that... ;-) After all, not everybody uses C& make.
>
> AFAIK, Subversion doesn't version timestamps. What it can do is to set
> the timestamp to the commit date at the time the file is checked-out.
Correct and this would fix my problem, I believe.
>> Robin> What tools do you use that need the benefits from retaining
>> Robin> timestamps? The only one I can think of is clearmake, but
>> Robin> then that tool goes with another SCM. Eclipse, for example,
>> Robin> will be just as confused by timestamps that travel backwards
>> Robin> in time, as make is.
>>
>> I think of tools called "humans", very common indeed on Earth. :-)
>
> For human beings, it's not really harder to run
>
> git log -1 file
I think the idea is that computers do the work, not humans... :-)
> than to look at the on-disk timestamp. And it continues working after
> you start modifying the file, so it's much less fragile than the
> filesystem timestamp.
>
> But if you insist in reproducing SVN's "use-commit-times = yes" setting,
> it should be doable with a post-checkout hook.
Mmm, this post-checkout hook would get the commit time from the commit
and "touch" all relevant files with that timestamp? Is that easily
done?
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-10-02 23:40 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Kyle Moffett, Michael Witten, Junio C Hamano, Evan Shelhamer,
Git Mailing List
In-Reply-To: <4E889813.8070205@gmail.com>
On 2 October 2011 09:57, Robin Rosenberg <robin.rosenberg@gmail.com> wrote:
> Hilco Wijbenga skrev 2011-08-22 22.10:
>>
>> [...] I just wish there was at least an option to
>> keep the timestamp (and possibly other such things). Even Subversion
>> can do that... ;-) After all, not everybody uses C& make.
>>
> What tools do you use that need the benefits from retaining timestamps? The
> only
> one I can think of is clearmake, but then that tool goes with another SCM.
> Eclipse,
> for example, will be just as confused by timestamps that travel backwards in
> time, as
> make is.
Why would timestamps travel back in time? They simply would not change.
Anyway, we're not really talking about the same thing. If there's an
update (i.e. git pull or something similar) then changing the
timestamp to something (anything) newer is the right thing to do. In
fact, it would be painful (as you already alluded to) if this were not
the case.
That's however not the scenario that I'm talking about. I'm talking about doing
git checkout branch
git checkout master
or
git stash
git stash pop
In both cases all files (or at least all affected files, in case of
git stash) get the current time as their timestamp instead of the
timestamp they had before. This is forcing (completely unnecessary)
rebuilds. *Nothing* has changed but I have to do a complete rebuild
(well, I suppose I could "touch" all build artifacts and such but I'm
sure you get the idea).
I understand *why* it's happening (it's simply reusing the existing
Git functionality) but in the scenarios above nothing has really
changed, I should be able to pick up from where I left off, shouldn't
I?
(Obviously, I moved the discussion off track when I started talking
about Subversion, commits, and commit times. That's really just an
implementation detail and I wish I had never brought it up.)
P.S. I'm quite happy with git-new-workdir so I do believe I have a
good workaround.
^ permalink raw reply
* FW:ไอ้ “เพียงดิน” ทาสรับใช้คนลาวทำร้ายคนไทย
From: relations @ 2011-10-02 23:26 UTC (permalink / raw)
To: git
เมื่ออาจารย์ “เพียงดิน” ยอมทิ้งอุดมการณ์เพียงเพื่อเศษเงินของ ดร.ริชาร์ด ไสสมมอน ความเป็นคนไทย
ที่ต้องพึ่งคนลาวทำให้ผมตัดสินใจว่า ผมไม่รู้จักคนที่ชื่อ นายเสน่ห์ ถิ่นแสน อีกต่อไป ขอให้ “เพียงดิน” เป็น
เพียงแค่ “เศษดินของคนลาว” เท่านั้น กระทู้เรื่อง “ขอน้ำใจและความสามัคคีของพี่น้องไทย” โดย
“Piangdin” เมื่อวันที่ 25 กันยายน 2554 แต่ถูก ดร.ริชาร์ด ไสสมมอน ลบไปเมื่อวันที่ 27 กันยายน 2554 และ
ไอ้ “Piangdin” บอกว่าไม่ติดใจที่ ดร.ริชาร์ด ลบกระทู้(ขอให้ได้เงินก็พอ) ข้อความในกระทู้ที่ผมจะนำมา
เปิดเผยนี้ถ้าไม่เป็นความจริง ขอให้สิ่งศักดิ์สิทธิ์ทั้งหลายลงโทษผมอย่างสาสม แต่ถ้าเป็นความจริงขอให้ฟ้าดิน
ลงโทษคนที่เห็นแก่เศษสตางค์ของคนลาวจงตกนรกหมกไหม้ ถึงไม่มี Internetfreedom เราคนไทยยังคงสู้
ต่อไปเพื่ออุดมการณ์ ไม่ใช่นักธุรกิจแอบแฝง ไอ้เลว... ขอให้พี่น้องที่มีเลือดสีแดงของคนไทยช่วยส่งเมล์กันต่อๆ
ไป
........... บรรพต…………
กระทู้เรื่อง “ขอน้ำใจและความสามัคคีของพี่น้องไทย” โดย “Piangdin” เมื่อวันที่ 25 กันยายน 2554
พี่น้องเสื้อแดงและพี่น้องไทยหัวใจรักประชาธิปไตยทุกท่านครับ
งานวันสิทธิมนุษยชน ไทย-ลาว ที่จะจัดกันในวันที่ 14 ตุลาคม ศกนี้ ณ สภาคองเกรส กรุงวอชิงตัน ดีซี นั้น
เป็นงานที่คนไทยเราออกหน้าร่วมมือกับ ดร.ริชาร์ด ที่เป็นผู้ดูแลหลักและตัวแทนฝ่ายลาว ส่วนตัวแทนฝ่ายไทยเรา
นั้น ปรากฏว่ายังไม่ลงตัว แม้กระทั่งนับมาถึง ณ วินาทีนี้
เราจำเป็นต้องแสดงน้ำใจของคนไทยต่อการเป็นเจ้าภาพครั้งนี้ ซึ่งผมกำลังคิดว่าจะออกหน้าเป็นประธานร่วมจัด
งานกับ ดร. ริชาร์ด ในนามคนไทย โดยอย่างน้อยเราควรต้องมีหรือช่วยเหลือ ดร. ริชาร์ด และเตรียมการในสิ่ง
เหล่านี้
หนึ่ง การบริจาคเงินเพื่อสนับสนุนงานครั้งนี้ ในนามคนไทย (ผมอยากให้มีการบริจาคเข้าสู่บัญชีสำหรับฝ่ายไทย
โดยไม่ผ่าน ดร. ริชาร์ด เพื่อจะได้ทราบว่า คนไทยเรามีส่วนร่วมแค่ไหนสำหรับงานนี้ ซึ่งเท่าที่ ดร.ริชาร์ด คำนวณ
คร่าว ๆ น่าจะใช้จ่ายมากถึงหลักหมื่นเหรียญถึงสามหมื่นเหรียญ ซึ่งผมกะว่าจะชี้แจงผ่านรายการ Seeds of
Democracy วันศุกร์นี้ และเรื่องบัญชีสำหรับการบริจาคและกฏเกณฑ์การดูแลเงินนั้น ผมจะคุยกับพี่น้องที่
ทำงาน และจะทำให้บัญชีมันโปร่งใส มีคนเบิกจ่ายและดูแลบัญชีพร้อมกันอย่างน้อยสามคน และจะมีการรายงาน
บัญชีการเงินอย่างโปร่งใสที่สุด เพื่อไม่ให้มีข้อครหาใด ๆ และเพื่อการดำเนินงานระยะยาวด้วย)
สอง ตอนนี้เรายังต้องการผู้ช่วยงานด้านต่าง ๆ เช่น การติดต่อประสานงาน การจัดสถานที่ การรับแขก การออก
หน้าในงานในฐานะตัวแทนคนไทย การถ่ายทอดรายการการบันทึกและรายงานข่าว ฯลฯ แต่ความจริงก็คือ เรายัง
ไม่มีคนทำงานครบครับ ผมกำลังจะออกหน้าเป็นหลักให้สำหรับงานนี้ แต่ยังต้องการกำลังคนที่จะไปงานและ
ทำงานร่วมกันช่วงเตรียมการและในวันงาน เพื่อแสดงว่าคนไทยเรารับเป็นเจ้าภาพร่วม แล้วจะไม่ปล่อยให้
ดร. ริชาร์ด และพี่น้องชาวลาวต้องแบกน้ำหนักมากเกินไป ผมขอให้พี่น้องที่จะสามารถไปร่วมงานได้หรืออยาก
ช่วยเหลือด้านอื่น ๆ กรุณาช่วยแจ้งรายชื่อผ่านไปทางอีเมล์ผม 4everche@gmail.com
สาม เราต้องการท่านที่ปรารถนาจะทำงานในฐานะคณะกรรมการของหน่วยงานในนามคนไทย ตอนนี้เราได้ ดร.
ริชาร์ด ทำหน้าที่ช่วยเรื่องเส้นสายในการเข้าหาผู้มีอำนาจในรัฐบาลอเมริกัน โดยเฉพาะในสภาคองเกรส และการ
จดทะเบียนองค์กร แต่การทำงานของเรา ควรต้องเป็นคนไทยที่มีรูปแบบองค์กรและตัวตน ที่มีศักยภาพและ
อำนาจในการจัดการกันในกลุ่มคนไทยให้ดีขึ้น โดยประสานงานและขอความร่วมมือจาก ดร. ริชาร์ด ตามสมควร
ดังนั้น ผมต้องการผู้ร่วมอุดมการณ์จำนวนหนึ่ง ที่พร้อมออกหน้า ใช้ชื่อในการจัดตั้งและพร้อมทำงานกันอย่าง
แท้จริง (ซึ่งไม่หนักหนาเกินไปแน่นอนครับ) ที่คิดไว้ตอนนี้ ผมจะทำให้องค์การนี้เป็นองค์การเพื่อสิทธิมนุษยชน
อย่างแท้จริง เรามีเลือดเสื้อแดง แต่จะไม่รับใช้คุณทักษิณ เพื่อไทย หรือติดภาพทางการเมืองชัดเจนเกินไป เพื่อผล
ในการทำงานและการต่อรองในระดับนานาชาติ โดยเราอาจจะใช้ชื่อว่า
Thai Activists for Human Rights (TAHR)
Association of Thais for Universal Human Rights (ATUHR)
Thai Friends for Democracy and Univeral Human Rights (ADUHR)
Thai Alliance for Democracy and Universal Human Rights (TADUHR)
Thai Activists for Human Rights (TAHR)
Activists for Democracy in Thailand (ADT)
Association of Thais for Human Rights (ATHR)
Association of Friends for Human Rights in Thailand (AFHRT)
Friends for Human Rights in Thailand (FHRT)
Networks of Thai Activists for Human Rights (NTAHR)
Democratic Association for Thailand’s Human Rights (DATHR)
หรืออาจจะเป็นชื่ออื่น ๆ ที่เหมาะสม
เรา มีคนที่มีชื่อในองค์กรเก่า ๆ อยู่แล้ว แต่เนื่องจากมันยังมีปัญหาเชิงรูปธรรมและความเหมาะสมบางประการ เรา
จึงได้ปรึกษากับ ดร. ริชาร์ดว่าจะเริ่มกันใหม่ ซื่งเราจะได้รับความช่วยเหลือจาก ดร. ริชาร์ด อย่างเต็มที่ ดังนั้นจะ
ไม่ใช่เรื่องยากเกินไป และงานนี้อยากให้เริ่มกันใหม่ โดยพี่น้องสมัครกันเข้ามาเอง ผมจะนำทัพในเบื้องต้นนี้ให้
โดยสมาชิกหรือคณะกรรมการบริหารองค์กรนี้ เราต้องการซักสิบคนนะครับ เป็นคนไทยทั่วโลก ทั้งที่อยู่ใน
ประเทศไทย และที่อยู่ในทุกทวีปทั่วโลก องค์กรนี้ เราจะไม่ให้มีภาพการล้มเจ้า เพราะมันมีผลกับการอยากมีส่วน
ร่วมของพี่น้องที่มีศักยภาพและความสามารถจำนวนมาก หลายคนอาจจะอยากสู้เพื่อประชาธิปไตย แต่ไม่อยากมี
ชื่อร่วมกับคนที่มีภาพล้มเจ้าอยู่แล้ว หรือต้องคดีความอยู่แล้ว เรายินดีต้อนรับพี่น้องที่มีพื้นความคิดหลากหลาย
(รวมทั้งพวกที่ไม่รักเจ้าด้วย) แต่เราจะทำให้องค์กรนี้ เป็นองค์กรทีมีวิถีบินสูงกว่าแค่เรื่องการเมือง หรือ
ผลประโยชน์ของพรรคใด ๆ แต่เราจะเน้นการพัฒนาประชาธิปไตยและสิทธิมนุษยชนพื้นฐานในไทย และร่วมกับ
มิตรประเทศทั่วโลก แต่ด้วยหลักการและเหตุผลแล้ง องค์กรนี้ สนับสนุนการเคลื่อนไหวของเสื้อแดงแบบสันติวิธี
และอยู่บนหลักเสรีภาพ เสมอภาค และภราดรภาพ สนับสนุนการล้มล้างกฏหมายที่ไม่เป็นประชาธิปไตย และ
สนับสนุนการป้องกันและปราบปรามการกระทำใด ๆ ที่ทำร้ายสิทธิและเสรีภาพตามหลักสิทธิมนุษยชนทุก
รูปแบบ โดยอยู่ภายใต้ภาพการเป็นนิติรัฐและการใช้นิติธรรมตามวิถีอารยะ
หากท่านจริงใจและจริงจังกับการทำงานร่วมกัน ขอให้ปาวารณาตัวท่านผ่านไปที่อีเมล์ของผมนะครับ
4everche@gmail.com แล้วผมจะติดต่อกลับ แล้วคงต้องมีการพูดคุยกันเป็นส่วนตัว เพื่อยืนยันว่าอยาก
ทำงานแน่นอน แล้วเราก็จะเดินหน้าไปด้วยกัน
ผม เชื่อว่าคนไทยรารักชาติไม่แพ้ชาติใด รักแผ่นดินเกิดไม่น้อยกว่าใคร ดร. ริชาร์ดได้ทำเพื่อพวกเรามามาก เรา
ต้องเติบโตและยืนบนขาตัวเองบนเวทีโลก เพื่อต่อสู้อย่างองอาจกล้าหาญ บนหลักการที่เรายึดถือร่วมกัน อันได้แก่
อำนาจอธิปไตยที่ไม่ถูกใครแย่งไป และการอยู่บนหลักเสรีภาพ เสมอภาค และภราดรภาพ อันยั่งยืน บนความ
เจริญก้าวหน้าของประเทศไทย ภาคีอาเซียน และของโลกที่เรายื่นมือไปช่วยเหลือได้
หวังว่าจะได้รับข่าวดีจากพี่ น้องร่วมอุดมกาณ์และผู้มีจิตใจที่ดีงามต่อบ้านเมืองเร็ว ๆ นี้ นะครับ และหวังว่างาน
วันที่ 14 ตุลาคม ศกนี้ จะเป็นโอกาสแรก ที่เราจะได้พบปะและพูดคุยกันตามประสาคนไทยหัวใจสีแดงที่รักเสรี
ประชาธิปไตย แบบสากล
โปรดติดตามรับฟังการอธิบายเพิ่มเติมในรายการ Seeds of Democracy ในวันศุกร์นี้ ทาง Red UDD
ตั้งแต่สองทุ่ม (เมืองไทย) นะครับ
ขอบคุณทุกท่านที่อ่านและพิจารณาร่วมมือ
piangdin
^ permalink raw reply
* Re: Restoring timestamps (Re: Branches & directories)
From: Hilco Wijbenga @ 2011-10-02 22:29 UTC (permalink / raw)
To: weigelt, Git Mailing List
In-Reply-To: <20111002150601.GB15083@nibiru.local>
On 2 October 2011 08:06, Enrico Weigelt <weigelt@metux.de> wrote:
> * Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>
>> Eclipse is a wonderful IDE except for how it makes sharing workspaces
>> practically impossible (where "share" means "put in SCM", not "used by
>> several developers at the same time").
>
> This is one the major points which render it rather useless for me ;-o
As long as Eclipse is the only IDE (AFAIK, of course) that has
workspaces (allowing you to easily group projects) and "Clean Up"
(which helps clean up Java code), I'll stick with it despite its
deficiencies.
^ permalink raw reply
* Re: Restoring timestamps (Re: Branches & directories)
From: Hilco Wijbenga @ 2011-10-02 22:25 UTC (permalink / raw)
To: Brandon Casey
Cc: Evan Shelhamer, Michael Witten, Kyle Moffett, Git Mailing List,
Junio C Hamano, Jonathan Nieder
In-Reply-To: <CA+sFfMf=gi5CWyfZEt-Nmdr4J9g__maQTqy1WePr1x8D-AVr4A@mail.gmail.com>
On 2 October 2011 08:47, Brandon Casey <drafnel@gmail.com> wrote:
> On Aug 22, 2011 10:06 PM, "Hilco Wijbenga" <hilco.wijbenga@gmail.com> wrote:
>> Is it possible to do git stash
>> pop without losing the stash?
>
> That's called 'git stash apply'.
:-) Yeah, I had actually discovered that myself. I had been using
"pop" and "apply" interchangeably until I noticed I had a number of
stashes stored that I was not aware of. That's when I discovered they
did in fact *not* have exactly the same meaning. :-)
^ permalink raw reply
* [PATCH] Spell retrieve correctly.
From: Kevin Lyda @ 2011-10-02 21:44 UTC (permalink / raw)
To: git, gitster; +Cc: kevin
---
perl/Git.pm | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index a86ab70..7422e13 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -962,7 +962,7 @@ my (%TEMP_FILEMAP, %TEMP_FILES);
=item temp_acquire ( NAME )
-Attempts to retreive the temporary file mapped to the string C<NAME>. If an
+Attempts to retrieve the temporary file mapped to the string C<NAME>. If an
associated temp file has not been created this session or was closed, it is
created, cached, and set for autoflush and binmode.
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] transport: do not allow to push over git:// protocol
From: Nguyen Thai Ngoc Duy @ 2011-10-02 21:11 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git@vger.kernel.org
In-Reply-To: <20111002223805.0bd6678b@zappedws>
2011/10/3 Alexey Shumkin <alex.crezoff@gmail.com>:
>> This protocol has never been designed for pushing. Attempts to push
>> over git:// usually result in
>>
>> fatal: The remote end hung up unexpectedly
>
> hmmm.. So, how does my project work? ))
>
> $ git remote -v
> origin git://drcis/d/Data/GitRepos/projects/billing+beeline.git (fetch)
> origin git://drcis/d/Data/GitRepos/projects/billing+beeline.git (push)
>
>
> $git daemon --help
> ...
> SERVICES
> ..
> receive-pack
> This serves git send-pack clients, allowing anonymous push.
> It is disabled by default
> ...
>
> It does not correspond your words...
>
> What do I miss?
.. what I said in a later mail, my patch is wrong :)
--
Duy
^ permalink raw reply
* Re: Branches & directories
From: Matthieu Moy @ 2011-10-02 19:09 UTC (permalink / raw)
To: Ronan Keryell
Cc: Robin Rosenberg, Hilco Wijbenga, Kyle Moffett, Michael Witten,
Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <87botznvua.fsf@an-dro.info.enstb.org>
Ronan Keryell <Ronan.Keryell@hpc-project.com> writes:
>>>>>> On Sun, 02 Oct 2011 18:57:55 +0200, Robin Rosenberg <robin.rosenberg@gmail.com> said:
>
> Robin> Hilco Wijbenga skrev 2011-08-22 22.10:
> >> [...] I just wish there was at least an option to keep the
> >> timestamp (and possibly other such things). Even Subversion can
> >> do that... ;-) After all, not everybody uses C& make.
AFAIK, Subversion doesn't version timestamps. What it can do is to set
the timestamp to the commit date at the time the file is checked-out.
> Robin> What tools do you use that need the benefits from retaining
> Robin> timestamps? The only one I can think of is clearmake, but
> Robin> then that tool goes with another SCM. Eclipse, for example,
> Robin> will be just as confused by timestamps that travel backwards
> Robin> in time, as make is.
>
> I think of tools called "humans", very common indeed on Earth. :-)
For human beings, it's not really harder to run
git log -1 file
than to look at the on-disk timestamp. And it continues working after
you start modifying the file, so it's much less fragile than the
filesystem timestamp.
But if you insist in reproducing SVN's "use-commit-times = yes" setting,
it should be doable with a post-checkout hook.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Branches & directories
From: Ronan Keryell @ 2011-10-02 17:31 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Hilco Wijbenga, Kyle Moffett, Michael Witten, Junio C Hamano,
Evan Shelhamer, Git Mailing List
In-Reply-To: <4E889813.8070205@gmail.com>
>>>>> On Sun, 02 Oct 2011 18:57:55 +0200, Robin Rosenberg <robin.rosenberg@gmail.com> said:
Robin> Hilco Wijbenga skrev 2011-08-22 22.10:
>> [...] I just wish there was at least an option to keep the
>> timestamp (and possibly other such things). Even Subversion can
>> do that... ;-) After all, not everybody uses C& make.
Robin> What tools do you use that need the benefits from retaining
Robin> timestamps? The only one I can think of is clearmake, but
Robin> then that tool goes with another SCM. Eclipse, for example,
Robin> will be just as confused by timestamps that travel backwards
Robin> in time, as make is.
I think of tools called "humans", very common indeed on Earth. :-)
The reward of git success is that it is not only used to develop the
Linux kernel. :-)
We use also git as a very smart repositories to store administrative
documents. It is very convenient to look at the real modification or
creation dates to figure out some historical aspects for example.
metastore is a nice tool providing a begin of this on top of git (or
whatever) but :
- this is not very convenient, needing to deal manually with these
aspects ;
- the metadata is binary and not textual (à la YAML ?) so we loose the
classical textual merging candies when conflict arises on metadata
(ouch).
It is one of my future project to do a more textual version of
metastore, but I'm afraid it is an unbound future... :-/
--
Ronan KERYELL |\/ Phone: +1 408 844 HPC0
HPC Project, Inc. |/) Cell: +33 613 143 766
5201 Great America Parkway #3241 K Ronan.Keryell@hpc-project.com
Santa Clara, CA 95054 |\ skype:keryell
USA | \ http://hpc-project.com
^ permalink raw reply
* Re: Branches & directories
From: Robin Rosenberg @ 2011-10-02 16:57 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Kyle Moffett, Michael Witten, Junio C Hamano, Evan Shelhamer,
Git Mailing List
In-Reply-To: <CAE1pOi1axNmGaPVXqBH02x0N=Z6tgO9R00RTokuJm50eY-OoNg@mail.gmail.com>
Hilco Wijbenga skrev 2011-08-22 22.10:
> [...] I just wish there was at least an option to
> keep the timestamp (and possibly other such things). Even Subversion
> can do that... ;-) After all, not everybody uses C& make.
>
What tools do you use that need the benefits from retaining timestamps?
The only
one I can think of is clearmake, but then that tool goes with another
SCM. Eclipse,
for example, will be just as confused by timestamps that travel
backwards in time, as
make is.
-- robin
^ permalink raw reply
* Re: Bug?: 'git log --find-copies' doesn't match 'git log --follow <rev> -- path/to/file'
From: Jeff King @ 2011-10-02 15:25 UTC (permalink / raw)
To: Alexander Pepper; +Cc: git
In-Reply-To: <67B22035-4B90-4A68-8960-DDB58F640CD9@inf.fu-berlin.de>
On Sun, Oct 02, 2011 at 05:10:26PM +0200, Alexander Pepper wrote:
> Using 'git log --numstat --find-copies-harder dd4e90f9' yields "immutable.java" as you expected:
>
> $ git log --numstat --find-copies-harder dd4e90f9
> [...]
> 6 10 src/java/voldemort/annotations/concurrency/Immutable.java => contrib/ec2-testing/src/java/voldemort/utils/ClusterOperation.java
OK. That at least explains what's going on.
> So is there a way to tell --follow to only use --find-copies instead
> of --find-copies harder?
No, it's hard-coded.
> And what is the advantage of using "--find-copies-harder" over "--find-copies"?
It finds more copies. The rename detection works like this:
--find-renames: for each newly-created file, consider any deleted
files as possible sources
--find-copies: like above, but also consider any modified files as
possible sources
--find-copies-harder: like above, but consider any file in the
repository as a possible source
So in theory --find-copies-harder is the most accurate, but it is also
the most expensive. We can afford to do it for --follow since we're only
considering a small subset of the possible destinations.
So git is saying that your immutable.java is actually a better match;
it's just that we don't usually find it because it wasn't modified in
the same commit. Have you looked at the contents? Is it actually a
better match, or is git wrong?
-Peff
^ permalink raw reply
* Re: Bug?: 'git log --find-copies' doesn't match 'git log --follow <rev> -- path/to/file'
From: Alexander Pepper @ 2011-10-02 15:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110930213841.GA9384@sigill.intra.peff.net>
Am 30.09.2011 um 23:38 schrieb Jeff King:
> On Fri, Sep 30, 2011 at 05:32:38PM +0200, Alexander Pepper wrote:
>
>> So git log with copy and rename detection on (--find-copies) tells me,
>> that the file StopClusterException.java is copied to
>> ClusterOperation.java. But If I ask git log for that specific file
>> with --follow git claims a copy from Immutable.java to
>> ClusterOperation.java!
>
> I think that --follow uses --find-copies-harder. Did you try:
>
> git log --numstat --find-copies-harder dd4e90f9
>
> ? Does it find Immutable.java as the source?
>
> -Peff
Using 'git log --numstat --find-copies-harder dd4e90f9' yields "immutable.java" as you expected:
$ git log --numstat --find-copies-harder dd4e90f9
[...]
6 10 src/java/voldemort/annotations/concurrency/Immutable.java => contrib/ec2-testing/src/java/voldemort/utils/ClusterOperation.java
So is there a way to tell --follow to only use --find-copies instead of --find-copies harder? And what is the advantage of using "--find-copies-harder" over "--find-copies"?
Greetings from Berlin
Alex
--
Alexander Pepper
pepper@inf.fu-berlin.de
^ permalink raw reply
* Re: Restoring timestamps (Re: Branches & directories)
From: Enrico Weigelt @ 2011-10-02 15:06 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <CAE1pOi1J=TWUmJKZorotBsDoz3wozXsioN7fVO=7JBxdMD7Zqg@mail.gmail.com>
* Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> Eclipse is a wonderful IDE except for how it makes sharing workspaces
> practically impossible (where "share" means "put in SCM", not "used my
> several developers at the same time").
This is one the major points which render it rather useless for me ;-o
> Is it possible to do git stash pop without losing the stash?
git cherry-pick stash{0}
Apropos IDEs:
I've been thinking about how to properly integrate IDEs with VCS'es
like git. My conclusion is that it should be directly built ontop
of it. Project metadata itself belongs into git, and the project
management tool should automatically create local working copies
on-demand. I would even delegate *all* the VCS handling to git
(even when using other VCS'es in the back)
Maybe I'll find some time to do some initial concepts.
Perhaps anybody likes to join in ?
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Enrico Weigelt @ 2011-10-02 14:50 UTC (permalink / raw)
To: git
In-Reply-To: <op.v2pox0g70aolir@keputer>
* Frans Klaver <fransklaver@gmail.com> wrote:
Putting on my business consultant hat:
> If you don't trust them, fix your trust and relationship, not some tool.
ACK. We're essentially talking about a social/political problem,
bot a technical one. Take my advise, solve the problem on the
layer it comes from.
The whole ideology of keeping individual devs on their little
tiny isle is to have the whole project structured into such
little islands in the first place. Meaning: a really strong
compartimentalization. This requires an strictly modular
architecture (which essentially means having completely
separate trees for the individual modules) and, of course,
good requirements engineering, contract-driven development,
etc, with all the associated role models, etc, etc.
What kind of project are we talking about ?
Tactical control or nuclear plant systems ?
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: fatal: index-pack failed
From: Robin Rosenberg @ 2011-10-02 13:47 UTC (permalink / raw)
To: Matti Linnanvuori; +Cc: git
In-Reply-To: <50B87B00-064C-4FCC-B1E8-94A9EB027468@portalify.com>
Matti Linnanvuori skrev 2011-09-30 10.11:
> Jenkins got an error:
>
> Error performing command: git fetch -t ssh://iac-builder@sorsa.portalify.com/p/git/.git+refs/heads/*:refs/
> Command "git fetch -t ssh://iac-builder@sorsa.portalify.com/p/git/.git+refs/heads/*:refs/remotes/origin/*" returned status code 128: error: refs/remotes/origin/HEAD does not point to a valid object!
> error: refs/remotes/origin/master does not point to a valid object!
> error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
> error: refs/remotes/origin/HEAD does not point to a valid object!
> error: refs/remotes/origin/master does not point to a valid object!
> error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
> error: Could not read 49f273234b582edb44bbdbda29193719e5054cb7
> error: refs/remotes/origin/HEAD does not point to a valid object!
> error: refs/remotes/origin/master does not point to a valid object!
> error: missing object referenced by 'refs/tags/iac-1.4.13'
> error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
> error: Could not read 49f273234b582edb44bbdbda29193719e5054cb7
> fatal: pack has 26 unresolved deltas
> fatal: index-pack failed
I saw this too a couple of weeks ago. I have no idea what caused it.
After removing all refs from the remote and fetching again everything
was fine. No system crash was involved.
(fresh) Hypothesis: A fetch updated the refs, but failed to get save the
actual objects. I think git tries hard to make sure that this cannot happen.
In my case JGit might have been used to perform the fetch that failed.
Since you say it's Jenkins, I'd guess not, since it uses C Git.
-- robin
^ permalink raw reply
* Re: how to produce an index with smudged entries
From: Robin Rosenberg @ 2011-10-02 13:10 UTC (permalink / raw)
To: Christian Halstrick; +Cc: git
In-Reply-To: <CAENte7h-sbv7VTBdV7A+=TtONTpgOBBfVWz2Nejm1DqJJ9tFiQ@mail.gmail.com>
Christian Halstrick skrev 2011-09-30 17.33:
> I am trying to find out how native git handles the racy git problem. I
> read https://raw.github.com/git/git/master/Documentation/technical/racy-git.txt.
> But I cannot reproduce the behaviour described in this text.
I guess that code is only likely to work if USE_NSEC is not set or the
file system has only whole second resolution. It might be very hard to
reproduce the situation since the likehood that a file AND the index has
the same timestamp at the subsecond level is very small. Nasty thing to
test :)
Is your file system one that does not have subsecond timestamp
resolution? The nanosecond part of the timestamp(s) should be 0 (byte
24-27 for mtime for the first index entry).
Touch can set the timestamp to an explicit value, so you can use that
instead of waiting for luck. Touch cannot set ctime, but you can make
git ignore ctime by setting core.trustctime to false.
For testing the issue with nanosecond resolution you have to roll your
own touch in C, perl or even Java.
-- robin
^ permalink raw reply
* Locked dev repository
From: Valon @ 2011-10-02 9:06 UTC (permalink / raw)
To: git
I used a tutorial to add a new user to gitosis, and at the same time I
removed the user who initially set up the whole thing (as he left the
project team).
Now I can only checkout the gitosis-admin repo, but not the development
repository anymore. Can anybody help me with what has happened and how to
fix this?
I tried already to commit an elder version of the gitosis.conf but sadly
this did not help me.
thanks, Valon
--
View this message in context: http://git.661346.n2.nabble.com/Locked-dev-repository-tp6852249p6852249.html
Sent from the git mailing list archive at Nabble.com.
^ 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