On 09/05/2013 11:36 AM, Jeff King wrote:
[...]
I haven't looked carefully at the pack v4 patches yet, but I suspect
that yes, it's still a problem. The premise of pack v4 is that we can do
better by not storing the raw git object bytes, but rather storing
specialized representations of the var
Those text files are installed as documentation (at least on my distribution).
That's probably a distribution bug (or a git makefile bug, depending
on how you look at it). It would be better to ship the HTML
documentation, converted to text, instead of keeping the version with
markup includin
On 06/10/2013 04:56 PM, Ramkumar Ramachandra wrote:
A Large Angry SCM wrote:
It is absolutely imperative to keep all our contributors productive,
and maximize output.
Why?
A useful "product" with a maintainable code base are what seems to be more
important to a successful open sou
On 06/10/2013 03:45 PM, Ramkumar Ramachandra wrote:
[...]
It is absolutely imperative to keep all our contributors productive,
and maximize output.
Why?
A useful "product" with a maintainable code base are what seems to be
more important to a successful open source effort.
A L
On 11/11/2012 12:15 PM, Jeff King wrote:
On Sun, Nov 11, 2012 at 12:00:44PM -0500, A Large Angry SCM wrote:
a) Leave the name conversion to the export tools, and when they miss
some weird corner case, like 'Author
[...]
b) Do the name conversion in fast-import itself, perhaps optionall
On 11/11/2012 12:16 PM, Felipe Contreras wrote:
On Sun, Nov 11, 2012 at 6:00 PM, A Large Angry SCM wrote:
On 11/11/2012 07:41 AM, Felipe Contreras wrote:
Such a filter would probably be quite complicated, and would decrease
performance.
Really?
The fast import stream protocol is pretty
On 11/11/2012 07:41 AM, Felipe Contreras wrote:
On Sat, Nov 10, 2012 at 8:25 PM, A Large Angry SCM wrote:
On 11/10/2012 01:43 PM, Felipe Contreras wrote:
So, the options are:
a) Leave the name conversion to the export tools, and when they miss
some weird corner case, like 'Author
On 11/10/2012 01:43 PM, Felipe Contreras wrote:
On Sat, Nov 10, 2012 at 6:28 PM, Michael J Gruber
wrote:
Felipe Contreras venit, vidit, dixit 09.11.2012 15:34:
On Fri, Nov 9, 2012 at 10:28 AM, Michael J Gruber
wrote:
Hg seems to store just anything in the author field ("committer"). The
v
The good news:
There is now some usable documentation for all the git commands except
for the following:
git-archimport (Martin?)
gitk(Paul?)
The bad news:
Some, if not most, of the command documentation is incomplete or
possibly incorrect. Mostly it's a case o
Junio C Hamano wrote:
A Large Angry SCM <[EMAIL PROTECTED]> writes:
Junio C Hamano wrote:
A Large Angry SCM <[EMAIL PROTECTED]> writes:
Naming and Directory Structure
--
Annotations are named by appending ".txt" to the basename of the
r
Junio C Hamano wrote:
[...]
Subject: [PATCH] Multi-backend merge driver.
This is just an illustration of concept patch.
The new command 'git merge' takes the current head and one or more
remote heads, with the commit log message for the automated case.
If the heads being merged are simple fast
Junio C Hamano wrote:
A Large Angry SCM <[EMAIL PROTECTED]> writes:
Naming and Directory Structure
--
Annotations are named by appending ".txt" to the basename of the
repository component it describes, and by appending ".dir" to each
Chuck Lever wrote:
yay! are you also proposing some git tools to deal with these? it
would be great to have some version control (keep these like generation
files so we can see the history of revisions).
A Large Angry SCM wrote:
GIT Repository Annotation Convention
[...]
I'
GIT Repository Annotation Convention
GIT repositories can benefit from descriptions of /intent/ for portions
of the repository. This document formalizes a method to store those
descriptions in the repository.
Annotations
Annotations are UTF8 text
Kay Sievers wrote:
On Thu, Sep 08, 2005 at 10:45:45AM +0200, Sven Verdoolaege wrote:
On Thu, Sep 08, 2005 at 04:30:22PM +1200, Martin Langhoff wrote:
Actually... should get it done. I'll see if I can sneak it in sometime soon...
This has been done at least twice already.
See e.g., http://www.l
Junio C Hamano wrote:
Zack Brown <[EMAIL PROTECTED]> writes:
It would be great if tags also allowed a brief description to go along with
them, that would show up in cg-tag-ls. Then I could seek to a tag that's just
an easy-to-type version number, and still have an idea of what's significant
abo
Junio C Hamano wrote:
Martin Atukunda <[EMAIL PROTECTED]> writes:
This script simply reports the version of git you have installed.
I wanted to ahve some way of recording the git version, but I am
wondering if 'git' without parameter telling the version number
would be good enough without int
Junio,
Looking over the latest commits I just noticed the "no documentation"
section in git.txt lists git-stripspace in error.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-
Actually, I'm cherry-picking the easier ones in an effort to reduce my
stress about my impending move to the LA area.
Hopefully you did git-diff-script, git-format-patch-script, and
git-rev-parse which don't look easy to document.
Junio C Hamano wrote:
You read my mind. I just finished docu
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]>
---
Documentation/git-show-rev-cache.txt | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
818a8f421dfa978aa4df7103e34aeadf1ba971f5
diff --git a/Documentation/git-show-rev-cache.txt
b/Documentation/git-sh
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]>
---
Documentation/git-build-rev-cache.txt | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
c7c6e77b9efa05b8a7b84fdf630f4ff64664872f
diff --git a/Documentation/git-build-rev-cache.txt
b/Documentati
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]>
---
Documentation/git-reset-script.txt | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
e6c59b4622ab3eac9c4a74cd1571136ab586ac5a
diff --git a/Documentation/git-reset-script.txt
b/Documentati
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]>
---
Documentation/git-checkout-script.txt | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
ac5328903884c402905dd2a778ce51a00c041ffc
diff --git a/Documentation/git-checkout-script.txt
b/Documentati
Santi Béjar wrote:
[...]
One thing I'm missing is a way to describe a branch. It can be
done in the $GIT_DIR/description, the first line for the whole
repository and the rest for the branches. So description file
for the git.git repository could be:
[description]
The following is the list of files in the Documentation directory that
have *NO* useful text in them at all.
git-build-rev-cache.txt
git-checkout-script.txt
git-diff-script.txt
git-format-patch-script.txt
git-get-tar-commit-id.txt
git-reset-script.
Junio C Hamano wrote:
Linus Torvalds <[EMAIL PROTECTED]> writes:
I'm testing bisection to find a bug that causes my G5 to no longer boot,
and during the process have found this command line very nice:
gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*)
it basically shows the sta
Linus Torvalds wrote:
> On Mon, 29 Aug 2005, A Large Angry SCM wrote:
>>Signed-off-by: <[EMAIL PROTECTED]>
>
> Btw, I enjoy your email address and name, but especially with something
> that is supposed to hopefully have some legal value down the line if
> somebody s
ches b/Documentation/SubmittingPatches
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -239,7 +239,7 @@ Thunderbird
(A Large Angry SCM)
Here are some hints on how to successfully submit patches inline using
-Thunderbird. [*3*]
+Thunderbird.
This recipe appears t
Copy & paste source comments into documentation.
Signed-off-by: <[EMAIL PROTECTED]>
---
Documentation/git-request-pull-script.txt | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
c309197099fceb12fa05d9aa23b0b7e5adf5f061
diff --git a/Documentation/git-request-pull-
Copy & paste source comments into documentation.
Signed-off-by: <[EMAIL PROTECTED]>
---
Documentation/git-daemon.txt | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
ea71ec7bde99f05a3766f5e1ad4ecc7bcb89ab13
diff --git a/Documentation/git-daemon.txt b/Docum
Copy & paste source comments into documentation.
Signed-off-by: <[EMAIL PROTECTED]>
---
Documentation/git-applypatch.txt | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
0c00e0e3bd83cc1297e2581cae66aeebc65e52a6
diff --git a/Documentation/git-applypatch.txt b/D
Junio C Hamano wrote:
A Large Angry SCM <[EMAIL PROTECTED]> writes:
Frank,
Can you produce a patch to update the git-repack-script documentation to
reflect the new functionality?
Not including the doc changes in the patch was my fault, but the
message was meant primarily as an expla
Junio C Hamano wrote:
This originally came from Frank Sorenson but with a bit of
rework to allow future enhancement to the command without
changing the external interface for removal part.
With the '-a' option, all objects in the current repository are
packed into a single pack. When the '-d' o
Linus Torvalds wrote:
On Sun, 28 Aug 2005, Robert Fitzsimons wrote:
Allow the user to force a patch to be applied even though there might
be whitespace differences. Added a test case for the new option.
If you ignore whitespace, then you should probably accept patches that are
whitespace corr
Add some documentation.
Text taken from the the commit messages and the command sources.
---
I made no attempt to use the proper terminology, as defined by the new
glossary, but instead used the text from the original commit messages and/or
the program source.
These are some of the easy ones. S
Daniel Barkalow wrote:
> I'm starting to work on letting the merging process see multiple
> ancestors, and I think it's messy enough that I should actually discuss
> it.
>
> Review of the issue:
>
> It is possible to lost reverts in cases when merging two commits with
> multiple ancestors, in the
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 15 Aug 2005, Junio C Hamano wrote:
>
>>Johannes Schindelin <[EMAIL PROTECTED]> writes:
>>
>>>Maybe we should enhance git-applymbox to detect whitespace corruption in
>>>particular, and output the User-Agent header (or if that does not
>>>exist, the M
Linus Torvalds wrote:
This adds a useful "Parent:" line to the git commit information window.
It looks something like this (from the infamous octopus merge):
Author: Junio C Hamano <[EMAIL PROTECTED]> 2005-05-05 16:16:54
Committer: Junio C Hamano <[EMAIL PROTECTED]> 2005-05-05
Paul Mackerras wrote:
...
I have been thinking about adding dialog windows to allow the user to
select which repository and which range of commits they want to look at.
Do you think that would be useful for you?
Yes!
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body o
Junio C Hamano wrote:
...
If the template files are to become something that always have
to exist, /etc first and then falling back on /usr/share would
make a lot of sense. But as Johannes Schindelin correctly
argued against the "Use the template mechanism to set up refs/
hierarchy as well." pat
[PATCH] Fix warning about non-void return in a void function.
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]>
---
receive-pack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
8eda2e60f24221255b77e48f4dd60e2b025839ed
diff --git a/receive-pack.c b/receive-pack.c
--- a/r
Ryan Anderson wrote:
Maybe it'd make sense to have the commits refuse to add a commit when it
would be younger than one of it's parents?
Better not to trust timestamps in distributed federations since you
can't guarantee any kind of accuracy across administrative boundaries.
-
To unsubscribe
Petr Baudis wrote:
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
Hi, A Large Angry SCM wrote:
So you're arguing for "last match wins" versus "first match wins". I,
personally, f
Junio C Hamano wrote:
...
While I agree gitk should not come as part of git package, this
brings up a different issue.
Ideally, I'd want to see gitk packaged from its repository
kernel.org:/pub/scm/gitk/git.git/ Paul Mackerras maintains, not
from GIT one which _will_ lag behind.
...
While I
Petr Baudis wrote:
I think this is wrong, and my brief experiments confirm that. I think
that the actually useful semantics of exclusion would be for
_subsequent_ exclusions, not preliminary ones. You generally don't say
"I never want this ignored, but I want the rest of that ignored", but
"I w
Junio C Hamano wrote:
While I do not have strong objections to make the build process
go faster, it is somewhat disturbing that the Makefile pieces
maintained in subdirectories need to name things they touch
using paths that include the subdirectory names. I do not have
a better alternative to s
Kirby C. Bohling wrote:
On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote:
Ryan Anderson wrote:
Convert build process from recurse Make to a single Make
Please explain the rational for this.
I'm new to the list, but given the subject, I'm fairly confident
it
Ryan Anderson wrote:
Convert build process from recurse Make to a single Make
Please explain the rational for this.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Diego Calleja wrote:
> El Tue, 26 Jul 2005 11:57:43 -0700 (PDT),
> Linus Torvalds <[EMAIL PROTECTED]> escribió:
>
>>I'm planning on doing the 2.4 tree too some day - either as a separate
>>branch in the same archive, or as a separate git archive, I haven't quite
>
> It'd be great to have the sam
Add -a option to get-tag-script to annotate but not sign a tag
Also fix the test for an existing tag.
Signed-off-by: A Large Angry SCM <[EMAIL PROTECTED]>
---
git-tag-script | 21 +++--
1 files changed, 15 insertions(+), 6 del
Junio C Hamano wrote:
Ryan Anderson <[EMAIL PROTECTED]> writes:
On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
Now if we had a mechanism to graft a later history which starts
at 2.6.12-rc2 on top of this earlier history leading up to
it,... ;-)
We do - it's not even very har
51 matches
Mail list logo
