* Re: Branches & directories
From: Jeff King @ 2011-10-03 7:34 UTC (permalink / raw)
To: Matthieu Moy
Cc: Hilco Wijbenga, Robin Rosenberg, Kyle Moffett, Michael Witten,
Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <vpqaa9ijzt4.fsf@bauges.imag.fr>
On Mon, Oct 03, 2011 at 09:32:07AM +0200, Matthieu Moy wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
> > Yes, I meant it literally. And, no, Git could not possibly know so it
> > would have to be optional behaviour. But it's probably a lot of work
> > for (for most people) little gain.
>
> Not only little gain, but also important risk: users of this feature
> would be likely to spend hours debugging something just because some
> files weren't recompiled at the right time.
>
> If you want to optimize the number of files compiled by "make", then
> ccache is your friend. This one is safe.
Yes. Despite my previous message showing what _could_ be done, I do
think it's crazy. You should just use ccache.
Speaking of which; does anybody know of a git-aware ccache-like tool?
We already have a nice index of the sha1 of each file in the repository
(along with a stat cache showing us whether it's up-to-date or not).
Something like ccache could avoid even looking in the C files at all if
it relied on git's index.
I don't know how much speedup it would yield in practice, though.
-Peff
^ permalink raw reply
* Re: Branches & directories
From: Matthieu Moy @ 2011-10-03 7:32 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Jeff King, Robin Rosenberg, Kyle Moffett, Michael Witten,
Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi2xmVHrVJcC85wvCv=anhn_kYizyUMpUVZF4EE33RoGmg@mail.gmail.com>
Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> Yes, I meant it literally. And, no, Git could not possibly know so it
> would have to be optional behaviour. But it's probably a lot of work
> for (for most people) little gain.
Not only little gain, but also important risk: users of this feature
would be likely to spend hours debugging something just because some
files weren't recompiled at the right time.
If you want to optimize the number of files compiled by "make", then
ccache is your friend. This one is safe.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Branches & directories
From: Jeff King @ 2011-10-03 7:30 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Robin Rosenberg, Kyle Moffett, Michael Witten, Junio C Hamano,
Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi2xmVHrVJcC85wvCv=anhn_kYizyUMpUVZF4EE33RoGmg@mail.gmail.com>
On Mon, Oct 03, 2011 at 12:15:33AM -0700, Hilco Wijbenga wrote:
> On 2 October 2011 20:07, Jeff King <peff@peff.net> wrote:
> <snip/>
> > 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".
>
> Yes, I meant it literally. And, no, Git could not possibly know so it
> would have to be optional behaviour. But it's probably a lot of work
> for (for most people) little gain.
If you really want the human to trigger it, then you can do something
like this:
cat >git-checkout-timestamp <<\EOF
#!/bin/sh
old=`git rev-parse HEAD`
git checkout "$@" || exit 1
time=`git log -1 --format=%at`
git diff-tree --name-only -z "$old" HEAD |
perl -0ne "utime($time, $time, \$_)";
EOF
Drop that somewhere in your $PATH, and use it instead of regular
checkout. It restores the timestamps on any changed files, but not on
those that were not touched. So your:
git checkout branch
git checkout master
example would end up with timestamps set for "master" on the changed
files. Two caveats:
1. This can still break makefiles! For example, like this:
make foo.o ;# now foo.o is recent
vi foo.c ;# but foo.c is _more_ recent
git checkout branch ;# now it's even newer
git checkout-timestamp master ;# now we've restored it to some
;# old timestamp, and make will
;# think it's older than foo.o
2. In general, I'm not sure it makes any sense if there are local
worktree modifications to the files in question. But I didn't think
about it too hard. That ways madness lies.
-Peff
^ permalink raw reply
* Re: [PATCH] Makefile: do not set setgid bit on directories on GNU/kFreeBSD
From: Jonathan Nieder @ 2011-10-03 7:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Salinger
In-Reply-To: <20111003064120.GA24396@elie>
Jonathan Nieder wrote:
> Since the setgid bit would only mean "do what you were going to do
> already", it's better to avoid setting it. Accordingly, ever since
> v1.5.5-rc0~59^2 (Do not use GUID on dir in git init --share=all on
> FreeBSD, 2008-03-05), git on true FreeBSD has done exactly that. Set
> DIR_HAS_BSD_GROUP_SEMANTICS in the makefile for GNU/kFreeBSD, too, so
> machines that use glibc with the kernel of FreeBSD get the same fix.
[...]
> Sorry to have taken so long to send this one out. Anyway, it seems
> to me like the right thing to do. Petr, what do you think?
fwiw:
Acked-by: Petr Salinger <Petr.Salinger@seznam.cz>
Thanks for looking it over.
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-10-03 7:15 UTC (permalink / raw)
To: Jeff King
Cc: Robin Rosenberg, Kyle Moffett, Michael Witten, Junio C Hamano,
Evan Shelhamer, Git Mailing List
In-Reply-To: <20111003030723.GA24523@sigill.intra.peff.net>
On 2 October 2011 20:07, Jeff King <peff@peff.net> wrote:
<snip/>
> 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".
Yes, I meant it literally. And, no, Git could not possibly know so it
would have to be optional behaviour. But it's probably a lot of work
for (for most people) little gain.
^ permalink raw reply
* Re: [PATCH v2] ident: check /etc/mailname if email is unknown
From: Johannes Sixt @ 2011-10-03 7:09 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, git, Matt Kraai, Gerrit Pape, Ian Jackson,
Linus Torvalds
In-Reply-To: <20111003061633.GB17289@elie>
Am 10/3/2011 8:16, schrieb Jonathan Nieder:
> +static int add_mailname_host(char *buf, size_t len)
> +{
> + FILE *mailname;
> +
> + mailname = fopen("/etc/mailname", "r");
> + if (!mailname) {
> + if (errno != ENOENT)
> + warning("cannot open /etc/mailname: %s",
> + strerror(errno));
This warns on EACCES. Is that OK? (Just asking, I have no opinion.)
-- Hannes
^ permalink raw reply
* [PATCH] Makefile: do not set setgid bit on directories on GNU/kFreeBSD
From: Jonathan Nieder @ 2011-10-03 6:41 UTC (permalink / raw)
To: Petr Salinger; +Cc: git
The g+s bit on directories to make group ownership inherited is a
SysVism --- BSD and most of its descendants do not need it since they
do the sane thing by default without g+s. In fact, on some
filesystems (but not all --- tmpfs works this way but UFS does not),
the kernel of FreeBSD does not even allow non-root users to set setgid
bit on directories and produces errors when one tries:
$ git init --shared dir
fatal: Could not make /tmp/dir/.git/refs writable by group
Since the setgid bit would only mean "do what you were going to do
already", it's better to avoid setting it. Accordingly, ever since
v1.5.5-rc0~59^2 (Do not use GUID on dir in git init --share=all on
FreeBSD, 2008-03-05), git on true FreeBSD has done exactly that. Set
DIR_HAS_BSD_GROUP_SEMANTICS in the makefile for GNU/kFreeBSD, too, so
machines that use glibc with the kernel of FreeBSD get the same fix.
This fixes t0001-init.sh and t1301-shared-repo.sh on GNU/kFreeBSD
when running tests with --root pointing to a directory that uses
tmpfs.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Sorry to have taken so long to send this one out. Anyway, it seems
to me like the right thing to do. Petr, what do you think?
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 8d6d4515..924749ed 100644
--- a/Makefile
+++ b/Makefile
@@ -820,6 +820,7 @@ ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
NO_MKSTEMPS = YesPlease
HAVE_PATHS_H = YesPlease
+ DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
endif
ifeq ($(uname_S),UnixWare)
CC = cc
--
1.7.7.rc1
^ permalink raw reply related
* Re: [PATCH v2] gitk: Show patch for initial commit
From: Marcus Karlsson @ 2011-10-03 6:33 UTC (permalink / raw)
To: Zbigniew J??drzejewski-Szmek; +Cc: git, gitster, Paul Mackerras
In-Reply-To: <4E878016.703@in.waw.pl>
On Sat, Oct 01, 2011 at 11:03:18PM +0200, Zbigniew J??drzejewski-Szmek wrote:
> [cc: Paul Mackerras]
>
> Hi,
> I think that the historical explanation that Junio gave could
> be used as a basis for a commit message:
>
> In early days, all projects managed by git (except for git itself) had the
> product of a fairly mature development history in their first commit, and
> it was deemed unnecessary clutter to show additions of these thousands of
> paths as a patch.
>
> "git log" learned to show the patch for the initial commit without requiring
> --root command line option at 0f03ca9 (config option log.showroot to show
> the diff of root commits, 2006-11-23).
>
> Teach gitk to respect log.showroot.
Absolutely, that would be a much better commit message. I'll wait and
see if there are more comments and then resubmit.
> Also the gitk should be mentioned in the man-page for git-config log.showroot.
> The current description of this option seems suboptimal because it explains
> how it used to be, which is not really relevant:
> log.showroot
> If true, the initial commit will be shown as a big creation event. This is
> equivalent to a diff against an empty tree. Tools like git-log(1) or git-
> whatchanged(1), which normally hide the root commit will now show it. True by
> default.
> This could be changed to:
> If true (the default), the root commit will be shown as a big creation
> event --- a diff against an empty tree. This diff can be very large for
> a project which was imported into git after some development history.
> If log.showroot is false tools like git-log(1), git-whatchanged(1), or
> gitk(1) will not display the added files.
I agree, but that feels like something that could be made into a
separate patch. Or should I include that too?
Marcus
^ permalink raw reply
* [PATCH v2] ident: check /etc/mailname if email is unknown
From: Jonathan Nieder @ 2011-10-03 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matt Kraai, Gerrit Pape, Ian Jackson, Linus Torvalds
In-Reply-To: <7v8vp2iqvc.fsf@alter.siamese.dyndns.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 maybe it could be
useful sometimes on other machines, too. 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 using a resolver that was slow to handle reverse DNS
lookups.
Alas, after this patch, 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. But
I think it's worth it.
Mechanics: the functionality of reading mailname goes in its own
function, so people who care about other distros can easily add an
implementation to a similar location without making copy_email() too
long and losing clarity. While at it, we split out the fallback
default logic that does gethostname(), too (rearranging it a little
and adding a check for errors from gethostname while at it).
Based on a patch by Gerrit Pape <pape@smarden.org>.
Requested-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano wrote:
> 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.
Makes sense. How about this?
Documentation/git-commit-tree.txt | 8 ++++-
ident.c | 66 +++++++++++++++++++++++++++++-------
2 files changed, 60 insertions(+), 14 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..edb43144 100644
--- a/ident.c
+++ b/ident.c
@@ -50,6 +50,54 @@ static void copy_gecos(const struct passwd *w, char *name, size_t sz)
}
+static int add_mailname_host(char *buf, size_t len)
+{
+ FILE *mailname;
+
+ mailname = fopen("/etc/mailname", "r");
+ if (!mailname) {
+ if (errno != ENOENT)
+ warning("cannot open /etc/mailname: %s",
+ strerror(errno));
+ return -1;
+ }
+ if (!fgets(buf, len, mailname)) {
+ if (ferror(mailname))
+ warning("cannot read /etc/mailname: %s",
+ strerror(errno));
+ fclose(mailname);
+ return -1;
+ }
+ /* success! */
+ fclose(mailname);
+ return 0;
+}
+
+static void add_domainname(char *buf, size_t len)
+{
+ struct hostent *he;
+ size_t namelen;
+ const char *domainname;
+
+ if (gethostname(buf, len)) {
+ warning("cannot get host name: %s", strerror(errno));
+ strlcpy(buf, "(none)", len);
+ return;
+ }
+ namelen = strlen(buf);
+ if (memchr(buf, '.', namelen))
+ return;
+
+ he = gethostbyname(buf);
+ buf[namelen++] = '.';
+ buf += namelen;
+ len -= namelen;
+ if (he && (domainname = strchr(he->h_name, '.')))
+ strlcpy(buf, domainname + 1, len);
+ else
+ strlcpy(buf, "(none)", len);
+}
+
static void copy_email(const struct passwd *pw)
{
/*
@@ -61,20 +109,12 @@ 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++] = '@';
- gethostname(git_default_email + len, sizeof(git_default_email) - len);
- if (!strchr(git_default_email+len, '.')) {
- struct hostent *he = gethostbyname(git_default_email + len);
- char *domainname;
- len = strlen(git_default_email);
- git_default_email[len++] = '.';
- if (he && (domainname = strchr(he->h_name, '.')))
- strlcpy(git_default_email + len, domainname + 1,
- sizeof(git_default_email) - len);
- else
- strlcpy(git_default_email + len, "(none)",
- sizeof(git_default_email) - len);
- }
+ if (!add_mailname_host(git_default_email + len,
+ sizeof(git_default_email) - len))
+ return; /* read from "/etc/mailname" (Debian) */
+ add_domainname(git_default_email + len,
+ sizeof(git_default_email) - len);
}
static void setup_ident(void)
--
1.7.7.rc1
^ permalink raw reply related
* 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
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