* The patch documenting --pretty options (oops)
From: Chris Riddoch @ 2006-11-18 6:28 UTC (permalink / raw)
To: git
Hi, folks.
I'm terribly sorry about the repost of my old patch. I fixed it,
adding more information about the rest of the output formats and the
'Merge: ' line, but then accidentally reposted the original one. I
hope this new version addresses your original concerns with my patch,
Junio.
--
epistemological humility
^ permalink raw reply
* [PATCH] Move --pretty options into Documentation/pretty-formats.txt
From: Chris Riddoch @ 2006-11-18 6:24 UTC (permalink / raw)
To: git; +Cc: Chris Riddoch
Asciidoc-include it into the manuals for programs that use the
--pretty command-line option, for consistency among the docs.
This describes all the pretty-formats currently listed in the cmit_fmt
enum in commit.h, and also briefly describes the presence and format
of the 'Merge: ' line in some pretty formats.
Signed-off-by: Chris Riddoch <chris@syntacticsugar.org>
---
Documentation/git-diff-tree.txt | 7 ++---
Documentation/git-log.txt | 3 +-
Documentation/git-rev-list.txt | 6 +---
Documentation/git-show.txt | 5 +---
Documentation/pretty-formats.txt | 56 ++++++++++++++++++++++++++++++++++++++
5 files changed, 62 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index f7e8ff2..add0d2f 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -73,10 +73,9 @@ separated with a single space are given.
This flag causes "git-diff-tree --stdin" to also show
the commit message before the differences.
---pretty[=(raw|medium|short)]::
- This is used to control "pretty printing" format of the
- commit message. Without "=<style>", it defaults to
- medium.
+
+include::pretty-formats.txt[]
+
--no-commit-id::
git-diff-tree outputs a line with the commit ID when
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index c9ffff7..3f50b70 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -24,8 +24,7 @@ This manual page describes only the most
OPTIONS
-------
---pretty=<format>::
- Controls the way the commit log is formatted.
+include::pretty-formats.txt[]
--max-count=<n>::
Limits the number of commits to show.
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 00a95e2..ec43c0b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -79,11 +79,7 @@ Using these options, gitlink:git-rev-lis
more specialized family of commit log tools: gitlink:git-log[1],
gitlink:git-show[1], and gitlink:git-whatchanged[1]
---pretty[='<format>']::
-
- Pretty print the contents of the commit logs in a given format,
- where '<format>' can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'. When left out the format default to 'medium'.
+include::pretty-formats.txt[]
--relative-date::
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 2b4df3f..4c880a8 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -26,10 +26,7 @@ OPTIONS
<commitid>::
ID of the commit to show.
---pretty=<format>::
- Controls the output format for the commit logs.
- <format> can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'.
+include::pretty-formats.txt[]
Author
------
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
new file mode 100644
index 0000000..293ea0f
--- /dev/null
+++ b/Documentation/pretty-formats.txt
@@ -0,0 +1,56 @@
+--pretty[='<format>']::
+
+ Pretty-prints the details of a commit. The default format is
+ 'medium'. If the commit is a merge, and the pretty-format is
+ not 'oneline', 'email' or 'raw', an additional line is
+ inserted before the 'Author:' line. This line begins with
+ "Merge: " and the sha1s of each parent commit are printed,
+ separated by spaces. These sha1's are abbreviated to 8
+ characters; use the --abbrev or --no-abbrev options to alter
+ this behavior.
+
+ * 'oneline'
+
+ <sha1> <title line>
+
+ * 'short'
+
+ commit <sha1>
+ Author: <author>
+ <title line>
+
+ * 'medium'
+
+ commit <sha1>
+ Author: <author>
+ Date: <date>
+ <full commit message>
+
+ * 'full'
+
+ commit <sha1>
+ Author: <author>
+ Commit: <committer>
+ <full commit message>
+
+ * 'fuller'
+
+ commit <sha1>
+ Author: <author>
+ AuthorDate: <date & time>
+ Commit: <committer>
+ CommitDate: <date & time>
+ <full commit message>
+
+ * 'email'
+
+ from <sha1> <date>
+ From: <author>
+ Date: <date & time>
+ Subject: [PATCH] <title line>
+
+ <full commit message>
+
+ * 'raw'
+
+ The entire commit exactly as stored in the commit object
--
1.4.4
^ permalink raw reply related
* [PATCH] Move --pretty options into Documentation/pretty-formats.txt
From: Chris Riddoch @ 2006-11-18 6:20 UTC (permalink / raw)
To: git; +Cc: Chris Riddoch
Asciidoc-include it into the manuals for programs that use the
--pretty command-line option, for consistency among the docs.
Signed-off-by: Chris Riddoch <chris@syntacticsugar.org>
---
Documentation/git-diff-tree.txt | 7 +++----
Documentation/git-log.txt | 3 +--
Documentation/git-rev-list.txt | 6 +-----
Documentation/git-show.txt | 5 +----
Documentation/pretty-formats.txt | 29 +++++++++++++++++++++++++++++
5 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index f7e8ff2..add0d2f 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -73,10 +73,9 @@ separated with a single space are given.
This flag causes "git-diff-tree --stdin" to also show
the commit message before the differences.
---pretty[=(raw|medium|short)]::
- This is used to control "pretty printing" format of the
- commit message. Without "=<style>", it defaults to
- medium.
+
+include::pretty-formats.txt[]
+
--no-commit-id::
git-diff-tree outputs a line with the commit ID when
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index c9ffff7..3f50b70 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -24,8 +24,7 @@ This manual page describes only the most
OPTIONS
-------
---pretty=<format>::
- Controls the way the commit log is formatted.
+include::pretty-formats.txt[]
--max-count=<n>::
Limits the number of commits to show.
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 00a95e2..ec43c0b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -79,11 +79,7 @@ Using these options, gitlink:git-rev-lis
more specialized family of commit log tools: gitlink:git-log[1],
gitlink:git-show[1], and gitlink:git-whatchanged[1]
---pretty[='<format>']::
-
- Pretty print the contents of the commit logs in a given format,
- where '<format>' can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'. When left out the format default to 'medium'.
+include::pretty-formats.txt[]
--relative-date::
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 2b4df3f..4c880a8 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -26,10 +26,7 @@ OPTIONS
<commitid>::
ID of the commit to show.
---pretty=<format>::
- Controls the output format for the commit logs.
- <format> can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'.
+include::pretty-formats.txt[]
Author
------
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
new file mode 100644
index 0000000..8995815
--- /dev/null
+++ b/Documentation/pretty-formats.txt
@@ -0,0 +1,29 @@
+--pretty[='<format>']::
+ Pretty-prints the details of a commit. The default is 'medium'
+ * 'oneline'
+
+ <sha1> <title line>
+
+ * 'short'
+
+ commit <sha1>
+ Author: <author>
+ <title line>
+
+ * 'medium'
+
+ commit <sha1>
+ Author: <author>
+ Date: <date>
+ <full commit message>
+
+ * 'full'
+
+ commit <sha1>
+ Author: <author>
+ Commit: <committer>
+ <full commit message>
+
+ * 'raw'
+
+ The entire commit exactly as stored in the commit object
--
1.4.4
^ permalink raw reply related
* Re: multi-project repos
From: Shawn Pearce @ 2006-11-18 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Han-Wen Nienhuys, git
In-Reply-To: <7virhem0ps.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > gitk HEAD@{1}..
>
> Are you sure about this? I've seen "next@{1}" to look at
> history of the named branch, but never history of "HEAD".
Yes. :-)
If the ref name is a symref then we resolve the symref all the
way down to the real ref before we open and walk the reflog.
Therefore this works.
--
^ permalink raw reply
* [PATCH] git-apply: Documentation typo fix
From: Petr Baudis @ 2006-11-18 5:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
inacurate -> inaccurate, sorry if it was a pun. ;-)
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-apply.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index d9137c7..2cc32d1 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -150,7 +150,7 @@ discouraged.
* `strip` outputs warnings for a few such errors, strips out the
trailing whitespaces and applies the patch.
---inacurate-eof::
+--inaccurate-eof::
Under certain circumstances, some versions of diff do not correctly
detect a missing new-line at the end of the file. As a result, patches
^ permalink raw reply related
* Re: [PATCH] Fix git-for-each-refs broken for tags
From: Petr Baudis @ 2006-11-18 4:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4psxfjmw.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 18, 2006 at 05:45:11AM CET, Junio C Hamano wrote:
> Thanks for noticing.
>
> This is not like rev-list where we walk all over the map of
> ancestry graph, so it might be a simpler and better to keep
> the buffer than to keep duplicate copies of pieces.
I would rather not do that in any new code since it's gonna be a problem
if you use this outside of the standalone command as part of libgit.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Petr Baudis @ 2006-11-18 4:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xi9fjw9.fsf@assigned-by-dhcp.cox.net>
On Sat, Nov 18, 2006 at 05:39:34AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > Some of the ref manipulation tools (git-for-each-ref and git-show-ref in
> > particular) would not handle hidden (~ /^\./) refs.
>
> refs.c::check_ref_format() seems to suggest that any ref whose
> path component begins with a dot is invalid (since October last
> year), so I am a bit surprised you are bringing this up now.
Oops, I must've forgotten that already.
> Do you know of specific examples where this is not enforced? It
> could even be argued that the places in the system that allow
> such a ref are buggy.
Cogito creates such refs for internal purposes in two scenarios, on the
other hand it could be argued that in one of those cases the file has no
business in refs/ at all (temporary fetching refs, but they may be
actually symrefs) and in the other case it has no business in refs/heads/
at all (pointers to shelved changes in a branch).
However, I in fact *did* intend to make leading-dot refnames a public
interface. The thing is, I need a way to mark some tags as private to
your repository if Cogito is to support autopushing tags, and I still
think the most elegant way to do that is to make them like hidden files.
Alternative suggestions welcome.
I don't *need* but it might be nice to have also private heads, for
possible setups when you declare heads namespace of two repositories
matching 1:1 but would like to temporarily make a short-lived head in
one of them or so.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [PATCH] Fix git-for-each-refs broken for tags
From: Junio C Hamano @ 2006-11-18 4:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061118025652.2970.10571.stgit@machine.or.cz>
Thanks for noticing.
This is not like rev-list where we walk all over the map of
ancestry graph, so it might be a simpler and better to keep
the buffer than to keep duplicate copies of pieces.
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Junio C Hamano @ 2006-11-18 4:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061118041137.6064.75827.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Some of the ref manipulation tools (git-for-each-ref and git-show-ref in
> particular) would not handle hidden (~ /^\./) refs.
refs.c::check_ref_format() seems to suggest that any ref whose
path component begins with a dot is invalid (since October last
year), so I am a bit surprised you are bringing this up now. Do
you know of specific examples where this is not enforced? It
could even be argued that the places in the system that allow
such a ref are buggy.
I do not recall why we decided that this particular restriction
was needed (I do understand the other three restrictions --- see
commit log of 03feddd6), although I do think this is not a
gratuitous change but comes from a list discussion. I suspect
it was to avoid confusion with ".." operator ("..." was added
much later in July this year), but it is not consistent that we
do not forbid the ones that end with a dot.
Maybe we should have found this inconsistency and added "names
that end with a dot" to the forbidden category when we
introduced the symmetric difference, but apparently nobody
noticed. Right now foo...bar is seriously ambiguous. Even
though it cannot be "foo" .. ".bar" (because ".bar" is not a
valid refname), it can be "foo." .. "bar" or "foo" ... "bar",
and worse yet spelling longhand form "refs/heads/foo." does not
help to disambiguate this.
^ permalink raw reply
* [PATCH] Do not ignore hidden refs
From: Petr Baudis @ 2006-11-18 4:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Some of the ref manipulation tools (git-for-each-ref and git-show-ref in
particular) would not handle hidden (~ /^\./) refs. This may be an
acceptable or possibly even desirable behaviour for the ref walkers and
repackers, but git-show-ref hiddenrefname must work.
This makes Git not ignore hidden refs at all. I'm not opposed to making
some particular parts of the ref interface to continue to ignore hidden
refs, but the restriction cannot be so deep.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
refs.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index f003a0b..06fa5c2 100644
--- a/refs.c
+++ b/refs.c
@@ -141,7 +141,8 @@ static struct ref_list *get_ref_dir(cons
int flag;
int namelen;
- if (de->d_name[0] == '.')
+ if (de->d_name[0] == '.' && (de->d_name[1] == '\0'
+ || (de->d_name[1] == '.' && de->d_name[2] == '\0')))
continue;
namelen = strlen(de->d_name);
^ permalink raw reply related
* http git and curl 7.16.0
From: George Sherwood @ 2006-11-18 4:07 UTC (permalink / raw)
To: Git List
I seem to be having a problem doing an http checkout with git built
with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a
clone, I get:
git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git
error: Unable to start request error: Could not interpret heads/master
as something to pull
If I rebuild git against curl 7.15.5 then I get:
git clone
http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git got
9a985de4a4cfa973a4573828df4cbb2e4f66c419 walk
9a985de4a4cfa973a4573828df4cbb2e4f66c419 got
c431dee75dfadb4c6f81bd95fa1ae44b2b07b359 got
6e645158ba349eaa68caa4c37d18412b30bfd76d walk
c431dee75dfadb4c6f81bd95fa1ae44b2b07b359 got
e452f63c2af324254b7f65f955cbb5ac8efa6762 got
and the checkout finishes.
Has any one else seen this?
George Sherwood
Lead Developer Sourcemage GNU/Linux
^ permalink raw reply
* [PATCH] Fix git-for-each-refs broken for tags
From: Petr Baudis @ 2006-11-18 2:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Unfortunately, git-for-each-refs is currently unusable for peeking into tag
comments, since it uses freed pointers, so it just prints out all sort of
garbage.
This makes it strdup() contents and body values.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
builtin-for-each-ref.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 173bf38..227aa3c 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -478,9 +478,9 @@ static void grab_sub_body_contents(struc
if (!strcmp(name, "subject"))
v->s = copy_line(subpos);
else if (!strcmp(name, "body"))
- v->s = bodypos;
+ v->s = xstrdup(bodypos);
else if (!strcmp(name, "contents"))
- v->s = subpos;
+ v->s = xstrdup(subpos);
}
}
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Michael K. Edwards @ 2006-11-18 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64dev88t.fsf@assigned-by-dhcp.cox.net>
On 11/16/06, Junio C Hamano <junkio@cox.net> wrote:
> "Michael K. Edwards" <medwards.linux@gmail.com> writes:
>
> > Presumably "git branch -D" should inspect everything under
> > .git/remotes to see whether one or more Pull: lines need to be
> > deleted along with the branch.
>
> I am not sure what you mean. .git/remotes files do not describe
> any relationship between local branches (and that is where one
> of the problem raised in recent thread -- pull does not notice
> on which branch you are on and change its behaviour depending on
> it), so I do not think there is anything gained for "git branch
> -D" by going through them.
.git/remotes/foo does contain Pull: lines which indicate the local
branch onto which to _fetch_ remote changes. It's the subsequent
_merge_ that doesn't notice which branch you have checked out.
Cheers,
^ permalink raw reply
* Re: [PATCH] Move --pretty options into Documentation/pretty-formats.txt
From: Junio C Hamano @ 2006-11-18 1:15 UTC (permalink / raw)
To: Chris Riddoch; +Cc: git
In-Reply-To: <11638115311562-git-send-email-chris@syntacticsugar.org>
Chris Riddoch <chris@syntacticsugar.org> writes:
> Asciidoc-include it into the manuals for programs that use the
> --pretty command-line option, for consistency among the docs.
Beautiful, although I doubt we would want to spell out the exact
output format in that documentation (if so you would need to
talk about Merge: entries that we conditionally give and how
commit object names are abbreviated and such). On the other
hand, we might want to talk about Merge: entries anyway to say
the values can be affected by merge simplification.
Independent of the above concerns, I trust somebody else will
follow this up with a patch to describe missing pretty formats?
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Junio C Hamano @ 2006-11-18 1:11 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <7virhdh9j8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> (Are there any octopus merges in git's history? If not, could I ask
>> for one for pedagogical value?)
>
> git.git itself is full of them, but the very first octopus (it
> actually is a pentapus) is rather nice to watch in gitk:
>
> 211232bae64bcc60bbf5d1b5e5b2344c22ed767e
Having said that, I think it is not a good idea to talk about
octopus in introductory documents. The 'feature' may be unique
to git and some people might even find it cool, but new people
should not be encouraged to use it until they understand the
ramifications.
The first ever octopus merge was just a bundle of five forked
development branches, each of which had only one commit since it
forked from the common parent.
.-a-.
.--b--.
O---c---X
'--d--'
'-e-'
They were independent, un-overlapping changes. "diff-tree -c"
would not show anything, and there was no inherent reason that
one change should come before the others, so in that sense,
presenting this as an octopus was making the history more
truthful than pretending one happened before another.
But octopus has a negative effect on bisecting performance.
Suppose commit X was bad and commit O was good. Because X
bundles five branches into one, and we know one of them
(hopefully) is what introduced the regression, our task is to
find the guilty one commit among five commits. But in order to
do so, we would end up having to test four commits. That is,
knowing that a, b and c are Ok does not give us any useful
information to determine which of d or e is the bad one (after
learning that a, b and c are Ok, we still need to test d and if
it turns out to be Ok then we can finally say e is the bad one).
If I did not do an octopus and laid out the commit ancestry
graph this way when I gave them to Linus:
O--a--b--c--d--e--X
the same bisect would have asked us check c first. If it is
good, then we do not even have to test a or b. The linear part
of the history is what bisect takes advantage of to cut the
search space efficiently, and an octopus actively defeats that.
So doing an octopus is a wrong thing to do, if there is a
possibility that something wrong is found later. So people
should not do an octopus unless the component changes are all
truely trivial.
If you want an esoteric topic for an introductory documentation,
it would be more useful to talk about evil merges (an evil merge
is a merge commit whose result does not match any of its
parents). A good example is found in
git show v1.0.0
^ permalink raw reply
* [PATCH] Move --pretty options into Documentation/pretty-formats.txt
From: Chris Riddoch @ 2006-11-18 0:58 UTC (permalink / raw)
To: git; +Cc: Chris Riddoch
Asciidoc-include it into the manuals for programs that use the
--pretty command-line option, for consistency among the docs.
Signed-off-by: Chris Riddoch <chris@syntacticsugar.org>
---
Documentation/git-diff-tree.txt | 7 +++----
Documentation/git-log.txt | 3 +--
Documentation/git-rev-list.txt | 6 +-----
Documentation/git-show.txt | 5 +----
Documentation/pretty-formats.txt | 29 +++++++++++++++++++++++++++++
5 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index f7e8ff2..add0d2f 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -73,10 +73,9 @@ separated with a single space are given.
This flag causes "git-diff-tree --stdin" to also show
the commit message before the differences.
---pretty[=(raw|medium|short)]::
- This is used to control "pretty printing" format of the
- commit message. Without "=<style>", it defaults to
- medium.
+
+include::pretty-formats.txt[]
+
--no-commit-id::
git-diff-tree outputs a line with the commit ID when
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index c9ffff7..3f50b70 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -24,8 +24,7 @@ This manual page describes only the most
OPTIONS
-------
---pretty=<format>::
- Controls the way the commit log is formatted.
+include::pretty-formats.txt[]
--max-count=<n>::
Limits the number of commits to show.
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 00a95e2..ec43c0b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -79,11 +79,7 @@ Using these options, gitlink:git-rev-lis
more specialized family of commit log tools: gitlink:git-log[1],
gitlink:git-show[1], and gitlink:git-whatchanged[1]
---pretty[='<format>']::
-
- Pretty print the contents of the commit logs in a given format,
- where '<format>' can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'. When left out the format default to 'medium'.
+include::pretty-formats.txt[]
--relative-date::
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 2b4df3f..4c880a8 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -26,10 +26,7 @@ OPTIONS
<commitid>::
ID of the commit to show.
---pretty=<format>::
- Controls the output format for the commit logs.
- <format> can be one of 'raw', 'medium', 'short', 'full',
- and 'oneline'.
+include::pretty-formats.txt[]
Author
------
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
new file mode 100644
index 0000000..8995815
--- /dev/null
+++ b/Documentation/pretty-formats.txt
@@ -0,0 +1,29 @@
+--pretty[='<format>']::
+ Pretty-prints the details of a commit. The default is 'medium'
+ * 'oneline'
+
+ <sha1> <title line>
+
+ * 'short'
+
+ commit <sha1>
+ Author: <author>
+ <title line>
+
+ * 'medium'
+
+ commit <sha1>
+ Author: <author>
+ Date: <date>
+ <full commit message>
+
+ * 'full'
+
+ commit <sha1>
+ Author: <author>
+ Commit: <committer>
+ <full commit message>
+
+ * 'raw'
+
+ The entire commit exactly as stored in the commit object
--
1.4.4
^ permalink raw reply related
* Re: [DRAFT] Branching and merging with git
From: Junio C Hamano @ 2006-11-18 0:40 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061118001355.23488.qmail@science.horizon.com>
linux@horizon.com writes:
> We seem to have developed a consensus on the desirability of allowing
> HEAD to point outside refs/heads, postponing the check until
> commit/merge time. (At least, junkio and Linus seemed to like it.)
Yes, and I am actually interested in at least doing the initial
damage assessment myself but people are welcome to beat me to
it. The easies part would be to just try writing a bare SHA-1
to .git/HEAD with:
H=$(git-rev-parse --verify HEAD)
echo $H >.git/HEAD
and see what breaks and start picking up the pieces from there.
> I'd like to learn more about the zillion options to git-log.
> If people feel like sharing useful incantations, it would be
> be very helpful to give a concrete example of its usefulness,
> preferably within the git history itself.
>
> (Are there any octopus merges in git's history? If not, could I ask
> for one for pedagogical value?)
git.git itself is full of them, but the very first octopus (it
actually is a pentapus) is rather nice to watch in gitk:
211232bae64bcc60bbf5d1b5e5b2344c22ed767e
You can look for them with:
git rev-list --parents HEAD | grep '..* ..* ..* ..* ..* ..*'
Repeat as many " ..*" as the number of parents you would want to require.
I knew the very first one was pentapus (I did it) so I wrote six ..*
there (one for the commit, one each for parents).
Len's dodecapus in linux-2.6.git is this one:
9fdb62af92c741addbea15545f214a6e89460865
It is very interesting to watch it with "git show". Len has
another one in August:
da547d775fa9ba8d9dcaee7bc4e960540e2be576
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Jakub Narebski @ 2006-11-18 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <20061118001355.23488.qmail@science.horizon.com>
linux@horizon.com wrote:
[...]
> (Are there any octopus merges in git's history? If not, could I ask
> for one for pedagogical value?)
See commit d425142e2a045a9dd7879d028ec68bd748df48a3 (most legged octopus
I found in git.git repository). Doing git-rev-parse --parents -all, or
git log --all and greppoing for merges is a good idea to find octopi.
The commit is both v1.1.2-gd425142 (git describe) and tags/v1.2.0^0~143
(git name-rev --tags)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: linux @ 2006-11-18 0:13 UTC (permalink / raw)
To: bfields, tytso; +Cc: git, linux
In-Reply-To: <20061117182157.GC11882@fieldses.org>
I'm working on incorporating all of the comments I've received, so
thank you all!
(BTW, the reason I didn't document git-describe is that I didn't
know about it! You fixed the latter, so I'll fix the former.)
I'm glad if others like it, but I was really scratching my own
itch. I'm still wrapping my head around how to work with git, and
writing this was my own learning experience.
Even writing it out in full rather than as rougher notes wasn't
an entirely unselfish act; it ensures:
1) I don't leave some important assumption unstated; that's the
type most likely to be wrong, and
2) If I can get it good enough to post publicly, I'll get all the
experts to fact-check it for me.
As for the target audience, it's basically someone who's read git(1)
and knows what a VCS is supposed to do, but has a CVS/SVN mindset.
The emphasis is on branching and merging because that's the big
"mental mode" difference in the way that git works.
For anyone else documenting git, I recommend describing "what if I
make a mistake" early. It was a bit of a revelation to realize
that there's not much point to "git pull --no-commit" because
it's so easy to undo.
Just a couple of questions:
We seem to have developed a consensus on the desirability of allowing
HEAD to point outside refs/heads, postponing the check until
commit/merge time. (At least, junkio and Linus seemed to like it.)
I proposed it, so I get to write it, but you notice I have a whole
section on how to work around the lack of that feature, so if someone
feels like picking up the baton while I'm still writing docs, it would
simplify things.
I'd like to learn more about the zillion options to git-log.
If people feel like sharing useful incantations, it would be
be very helpful to give a concrete example of its usefulness,
preferably within the git history itself.
(Are there any octopus merges in git's history? If not, could I ask
^ permalink raw reply
* Re: [RFC] gitweb TODO
From: Junio C Hamano @ 2006-11-18 0:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611172224.40252.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> ... But for gitweb more important than producing safe patch
> is producing _readable_ patch[*1*]. Hence request for -T option
> (or under other, better name) to git-diff which would _not_
> split patch (not create two patches for one raw difftree line).
>
> [*1*] Well, as far as diff for symlink is readable anyway.
Honestly, I do not have strong feeling either way. As you say,
I suspect diff to change between symlink and regular file is not
readable no matter how you present it, and it is a corner case
that is not very interesting. It happens in real life but it is
rare enough that split patches or a single patch would not make
much difference either way.
So I would not oppose to a patch to add an option to update
git-diff to produce either format, but I doubt it is worth the
effort required to make sure that the change does not break
anything else and also to make matching adjustment to git-apply,
so that it can understand both formats.
>> I am not sure what you mean by patchset part, but if you are
>> talking about the multiway diff text, I think most of the time
>> output from "-c -p" is much less interesting than "--cc".
>
> Sorry, perhaps I was not clear. I'd like for git-diff-tree --cc
> --raw -p to output both raw part (perhaps taken from -c) and
> patch part...
I can see why somebody might want to do this, to exactly the
same degree that I can see why somebody might want to use the
combination of "--raw -p".
I think this would work in git.git itself:
git diff-tree --cc --numstat --raw -p v1.0.0
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Sean @ 2006-11-17 23:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20061117213125.GG7201@pasky.or.cz>
On Fri, 17 Nov 2006 22:31:26 +0100
Petr Baudis <pasky@suse.cz> wrote:
> It's not about documentation but ease to use. I agree and sympathise
> very much with the effort of making core Git more easy to use and
> obsoleting Cogito, but until it gets there we should have what's nicest
> to the users.
As some new users have already tried to tell you, it's confusing for
_them_ when they're trying to learn Git to be confronted with Cogito
documentation.
The way we're going to get Git to be better is to expose new people
to it and respond to their comments, complaints and ideas about how
to make it better and easier to understand as they get up to speed.
Having Cogito plastered all over the Git website as the _easy_
alternative is counterproductive to that effort. We need fresh
blood looking at the Git documentation and trying to learn Git.
By using the GIT webpage to promote Cogito as the "easy" alternative
you make it look like the entire GIT community is recommending
new users should use Cogito instead. That does not represent
the views of the entire GIT community. You should be very careful
to represent the entire community in your role as GIT webmaster.
If people go to a Cogito website, _that's_ where they should learn
about your opinions about why someone should use Cogito in
place of Git. Cogito isn't "nicest" for users who don't need
its extra functionality, or for getting new users involved in
the improvement effort of native Git.
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Petr Baudis @ 2006-11-17 22:50 UTC (permalink / raw)
To: Chris Riddoch; +Cc: Sean, Nguyen Thai Ngoc Duy, git
In-Reply-To: <6efbd9b70611171436t1e0cadf2j7e9387ca77f85538@mail.gmail.com>
On Fri, Nov 17, 2006 at 11:36:25PM CET, Chris Riddoch wrote:
> On 11/17/06, Petr Baudis <pasky@suse.cz> wrote:
> >If someone writes a crash course in pure Git covering the same grounds
> >as the current ones (possibly by just extending/retouching the tutorial)
> >(it does not necessarily need to be a "refugee" crash course, it can
> >build up from scratch), I can add it on the web. If it becomes as easy
> >to use and with as mild learning curve as Cogito, it means Cogito got
> >mostly obsolete and I'll happily remove the Cogito crash courses from
> >the web.
>
> As a relatively new user myself, I ran into the same confusion when I
> came to the website for the first time. One of the most prominent
> things on the front page is the "Git Crash Courses." Clicking on that
> gives me the crash courses, all of which are about Cogito, not for
> Git. So why doesn't the front page say "Cogito Crash Courses"
> instead?
>
> And I don't think it matters much whether Cogito makes things easier
> or not -- the Git website really should make Git's documentation more
> prominent than Cogito's. I'd expect the opposite of Cogito's website.
I think the difference here is the Git _tool_ vs. the Git version
control system. Cogito is an element of the second: To use Git, you can
either use the Git tool or the Cogito tool or the StGIT tool or even
just the qgit tool (which also lets you inspect the working copy and
commit). I believe the tool best suited for general usage by newbies _at
this point_ is Cogito, so that's what I use for introduction to Git. I'm
not saying this is ideal situation and I and others are/will be working
to fix it.
I'm all for making it more obvious what's going on at the website, I
think the current wording is better. Also, if people believe that a
crash course for core Git would help things, I'm all for it as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Chris Riddoch @ 2006-11-17 22:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sean, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20061117213125.GG7201@pasky.or.cz>
On 11/17/06, Petr Baudis <pasky@suse.cz> wrote:
> If someone writes a crash course in pure Git covering the same grounds
> as the current ones (possibly by just extending/retouching the tutorial)
> (it does not necessarily need to be a "refugee" crash course, it can
> build up from scratch), I can add it on the web. If it becomes as easy
> to use and with as mild learning curve as Cogito, it means Cogito got
> mostly obsolete and I'll happily remove the Cogito crash courses from
> the web.
As a relatively new user myself, I ran into the same confusion when I
came to the website for the first time. One of the most prominent
things on the front page is the "Git Crash Courses." Clicking on that
gives me the crash courses, all of which are about Cogito, not for
Git. So why doesn't the front page say "Cogito Crash Courses"
instead?
And I don't think it matters much whether Cogito makes things easier
or not -- the Git website really should make Git's documentation more
prominent than Cogito's. I'd expect the opposite of Cogito's website.
It *is* unnecessarily confusing.
--
epistemological humility
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-17 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, git
In-Reply-To: <7virhdiwon.fsf@assigned-by-dhcp.cox.net>
On Fri, Nov 17, 2006 at 10:35:04PM CET, Junio C Hamano wrote:
> Unfortunately the only way to know if there will be a file-level
> conflict is to try one, and stashing away the current state just
> in case it conflicted is a performance penalty, so this probably
> should stay as an option just like "-m" to the "checkout".
I think it would be just great if it worked at least for fast-forwarding
case; I think this is where it is actually most useful. Cogito tries to
support even the three-way case as long as the changes touch different
files, but I'm not sure if it was a good idea to begin with.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-17 21:35 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <455E1BF1.1030003@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> echo foo >> child1/testfile
> perl -pi -e 's/tree/shrub/' child2/testfile
>...
> git-diff --binary > /tmp/patch
> git-reset --hard
> git-pull
> git-apply /tmp/patch
>
> I might have gotten that slightly wrong, but I think I have the
> general idea right.
stg pull would help you in such a situation as well, but I see
what you mean.
Just like we have an explicit -m option to "checkout" to allow
file-level merging of local changes, I think it is reasonable to
hav an option that allows file-level merging of local changes
when doing a pull that you _know_ will not conflict.
When there will be a conflict between your HEAD and MERGE_HEAD
even without your local changes, you somehow need to sort out
the resulting mess that come from conflicts due to the branch
diversion (i.e. log HEAD...MERGE_HEAD) and conflicts between
your local change and what the other branch did. The resulting
merge commit obviously needs to record resolutions only to the
former and should not even record anything you did locally,
conflicted or not. Which is a pain for the end user and giving
them a way to revert to the state before this three-and-half
way merge started also needs to be there.
Unfortunately the only way to know if there will be a file-level
conflict is to try one, and stashing away the current state just
in case it conflicted is a performance penalty, so this probably
should stay as an option just like "-m" to the "checkout".
But the basic mechanism to do this three-and-half way merge is
simple and I have no objection if somebody wanted to add such an
option to "git pull".
^ 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