* Git weekly news: 2008-50
From: Felipe Contreras @ 2008-12-13 1:10 UTC (permalink / raw)
To: git list
Hi all,
This week I'm trying to address some of the issues mentioned here. I
still would like people to request user accounts to this blog if they
wish to make some git related posts.
http://gitlog.wordpress.com/2008/12/13/git-weekly-links-2008-50/
== Articles ==
Why Subversion does not suck
http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx
Articles on Git, a distributed version control system
http://www.gnome.org/~federico/index.html#git
Pushing and pulling with Git, part 2
http://www.gnome.org/~federico/news-2008-12.html#pushing-and-pulling-with-git-2
Setting Up Ruby on Rails Projects with Git and Github
A straight forward guide to setup git and github in Windows
http://beans.seartipy.com/2008/12/09/setting-up-ruby-on-rails-projects-with-git-and-github/
Insider Guide to GitHub
Comprehensive screencasts to get familiar with git by Scott Chacon
http://github.com/blog/261-insider-guide-to-github-series
http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github
YUI on GitHub
Yahoo's User Interface Library is now hosted publicly on Github
http://github.com/blog/262-yui-on-github
Las ventajas de Git
Discussion about Git's advantages in barrapunto.com (Spanish's slashdot)
http://preguntas.barrapunto.com/article.pl?sid=08/12/08/019203
== In Japaneese (I've no idea) ==
coderepos の commit 数ナンバー１の人が github を練習したメモ
http://d.hatena.ne.jp/tokuhirom/20081212/1229080990
gitでドットファイルをバージョン管理する
http://d.hatena.ne.jp/javascripter/20081208/1228730967
gistコマンドよりちょっと便利なgisty
http://d.hatena.ne.jp/swdyh/20081207/1228655198
== Still popular ==
Why Git is Better than X
Brief explanation about why you should switch from X to Git
http://whygitisbetterthanx.com/
Por qué Git es mejor que X
Also very popular is the Spanish version
http://es.whygitisbetterthanx.com/
== My picks ==
What are your favorite git features or tricks?
A bunch of git tricks
http://stackoverflow.com/questions/347901/what-are-your-favorite-git-features-or-tricks
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: David Howells @ 2008-12-13 1:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: dhowells, torvalds, git, linux-kernel
In-Reply-To: <20081212190900.GL5691@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> > > Is there any reason you hide the tag object?
> >
> > What's a tag object?
>
> http://www.kernel.org/pub/software/scm/git/docs/gitglossary.html#def_tag_object
Okay. I do mention tags. How they're stored in the database is irrelevant.
As far as most users need be concerned, a tag is a symbolic representation of
a particular commit in the tree; a particular state of the source tree.
Think of symbolic links as an analogy. Most users just need to know that a
symlink represents the location of another part of the VFS tree; actually most
users will just think of them as a pointer to the name of a file, if even that
much. The fact that, say, ReiserFS tail packs them because they tend to be
small, or that AFS symlinks have weird properties that encode mountpoints is
irrelevant to most users. You don't need to know that to use them.
Yes, GIT's database has blob objects, tree objects, commit objects and tag
objects; but as far as the normal user is concerned, it stores files, lists of
files (directories or, more probably, folders), commits and tags. The
physical low-level stuff is completely irrelevant.
There is one exception to that: commit IDs. These are public-facing as it
were. GIT waves them in your face, and you have to use them occasionally, so
it's useful to say a bit about them.
David
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: David Howells @ 2008-12-13 1:14 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: dhowells, torvalds, git, linux-kernel
In-Reply-To: <20081213010328.GA23224@fieldses.org>
J. Bruce Fields <bfields@fieldses.org> wrote:
> (Also: this patch applies to either the git or linux trees, and you sent
> it to both mailing lists. Looks like you meant it for linux, but you
> might want to clarify....)
It was aimed at addition to Linux, but someone might think it goes better in
GIT instead, and the GIT list is more narrowly focused on the right people to
review it.
David
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Sverre Rabbelier @ 2008-12-13 1:16 UTC (permalink / raw)
To: David Howells; +Cc: Jakub Narebski, torvalds, git, linux-kernel
In-Reply-To: <32073.1229130284@redhat.com>
On Sat, Dec 13, 2008 at 02:04, David Howells <dhowells@redhat.com> wrote:
> (3) You put some non-basic stuff in the basic section (branching - this isn't
> ordinarily useful, IMHO), but you miss other stuff out ('git rm' for
> example).
Erm, branching is not ordinarily useful? I think you're Doing It Wrong
(TM) then, since branching is a Big Thing (also TM) in DVC, not using
branches would be a bit like only using the first 4 gears in a car;
sure, it's possible, but you're missing all that extra power!
> (4) It needs to be installed with GIT in a form that can easily be cut and
> pasted from (maybe this is the case).
I'll agree with you that the git-scm site is in fact, a site, and as
such cannot easily be accessed.
> github
First hit on google:http://github.com/
> repoorcz
http://repo.or.cz
I'm sure both are supposed to be hyperlinks, and some text there as well.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Nicolas Pitre @ 2008-12-13 1:22 UTC (permalink / raw)
To: David Howells; +Cc: Jakub Narebski, torvalds, git, linux-kernel
In-Reply-To: <32073.1229130284@redhat.com>
On Sat, 13 Dec 2008, David Howells wrote:
> (3) You put some non-basic stuff in the basic section (branching - this isn't
> ordinarily useful, IMHO), but you miss other stuff out ('git rm' for
> example).
Hmmm... I use git branches many times a day, while I use git rm...
well... almost never.
Nicolas
^ permalink raw reply
* Re: gitweb and unicode special characters
From: Jakub Narebski @ 2008-12-13 1:31 UTC (permalink / raw)
To: Praveen A; +Cc: git, Santhosh Thottingal
In-Reply-To: <3f2beab60812121655m6cd868bfhaaf386e6f5457533@mail.gmail.com>
On Sat, 13 Dec 2008 01:55, Praveen A wrote:
> 2008/12/12 Jakub Narebski <jnareb@gmail.com>:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> "Praveen A" <pravi.a@gmail.com> writes:
>>>
>>>> Git currently does not handle unicode special characters ZWJ and ZWNJ,
>>>> both are heavily used in Malayalam and common in other languages
>>>> needing complex text layout like Sinhala and Arabic.
>>>>
>>>> An example of this is shown in the commit message here
>>>> http://git.savannah.gnu.org/gitweb/?p=smc.git;a=commit;h=c3f368c60aabdc380c77608c614d91b0a628590a
>>>>
>>>> \20014 and \20015 should have been ZWNJ and ZWJ respectively. You just
>>>> need to handle them as any other unicode character - especially it is
>>>> a commit message and expectation is normal pain text display.
>>>
>>> [...] git_commit calls format_log_line_html, which
>>> in turn calls esc_html. esc_html looks like this:
>>>
>>> sub esc_html ($;%) {
[...]
>>> ** $str =~ s|([[:cntrl:]])|(($1 ne "\t") ? quot_cec($1) : $1)|eg;
>>> return $str;
>>> }
>>>
>>> The two important lines are marked with '**'.
>> [...]
>>
>>> So it looks like Perl treats \20014 and \20015 (ZWNJ and ZWJ) as
>>> belonging to '[:cntrl:]' class. I don't know if it is correct from the
>>> point of view of Unicode character classes, therefore if it is a bug
>>> in Perl, or just in gitweb.
>>
>> I checked this, via this simple Perl script:
[...]
>> "\N{ZWNJ}" =~ /[[:cntrl:]]/ and print "is [:cntrl:]";
>>
>> And the answer was:
>>
>> oct=20014 dex=8204 hex=200c
>> is [:cntrl:]
>>
>> 'ZERO WIDTH NON-JOINER' _is_ control character... We probably should
>> use [^[:print:][:space:]] instead of [[:cntrl:]] here.
>
> That looks good. But I'm wondering why do we need to filter at all?
> Is it a security concern? It is just description.
First, from the new description [^[:print:][:space:]], or even
[^[:print:]] (whichever we choose) you can see that those characters
we are showing using C (\r, \v, \b,...) + octal (in older gitweb) or
hex (in never gitweb) escapes would be invisible otherwise, or do
the strange things like \b aka backspace character.
Sidenote: There is probably one exception we want to add, namely not
escape '\r' at the end of line, to be able to deal better with DOS
line endings (\r\n).
Second, and that is I think reason we started to escape control
characters like \014 or ^L i.e. FORM FEED (FF) character (e.g. in
COPYING file), or \033 or ^[ i.e. ESCAPE (\e) character (e.g. commit
20a3847d) is that they are not allowed in XML, which means that they
are not allowed in XHTML, which means that if they are on the page,
and MIME-type is 'application/xml+html' forcing strict XML/XHTML mode
validating browsers would not display the page because it is not valid
XHTML. Mozilla 1.17.2 did this, and it would not show page; I don't
know how it works with more modern browsers.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] guilt: add option guilt.diffstat
From: Wu Fengguang @ 2008-12-13 2:14 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git
Introduce option guilt.diffstat so that we don't have to type
"guilt refresh --diffstat" in its full form every time.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
guilt | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- guilt.orig 2008-12-13 09:53:32.000000000 +0800
+++ guilt 2008-12-13 10:01:03.000000000 +0800
@@ -538,7 +538,7 @@ __refresh_patch()
[ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
- if [ ! -z "$5" ]; then
+ if [ -n "$5" -o "x$diffstat" = "x1" ]; then
(
echo "---"
git diff --stat $diffopts "$2"
@@ -627,6 +627,9 @@ guilt_push_diff_context=1
# default autotag value
AUTOTAG_DEFAULT=1
+# default diffstat value
+DIFFSTAT_DEFAULT=0
+
#
# Parse any part of .git/config that belongs to us
#
@@ -635,6 +638,10 @@ AUTOTAG_DEFAULT=1
autotag=`git config guilt.autotag`
[ -z "$autotag" ] && autotag=$AUTOTAG_DEFAULT
+# generate diffstat?
+diffstat=`git config guilt.diffstat`
+[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
+
#
# The following gets run every time this file is source'd
#
^ permalink raw reply
* [JGIT PATCH 1/2] Add raw buffer fetch methods to FileHeader, HunkHeader
From: Shawn O. Pearce @ 2008-12-13 2:42 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
These permit application level code to read back the patch
script, for example to slice it up and output parts into a
UI on a per-file or per-hunk basis.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Two last-minute patches. While using this code in Gerrit 2 I
realized I forgot to add a way to get the script back after its
been parsed by the library. :-)
.../src/org/spearce/jgit/patch/BinaryHunk.java | 15 +++++++++++++++
| 15 +++++++++++++++
| 15 +++++++++++++++
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
index 92eab86..f43a1b9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
@@ -81,6 +81,21 @@ public FileHeader getFileHeader() {
return file;
}
+ /** @return the byte array holding this hunk's patch script. */
+ public byte[] getBuffer() {
+ return file.buf;
+ }
+
+ /** @return offset the start of this hunk in {@link #getBuffer()}. */
+ public int getStartOffset() {
+ return startOffset;
+ }
+
+ /** @return offset one past the end of the hunk in {@link #getBuffer()}. */
+ public int getEndOffset() {
+ return endOffset;
+ }
+
/** @return type of this binary hunk */
public Type getType() {
return type;
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
index 79e4b0a..7c3a45a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
@@ -173,6 +173,21 @@ int getParentCount() {
return 1;
}
+ /** @return the byte array holding this file's patch script. */
+ public byte[] getBuffer() {
+ return buf;
+ }
+
+ /** @return offset the start of this file's script in {@link #getBuffer()}. */
+ public int getStartOffset() {
+ return startOffset;
+ }
+
+ /** @return offset one past the end of the file script. */
+ public int getEndOffset() {
+ return endOffset;
+ }
+
/**
* Get the old name associated with this file.
* <p>
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
index fc149ac..12c670d 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
@@ -123,6 +123,21 @@ public FileHeader getFileHeader() {
return file;
}
+ /** @return the byte array holding this hunk's patch script. */
+ public byte[] getBuffer() {
+ return file.buf;
+ }
+
+ /** @return offset the start of this hunk in {@link #getBuffer()}. */
+ public int getStartOffset() {
+ return startOffset;
+ }
+
+ /** @return offset one past the end of the hunk in {@link #getBuffer()}. */
+ public int getEndOffset() {
+ return endOffset;
+ }
+
/** @return information about the old image mentioned in this hunk. */
public OldImage getOldImage() {
return old;
--
1.6.1.rc2.306.ge5d5e
^ permalink raw reply related
* [JGIT PATCH 2/2] Add getPatchText functions to obtain the plain-text version of a patch
From: Shawn O. Pearce @ 2008-12-13 2:42 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1229136146-15359-1-git-send-email-spearce@spearce.org>
The conversion from byte[] to String is performed one line at a time,
in case the patch is a character encoding conversion patch for the
file. For simplicity we currently assume UTF-8 still as the default
encoding for any content, but eventually we should support using the
.gitattributes encoding property when performing this conversion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/patch/BinaryHunk.java | 8 ++
| 6 ++
| 7 ++
.../src/org/spearce/jgit/patch/PatchUtil.java | 79 ++++++++++++++++++++
4 files changed, 100 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
diff --git a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
index f43a1b9..f4e2ee3 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
@@ -42,6 +42,8 @@
import static org.spearce.jgit.util.RawParseUtils.nextLF;
import static org.spearce.jgit.util.RawParseUtils.parseBase10;
+import org.spearce.jgit.lib.Constants;
+
/** Part of a "GIT binary patch" to describe the pre-image or post-image */
public class BinaryHunk {
private static final byte[] LITERAL = encodeASCII("literal ");
@@ -96,6 +98,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getHunkText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/** @return type of this binary hunk */
public Type getType() {
return type;
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
index 7c3a45a..0110f4a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
@@ -188,6 +188,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getScriptText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/**
* Get the old name associated with this file.
* <p>
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
index 12c670d..5a3b590 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
@@ -42,6 +42,7 @@
import static org.spearce.jgit.util.RawParseUtils.parseBase10;
import org.spearce.jgit.lib.AbbreviatedObjectId;
+import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.util.MutableInteger;
/** Hunk header describing the layout of a single block of lines */
@@ -138,6 +139,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getHunkText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/** @return information about the old image mentioned in this hunk. */
public OldImage getOldImage() {
return old;
diff --git a/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java b/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
new file mode 100644
index 0000000..89136c0
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2008, Google Inc.
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.patch;
+
+import java.nio.charset.Charset;
+
+import org.spearce.jgit.util.RawParseUtils;
+
+/** Patch related utility functions. */
+public class PatchUtil {
+ /**
+ * Decode a region of a buffer one line at a time.
+ * <p>
+ * Unlike {@link RawParseUtils#decode(Charset, byte[], int, int)} this
+ * method reads the input one line at a time and decodes each line
+ * individually. This permits a decoding of a file converting from
+ * ISO-8859-1 to UTF-8 encoding (for example), as each line in the patch
+ * script will be in one encoding or the other.
+ *
+ * @param cs
+ * preferred character set to use when decoding the buffer.
+ * @param buf
+ * buffer to pull the raw bytes from.
+ * @param ptr
+ * first position to read.
+ * @param end
+ * one position past the last position to read.
+ * @return a string representation of the region, decoded per-line.
+ */
+ public static String decode(final Charset cs, final byte[] buf, int ptr,
+ final int end) {
+ final StringBuilder r = new StringBuilder(end - ptr);
+ while (ptr < end) {
+ final int eol = Math.min(end, RawParseUtils.nextLF(buf, ptr));
+ r.append(RawParseUtils.decode(cs, buf, ptr, eol));
+ ptr = eol;
+ }
+ return r.toString();
+ }
+
+ private PatchUtil() {
+ // No instances
+ }
+}
--
1.6.1.rc2.306.ge5d5e
^ permalink raw reply related
* Re: gitweb and unicode special characters
From: Edward Z. Yang @ 2008-12-13 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <200812130231.06929.jnareb@gmail.com>
Jakub Narebski wrote:
> Sidenote: There is probably one exception we want to add, namely not
> escape '\r' at the end of line, to be able to deal better with DOS
> line endings (\r\n).
I'm sorry, but I have to disagree. I find being able to see \r
line-endings in the pretty-printed format is exceedingly useful for
figuring out if a file has been checked in with the wrong line-endings.
The number of files that must have \r line endings are vanishingly small
(Bat files are perhaps the one example I can think of right now).
Cheers,
Edward
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Miklos Vajna @ 2008-12-13 3:34 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <32096.1229130776@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
On Sat, Dec 13, 2008 at 01:12:56AM +0000, David Howells <dhowells@redhat.com> wrote:
> Okay. I do mention tags. How they're stored in the database is irrelevant.
> As far as most users need be concerned, a tag is a symbolic representation of
> a particular commit in the tree; a particular state of the source tree.
Actually I think it matters, that's why a 'tag' differs to a 'tag
object'. Also, a tag can point to any other object, not just to a
commit. (Though usually it does.)
> Think of symbolic links as an analogy. Most users just need to know that a
> symlink represents the location of another part of the VFS tree; actually most
> users will just think of them as a pointer to the name of a file, if even that
> much. The fact that, say, ReiserFS tail packs them because they tend to be
> small, or that AFS symlinks have weird properties that encode mountpoints is
> irrelevant to most users. You don't need to know that to use them.
Won't it be confusing that a symlink can be stored as a blob, tags are
refs, but refs are not blobs?
> Yes, GIT's database has blob objects, tree objects, commit objects and tag
> objects; but as far as the normal user is concerned, it stores files, lists of
> files (directories or, more probably, folders), commits and tags. The
> physical low-level stuff is completely irrelevant.
Agreed, the object database is not interesting for a beginner.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Junio C Hamano @ 2008-12-13 3:35 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <20081212182827.28408.40963.stgit@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Add a guide to using GIT's simpler features.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> Documentation/git-haters-guide.txt | 1283 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 1283 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/git-haters-guide.txt
>
>
> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
> new file mode 100644
> index 0000000..51e4dac
> --- /dev/null
> +++ b/Documentation/git-haters-guide.txt
> @@ -0,0 +1,1283 @@
> + ===================================
> + THE GIT HATER'S GUIDE TO THE GALAXY
> + ===================================
> +
> +By David Howells <dhowells@redhat.com>
> +
> +Contents:
> ...
> +============
> +INTRODUCTION
> +============
> +
> +So, you want to do some Linux kernel development? And you hear there's this
> +piece of software called 'GIT' that you probably ought to be using when dealing
> +with the kernel community? Then you find out that not only was Linux started
> +by this Linus Torvalds person, but GIT was too! Perhaps it doesn't seem fair:
> +Linus has not just _one_ huge piece of software named after himself, but _two_!
> +And on top of that, globe spanning hardware vendors just queue up to give him
> +all the herring he can eat!!
> +
> +Then you look at webpages about GIT. You look at the manpages! You run the
> +commands with --help! And you *still* don't know how to do anything complex
> +with it!! You feel certain that there's some secret rite you have to perform
> +to become a GIT initiate - probably something involving two goats, an altar and
> +a full moon - oh, and lots of beer (we *are* talking about kernel developers
> +after all).
> +
> +Then you ask around, and people look at you blankly, hedge or say that it's
> +easy and obvious (they should know - they wrote the damned thing). You realise
> +that the manpages are more an aide-memoire and that what you really want is
> +some sort of crib sheet; something that can hold your hand whilst you cut and
> +paste things from of it until you can see the point.
> +
> +Well, let's see if I can help...
> +
> +
> +DISCLAIMER
> +----------
> +
> +I don't really know what I'm doing with GIT...
I think this patch is good up to this point. It is mildly funny and there
would exist some people who share the same sense of humor as the above
paragraphs (I am unfortunately one of them, though).
I've only skimmed the remainder of the patch, and found there are quite a
few technical errors and deviations from standard terminologies that I do
not care to enumerate (I do not have infinite amount of time). They make
me suspect that anybody who tries to learn from this document would be
harmed rather than helped in the longer run.
The document could be a good addition if the remainder of the patch is
replaced by a collection of links to better introductory documents that
are already available on the net, IMHO.
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Josef Jeff Sipek @ 2008-12-13 4:43 UTC (permalink / raw)
To: Wu Fengguang; +Cc: git
In-Reply-To: <20081213021422.GA28249@localhost>
On Sat, Dec 13, 2008 at 10:14:22AM +0800, Wu Fengguang wrote:
> Introduce option guilt.diffstat so that we don't have to type
> "guilt refresh --diffstat" in its full form every time.
Good idea.
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> ---
> guilt | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> --- guilt.orig 2008-12-13 09:53:32.000000000 +0800
> +++ guilt 2008-12-13 10:01:03.000000000 +0800
> @@ -538,7 +538,7 @@ __refresh_patch()
>
> [ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
>
> - if [ ! -z "$5" ]; then
> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
Why the 'x' thing? I've seen it is some scripts before, but I can't think of
a reason to use it if the variable is surrounded in quotation marks.
> (
> echo "---"
> git diff --stat $diffopts "$2"
> @@ -627,6 +627,9 @@ guilt_push_diff_context=1
> # default autotag value
> AUTOTAG_DEFAULT=1
>
> +# default diffstat value
> +DIFFSTAT_DEFAULT=0
> +
> #
> # Parse any part of .git/config that belongs to us
> #
> @@ -635,6 +638,10 @@ AUTOTAG_DEFAULT=1
> autotag=`git config guilt.autotag`
> [ -z "$autotag" ] && autotag=$AUTOTAG_DEFAULT
>
> +# generate diffstat?
> +diffstat=`git config guilt.diffstat`
> +[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
> +
> #
> # The following gets run every time this file is source'd
> #
Could you throw a quick note into the manpages?
Thanks,
Josef 'Jeff' Sipek.
--
My public GPG key can be found at
http://www.josefsipek.net/gpg/public-0xC7958FFE.txt
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-12-13 5:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Johannes Sixt, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce,
Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812120854k1c366327o9bc696184ea4f02e@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 12/12/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> ...
>> But what if the same persion notices a #define in a kdeutils header file
>> and want's to know whether it is unused in order to remove it:
>>
>> $ git grep FOO
>> kdeutils/foo.h:#define FOO bar
>
> "git grep --cached FOO" ?
That should behave identically when the work tree does not have change
since the index, and by definition paths outside the checkout area in the
"sparse" mode cannot have changes, so "git grep FOO" should behave the
same and should find it.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-12-13 5:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Daniel Barkalow, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812120813m2949e36ar7905d5688b8f6ecb@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 12/12/08, Junio C Hamano <gitster@pobox.com> wrote:
>> So "git grep -e frotz Documentation/", whether you only check out
>> Documentation or the whole tree, should grep only in Documentation area,
>> and "git grep -e frotz" should grep in the whole tree, even if you happen
>> to have a sparse checkout. By definition, a sparse checkout has no
>> modifications outside the checkout area, so whenever grep wants to look
>> for strings outside the checkout area it should pretend as if the same
>> content as what the index records is in the work tree. This is consistent
>> with the way how "git diff" in a sparsely checked out work tree should
>> behave.
>
> Assume someone is using sparse checkout with KDE git repository. They
> sparse-checkout kdeutils module and do "git grep -e foo". I would
> expect that the command only searches in kdeutils only (and is the
> current behavior).
Yes it is the "current in next" behaviour, and no that is not what you
should expect, and that is why I earlier said it is a mistake. The
ability to choose which part to leave out of the working tree should not
change the fact that git is about managing the history of the whole tree,
not an individual file nor a subset of files.
I do not think it is unreasonable to have a mechanism to let the user
limit the area of the whole tree often used Porcelain commands look at.
We already have pathspec "git grep -e foo kdeutils/" mechanism that lets
you do such limiting. It is conceivable that some workflows _might_ find
having the default pathspec convenient in end-user initiated operations,
but then it would be convenient whether the end-user uses the sparse
checkout to limit the area to kdeutils/ or has the whole checkout.
Although I think it would be Okay to default the default pathspec match
the checkout area when the sparse checkout feature is in use, I think the
"checkout area" and "area of interest" should be two independent concepts.
I said "_might_" in the above because I do not think it is such a good
idea to have _the_ default pathspec to begin with, though. It would
probably be more useful to allow people to use shorthands to pathspecs,
and at that point you can use usual shell variables to do that already,
e.g. instead of having to say "git grep -e foo arch/x86 include/asm-i386",
you would say "git grep -e foo $i386", after "i386=arch/x86 include/asm-i386",
or something like that.
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Junio C Hamano @ 2008-12-13 5:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Howells, torvalds, git, linux-kernel
In-Reply-To: <4942C2D1.4090309@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> What do you feel is missing from the Kernel Hackers' Guide to Git? :)
>
> http://linux.yyz.us/git-howto.html
>
> Jeff
For a starter, it is not in-tree ;-).
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Boyd Stephen Smith Jr. @ 2008-12-13 6:18 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: Wu Fengguang, git
In-Reply-To: <20081213044357.GD15407@josefsipek.net>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Friday 2008 December 12 22:43:57 Josef Jeff Sipek wrote:
>> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
>
>Why the 'x' thing? I've seen it is some scripts before, but I can't think of
>a reason to use it if the variable is surrounded in quotation marks.
'[' or test see the arguments after they are unquoted (normally). So,
if "$diffstat" is "-n" it might try and do the -n test, rather than the =
test.
It could be re-written as "1" == "${diffstat}" instead to avoid the x, but
it's not a big deal (to me). That also looks backwards to a lot of people.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Josef Jeff Sipek @ 2008-12-13 6:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Wu Fengguang, git
In-Reply-To: <200812130018.56061.bss03@volumehost.net>
On Sat, Dec 13, 2008 at 12:18:50AM -0600, Boyd Stephen Smith Jr. wrote:
> On Friday 2008 December 12 22:43:57 Josef Jeff Sipek wrote:
> >> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
> >
> >Why the 'x' thing? I've seen it is some scripts before, but I can't think of
> >a reason to use it if the variable is surrounded in quotation marks.
>
> '[' or test see the arguments after they are unquoted (normally). So,
> if "$diffstat" is "-n" it might try and do the -n test, rather than the =
> test.
Oh. I haven't even thought of that posibility!
> It could be re-written as "1" == "${diffstat}" instead to avoid the x, but
> it's not a big deal (to me). That also looks backwards to a lot of people.
Including me.
Thanks for the info.
Josef 'Jeff' Sipek.
--
Penguin : Linux version 2.6.25.4 on an i386 machine (6135.73 BogoMips).
^ permalink raw reply
* Re: [PATCH v2] git-branch: display sha1 on branch deletion
From: Jeff King @ 2008-12-13 6:31 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git
In-Reply-To: <UfCPFu_boLV0ycLKLmOno8GTqmtC4RSZZ9O6aRLGYjmSZOdKv6ywhCjApnplTHLxUIzO8KJ5Mww@cipher.nrlssc.navy.mil>
On Fri, Dec 12, 2008 at 05:20:07PM -0600, Brandon Casey wrote:
> Make it easier to recover from a mistaken branch deletion by displaying the
> sha1 of the branch's tip commit.
This version looks fine to me, but one nit:
> - test "$(git branch -d my7 2>&1)" = "Deleted branch my7."'
> + sha1=$(git rev-parse my7 | cut -c 1-7) &&
> + test "$(git branch -d my7 2>&1)" = "Deleted branch my7 ($sha1)."'
There is a very very small chance that this sha1 might require more
than 7 characters to be unique (small because we have such a tiny number
of objects in the trash repo). Maybe:
sha1=$(git log --pretty=format:%h -1 my7)
is better (though I have to admit, if I were writing the test originally
I would have tested the exit value of "git branch" instead of the
message).
-Peff
^ permalink raw reply
* characterizing commits
From: William Pursell @ 2008-12-13 8:28 UTC (permalink / raw)
To: git
I have a desire to add metadata to commits to characterize
their importance/type. (Or I'd like another recommended
method to achieve the following behavior).
A lot of commits in any given project can be grouped into
different types. eg, looking at the history for git,
there are a lot of merge commits, a lot of commits
that only touch gitk, a lot of 'auto-generated manpages',
a lot of 'typo in documentation' etc. In my own
projects, I have a fairly high percentage of commits
that are trivial (eg whitespace only, typos, etc).
What I'm after is the ability to do something like:
git log --group=!trivial
git log --group=importance:3+
and only get the log for those commits that have been
not been classified "trivial" or that have a precedence
of 3 or greater.
For example, I'd like the following work flow:
$ git log --pretty=oneline
e62bb07a6894d282cdc0fdba6c67ae2ecd086cbb 5
b0986c6e8415c45e123e1838fbe8bf9e8518a90d 4
89916e36bae3208a76c338e91508759787563042 3
3942ef4e118dde3d844da5d84f466ac9666fae62 2
6fa2e40ed491d1dcbbfac9f2d301b517413bec3b 1
04dcd38a8cb6496e37594a273ca39542912ca1eb important
9bd23c2d08e254058a1a9709f963737dc9a71d16 trivial change
$ git group 6fa2e trivial
$ git group 9bd23 trivial
$ git log --pretty=oneline --group=!trivial
e62bb07a6894d282cdc0fdba6c67ae2ecd086cbb 5
b0986c6e8415c45e123e1838fbe8bf9e8518a90d 4
89916e36bae3208a76c338e91508759787563042 3
3942ef4e118dde3d844da5d84f466ac9666fae62 2
04dcd38a8cb6496e37594a273ca39542912ca1eb important
Is there already a mechanism for filtering
commits that I could extend to accomplish this?
--
William Pursell
^ permalink raw reply
* Announce: TortoiseGit 0.1 preview version
From: 李智 @ 2008-12-13 8:33 UTC (permalink / raw)
To: git
TortoiseGit is porting from TortoiseSVN. It is explore extension.
This version just finish a min set of TortoiseSVN porting
1.Context menu(subset of TortoiseSVN)
2.Icon Overlay(version controled\unversion controled at directory)
3.Unified DIFF
4.Use third part diff tools (such as kdiff3)
5.Commit change
6.Show Log
7.Create Repository
Project Home Page at:
http://code.google.com/p/tortoisegit/
Source code at
http://repo.or.cz/w/TortoiseGit.git
It need msysgit 1.6.0.2.
^ permalink raw reply
* Re: characterizing commits
From: Jeff King @ 2008-12-13 8:52 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <4943721C.7070200@gmail.com>
On Sat, Dec 13, 2008 at 08:28:12AM +0000, William Pursell wrote:
> A lot of commits in any given project can be grouped into
> different types. eg, looking at the history for git,
> there are a lot of merge commits, a lot of commits
> that only touch gitk, a lot of 'auto-generated manpages',
> a lot of 'typo in documentation' etc. In my own
> projects, I have a fairly high percentage of commits
> that are trivial (eg whitespace only, typos, etc).
> What I'm after is the ability to do something like:
>
> git log --group=!trivial
> git log --group=importance:3+
>
> [...]
> Is there already a mechanism for filtering
> commits that I could extend to accomplish this?
Generally you would put a pseudo-header into your commit message, like:
Status: trivial
Importance: 3
and then use --grep to filter matching commits:
git log --grep="Status: trivial"
git log --grep="Importance: [3-9]"
Obviously the syntax is a little bit clunkier. You could fix that with
an option to parse arbitrary pseudo-headers (and even support numeric
relations), something like:
git log --filter='importance > 3'
which would be converted internally to a grep of the commit message like
this:
/^importance: (\d+)/i
and compare the result to 3.
The nice thing about that approach is that the storage remains the same:
text in the commit message. That means it gets displayed when you look
at the commit, people with older versions of git can still read it, etc.
One thing this _doesn't_ get you is annotating commits after the fact.
This has been discussed in the past; try searching the list for "notes".
-Peff
^ permalink raw reply
* Re: [JGIT PATCH 2/2] Add getPatchText functions to obtain the plain-text version of a patch
From: Robin Rosenberg @ 2008-12-13 11:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1229136146-15359-2-git-send-email-spearce@spearce.org>
lördag 13 december 2008 03:42:26 skrev Shawn O. Pearce:
> The conversion from byte[] to String is performed one line at a time,
> in case the patch is a character encoding conversion patch for the
> file. For simplicity we currently assume UTF-8 still as the default
> encoding for any content, but eventually we should support using the
> .gitattributes encoding property when performing this conversion.
For usefulness we must be able to pass the encoding from outside,
e.g. the encoding Eclipse uses, which often is not UTF-8-
-- robin
^ permalink raw reply
* [patch] Fix a corner case in git update-index --index-info
From: Thomas Jarosch @ 2008-12-13 13:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Fix a corner case in git update-index --index-info:
If there are no input lines, it won't create an empty index.
Here's a short test for this:
echo -n "" |GIT_INDEX_FILE=index.new git update-index --index-info
-> The index "index.new" won't get created
It failed for me while I was using
git filter-branch as described in the man page:
git filter-branch --index-filter \
´git ls-files -s | sed "s-\t-&newsubdir/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE´ HEAD
The conversion aborted because the first commit was empty.
(created by cvs2svn)
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 65d5775..998a48e 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -299,6 +299,7 @@ static void read_index_info(int line_termination)
{
struct strbuf buf = STRBUF_INIT;
struct strbuf uq = STRBUF_INIT;
+ int found_something = 0;
while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
char *ptr, *tab;
@@ -308,6 +309,8 @@ static void read_index_info(int line_termination)
unsigned long ul;
int stage;
+ found_something = 1;
+
/* This reads lines formatted in one of three formats:
*
* (1) mode SP sha1 TAB path
@@ -383,6 +386,11 @@ static void read_index_info(int line_termination)
bad_line:
die("malformed index info %s", buf.buf);
}
+
+ /* Force creation of empty index - needed by git filter-branch */
+ if (!found_something)
+ active_cache_changed = 1;
+
strbuf_release(&buf);
strbuf_release(&uq);
}
^ permalink raw reply related
* Re: [PATCH] guilt: add option guilt.diffstat
From: Wu Fengguang @ 2008-12-13 13:17 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git@vger.kernel.org, Boyd Stephen Smith Jr.
In-Reply-To: <20081213044357.GD15407@josefsipek.net>
Hi Jeff,
On Sat, Dec 13, 2008 at 06:43:57AM +0200, Josef Jeff Sipek wrote:
> On Sat, Dec 13, 2008 at 10:14:22AM +0800, Wu Fengguang wrote:
> > Introduce option guilt.diffstat so that we don't have to type
> > "guilt refresh --diffstat" in its full form every time.
>
> Good idea.
Thanks.
> Could you throw a quick note into the manpages?
Sure. Here is the updated patch. This time I used "git-config --bool"
to ensure diffstat will be either "true" or "false":
The type specifier can be either --int or --bool, which will
make git-config ensure that the variable(s) are of the given
type and convert the value to the canonical form (simple
decimal number for int, a "true" or "false" string for bool).
If no type specifier is passed, no checks or transformations
are performed on the value.
Thanks,
Fengguang
---
guilt: add option guilt.diffstat
Introduce option guilt.diffstat so that we don't have to type
"guilt refresh --diffstat" in its full form every time.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
diff --git a/Documentation/guilt-refresh.txt b/Documentation/guilt-refresh.txt
index 9a0b4e8..7757bdc 100644
--- a/Documentation/guilt-refresh.txt
+++ b/Documentation/guilt-refresh.txt
@@ -20,8 +20,14 @@ OPTIONS
format (e.g., rename and copy detection).
--diffstat::
- Include a diffstat output in the patch file. Useful for cases where
- patches will be submitted with other tools.
+Include a diffstat output in the patch file. Useful for cases where
+patches will be submitted with other tools.
++
+If the command line option is omitted, the corresponding git-config
+option "guilt.diffstat" will be queried. So this would enable diffstat
+output by default:
+
+ git config --global guilt.diffstat true
Author
------
diff --git a/guilt b/guilt
index fabee17..12361da 100755
--- a/guilt
+++ b/guilt
@@ -544,7 +544,7 @@ __refresh_patch()
[ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
- if [ ! -z "$5" ]; then
+ if [ -n "$5" -o $diffstat = "true" ]; then
(
echo "---"
git diff --stat $diffopts "$2"
@@ -633,6 +633,9 @@ guilt_push_diff_context=1
# default autotag value
AUTOTAG_DEFAULT=1
+# default diffstat value: true or false
+DIFFSTAT_DEFAULT="false"
+
#
# Parse any part of .git/config that belongs to us
#
@@ -641,6 +644,10 @@ AUTOTAG_DEFAULT=1
autotag=`git config guilt.autotag`
[ -z "$autotag" ] && autotag=$AUTOTAG_DEFAULT
+# generate diffstat?
+diffstat=`git config --bool guilt.diffstat`
+[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
+
#
# The following gets run every time this file is source'd
#
^ permalink raw reply related
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