* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Andy Parkins @ 2007-05-14 22:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <7v646vo3pn.fsf@assigned-by-dhcp.cox.net>
On Monday 2007, May 14, Junio C Hamano wrote:
> My take when I did the $ident$ stuff on this issue was quite the
> opposite. CVS "$Id$" means quite a different thing (pathname,
You're right, but I think it's intended as a unique identifier rather
than that specific information. If that were wanted by a CVS/SVN user
they would have used $Author$, $Rev$, $Date$, etc. $Id$ to me was just
some way of identifying the file its in uniquely - the fact that git
has a much better way of doing that is a bonus, and is exactly right
for $Id$ IMHO.
> per-file revision number, date, and status) and it would not be
> right to overwrite it with $ident$ which does not record any of
> those "context sensitive" information.
It would be perfectly correct to overwrite it, as in the repository
version none of that information is present, and even if it wasn't, as
we've discussed at length, it's all meaningless in a git context
anyway - the best thing that you could do for it _is_ overwrite it.
> I did not think other systems making that mistake was not an
> excuse for us to do so, but on the other hand, if the users of
> those other systems are happy to lose the information from CVS
> then perhaps the users do want $Id$.
As I said, there is no information in that field when we import from
CVS/SVN - the repository versions are stored with the fields
collapsed - so you are not overwriting anything, and therefore not
losing information.
> Obviously I do not care much about this feature and I have not
> look at Andy's patch too deeply yet, but in any case I think the
> inverse conversion needs to be modified to match it, if it
> hasn't been done so.
I believe I did the inverse conversion as well. It's only rough, in the
end I don't care much either way - I've already converted everything of
mine to git so it affects me not at all. I offer it only as a
suggestion for imports from other repositories.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Implement packed refs
From: Shawn O. Pearce @ 2007-05-14 22:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <11790995571637-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> index 76191be..3b2a82c 100644
> @@ -411,6 +412,10 @@ public class Repository {
> private Ref readRefBasic(String name) throws IOException {
> int depth = 0;
> REF_READING: do {
> + ObjectId id = packedRefs.get(name);
> + if (id != null)
> + return new Ref(null, id);
> +
> final File f = new File(getDirectory(), name);
> if (!f.isFile()) {
> return new Ref(f, null);
This is actually backwards. Git checks the loose ref first, and
then the packed ref. The reason is so that users can pack all
of their refs (git pack-refs --all) and then just create new ref
files for those that they change, rather than rewriting the entire
packed-refs file over again.
I'm adding a commit after your series to correct this.
> + } catch (IOException e) {
> + e.printStackTrace();
> + }
We really should be throwing exceptions back to the caller,
especially on things that could indicate corruption or other
problems with reading the repository contents.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Implement packed refs
From: Robin Rosenberg @ 2007-05-14 22:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070514224533.GA28832@spearce.org>
tisdag 15 maj 2007 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> > index 76191be..3b2a82c 100644
> > @@ -411,6 +412,10 @@ public class Repository {
> > private Ref readRefBasic(String name) throws IOException {
> > int depth = 0;
> > REF_READING: do {
> > + ObjectId id = packedRefs.get(name);
> > + if (id != null)
> > + return new Ref(null, id);
> > +
> > final File f = new File(getDirectory(), name);
> > if (!f.isFile()) {
> > return new Ref(f, null);
>
> This is actually backwards. Git checks the loose ref first, and
> then the packed ref. The reason is so that users can pack all
> of their refs (git pack-refs --all) and then just create new ref
> files for those that they change, rather than rewriting the entire
> packed-refs file over again.
>
> I'm adding a commit after your series to correct this.
Thanks.
> > + } catch (IOException e) {
> > + e.printStackTrace();
> > + }
>
> We really should be throwing exceptions back to the caller,
> especially on things that could indicate corruption or other
> problems with reading the repository contents.
Well, [looking for something to blame]...
-- robin
^ permalink raw reply
* RE: git as a backup tool?
From: Ron Parker @ 2007-05-14 22:53 UTC (permalink / raw)
To: Geert Uytterhoeven, git
In-Reply-To: <Pine.LNX.4.64.0705141334120.20215@anakin>
> Geert Uytterhoeven wrote:
> Has anyone considered using git as a backup tool? I.e.
At the very least you would have a lot of chgrp/chown work to do after a
"restore". Git stores file mode, but not ownership information, ACL's
or extended attributes.
I found this out when I tried using git to backup part of BOINC
development server. Various files and directories had to have different
ownership and extended attributes (for SELinux).
--
Ron Parker
^ permalink raw reply
* [PATCH] gitweb: Add a few comments about %feature hash
From: Jakub Narebski @ 2007-05-14 23:55 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c2eeca9..a13043d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -102,10 +102,13 @@ our %feature = (
# 'override' => allow-override (boolean),
# 'default' => [ default options...] (array reference)}
#
- # if feature is overridable (it means that allow-override has true value,
+ # if feature is overridable (it means that allow-override has true value),
# then feature-sub will be called with default options as parameters;
# return value of feature-sub indicates if to enable specified feature
#
+ # if there is no 'sub' key (no feature-sub), then feature cannot be
+ # overriden
+ #
# use gitweb_check_feature(<feature>) to check if <feature> is enabled
# Enable the 'blame' blob view, showing the last commit that modified
@@ -138,6 +141,7 @@ our %feature = (
# Enable text search, which will list the commits which match author,
# committer or commit text to a given string. Enabled by default.
+ # Project specific override is not supported.
'search' => {
'override' => 0,
'default' => [1]},
--
1.5.1.4
^ permalink raw reply related
* Re: [PATCH] git-am: Clean up the asciidoc documentation
From: Junio C Hamano @ 2007-05-15 0:01 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <11791538941022-git-send-email-frank@lichtenheld.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> -i, --interactive::
> - Run interactively, just like git-applymbox.
> + Run interactively, just like `git-applymbox` (see gitlink:git-applymbox[1]).
This is an unclear description from the original, but I think we
should say just like `git-applybox -i`, or drop this altogether.
> @@ -99,7 +102,7 @@ message, and commit author time is taken from the "Date: " line
> of the message. The "Subject: " line is used as the title of
> the commit, after stripping common prefix "[PATCH <anything>]".
> It is supposed to describe what the commit is about concisely as
> -a one line text.
> +an one line text.
I think 'one' does not begin with a vowel.
Other than that, I would agree everything in your update is a
clear improvement.
^ permalink raw reply
* Re: [PATCH] Documentation: format-patch has no --mbox option
From: Junio C Hamano @ 2007-05-15 0:03 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <11791538941530-git-send-email-frank@lichtenheld.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> git-applymbox and git-mailinfo refer to a --mbox
> option of git-format-patch. But there is no such
> option AFAICT. mbox output can produced with
> format-patch --stdout.
>
> This patch only replaces --mbox with --stdout.
> Some further explanation and/or format-patch
> arguments (e.g. -k) might be needed.
I would agree. "Reads single mbox with one or more patches in
it, without munging the subject line" is what it really does, so
we obviously mean "--stdout -k >mbox" here.
^ permalink raw reply
* Re: [PATCH 02/10] user-manual: revise birdseye-view chapter
From: Junio C Hamano @ 2007-05-15 0:07 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, Johannes Schindelin
In-Reply-To: <30964.7168651738$1179156134@news.gmane.org>
"J. Bruce Fields" <bfields@citi.umich.edu> writes:
> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> Some revisions suggested by Junio along with some minor style fixes and
> one compile fix (asterisks need escaping).
>
> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
> ---
> Documentation/user-manual.txt | 43 +++++++++++++++++++---------------------
> 1 files changed, 20 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index bac9660..7abdc3e 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3161,8 +3161,12 @@ contrast, running "git prune" while somebody is actively changing the
> repository is a *BAD* idea).
>
> [[birdview-on-the-source-code]]
> -A birdview on Git's source code
> ------------------------------
> +A birds-eye view of Git's source code
> +-------------------------------------
> +
> +It is not always easy for new developers to find their way through Git's
> +source code. This section gives you a gentle guidance to show where to
> +start.
>
> While Git's source code is quite elegant, it is not always easy for
> new developers to find their way through it. A good idea is to look
Perhaps you meant to drop this first sentence "While ... through
it." from the original?
^ permalink raw reply
* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Junio C Hamano @ 2007-05-15 0:17 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Johannes Sixt
In-Reply-To: <200705142324.02929.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> It would be perfectly correct to overwrite it, as in the repository
> version none of that information is present, and even if it wasn't, as
> we've discussed at length, it's all meaningless in a git context
> anyway - the best thing that you could do for it _is_ overwrite it.
Ok, you are right, and we should obviously do this before v1.5.2
final.
^ permalink raw reply
* Re: [PATCH] Documentation: format-patch has no --mbox option
From: Junio C Hamano @ 2007-05-15 0:20 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <7v8xbrlzqk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Frank Lichtenheld <frank@lichtenheld.de> writes:
>
>> git-applymbox and git-mailinfo refer to a --mbox
>> option of git-format-patch. But there is no such
>> option AFAICT. mbox output can produced with
>> format-patch --stdout.
>>
>> This patch only replaces --mbox with --stdout.
>> Some further explanation and/or format-patch
>> arguments (e.g. -k) might be needed.
>
> I would agree. "Reads single mbox with one or more patches in
> it, without munging the subject line" is what it really does, so
> we obviously mean "--stdout -k >mbox" here.
Come to think of it, "no munging of Subject lines" is orthogonal
to the number of patches in a file, so it should say that the
option corresponds to -k in format-patch, I think.
So, I think we can just do s/--mbox/-k/, instead of s/--mbox/--stdout/
which is what you did.
^ permalink raw reply
* Re: [PATCH] gitweb: Add a few comments about %feature hash
From: Junio C Hamano @ 2007-05-15 0:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11791869442413-git-send-email-jnareb@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Junio C Hamano @ 2007-05-15 2:03 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Johannes Sixt
In-Reply-To: <200705142324.02929.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Monday 2007, May 14, Junio C Hamano wrote:
>
>> Obviously I do not care much about this feature and I have not
>> look at Andy's patch too deeply yet, but in any case I think the
>> inverse conversion needs to be modified to match it, if it
>> hasn't been done so.
>
> I believe I did the inverse conversion as well.
I think this on top of your patch would be the minimum necessary
for v1.5.2.
Documentation/RelNotes-1.5.2.txt | 2 +-
Documentation/gitattributes.txt | 6 +++---
convert.c | 14 +++++++-------
t/t0021-conversion.sh | 4 ++--
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/RelNotes-1.5.2.txt b/Documentation/RelNotes-1.5.2.txt
index d1c2cac..7dbdb26 100644
--- a/Documentation/RelNotes-1.5.2.txt
+++ b/Documentation/RelNotes-1.5.2.txt
@@ -26,7 +26,7 @@ Updates since v1.5.1
considered a binary or text (the former would be treated by
'git diff' not to produce textual output; the latter can go
through the line endings conversion process in repositories
- with core.autocrlf set), expand and unexpand '$ident$' keyword
+ with core.autocrlf set), expand and unexpand '$Id$' keyword
with blob object name, specify a custom 3-way merge driver,
and specify a custom diff driver. You can also apply
arbitrary filter to contents on check-in/check-out codepath
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 8772310..d3ac9c7 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -138,11 +138,11 @@ upon checkout.
^^^^^^^
When the attribute `ident` is set to a path, git replaces
-`$ident$` in the blob object with `$ident:`, followed by
+`$Id$` in the blob object with `$Id:`, followed by
40-character hexadecimal blob object name, followed by a dollar
sign `$` upon checkout. Any byte sequence that begins with
-`$ident:` and ends with `$` in the worktree file is replaced
-with `$ident$` upon check-in.
+`$Id:` and ends with `$` in the worktree file is replaced
+with `$Id$` upon check-in.
Interaction between checkin/checkout attributes
diff --git a/convert.c b/convert.c
index c46ab1b..12abdaf 100644
--- a/convert.c
+++ b/convert.c
@@ -422,20 +422,20 @@ static int count_ident(const char *cp, unsigned long size)
size--;
if (ch != '$')
continue;
- if (size < 6)
+ if (size < 3)
break;
- if (memcmp("ident", cp, 5))
+ if (memcmp("Id", cp, 2))
continue;
- ch = cp[5];
- cp += 6;
- size -= 6;
+ ch = cp[2];
+ cp += 3;
+ size -= 3;
if (ch == '$')
- cnt++; /* $ident$ */
+ cnt++; /* $Id$ */
if (ch != ':')
continue;
/*
- * "$ident: ... "; scan up to the closing dollar sign and discard.
+ * "$Id: ... "; scan up to the closing dollar sign and discard.
*/
while (size) {
ch = *cp++;
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index bab9ecc..6c26fd8 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -21,7 +21,7 @@ test_expect_success setup '
{
echo a b c d e f g h i j k l m
echo n o p q r s t u v w x y z
- echo '\''$ident$'\''
+ echo '\''$Id$'\''
} >test &&
cat test >test.t &&
cat test >test.o &&
@@ -31,7 +31,7 @@ test_expect_success setup '
git checkout -- test test.t test.i
'
-script='s/^\$ident: \([0-9a-f]*\) \$/\1/p'
+script='s/^\$Id: \([0-9a-f]*\) \$/\1/p'
test_expect_success check '
^ permalink raw reply related
* Re: kernel cherry UN-picking?
From: Josef Sipek @ 2007-05-15 2:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jeff Garzik, Git Mailing List, Linus Torvalds
In-Reply-To: <20070511145509.09f3c354.akpm@linux-foundation.org>
On Fri, May 11, 2007 at 02:55:09PM -0700, Andrew Morton wrote:
> On Fri, 11 May 2007 17:31:14 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>
> > So, I merge the next batch of net driver patches. After I merge a PPP
> > patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent
> > that to you, don't apply it" ;-)
>
> I'm bad.
>
> > Right now, my process for reversing this damage is to start over:
> > create a new branch, manually double-click the mouse on each commit in
> > the "damaged" branch, and git-cherrypick it. Very, very time consuming
> > when you have more than a couple commits.
> >
> > Is there a better way?
> > Is there any way to say "cherrypick all commits except <these>"?
>
> Let me refactor your question more usefully. What we want is quilt-export
> and quilt-import. And I really mean that: commands called git-quilt-export
> and git-quilt-import.
>
> coz then, your problem becomes
>
> git-quilt-export
> <delete one line from the series file>
> git-quilt-import
<shameless plug>
You can use Guilt:
$ guilt-init
$ guilt-import-commit <the bad commit hash>^..
$ $EDITOR .git/patches/$branch/series
# remove the offending line from the series file
$ guilt-push -a
$ rm -rf .git/patches/$branch
</shameless plug>
Josef "Jeff" Sipek.
--
All science is either physics or stamp collecting.
- Ernest Rutherford
^ permalink raw reply
* torvalds talk on youtube
From: Han-Wen Nienhuys @ 2007-05-15 2:41 UTC (permalink / raw)
To: git
In case you haven't noticed yet, the talk that Linus gave on Git
at Google is now on YouTube.
See:
http://www.youtube.com/watch?v=4XpnKHJAok8
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [PATCH] Documentation/branch: fix small typo in -D example
From: Quy Tonthat @ 2007-05-15 2:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
Documentation/git-branch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 603f87f..8dc5171 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -136,7 +136,7 @@ $ git branch -D test <2>
+
<1> delete remote-tracking branches "todo", "html", "man"
<2> delete "test" branch even if the "master" branch does not have all
-commits from todo branch.
+commits from test branch.
Notes
--
1.5.2.rc3.2q
^ permalink raw reply related
* Re: [PATCH 02/10] user-manual: revise birdseye-view chapter
From: J. Bruce Fields @ 2007-05-15 2:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v4pmflzkn.fsf@assigned-by-dhcp.cox.net>
On Mon, May 14, 2007 at 05:07:04PM -0700, Junio C Hamano wrote:
> Perhaps you meant to drop this first sentence "While ... through
> it." from the original?
Thanks, fixed.--b.
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: J. Bruce Fields @ 2007-05-15 4:50 UTC (permalink / raw)
To: Jeff King; +Cc: Karl Hasselström, git
In-Reply-To: <20070515042200.GA10884@coredump.intra.peff.net>
On Tue, May 15, 2007 at 12:22:00AM -0400, Jeff King wrote:
> Your original mail _does_ claim utf-8 for me. I wonder if Karl's mail is
> getting munged by something along the path (my path is straight from vger to a
> qmail server that I know is doing no munging). The headers I received, for
> reference:
Hm. Yes, so if I send that patch to myself with git-send-email, I see
the same thing as you:
...
> From: "J. Bruce Fields" <bfields@citi.umich.edu>
> To: Junio C Hamano <junkio@cox.net>
> Cc: git@vger.kernel.org,
> Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Subject: [PATCH 01/10] Add a birdview-on-the-source-code section to the user man
> ual
> Date: Mon, 14 May 2007 11:21:20 -0400
> Message-Id: <11791560893572-git-send-email->
> X-Mailer: git-send-email 1.5.1.4.19.g69e2
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
...
But the mail I got through the git list yesterday has some odd stuff in
it:
>From git-owner@vger.kernel.org Mon May 14 11:22:01 2007
Received: from vger.kernel.org ([209.132.176.167])
by fieldses.org with esmtp (Exim 4.67)
(envelope-from <git-owner@vger.kernel.org>)
id 1HncN6-00051C-Mh
for bfields@fieldses.org; Mon, 14 May 2007 11:22:01 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1755729AbXENPVe (ORCPT <rfc822;bfields@fieldses.org>);
Mon, 14 May 2007 11:21:34 -0400
X-Warning: Original message contained 8-bit characters, however during
the SMTP transport session the receiving system did not announce
capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
message does not have MIME headers (RFC 2045-2049) to enable
encoding change, we had very little choice.
X-Warning: We ASSUME it is less harmful to add the MIME headers, and
convert the text to Quoted-Printable, than not to do so,
and to strip the message to 7-bits.. (RFC 1428 Appendix A)
X-Warning: We don't know what character set the user used, thus we had to
write these MIME-headers with our local system default value.
MIME-Version: 1.0
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756250AbXENPVc
(ORCPT <rfc822;git-outgoing>); Mon, 14 May 2007 11:21:32 -0400
Received: from mail.fieldses.org ([66.93.2.214]:54954 "EHLO fieldses.org"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1755315AbXENPVb (ORCPT <rfc822;git@vger.kernel.org>);
Mon, 14 May 2007 11:21:31 -0400
Received: from bfields by fieldses.org with local (Exim 4.67)
(envelope-from <bfields@fieldses.org>)
id 1HncMb-0004z0-E7; Mon, 14 May 2007 11:21:29 -0400
From: "J. Bruce Fields" <bfields@citi.umich.edu>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
Date: Mon, 14 May 2007 11:21:20 -0400
Message-Id: <11791560893572-git-send-email->
X-Mailer: git-send-email 1.5.1.4.19.g69e2
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Status: RO
Any idea how that happened?
--b.
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Jeff King @ 2007-05-15 5:08 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Karl Hasselström, git
In-Reply-To: <20070515045044.GB2805@fieldses.org>
On Tue, May 15, 2007 at 12:50:44AM -0400, J. Bruce Fields wrote:
> But the mail I got through the git list yesterday has some odd stuff in
> it:
>
> From git-owner@vger.kernel.org Mon May 14 11:22:01 2007
> Received: from vger.kernel.org ([209.132.176.167])
> by fieldses.org with esmtp (Exim 4.67)
> (envelope-from <git-owner@vger.kernel.org>)
> id 1HncN6-00051C-Mh
> for bfields@fieldses.org; Mon, 14 May 2007 11:22:01 -0400
> Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
> id S1755729AbXENPVe (ORCPT <rfc822;bfields@fieldses.org>);
> Mon, 14 May 2007 11:21:34 -0400
> X-Warning: Original message contained 8-bit characters, however during
> the SMTP transport session the receiving system did not announce
> capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
> message does not have MIME headers (RFC 2045-2049) to enable
> encoding change, we had very little choice.
> X-Warning: We ASSUME it is less harmful to add the MIME headers, and
> convert the text to Quoted-Printable, than not to do so,
> and to strip the message to 7-bits.. (RFC 1428 Appendix A)
> X-Warning: We don't know what character set the user used, thus we had to
> write these MIME-headers with our local system default value.
> MIME-Version: 1.0
> Content-Transfer-Encoding: QUOTED-PRINTABLE
> Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Interesting. vger is correct in translating, since your mail server does
_not_ advertise the 8BITMIME extension (even though exim is 8-bit clean,
and could handle it).
However, the content-type is already specified, so it shouldn't need to
rewrite. However, I notice that your original message is missing a
MIME-Version: 1.0 header. My guess is that vger's logic is that without
that header, it can't trust the Content-Type you have provided (and
indeed, not including MIME-Version violates the MIME RFCs, I believe).
I assumed this was a bug in git-send-email, but looking closer, it
doesn't put in any mime information at all! So your sending smtp server
is adding in the content-type header, but it's failing to add the
MIME-Version header, which I think is a bug (I can dig up the RFC
reference if you want).
Arguably, git should be generating the full MIME header-set, since it
knows what actual encoding the message is in.
-Peff
^ permalink raw reply
* Re: git as a backup tool?
From: Russell @ 2007-05-15 5:09 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705141334120.20215@anakin>
On 5/14/07, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi,
>
> Has anyone considered using git as a backup tool? I.e.
> - put your whole file system in git
> - do `git add .; git commit -a' from cron
> - copy .git to external media once in a while
> - clean up old stuff (unused and older than xx days) from .git
I'm using git to backup my private email, all in Maildir format, in
that manner. In addition, I push to a remote bare repository
automatically, using ssh host keys.
The most annoying issue was trying to prevent spam getting stuck in
the mail history. I do this by having the "unsure" mail folder in a
different place, and then having a symlink from the mail store point
there so mutt can still find it easily if needed.
Backing up a whole home directory would require careful thought about
what _not_ to backup, similar to the spam issue. You probably
wouldn't want to backup things that you download off the net and can
easily retrieve again, like foo-1.2.tar.gz etc.
I'm not sure what you mean by cleaning up old stuff. git (or at least
my usage of it) requires the whole history to be in the repository. I
haven't looked at shallow clones or other ways to prune history.
--
Virus found in this message.
^ permalink raw reply
* Re: git as a backup tool?
From: Peter Baumann @ 2007-05-15 5:51 UTC (permalink / raw)
To: Russell; +Cc: Geert Uytterhoeven, git
In-Reply-To: <c1b8b6670705142209x267e44cbrea26aa8818275aea@mail.gmail.com>
On Tue, May 15, 2007 at 01:09:06PM +0800, Russell wrote:
> On 5/14/07, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Hi,
> >
> > Has anyone considered using git as a backup tool? I.e.
> > - put your whole file system in git
> > - do `git add .; git commit -a' from cron
> > - copy .git to external media once in a while
> > - clean up old stuff (unused and older than xx days) from .git
>
> I'm using git to backup my private email, all in Maildir format, in
> that manner. In addition, I push to a remote bare repository
> automatically, using ssh host keys.
>
> The most annoying issue was trying to prevent spam getting stuck in
> the mail history. I do this by having the "unsure" mail folder in a
> different place, and then having a symlink from the mail store point
> there so mutt can still find it easily if needed.
>
> Backing up a whole home directory would require careful thought about
> what _not_ to backup, similar to the spam issue. You probably
> wouldn't want to backup things that you download off the net and can
> easily retrieve again, like foo-1.2.tar.gz etc.
>
> I'm not sure what you mean by cleaning up old stuff. git (or at least
> my usage of it) requires the whole history to be in the repository. I
> haven't looked at shallow clones or other ways to prune history.
>
There was already a discussion about using git for backup in [1], which
is probabily worth reading. For cleaning up old history Junio explained a
very elegant solution in [2].
-Peter
[1]: http://thread.gmane.org/gmane.comp.version-control.git/33887
[2]: http://article.gmane.org/gmane.comp.version-control.git/34455
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Jeffrey C. Ollie @ 2007-05-15 5:57 UTC (permalink / raw)
To: git
In-Reply-To: <20070515050808.GA11745@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
On Tue, 2007-05-15 at 01:08 -0400, Jeff King wrote:
> Interesting. vger is correct in translating, since your mail server
> does
> _not_ advertise the 8BITMIME extension (even though exim is 8-bit
> clean,
> and could handle it).
Exim can advertise the 8BITMIME extension - it's turned off by default:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: David Kågedal @ 2007-05-15 0:57 UTC (permalink / raw)
To: git
In-Reply-To: <8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com>
"Guilhem Bonnefille" <guilhem.bonnefille@gmail.com> writes:
> In order to improve my productivity with Git, and in order to avoid
> traps around moving from SVN to Git, I often use the Git Emacs mode.
> It is really usefull for beginners as it works similarly for CVS, SVN
> and Git: synthetic view of all modifications, easy selection of what
> will be commited... The biggest drawback of this "porcelain": using
> it, you do not understand the Git's index philosophy.
And it's broken as well. If you "update" in the emacs mode you cannot
do a "git commit" in a terminal without manually running "git
update-index" first.
I think an emacs-mode that is closer to git-gui would be better, and
closer to the git philosophy
--
David Kågedal
^ permalink raw reply
* Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: Jeff King @ 2007-05-15 6:24 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: git
In-Reply-To: <1179208673.3714.16.camel@lt21223.campus.dmacc.edu>
On Tue, May 15, 2007 at 12:57:53AM -0500, Jeffrey C. Ollie wrote:
> Exim can advertise the 8BITMIME extension - it's turned off by default:
Yes, although turning it on would just paper over the actual problem,
which is that vger is rewritin the content-type header with the wrong
charset. It would fix the problem for Bruce, but not for other
receivers.
The real problem is (I believe) the lack of the MIME-Version header. I
will do a few test messages momentarily (which will unfortunately
require me spamming the list a bit).
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb: Do not use absolute font sizes
From: David Kågedal @ 2007-05-15 1:06 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <f2a3si$ein$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Petr Baudis wrote:
>
>> Note that this patch actually does change visual look of gitweb in Firefox
>> with my resolution and default settings - everything is bigger and I can't
>> explain the joy of actually seeing gitweb text that is in _readable_ size;
>> also, my horizontal screen real estate feels better used now.
>
> Not everyone has those huge monitors with extreme resultion. For me new
> gitweb look uses much to big font, so not very much fits in screen.
>
> I'd remove
>
>> --- a/gitweb/gitweb.css
>> +++ b/gitweb/gitweb.css
>> @@ -1,6 +1,5 @@
>> body {
>> font-family: sans-serif;
>> - font-size: 12px;
>> border: solid #d9d8d1;
>> border-width: 1px;
>> margin: 10px;
>
> chunk
But then we'd be back to the brain-damaged explicit-pixel sizes.
gitweb is simply using the font size you have configured your browser
to use, and if you think that it too large, you are free to
reconfigure it.
Unfortunately, the problem is that too many web sites explicitly
select extra small font sizes, which means that you have to select a
"standard" font size in your browser that is a bit larger than you'd
actually like.
--
David Kågedal
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: David Kågedal @ 2007-05-15 1:00 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705081256410.4167@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 8 May 2007, Martin Langhoff wrote:
>
>> Heh. Making the index very visible makes sense when you are merging,
>
> You're saying that the main use of the index is to help merging. I have to
> disagree strongly.
>
> When I have been chasing a bug all over the place, and finally found it,
> my working tree is a mess. Lots of assertions, lots of debugging
> statements, some of them commented out. So, now it is cleanup time, right?
>
> The problem is that more often than not, I broke my fix while cleaning up.
>
> Therefore, I now put all changed files into the index (git add -u), and
> clean up the files one by one, always checking with "git diff" and "git
> diff HEAD" what I still have to do.
Why not simply use a temporary branch for this? They're free, and you
can diff just as easily, if not more. And you don't risk losing it if
you slip with a command.
--
David Kågedal
^ 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