* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Felipe Contreras @ 2008-10-29 19:49 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster
In-Reply-To: <1225237145-95435-1-git-send-email-dsymonds@gmail.com>
On Wed, Oct 29, 2008 at 1:39 AM, David Symonds <dsymonds@gmail.com> wrote:
> Signed-off-by: David Symonds <dsymonds@gmail.com>
> ---
> This isn't a particularly serious patch, but is very relevant to our
> current discussion at GitTogether '08.
I've thought about some commands like:
git stage $file (git add $file)
git unstage $file (git reset $file)
Perhaps
git stage add
git stage rm
And then your proposal would fit with:
git stage diff
Or something like that.
--
Felipe Contreras
^ permalink raw reply
* Re: [VOTE] git versus mercurial
From: Boyd Lynn Gerber @ 2008-10-29 19:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, walt, git
In-Reply-To: <alpine.DEB.1.00.0810292047530.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Wed, 29 Oct 2008, Johannes Schindelin wrote:
> On Wed, 29 Oct 2008, Boyd Lynn Gerber wrote:
>> On Wed, 29 Oct 2008, Shawn O. Pearce wrote:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>> On Tue, 28 Oct 2008, walt wrote:
>>>>> walt wrote:
>>>>>> No, no, I'm not the one calling for a vote. You old-timers here
>>>>>> will know the name Matt Dillon, who is leading the dragonflybsd
>>>>>> project (www.dragonflybsd.org).
>>>>>>
>>>>>> Matt is the one who is calling for the vote in his thread "Vote
>>>>>> for your source control system" in the dragonfly.kernel group,
>>>>>> accessible via nntp://nntp.dragonflybsd.org...
>>>>>
>>>>> The official vote was 19 to 19, plus one for perforce and one for
>>>>> svn. Matt has proposed a primary git repository and a mirror in
>>>>> hg, and that's being debated now.
>>>
>>> FWIW at the Google Summer of Code Mentor Summit this past weekend we
>>> had a "Git vs. Hg" talk with both Git and Hg represented by
>>> contributors to each project.
>>>
>>> Slides are online here:
>>>
>>> http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr
>>
>> But how do I save the presentation? I do not seem to be able to do it.
>> I would like to view it off-line.
>
> Just an idea: print to PDF? There is a link "print slides" on the lower
> right.
That worked. I had to make my window full screen to see the option. It
did not show-up in my normal window.
Thanks,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: A typesetting problem with git man pages
From: Jonas Fonseca @ 2008-10-29 20:14 UTC (permalink / raw)
To: Jeff King; +Cc: Teemu Likonen, git
In-Reply-To: <20081029193958.GA12856@sigill.intra.peff.net>
On Wed, Oct 29, 2008 at 20:39, Jeff King <peff@peff.net> wrote:
> so the problem is the extra \&. But I don't know why that is being
> generated. It _should_ be part of the character entity, I thought, but
> xmlto seems to be rendering it as the newline character entity _plus_
> the ampersand.
>
> So it seems like a bug to me in the XML parser, but it is more likely
> that I'm somehow clueless about XML.
The way I understand it is that the DocBook XSL (stylesheet) doing the
conversion from xml to the manpage ensures that possible problematic
characters that could break the manpage are escaped. A dot in the
start of a line is problematic since it could be interpreted as markup
by the manpage viewer and in the mentioned case, the code was not
generated by the stylesheet, thus it must be escaped. So IMO, the
stylesheet is hardly to blame, the problem is that the asciidoc.conf
file defines a macro for literallayout, in which it expects manpage
code to be passed through unescaped.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: David Kågedal @ 2008-10-29 20:24 UTC (permalink / raw)
To: git
Cc: Teemu Likonen, Wincent Colaiuta, Johannes Schindelin,
David Symonds, gitster, Jeff King
In-Reply-To: <878ws7w8xc.fsf@iki.fi>
Teemu Likonen <tlikonen@iki.fi> writes:
> Wincent Colaiuta (2008-10-29 18:42 +0100) wrote:
>
>> El 29/10/2008, a las 18:03, Johannes Schindelin escribió:
>>> I completely disagree. If the existing set of commands causes
>>> confusion, we need to deprecate those parts and add new commands.
>>> Even if we have a ton of commands already.
>>
>> The confusion isn't at the command level; it's at the switch/option
>> level. The solution isn't to add a new command.
>
> I don't remember being confused in particular area but I think it's a
> _very_ good thing that the following three are behind the same "diff"
> command:
>
> git diff
> git diff --cached (or --staged)
> git diff HEAD
One irregularity hear is that there is no way to explicitly say what
you want to compare against the index (the staging area). Diff
compares two things to each other, and a more regular and general way
to express what it does would be something like
git diff STAGE WORKTREE (like "git diff" today)
git diff HEAD WORKTREE (like "git diff HEAD" today)
git diff WORKTREE HEAD (like "git diff -R HEAD" today)
git diff HEAD STAGE (like "git diff --cached" today)
git diff commit STAGE (like "git diff --cached commit" today)
To me, it isn't obvious that --cached changes the thing you *compare*
rather than the thing you compare *against*. I think it would be
useful to have a way of explicitly stating what you compare, something
like what I wrote above, and then having useful shortcuts for common
cases (like that no arguments compares the work tree against the
stage).
--
David Kågedal
^ permalink raw reply
* [PATCH 1/7] Documentation: do not use regexp in refspec descriptions
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-1-git-send-email-mail@cup.kalibalik.dk>
The refspec format description was a mix of regexp and BNF, making it
very difficult to read.
The syntax is now easier to read, though wrong: all parts of the
refspec are actually optional.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 2 +-
Documentation/pull-fetch-param.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6150b1b..df99c0b 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -32,7 +32,7 @@ OPTIONS
<refspec>...::
The canonical format of a <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
+ `[+]<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index ebdd948..0ff1700 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -6,7 +6,7 @@
<refspec>::
The canonical format of a <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
+ `[+]<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* Some updates to refspec documentation
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster
I have skimmed the git-push manpage many times over a period of
several months, without fully understanding it. Today I sat down and
figured it out. It took some experiments and a little reading of the
source.
Here I offer some updates to the refspec documentation, so that others
can hopefully learn it faster than I did. As I expect some changes to
be more controversial than others, I have split it up in several small
parts. Feel free to squash.
There is a risk that I have changed some things to be wrong. I wanted
to make this update while I was still a frustrated newbie.
Anders
^ permalink raw reply
* [PATCH 3/7] Documentation: rework SHA1 description in git push
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-3-git-send-email-mail@cup.kalibalik.dk>
Get rid of a double pair of parentheses. The arbitrary SHA1 is a
special case, so it can be postponed a bit.
Also mention HEAD, which is possibly the most useful SHA1 in this
situation.
Mention that a SHA1 cannot be automatically matched to a <dst>.
Add HEAD as an example of an arbitrary SHA1.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 02c7dae..fb9fb97 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -38,9 +38,7 @@ OPTIONS
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
-The <src> side represents the source branch (or arbitrary
-"SHA1 expression", such as `master~4` (four parents before the
-tip of `master` branch); see linkgit:git-rev-parse[1]) that you
+The <src> side represents the source branch that you
want to push. The <dst> side represents the destination location.
+
The local ref that matches <src> is used
@@ -63,6 +61,10 @@ the local side, the remote side is updated if a head of the same name
already exists on the remote side. This is the default operation mode
if no explicit refspec is found (that is neither on the command line
nor in any Push line of the corresponding remotes file---see below).
++
+The <src> can be an arbitrary "SHA1 expression", such as `HEAD`
+or `master~4` (see linkgit:git-rev-parse[1]). In this case, a
+<dst> location has to be named.
--all::
Instead of naming each ref to push, specifies that all
@@ -193,6 +195,10 @@ git push origin master::
with it. If `master` did not exist remotely, it would be
created.
+git push origin HEAD:master::
+ Push the current head to the remote ref matching `master` in
+ the `origin` repository.
+
git push origin :experimental::
Find a ref that matches `experimental` in the `origin` repository
(e.g. `refs/heads/experimental`), and delete it.
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 2/7] Documentation: git push repository can also be a remote
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-2-git-send-email-mail@cup.kalibalik.dk>
This is copied from pull-fetch-param.txt and helps the reader
to not get stuck in the URL section.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index df99c0b..02c7dae 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -28,7 +28,9 @@ OPTIONS
-------
<repository>::
The "remote" repository that is destination of a push
- operation. See the section <<URLS,GIT URLS>> below.
+ operation. This parameter can be either a URL
+ (see the section <<URLS,GIT URLS>> below) or the name
+ of a remote (see the section <<REMOTES,REMOTES>> below).
<refspec>...::
The canonical format of a <refspec> parameter is
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 6/7] Documentation: mention branches rather than heads
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-6-git-send-email-mail@cup.kalibalik.dk>
Most of the git push page talks about branches, so make it consistent
also in this paragraph.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 52035db..4e339c7 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -53,8 +53,8 @@ Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
+
The special refspec `:` (or `+:` to allow non-fast forward updates)
-directs git to push "matching" heads: for every head that exists on
-the local side, the remote side is updated if a head of the same name
+directs git to push "matching" branches: for every branch that exists on
+the local side, the remote side is updated if a branch of the same name
already exists on the remote side. This is the default operation mode
if no explicit refspec is found (that is neither on the command line
nor in any Push line of the corresponding remotes file---see below).
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 5/7] Documentation: elaborate on pushing tags
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-5-git-send-email-mail@cup.kalibalik.dk>
Make the description of pushing tags easier to read, but move the
shorthand notation towards the end of the description. This gives
a better flow.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 9788d49..52035db 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -38,7 +38,7 @@ OPTIONS
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
-The <src> side represents the source branch that you
+The <src> side represents the source branch or tag that you
want to push. The <dst> side represents the destination location.
+
The local ref that matches <src> is used
@@ -46,8 +46,6 @@ to fast forward the remote ref that matches <dst>. If
the optional leading plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
-`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
-+
A parameter <ref> without a colon pushes the <ref> from the source
repository to the destination repository under the same name.
+
@@ -64,6 +62,10 @@ nor in any Push line of the corresponding remotes file---see below).
The <src> can be an arbitrary "SHA1 expression", such as `HEAD`
or `master~4` (see linkgit:git-rev-parse[1]). In this case, a
<dst> location has to be named.
++
+When pushing tags, `tag <tag>` can be used as a shorthand for
+`refs/tags/<tag>:refs/tags/<tag>`. This should be specified as
+two arguments (that is, without quotes in the shell).
--all::
Instead of naming each ref to push, specifies that all
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 4/7] Documentation: remove a redundant elaboration
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-4-git-send-email-mail@cup.kalibalik.dk>
The comment in parentheses is wrong, as one has to leave out both the
colon and <dst>. This situation is covered by the section a few lines
down:
A parameter <ref> without a colon pushes the <ref> from the source
repository to the destination repository under the same name.
So, just remove the parentheses.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fb9fb97..9788d49 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -42,8 +42,7 @@ The <src> side represents the source branch that you
want to push. The <dst> side represents the destination location.
+
The local ref that matches <src> is used
-to fast forward the remote ref that matches <dst> (or, if no <dst> was
-specified, the same ref that <src> referred to locally). If
+to fast forward the remote ref that matches <dst>. If
the optional leading plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 7/7] Documentation: avoid using undefined parameters
From: Anders Melchiorsen @ 2008-10-29 20:25 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
In-Reply-To: <1225311945-17100-7-git-send-email-mail@cup.kalibalik.dk>
The <ref> parameter has not been introduced, so rewrite to
avoid it.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4e339c7..e848ff9 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -46,8 +46,8 @@ to fast forward the remote ref that matches <dst>. If
the optional leading plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
-A parameter <ref> without a colon pushes the <ref> from the source
-repository to the destination repository under the same name.
+A lonely <src> parameter (without a colon and a destination) pushes
+the <src> to the same name in the destination repository.
+
Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* Re: [PATCH] increase git el1T3nEss
From: Daniel Barkalow @ 2008-10-29 20:28 UTC (permalink / raw)
To: Jeff King
Cc: Petr Baudis, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <20081029170631.GA12078@sigill.intra.peff.net>
On Wed, 29 Oct 2008, Jeff King wrote:
> The uptake of git by script kiddies has been disappointingly
> minimal. Let's make it more palatable by allowing mixed-case
> and l33t-speak commands.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This commit was made by "git c0mM1t".
>
> git.c | 27 ++++++++++++++++++++++++++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/git.c b/git.c
> index 89feb0b..fd0ca67 100644
> --- a/git.c
> +++ b/git.c
> @@ -261,6 +261,31 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
> return 0;
> }
>
> +static char deelite(char in) {
> + if (isalpha(in))
> + return tolower(in);
> + switch (in) {
> + case '0': return 'o';
> + case '1': return 'i';
> + case '3': return 'e';
> + case '5': return 's';
> + case '7': return 'l';
Your mapping doesn't comply with ISO 1337.5p34k; 1 can be l (in addition
to i), and 7 is T. Also, you're missing 4.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Bill Lear @ 2008-10-29 20:33 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0810290925s493cdc6oc7534904c864db28@mail.gmail.com>
On Wednesday, October 29, 2008 at 17:25:37 (+0100) Santi Béjar writes:
>On Wed, Oct 29, 2008 at 4:23 PM, Bill Lear <rael@zopyra.com> wrote:
>> We have had a few "crossed stream" problems when developers are
>> working on a local branch and they do an unguarded git push/pull,
>> when they really intended to do git push/pull origin branchname.
>>
>> We use git in a way that makes it desirable for us to only push/pull
>> to the same remote branch. So, if I'm in branch X, I want 'git push'
>> to push to origin/X, and 'git pull' to fetch into origin/X and then
>> merge into X from origin/X.
>>
>> In other words, we want git push/pull to behave in branches other than
>> master the same way it does when in master.
>>
>> I have discovered the '--track' option when creating a local branch,
>> and this appears to me to be the thing that gives us the desired
>> behavior.
>
>branch.autosetupmerge controls if --track is used by default (it is
>true by default since a long time)
>(See "git help config" for details)
Ah, problem solved then. I'll just have everyone upgrade to the
latest git. Thanks very much, Santi.
Bill
^ permalink raw reply
* Re: [PATCH 5/7] Documentation: elaborate on pushing tags
From: Daniel Barkalow @ 2008-10-29 20:40 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster
In-Reply-To: <1225311945-17100-6-git-send-email-mail@cup.kalibalik.dk>
On Wed, 29 Oct 2008, Anders Melchiorsen wrote:
> Make the description of pushing tags easier to read, but move the
> shorthand notation towards the end of the description. This gives
> a better flow.
>
> Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
> ---
> Documentation/git-push.txt | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 9788d49..52035db 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -38,7 +38,7 @@ OPTIONS
> by the source ref, followed by a colon `:`, followed by
> the destination ref.
> +
> -The <src> side represents the source branch that you
> +The <src> side represents the source branch or tag that you
> want to push. The <dst> side represents the destination location.
> +
> The local ref that matches <src> is used
> @@ -46,8 +46,6 @@ to fast forward the remote ref that matches <dst>. If
> the optional leading plus `+` is used, the remote ref is updated
> even if it does not result in a fast forward update.
> +
> -`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
> -+
> A parameter <ref> without a colon pushes the <ref> from the source
> repository to the destination repository under the same name.
> +
> @@ -64,6 +62,10 @@ nor in any Push line of the corresponding remotes file---see below).
> The <src> can be an arbitrary "SHA1 expression", such as `HEAD`
> or `master~4` (see linkgit:git-rev-parse[1]). In this case, a
> <dst> location has to be named.
> ++
> +When pushing tags, `tag <tag>` can be used as a shorthand for
> +`refs/tags/<tag>:refs/tags/<tag>`. This should be specified as
> +two arguments (that is, without quotes in the shell).
I think this should be "When pushing a tag, ...", to avoid confusion with
"--tags", which pushes (all) tags and doesn't need the "tag <tag>"
arguments.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Some updates to refspec documentation
From: Anders Melchiorsen @ 2008-10-29 20:41 UTC (permalink / raw)
To: git
In-Reply-To: <1225311945-17100-1-git-send-email-mail@cup.kalibalik.dk>
During my struggle, I also found a git push usability problem. The
refspec ":dst" will delete the remote branch without warning.
While this is indeed documented, you cannot blame somebody for
thinking that a left out <src> will default to HEAD, as it does for so
many other commands.
In a CVS-like setup, with everybody pushing to master, this could
cause havoc.
As the "git push <repository> :<dst>" operation is destructive, I
think it should be protected by the -f option.
For the record, I did realize this before trying to push ":master" :-).
Anders.
^ permalink raw reply
* Re: Some updates to refspec documentation
From: Anders Melchiorsen @ 2008-10-29 20:44 UTC (permalink / raw)
To: git
In-Reply-To: <878ws7b0d2.fsf@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> While this is indeed documented, you cannot blame somebody for
> thinking that a left out <src> will default to HEAD, as it does for
> so many other commands.
I actually think that <src> defaulting to HEAD would be reasonable,
but it is probably less reasonable to change the meaning at this
point.
Anders
^ permalink raw reply
* a few git notes numbers
From: Jeff King @ 2008-10-29 21:40 UTC (permalink / raw)
To: Johannes Schindelin, Shawn O. Pearce; +Cc: git
I looked a little bit at how bad tree lookup speed would be for notes.
My test implementation was a notes tree made like this:
blob=`echo this is a note | git hash-object -w --stdin`
export GIT_INDEX_FILE=.git/notes
# attach the note to every commit;
# note that this uses a less-efficient ascii encoding
git rev-list HEAD | while read commit; do
echo -e "100644 blob $blob\t$commit"
done | git update-index --index-info
tree=`git write-tree`
commit=`echo notes | git commit-tree $tree`
git update-ref refs/notes $tree
Then I added a %N format specifier that looked up the note in the
refs/notes tree for every commit. For a baseline, here is just looking
at the subject of a commit message:
/usr/bin/time git log --pretty=format:'%s' >/dev/null
0.57user 0.00system 0:00.58elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3497minor)pagefaults 0swaps
So it takes about half a second without notes. When I used the regular
init_tree_desc() and tree_entry() walk, that bumped to about 37 seconds
(sorry, I didn't save the /usr/bin/time output). Converting the stupid
ascii filename format to binary brought it down to 27 seconds. So both
obviously crappy due to the linear walk.
Then at somebody (David Reiss?)'s suggestion, I used our hash table
implementation and pre-seeded the table. I kept with the ascii
filenames in the tree, since they are a little easier to create, and
since we only pay the price for conversion when seeding the hash table.
And I got these numbers:
$ /usr/bin/time git log --pretty=format:'%s: %N' >/dev/null
0.85user 0.12system 0:00.98elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+20914minor)pagefaults 0swaps
So not too bad, though check out those minor page faults. Patch is
below:
---
diff --git a/pretty.c b/pretty.c
index f6ff312..c4930ac 100644
--- a/pretty.c
+++ b/pretty.c
@@ -498,6 +498,67 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
+struct note_entry {
+ unsigned char from[20];
+ unsigned char to[20];
+ struct note_entry *next;
+};
+
+static struct hash_table *notes_tree(void)
+{
+ static int initialized;
+ static struct hash_table table;
+
+ if (!initialized) {
+ unsigned char sha1[20];
+ struct tree *tree;
+ struct tree_desc desc;
+ struct name_entry entry;
+
+ init_hash(&table);
+ if(get_sha1("refs/notes", sha1) == 0)
+ tree = parse_tree_indirect(sha1);
+ init_tree_desc(&desc, tree->buffer, tree->size);
+ while (tree_entry(&desc, &entry)) {
+ struct note_entry *note;
+ unsigned int hash;
+ void **pos;
+
+ note = malloc(sizeof *note);
+ if (get_sha1_hex(entry.path, note->from) < 0) {
+ free(note);
+ continue;
+ }
+ memcpy(note->to, entry.sha1, 20);
+ memcpy(&hash, note->from, sizeof(hash));
+ pos = insert_hash(hash, note, &table);
+ if (pos) {
+ note->next = *pos;
+ *pos = note;
+ }
+ }
+
+ initialized = 1;
+ }
+ return &table;
+}
+
+static char *lookup_note(const unsigned char *sha1, unsigned long *size) {
+ struct hash_table *table = notes_tree();
+ struct note_entry *note;
+ unsigned int hash;
+
+ memcpy(&hash, sha1, sizeof(hash));
+ note = lookup_hash(hash, table);
+ while (note) {
+ if (!memcmp(sha1, note->from, 20)) {
+ enum object_type type;
+ return read_sha1_file(note->to, &type, size);
+ }
+ }
+ return NULL;
+}
+
static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -537,6 +598,17 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
return 3;
} else
return 0;
+ case 'N':
+ {
+ unsigned long size;
+ char *buf;
+ buf = lookup_note(commit->object.sha1, &size);
+ if (buf) {
+ strbuf_add(sb, buf, size);
+ free(buf);
+ }
+ }
+ return 1;
}
/* these depend on the commit */
^ permalink raw reply related
* Re: [PATCH] increase git el1T3nEss
From: Jeff King @ 2008-10-29 21:50 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Petr Baudis, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <alpine.LNX.1.00.0810291623360.19665@iabervon.org>
On Wed, Oct 29, 2008 at 04:28:16PM -0400, Daniel Barkalow wrote:
> Your mapping doesn't comply with ISO 1337.5p34k; 1 can be l (in addition
> to i), and 7 is T. Also, you're missing 4.
Patches welcome.
-Peff
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Jeff King @ 2008-10-29 21:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano, René Scharfe
In-Reply-To: <81b0412b0810290338j1beaa25bx9fb373a69f5dfe7@mail.gmail.com>
On Wed, Oct 29, 2008 at 11:38:32AM +0100, Alex Riesen wrote:
> There can be a problem with "-printf": Open Group SUS does not specify
> -printf for find(1), so it is probably a problem somewhere. I just don't know.
> [...]
> + find extract/a/a -printf "%T@\\n" >b.mtime &&
$ uname -sr
FreeBSD 6.1-RELEASE-p17-jc1
$ find . -printf "%T@\\n"
find: -printf: unknown option
> There is always a fallback, which is to write a small program which calls
> native stat(2). Or modify test-chmtime to just print mtime when asked.
I think that makes the most sense.
-Peff
^ permalink raw reply
* request for pre-generated git.info pages
From: Leo Razoumov @ 2008-10-29 22:00 UTC (permalink / raw)
To: git, Junio C Hamano
I am an emacs user but with my current setup I have difficulties
generating git.info pages. Main Git repo already provides
pre-generated man and html documentation in "man" and "html"
branches. I would kindly beg to extend this privilege to "info" pages
to benefit all the emacs users out there.
--Leo--
^ permalink raw reply
* Re: A typesetting problem with git man pages
From: Teemu Likonen @ 2008-10-29 22:22 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30810291235j554cc21dw4e3da4fdbfe633ee@mail.gmail.com>
Jonas Fonseca (2008-10-29 20:35 +0100) wrote:
> On Wed, Oct 29, 2008 at 20:16, Teemu Likonen <tlikonen@iki.fi> wrote:
>> Does anybody know why "man" prints those ".ft" commands? The
>> corresponding code in git-log.1 file is this:
> I had a similar problem after upgrading on Ubuntu and came up with a
> patch to optionally disable some of asciidoc.conf (commit
> 7f55cf451c9e7). Try putting DOCBOOK_XSL_172=Yes in your config.mak.
Ah, thank you. That fixed it.
In case someone is interested there is still a minor flaw that an
example command and the following paragraph is printed with no empty
line between them. Like in the beginning of "git help tutorial", for
example:
First, note that you can get documentation for a command such as git
log --graph with:
$ man git-log
It is a good idea to introduce yourself to git [...]
It would be nicer if there was empty line after "$ man git-log". I can't
remember if this is new issue or not. This applies only to man pages; in
html pages there are nice boxes around example commands and equal
spacing before and after them.
^ permalink raw reply
* Re: [PATCH 1/1] diff: support making output friendlier for fine, grand users
From: Petr Baudis @ 2008-10-29 22:24 UTC (permalink / raw)
To: git, A Large Angry SCM
Cc: Johannes Schindelin, Scott Chacon, Tom Preston-Werner, Jeff King,
J.H., Sam Vilain, Christian Couder, Kai Blin
In-Reply-To: <1225257832-29086-1-git-send-email-pasky@suse.cz>
On Tue, Oct 28, 2008 at 10:23:52PM -0700, Petr Baudis wrote:
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Scott Chacon <schacon@gmail.com>
> Signed-off-by: Tom Preston-Werner <tom@github.com>
> Signed-off-by: Jeff King <peff@peff.net>
> Signed-off-by: J.H. <warthog19@eaglescrag.net>
> Signed-off-by: Sam Vilain <sam@vilain.net>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> Signed-off-by: Kai Blin <kai@samba.org>
> Acked-by: Petr Baudis <pasky@suse.cz>
> Enabled-by: Cascade "Smooth" Amber <clarity@tiedhouse.com>
Sponsored-by: A Large Angry SCM <gitzilla@gmail.com>
^ permalink raw reply
* jgit as a jira plugin
From: J. Longman @ 2008-10-29 23:02 UTC (permalink / raw)
To: git
Hey there,
I've integrated jgit into a plugin for the Jira Issue tracking
system. There is more information here: http://confluence.atlassian.com/display/JIRAEXT/Jira+Git+Plugin
I'm new to git, jgit and jira plugin writing, so I have a number of
questions. These are the ones I have for you:
1) I noticed that there is a maven pom file. Are you present in a
maven repository? Also any problem with embedding a working snapshot
in my plugin?
2) I'd like to find out the jgit way to achieve the equivalent of 'svn
update'. I understand that fetch can do this but being new to git, I
don't really understand quite what I need yet. The goal is to have
git the latest commits from the origin before indexing.
Thanks for jgit - it took me a day or two to wrap my head around
getting the list of files changed in a commit but otherwise its great
to have something that can be integrated into jira.
later, jl
--
J. Longman
longman@xiplink.com
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you have received this in error, please contact the sender
and delete this communication and any copy immediately. Thank you.
^ permalink raw reply
* [PATCH 0/9] more robustness against pack corruptions
From: Nicolas Pitre @ 2008-10-29 23:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
A few months ago I produced a set of patches to allow git to work even
in the presence of pack corruption given that the corrupted objects have
a good duplicate in the object store. Turns out that this work was
rather incomplete and covered only a limited set of cases.
This series extend coverage to all cases I could think about, and make
repack-objects able to create a good pack in such conditions to "fix"
the corruption without having to perform a full repack.
Yes, this is all about the small and trivial patch I posted a while ago
that I intended to repost with a test case. Well, the test failed
miserably, resulting in this series before it finally all passed. ;-)
builtin-pack-objects.c | 79 +++++++++++++++++-----
builtin-unpack-objects.c | 2 +
cache.h | 2 +-
index-pack.c | 2 +-
pack-revindex.c | 3 +-
sha1_file.c | 85 ++++++++++++++++++-----
t/t5302-pack-index.sh | 3 +-
t/t5303-pack-corruption-resilience.sh | 96 +++++++++++++++++++++++++--
8 files changed, 223 insertions(+), 49 deletions(-)
Nicolas
^ 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