* Re: why does git perpetually complain about include/asm-blackfin/macros.h?
From: Sam Ravnborg @ 2007-07-14 7:45 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alex Riesen, Jesper Juhl, Robert P. J. Day,
Linux Kernel Mailing List, Git Mailing List, Linus Torvalds
In-Reply-To: <46890DA8.4070400@garzik.org>
On Mon, Jul 02, 2007 at 10:37:28AM -0400, Jeff Garzik wrote:
> Alex Riesen wrote:
> >Do some of your branches miss the commit by which it was removed?
>
> git-clone followed by git-checkout master recreates the problem.
>
> But to answer your question directly, I rebase, so they absolutely do
> not miss any commits.
>
>
> >It is somewhat unclear what "reappear" means, though: do you mean
>
> Attempts to give you precise output to answer your question yielded a
> data point, the kernel's "make distclean" causes this:
>
> [jgarzik@pretzel linux-2.6]$ make distclean && git checkout master &&
> git diff HEAD
> D include/asm-blackfin/macros.h
> Switched to branch "master"
> diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h
> deleted file mode 100644
> index e69de29..0000000
>
> [jgarzik@pretzel linux-2.6]$ git checkout -f
>
> [jgarzik@pretzel linux-2.6]$ make distclean && git checkout master &&
> git diff HEAD
> D include/asm-blackfin/macros.h
> Switched to branch "master"
> diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h
> deleted file mode 100644
> index e69de29..0000000
>
> [jgarzik@pretzel linux-2.6]$ git checkout -f
>
> [jgarzik@pretzel linux-2.6]$ git checkout master && git diff
> HEADSwitched to branch "master"
>
> [jgarzik@pretzel linux-2.6]$ git checkout master && git diff HEAD
> Switched to branch "master"
>
> [jgarzik@pretzel linux-2.6]$
>
>
> So, not a git problem but a kernel Makefile problem. Sorry for the git
> noise.
distclean on purpose delete zero size files.
And the kernel tree shall not contain such files - if it does it is a bug.
So I do not see a 'problem' with the kernel makefile but instead a problem
with the kernel tree wich is about to be fixed.
Agree?
Sam
^ permalink raw reply
* Re: [PATCH] remote: document the 'rm' subcommand
From: Junio C Hamano @ 2007-07-14 7:41 UTC (permalink / raw)
To: James Bowes; +Cc: Johannes Schindelin, git
In-Reply-To: <7vodio6ivo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Care to resend a three-patch series (implementation, this
> documentation, and test suite updates)?
It seems that this has to miss the boat for 1.5.3...
^ permalink raw reply
* Re: [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Junio C Hamano @ 2007-07-14 7:16 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Johannes Schindelin
In-Reply-To: <7vfy3rlbnp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Although I would not be using it often myself, I think this
> would make "git rm" more pleasant to use.
>
> Thanks for the patch, and my thanks also go to people who
> commented on the patch.
Having said that, I think this comment is not quite right.
+ else if (!index_only) {
+ /* It's not dangerous to git-rm --cached a
+ * file if the index matches the file or the
+ * HEAD, since it means the deleted content is
+ * still available somewhere.
+ */
Personally I do not think "rm --cached" needs any such "safety",
even though I'll keep the check for now, primarily because
loosening the restriction later is always easier than adding new
restriction. I really do not think this is about protecting the
user from "deleted content is not available anywhere else".
In this sequence:
edit a-new-file
git add a-new-file
edit a-new-file
git add a-new-file
we do not complain, even though we are *losing* the contents we
earlier staged. If you replace the second "git add" with
"git-rm --cached", the sequence should work the same way. In
either case, you are working towards your next commit, and most
likely are doing a partial commit (iow, your working tree does
not match any of the commit you create in the middle). Earlier
you thought you would want one state of the file in the next
commit, but now you decided against putting that new file in the
first commit in the series. You may make further updates to the
index and would make a commit, but after making the commit, your
working tree still has "a-new-file" and you can add the contents
from it for the later commit.
^ permalink raw reply
* Re: [PATCH] Fix git-rebase -i to allow squashing of fast-forwardable commits
From: Andy Parkins @ 2007-07-14 7:09 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Alex Riesen, Johannes Schindelin
In-Reply-To: <7vejjbmtva.fsf@assigned-by-dhcp.cox.net>
On Saturday 2007, July 14, Junio C Hamano wrote:
> I think this makes sense. Thanks for fixing it up.
I was experiencing the problem, and this patch fixed it.
Acked-by: Andy Parkins
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] Wire new date formats to --date=<format> parser.
From: Junio C Hamano @ 2007-07-14 6:54 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git, Robin Rosenberg
In-Reply-To: <20070714064451.GH11809@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> On Fri, 2007-07-13 23:43:00 -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> --- a/revision.c
>> +++ b/revision.c
>> @@ -1133,6 +1133,14 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
>> if (!strncmp(arg, "--date=", 7)) {
>> if (!strcmp(arg + 7, "relative"))
>> revs->date_mode = DATE_RELATIVE;
>> + else if (!strcmp(arg + 7, "iso8601") ||
>> + !strcmp(arg + 7, "iso"))
>> + revs->date_mode = DATE_ISO8601;
>> + else if (!strcmp(arg + 7, "rfc2822") ||
>> + !strcmp(arg + 7, "rfc"))
>
> Maybe also add "rfc822"?
I've thought about it, but did not bother; I suspect people would
just say "rfc" anyway.
^ permalink raw reply
* Re: [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Junio C Hamano @ 2007-07-14 6:52 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Johannes Schindelin
In-Reply-To: <11843484982037-git-send-email-Matthieu.Moy@imag.fr>
Although I would not be using it often myself, I think this
would make "git rm" more pleasant to use.
Thanks for the patch, and my thanks also go to people who
commented on the patch.
^ permalink raw reply
* [PATCH] Document new --date=<format>
From: Junio C Hamano @ 2007-07-14 6:49 UTC (permalink / raw)
To: git; +Cc: Robin Rosenberg
In-Reply-To: <20070713225836.17922.32546.stgit@lathund.dewire.com>
Now, git-log family can take full range of internally supported date format
to their --date=<format> argument. Document it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* And the documentation...
Documentation/git-rev-list.txt | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 20dcac6..08e7573 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -28,7 +28,7 @@ SYNOPSIS
[ \--encoding[=<encoding>] ]
[ \--(author|committer|grep)=<pattern> ]
[ \--regexp-ignore-case ] [ \--extended-regexp ]
- [ \--date={local|relative|default} ]
+ [ \--date={local|relative|default|iso|rfc|short} ]
[ [\--objects | \--objects-edge] [ \--unpacked ] ]
[ \--pretty | \--header ]
[ \--bisect ]
@@ -96,7 +96,7 @@ include::pretty-options.txt[]
Synonym for `--date=relative`.
---date={relative,local,default}::
+--date={relative,local,default,iso,rfc}::
Only takes effect for dates shown in human-readable format, such
as when using "--pretty".
@@ -106,6 +106,13 @@ e.g. "2 hours ago".
+
`--date=local` shows timestamps in user's local timezone.
+
+`--date=iso` (or `--date=iso8601`) shows timestamps in ISO 8601 format.
++
+`--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822
+format, often found in E-mail messages.
++
+`--date=short` shows only date but not time, in `YYYY-MM-DD` fomat.
++
`--date=default` shows timestamps in the original timezone
(either committer's or author's).
--
1.5.3.rc1.4.gaf83
^ permalink raw reply related
* Re: [PATCH 2/2] Wire new date formats to --date=<format> parser.
From: Jan-Benedict Glaw @ 2007-07-14 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Robin Rosenberg
In-Reply-To: <7vodiflc3v.fsf_-_@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]
On Fri, 2007-07-13 23:43:00 -0700, Junio C Hamano <gitster@pobox.com> wrote:
> --- a/revision.c
> +++ b/revision.c
> @@ -1133,6 +1133,14 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
> if (!strncmp(arg, "--date=", 7)) {
> if (!strcmp(arg + 7, "relative"))
> revs->date_mode = DATE_RELATIVE;
> + else if (!strcmp(arg + 7, "iso8601") ||
> + !strcmp(arg + 7, "iso"))
> + revs->date_mode = DATE_ISO8601;
> + else if (!strcmp(arg + 7, "rfc2822") ||
> + !strcmp(arg + 7, "rfc"))
Maybe also add "rfc822"?
> + revs->date_mode = DATE_RFC2822;
> + else if (!strcmp(arg + 7, "short"))
> + revs->date_mode = DATE_SHORT;
> else if (!strcmp(arg + 7, "local"))
> revs->date_mode = DATE_LOCAL;
> else if (!strcmp(arg + 7, "default"))
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
the second :
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/2] Wire new date formats to --date=<format> parser.
From: Junio C Hamano @ 2007-07-14 6:43 UTC (permalink / raw)
To: git; +Cc: Robin Rosenberg
In-Reply-To: <20070713225836.17922.32546.stgit@lathund.dewire.com>
Now we can use all internally supported date formats with
git log --date=<format>
syntax. Earlier, we only allowed relative/local/default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index 27cce09..28b5f2e 100644
--- a/revision.c
+++ b/revision.c
@@ -1133,6 +1133,14 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (!strncmp(arg, "--date=", 7)) {
if (!strcmp(arg + 7, "relative"))
revs->date_mode = DATE_RELATIVE;
+ else if (!strcmp(arg + 7, "iso8601") ||
+ !strcmp(arg + 7, "iso"))
+ revs->date_mode = DATE_ISO8601;
+ else if (!strcmp(arg + 7, "rfc2822") ||
+ !strcmp(arg + 7, "rfc"))
+ revs->date_mode = DATE_RFC2822;
+ else if (!strcmp(arg + 7, "short"))
+ revs->date_mode = DATE_SHORT;
else if (!strcmp(arg + 7, "local"))
revs->date_mode = DATE_LOCAL;
else if (!strcmp(arg + 7, "default"))
--
1.5.3.rc1.4.gaf83
^ permalink raw reply related
* [PATCH 1/2] Make show_rfc2822_date() just another date output format.
From: Junio C Hamano @ 2007-07-14 6:42 UTC (permalink / raw)
To: git; +Cc: Robin Rosenberg
In-Reply-To: <20070713225836.17922.32546.stgit@lathund.dewire.com>
These days, show_date() takes a date_mode parameter to specify
the output format, and a separate specialized function for dates
in E-mails does not make much sense anymore.
This retires show_rfc2822_date() function and make it just
another date output format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> Updated docs too. The show --date is not included because I didn't know
> about it.
Thanks. Here is what I had in mind when I "wondered" aloud earlier...
cache.h | 11 +++++++++--
commit.c | 8 ++++----
date.c | 20 +++++---------------
refs.c | 4 ++--
sha1_name.c | 2 +-
5 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/cache.h b/cache.h
index b39557d..328c1ad 100644
--- a/cache.h
+++ b/cache.h
@@ -409,9 +409,16 @@ extern void *read_object_with_reference(const unsigned char *sha1,
unsigned long *size,
unsigned char *sha1_ret);
-enum date_mode { DATE_NORMAL = 0, DATE_RELATIVE, DATE_SHORT, DATE_LOCAL, DATE_ISO8601 };
+enum date_mode {
+ DATE_NORMAL = 0,
+ DATE_RELATIVE,
+ DATE_SHORT,
+ DATE_LOCAL,
+ DATE_ISO8601,
+ DATE_RFC2822
+};
+
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
-const char *show_rfc2822_date(unsigned long time, int timezone);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
diff --git a/commit.c b/commit.c
index d11941c..4c5dfa9 100644
--- a/commit.c
+++ b/commit.c
@@ -585,7 +585,7 @@ static int add_user_info(const char *what, enum cmit_fmt fmt, char *buf,
break;
case CMIT_FMT_EMAIL:
ret += sprintf(buf + ret, "Date: %s\n",
- show_rfc2822_date(time, tz));
+ show_date(time, tz, DATE_RFC2822));
break;
case CMIT_FMT_FULLER:
ret += sprintf(buf + ret, "%sDate: %s\n", what,
@@ -778,9 +778,9 @@ static void fill_person(struct interp *table, const char *msg, int len)
tz = -tz;
}
- interp_set_entry(table, 2, show_date(date, tz, 0));
- interp_set_entry(table, 3, show_rfc2822_date(date, tz));
- interp_set_entry(table, 4, show_date(date, tz, 1));
+ interp_set_entry(table, 2, show_date(date, tz, DATE_NORMAL));
+ interp_set_entry(table, 3, show_date(date, tz, DATE_RFC2822));
+ interp_set_entry(table, 4, show_date(date, tz, DATE_RELATIVE));
interp_set_entry(table, 6, show_date(date, tz, DATE_ISO8601));
}
diff --git a/date.c b/date.c
index 735d8f3..45b0b1d 100644
--- a/date.c
+++ b/date.c
@@ -144,6 +144,11 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec,
tz);
+ else if (mode == DATE_RFC2822)
+ sprintf(timebuf, "%.3s, %d %.3s %d %02d:%02d:%02d %+05d",
+ weekday_names[tm->tm_wday], tm->tm_mday,
+ month_names[tm->tm_mon], tm->tm_year + 1900,
+ tm->tm_hour, tm->tm_min, tm->tm_sec, tz);
else
sprintf(timebuf, "%.3s %.3s %d %02d:%02d:%02d %d%c%+05d",
weekday_names[tm->tm_wday],
@@ -156,21 +161,6 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
return timebuf;
}
-const char *show_rfc2822_date(unsigned long time, int tz)
-{
- struct tm *tm;
- static char timebuf[200];
-
- tm = time_to_tm(time, tz);
- if (!tm)
- return NULL;
- sprintf(timebuf, "%.3s, %d %.3s %d %02d:%02d:%02d %+05d",
- weekday_names[tm->tm_wday], tm->tm_mday,
- month_names[tm->tm_mon], tm->tm_year + 1900,
- tm->tm_hour, tm->tm_min, tm->tm_sec, tz);
- return timebuf;
-}
-
/*
* Check these. And note how it doesn't do the summer-time conversion.
*
diff --git a/refs.c b/refs.c
index 4dc7e8b..2694e70 100644
--- a/refs.c
+++ b/refs.c
@@ -1300,7 +1300,7 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
if (hashcmp(logged_sha1, sha1)) {
fprintf(stderr,
"warning: Log %s has gap after %s.\n",
- logfile, show_rfc2822_date(date, tz));
+ logfile, show_date(date, tz, DATE_RFC2822));
}
}
else if (date == at_time) {
@@ -1313,7 +1313,7 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
if (hashcmp(logged_sha1, sha1)) {
fprintf(stderr,
"warning: Log %s unexpectedly ended on %s.\n",
- logfile, show_rfc2822_date(date, tz));
+ logfile, show_date(date, tz, DATE_RFC2822));
}
}
munmap(log_mapped, mapsz);
diff --git a/sha1_name.c b/sha1_name.c
index 858f08c..2d727d5 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -370,7 +370,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
fprintf(stderr,
"warning: Log for '%.*s' only goes "
"back to %s.\n", len, str,
- show_rfc2822_date(co_time, co_tz));
+ show_date(co_time, co_tz, DATE_RFC2822));
else
fprintf(stderr,
"warning: Log for '%.*s' only has "
--
1.5.3.rc1.4.gaf83
^ permalink raw reply related
* Re: failing to send patches to the list
From: martin f krafft @ 2007-07-14 6:05 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <81b0412b0707130557g6cf04365j232654734b148c3f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
also sprach Alex Riesen <raa.lkml@gmail.com> [2007.07.13.1457 +0200]:
> I suggest you try "git format-patch -s --stdout |less" before
> sending format-patch without parameters produces nothing.
I did. I simply misquoted in the email. Fact is that sendmail did
send an email, which VGER recognised to be a diff; yet it never
showed up.
I think the missing message ID is likely the problem. I'll look into
it.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
humpty was pushed.
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix git-rebase -i to allow squashing of fast-forwardable commits
From: Junio C Hamano @ 2007-07-14 5:34 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Johannes Schindelin
In-Reply-To: <20070712223035.GB30532@steel.home>
I think this makes sense. Thanks for fixing it up.
^ permalink raw reply
* Re: CVS -> SVN -> Git
From: Martin Langhoff @ 2007-07-14 5:30 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Julian Phillips, git
In-Reply-To: <469804B4.1040509@alum.mit.edu>
On 7/14/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Incidentally, now that cvs2svn 2.0.0 is nearly out, I am thinking about
> what it would take to write some other back ends for cvs2svn--turning
> it, essentially, into cvs2xxx. Most of the work that cvs2svn does is
> inferring the most plausible history of the repository from CVS's
> sketchy, incomplete, idiomatic, and often corrupt data. This work
> should also be useful for a cvs2git or cvs2hg or cvs2baz or ...
Great to hear that. I'm game if we can do something in this direction
- surely we can make it talk to fastimport ;-)
Does cvs2svn handle incremental imports, remembering any "guesses"
taken earlier? Last time I looked at it, it had far better logic than
cvsps, but it didn't do incremental imports, and repeated imports done
at different times would "guess" different branching points for new
branches, so it _really_ didn't support incrementals
cheers,
m
^ permalink raw reply
* Re: [PATCH] git-reset: allow --soft in a bare repo
From: Jeff King @ 2007-07-14 5:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vir8nmujo.fsf@assigned-by-dhcp.cox.net>
On Fri, Jul 13, 2007 at 10:19:23PM -0700, Junio C Hamano wrote:
> > Somebody asked about this on irc ("how do I rewind history in a bare
> > repo"). The only other ways right now are to update the ref manually
> > (which involves plumbing), or to "git-push -f" from a non-bare
> > repository. I can't think of any good reason why a soft reset shouldn't
> > be allowed.
>
> How about "git branch -f this $that"???
Ah, I hadn't thought of that. It seems a bit of a contortion, though,
since git-branch is usually used for _making_ a branch, whereas
git-reset is usually used for _changing_ a branch. But maybe that's just
me.
At any rate, it might still be worth applying the patch. It should be
harmless to loosen the restriction, and even if there are several ways
to accomplish the same thing, why punish people who try git-reset first?
On the other hand, this is the first time I've seen it come up, so maybe
this isn't confusing people.
-Peff
^ permalink raw reply
* Re: [PATCH] git-reset: allow --soft in a bare repo
From: Junio C Hamano @ 2007-07-14 5:19 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070714044916.GA24911@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Previously, git-reset always required a work directory. For
> --mixed and --hard resets, this makes sense, as the bare
> repo doesn't have an index or a working tree. However, for
> --soft, there's no reason to prohibit this behavior.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Somebody asked about this on irc ("how do I rewind history in a bare
> repo"). The only other ways right now are to update the ref manually
> (which involves plumbing), or to "git-push -f" from a non-bare
> repository. I can't think of any good reason why a soft reset shouldn't
> be allowed.
How about "git branch -f this $that"???
^ permalink raw reply
* [PATCH] git-reset: allow --soft in a bare repo
From: Jeff King @ 2007-07-14 4:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Previously, git-reset always required a work directory. For
--mixed and --hard resets, this makes sense, as the bare
repo doesn't have an index or a working tree. However, for
--soft, there's no reason to prohibit this behavior.
Signed-off-by: Jeff King <peff@peff.net>
---
Somebody asked about this on irc ("how do I rewind history in a bare
repo"). The only other ways right now are to update the ref manually
(which involves plumbing), or to "git-push -f" from a non-bare
repository. I can't think of any good reason why a soft reset shouldn't
be allowed.
git-reset.sh | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/git-reset.sh b/git-reset.sh
index 1dc606f..5450289 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -6,7 +6,6 @@ USAGE='[--mixed | --soft | --hard] [<commit-ish>] [ [--] <paths>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
set_reflog_action "reset $*"
-require_work_tree
update= reset_type=--mixed
unset rev
@@ -32,6 +31,13 @@ do
shift
done
+case "$reset_type" in
+ --soft)
+ ;;
+ *)
+ require_work_tree
+esac
+
: ${rev=HEAD}
rev=$(git rev-parse --verify $rev^0) || exit
--
1.5.3.rc1.807.g51fb9-dirty
^ permalink raw reply related
* Re: [PATCH] make git-send-email.perl handle email addresses with no names when Email::Valid is present
From: Greg KH @ 2007-07-14 4:00 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Junio C Hamano, git
In-Reply-To: <20070713182818.fd37372f.sfr@canb.auug.org.au>
On Fri, Jul 13, 2007 at 06:28:18PM +1000, Stephen Rothwell wrote:
> On Thu, 12 Jul 2007 23:34:14 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Jul 12, 2007 at 10:47:17PM -0700, Junio C Hamano wrote:
> > > Greg KH <greg@kroah.com> writes:
> > >
> > > > When using git-send-email.perl on a changeset that has:
> > > > Cc: <stable@kernel.org>
> > > > in the body of the description, and the Email::Valid perl module is
> > > > installed on the system, the email address will be deemed "invalid" for
> > > > some reason (Email::Valid isn't smart enough to handle this?) and
> > > > complain and not send the address the email.
> > >
> > > That appears to be the case.
> > >
> > > bad foo
> > > bad <foo@bar.baz>
> > > ok foo@bar.baz
> > > ok Foo <foo@bar.baz>
>
> This would be a bug in Email::Valid as it complains that the second
> address fails the rfc822 check, however rfc822 says that the "display
> name" before the '<' is optional.
I agree, do you know how to get such a fix made?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Jeff King @ 2007-07-14 3:42 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <vpq8x9kp231.fsf@bauges.imag.fr>
On Fri, Jul 13, 2007 at 08:53:38PM +0200, Matthieu Moy wrote:
> do.". The behavior without --cached is not modified, except for the
> error message, and the previous was to require -f whenever the index
> doesn't match the head, *or* doesn't match the file. So, without
> --cached, you need to have file=index=HEAD to be able to git-rm.
>
> If I missunderstand you, please, provide a senario where my patch
> doesn't do the expected.
Right, my point was that there is a case where running without --cached
could lose content: when there is no working tree file. However,
thinking about it more, I recall that Junio made the point that allowing
that behavior means the CVS idiom of "rm file; git-rm file" will just
work.
Not that that was a problem you introduced; I merely wanted to push for
total consistency rather than just handling --cached. But I think the
non --cached behavior is actually right now, so let me retract my
complaint.
And assuming the "git-rm when no working tree file" current behavior is
OK, then I think your patch removes the last consistency problem that I
mentioned in my state table here:
http://article.gmane.org/gmane.comp.version-control.git/51449
So in a round-about way, I totally approve of your patch. Sorry for the
confusion.
-Peff
^ permalink raw reply
* Re: Possible to make a totally empty repository for remote access?
From: Jeff King @ 2007-07-14 2:59 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git
In-Reply-To: <20070714025819.GA22559@coredump.intra.peff.net>
On Fri, Jul 13, 2007 at 10:58:19PM -0400, Jeff King wrote:
> $ git-remote origin server:/pub/git/test.git
Sorry, this should be:
git-remote add origin server:/pub/git/test.git
-Peff
^ permalink raw reply
* Re: Possible to make a totally empty repository for remote access?
From: Jeff King @ 2007-07-14 2:58 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git
In-Reply-To: <95A1FBFA-DCB7-4767-B857-89660822C6E6@wincent.com>
On Sat, Jul 14, 2007 at 04:19:41AM +0200, Wincent Colaiuta wrote:
> To make such pushes easier in the future you can create a local shortcut
> file, .git/remotes/shortcut (or similar), with contents like:
>
> URL: git.server.example.com:/pub/git/test.git
> Push: master
The "new" way (by "new" I mean available for over a year, since v1.4.1)
is to put such configuration into your .git/config file:
[remote "shortcut"]
url = git.server.example.com:/pub/git/test.git
Though if this is going to be the upstream from which you will be
pushing and pulling, you may want to call it "origin" (which will make
it the default for pushing and pulling).
Even more simply, you can get the same remote config that git-clone
would have set up by using the git-remote command:
$ git-init
$ git-remote origin server:/pub/git/test.git
-Peff
^ permalink raw reply
* Re: Possible to make a totally empty repository for remote access?
From: Wincent Colaiuta @ 2007-07-14 2:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzs8lzgk.fsf@assigned-by-dhcp.cox.net>
El 14/7/2007, a las 0:18, Junio C Hamano escribió:
> Note that the private working place does not have to be a clone
> of the empty one. That actually is backwards. Your work
> started from your private working place to the publishing one.
Thanks very much for the clarification, Junio. I didn't realize I
could push like that (thought it had to be from a clone); that's very
flexible indeed.
For the benefit of others who might stumble across this question in
the archives, the basic pattern is:
# create the bare, empty public repository on the remote server:
mkdir test.git
cd test.git
git --bare init
touch git-daemon-export-ok
# locally, create some initial content
mkdir test
cd test
git init
vi foobar # etc
git add .
git commit -s
git tag -s v0.0.1
# push initial contents
git push git.server.example.com:/pub/git/test.git master
This assumes that you have git-daemon set up to provide public read-
only access, and appropriate SSH accounts and configuration for those
who need write access, but that's all fairly well documented
elsewhere (ie in the git-daemon man page, and in abundant information
on the web about setting up SSH access with public-key auth).
To make such pushes easier in the future you can create a local
shortcut file, .git/remotes/shortcut (or similar), with contents like:
URL: git.server.example.com:/pub/git/test.git
Push: master
If other developers will have write access to the remote repo then
you can add "Pull:" statements as well so as to keep up to date (as
detailed in the git-push man page, and in the "Everyday GIT With 20
Commands Or So" document: <http://www.kernel.org/pub/software/scm/git/
docs/everyday.html>), and you can synchronize multiple branches in
both directions by adding additional "Push:" and "Pull:"
declarations. With the shortcut file in place you could have written
the above push as:
git push shortcut
To push your initial tag you would do:
git push shortcut v.0.0.1
(Or you could have included the tag in the original push by passing
the --tags switch.)
One thing to note: the ".git/remotes/shortcut" file should not be
confused with the directories under ".git/refs/remotes".
Finally, now that the remote repository actually has some content in
it you also have the option of just creating a fresh local clone of
it, and thus benefitting from the automatic set-up that "git clone"
does for you:
git clone git://git.server.example.com/test
The Git documentation is shockingly good; almost too good: there is
so much of it that sometimes it can be hard to find exactly what
you're looking for. For reference, the "Git core tutorial for
developers" was the one place which I could find which explicitly
talked about the missing piece of the puzzle: pushing from a private
repo (not a clone) to an empty public one:
<http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html>
Cheers,
Wincent
^ permalink raw reply
* Re: mtimes of working files
From: Jakub Narebski @ 2007-07-14 1:29 UTC (permalink / raw)
To: git
In-Reply-To: <1184374174.2785.104.camel@shinybook.infradead.org>
David Woodhouse wrote:
> Branches have their place, and some people seem very happy with them as
> part of their local workflow. I just wonder if we have to have them on
> the servers too; that's all.
Multiple branches in one [public] repository help sharing data. While you
can do similar with sharing object database (via alternates mechanism)
the second solution has drawbacks the multiple branches didn't have.
IIRC multiple branches was not something _planned_ by Linus when creating
git; users requested this feature, and it turned out to be useful.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: failing to send patches to the list
From: Jakub Narebski @ 2007-07-14 0:58 UTC (permalink / raw)
To: git
In-Reply-To: <20070713093050.GA18001@lapse.madduck.net>
martin f krafft wrote:
> Subject: [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available
>
> Uses $(CPP) to attempt to preprocess an include <openssl/sha.h> directive. If
> that fails, NO_OPENSSL is defined, causing the Makefile to fall back to using
> mozilla's SHA implementation.
Shouldn't this be rather in configure.in? Main Makefile has only defaults
for different systems, but does not do tests.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: mtimes of working files
From: David Woodhouse @ 2007-07-14 0:49 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Linus Torvalds, Theodore Tso, Andy Parkins, git, Jan Hudec,
Johannes Schindelin
In-Reply-To: <20070714004433.GB10131@fieldses.org>
On Fri, 2007-07-13 at 20:44 -0400, J. Bruce Fields wrote:
> On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:
> > Yeah, much of it. Although I've also seen other people trying to get
> > to grips with git and tripping up over branches recently.
>
> Could you give any details? What specifically was it they were having
> trouble with?
Just conversations on IRC where stuff had to be explained. People not
understanding that they'd actually cloned _multiple_ branches and they
needed to select the one they wanted, making the same kind of stupid
mistakes I did with committing to the wrong place, etc. Nothing specific
stands out as being fixable, certainly.
Branches have their place, and some people seem very happy with them as
part of their local workflow. I just wonder if we have to have them on
the servers too; that's all.
--
dwmw2
^ permalink raw reply
* Re: mtimes of working files
From: J. Bruce Fields @ 2007-07-14 0:44 UTC (permalink / raw)
To: David Woodhouse
Cc: Linus Torvalds, Theodore Tso, Andy Parkins, git, Jan Hudec,
Johannes Schindelin
In-Reply-To: <1184373393.2785.99.camel@shinybook.infradead.org>
On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:
> Yeah, much of it. Although I've also seen other people trying to get to
> grips with git and tripping up over branches recently.
Could you give any details? What specifically was it they were having
trouble with?
--b.
^ 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