Johannes Sixt wrote:
I haven't followed the topic closely, but I wonder why there are so many
explicit assignments to GIT_REFLOG_ACTION. Is calling set_reflog_action
(defined in git-sh-setup) the wrong thing to do?
Does this answer your question?
set_reflog_action() {
if [ -z
Hi,
Richard Hansen wrote:
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -82,6 +82,17 @@ to point at the new commit.
to the top def_directory,directory of the stored
revision.
+[[def_committish]]committish (also commit-ish)::
+ A
Am 6/19/2013 8:09, schrieb Ramkumar Ramachandra:
Johannes Sixt wrote:
I haven't followed the topic closely, but I wonder why there are so many
explicit assignments to GIT_REFLOG_ACTION. Is calling set_reflog_action
(defined in git-sh-setup) the wrong thing to do?
Does this answer your
We read loose references in two steps. The code is roughly:
lstat()
if error ENOENT:
loose ref is missing; look for corresponding packed ref
else if S_ISLNK:
readlink()
if error:
report failure
else if S_ISDIR:
report failure
else
There is only one break statement within the loop, which jumps to
the code after the loop that handles the case of a file that holds a
SHA-1. So move that code from below the loop into the if statement
where the break was previously located. This makes the logic flow
more local.
Signed-off-by:
The nesting was getting a bit out of hand, and it's about to get
worse.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 56 +++-
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/refs.c b/refs.c
index
The following command
$ git cherry-pick --ff b8bb3f
writes the following uninformative message to the reflog
cherry-pick
Improve it to
cherry-pick: fast-forward
Avoid hard-coding cherry-pick in fast_forward_to(), so the sequencer
is generic enough to support future actions.
On Tue, 18 Jun 2013, Jeff King wrote:
But, I don't know if there is any multi-processing happening within the
curl library.
I don't think curl does any threading; when we are not inside
curl_*_perform, there is no curl code running at all (Daniel can correct me
if I'm wrong on that).
Re-roll of mh/ref-races. Thanks to Peff, Junio, and Ramsay for
reviewing v1.
Changes since v1:
* mh/reflife has graduated to master, so this patch series now applies
directly to master.
* Some trivial constness adjustments were necessary because of
21a6b9fa read-cache: mark cache_entry
From: Jeff King p...@peff.net
Once we read the packed-refs file into memory, we cache it
to save work on future ref lookups. However, our cache may
be out of date with respect to what is on disk if another
process is simultaneously packing the refs. Normally it
is acceptable for us to be a little
In struct packed_ref_cache, keep a count of the number of users of the
data structure. Only free the packed ref cache when the reference
count goes to zero rather than when the packed ref cache is cleared.
This mechanism will be used to prevent the cache data structure from
being freed while it
As we know, we can solve any problem in this manner. In this case,
the problem is to avoid freeing a packed refs cache while somebody is
using it. So add a level of indirection as a prelude to
reference-counting the packed refs cache.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Increment the packed_ref_cache reference count while it is locked to
prevent its being freed.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index d90f487..6d48b42 100644
--- a/refs.c
+++
It can sometimes be useful to know whether a path in the
filesystem has been updated without going to the work of
opening and re-reading its content. We trust the stat()
information on disk already to handle index updates, and we
can use the same trick here.
This patch introduces a stat_validity
Split pack_refs() into multiple passes:
* Iterate over loose refs. For each one that can be turned into a
packed ref, create a corresponding entry in the packed refs cache.
* Write the packed refs to the packed-refs file.
This change isolates the mutation of the packed-refs file to a single
This function calls a user-supplied callback function which could do
something that causes the packed refs cache to be invalidated. So
acquire a reference count on the data structure to prevent our copy
from being freed while we are iterating over it.
Signed-off-by: Michael Haggerty
The repack_without_ref() function first removes the deleted ref from
the internal packed-refs list, then writes the packed-refs list to
disk, omitting any broken or stale entries. This patch splits that
second step into multiple passes:
* collect the list of refnames that should be deleted from
Add public functions fill_stat_data() and match_stat_data() to work
with it. This infrastructure will later be used to check the validity
of other types of file.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/ls-files.c | 12 +++--
cache.h| 33 +---
Handle simple transactions for the packed-refs file at the
packed_ref_cache level via new functions lock_packed_refs(),
commit_packed_refs(), and rollback_packed_refs().
Only allow the packed ref cache to be modified (via add_packed_ref())
while the packed refs file is locked.
Change clone to
From: Jeff King p...@peff.net
If we are iterating through the refs using for_each_ref (or
any of its sister functions), we can get into a race
condition with a simultaneous pack-refs --prune that looks
like this:
0. We have a large number of loose refs, and a few packed
refs.
Now that we keep track of the packed-refs file metadata, we can detect
when the packed-refs file has been modified since we last read it, and
we do so automatically every time that get_packed_ref_cache() is
called. So there is no need to invalidate the cache automatically
when lock_packed_refs()
Ok, this is how it looks. If everything is ok, I'm sending it to the ML
From 262bdfb5cc84fec7c9b74dc92bb604f9d168ef9a Mon Sep 17 00:00:00 2001
From: Alexander Nestorov alexander...@gmail.com
Date: Wed, 19 Jun 2013 09:55:42 +0200
Subject: [PATCH] Add example for reseting based on content changes
b397ea4 (status: show more info than currently not on any branch,
2013-03-13) attempted to make the output of 'git status' richer in
the case of a detached HEAD. Before this patch, with a detached
HEAD, we saw:
$ git status
# Not currently on any branch.
But after the patch, we see:
$
So, this is hopefully the final re-roll. [6/7] and [7/7] have updated
commit messages and comments describing what this new
base_reflog_action is. Also, to prevent breakages with another
in-flight topic, the test that Junio contributed to [7/7] uses a
different branch name.
Thanks.
Junio C
From: Junio C Hamano gits...@pobox.com
b397ea (status: show more info than currently not on any branch,
2013-03-13) wanted to make sure that after a checkout to detach HEAD,
the user can see where the HEAD was originally detached from. The last
test added by that commit to t/status-help shows
The struct grab_1st_switch_cbdata has the field found, which is
set in grab_1st_switch() when a match is found. This information is
redundant and unused by any code. The return value of the function
serves to communicate this information anyway.
Remove the field.
Signed-off-by: Ramkumar
$ git checkout -
does not work as expected after a rebase. This is because the
reflog records checkout made by rebase as its implementation
detail the same way as end-user initiated checkout, and makes it
count as the branch that was previously checked out.
Add four failing tests documenting
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Several other commands
including merge, reset, and commit respect it.
Fix the failing tests in t/checkout-last by making checkout respect it
too. You can now expect
$ git
Now that the checkout invoked internally from rebase knows to honor
GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when rebase anotherbranch, rebase --onto branch,
etc. internally checks out the new fork point. We will write:
rebase: checkout master
instead of the
Now that the checkout invoked internally from rebase -i knows to
honor GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when rebase -i anotherbranch, rebase -i --onto branch,
etc. internally checks out the new fork point. We will write:
rebase -i (start): checkout
Chanel Taschen Outlet http://www.onlinechaneltaschenshop.de/
Normalerweise würden Sie brauchen, um eine Chanel Flagship-Store, oder
hochwertigen Bereich Shop besuchen, um Chanel Designer-Handtaschen und
Taschen zu finden, und zusätzlich würden Sie zahlen eine ganz Cent für jeden
einzelnen
Nike Air Max billig http://www.schuhenzalando.de/nike-air-max Ich habe
Ausübung ca. 3 Jahren und genutzt haben diese tolle Alltag Nike Shox oz
Schuhe, die teure Reebok sowie die Damen Adidas Originals Jeremy Scott zigs.
Out und auch weg, Entwicklung des Kindes eine große Anzahl von flexiblen
Am 6/19/2013 10:04, schrieb Ramkumar Ramachandra:
+test_expect_failure 'checkout - works after a rebase -i A B' '
+ git branch foodle master~1
+ git checkout master
+ git checkout other
+ git rebase master foodle
git rebase -i master foodle
+ git checkout -
Johannes Sixt wrote:
Am 6/19/2013 10:04, schrieb Ramkumar Ramachandra:
+test_expect_failure 'checkout - works after a rebase -i A B' '
+ git branch foodle master~1
+ git checkout master
+ git checkout other
+ git rebase master foodle
git rebase -i master foodle
Introduce test_pushdefault_workflows(), and test that all push.default
modes work with central and triangular workflows as expected.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5528-push-default.sh | 36
1 file changed, 36 insertions(+)
The setup creates two bare repositories: repo1 and repo2, but
test_push_commit() hard-codes checking in repo1 for the actual output.
Generalize it and its caller, test_push_success(), to optionally accept
a third argument to specify the name of the repository to check for
actual output. We will
[2/6] documents existing push.default modes properly, but doesn't
touch `simple`. It incorporates feedback from Junio, Philip Oakley,
Matthieu Moy.
[3/6] gives `simple` an exciting new meaning. I think it's an
absolutely fabulous default! It's aimed at triangular people who
occassionally need
When remote.pushdefault or branch.name.pushremote is set (a triangular
workflow feature), master@{u} != origin, and push.default is set to
`upstream` or `simple`:
$ git push
fatal: You are pushing to remote 'origin', which is not the upstream of
your current branch 'master', without telling
Now that simple has been decoupled from upstream in setup_push_simple(),
remove the dead code in setup_push_upstream().
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/push.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/builtin/push.c
4d3592 (Merge branch 'rr/triangle', 2013-04-07) introduced support for
triangular workflows in Git, but the push.default values still assume
central workflows. Rewrite the descriptions of `nothing`, `current`,
`upstream` and `matching` for greater clarity, and explicitly explaining
how they
The line
test_config push.default upstream
appears unnecessarily in two tests, as the final test_push_failure sets
push.default before pushing anyway.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5528-push-default.sh | 2 --
1 file changed, 2 deletions(-)
diff --git
From: Jorge Juan Garcia Garcia jorge-juan.garcia-gar...@ensimag.imag.fr
Make it so that we can use a list of email in flags
instead of having to use one flag per email address.
The use-case is to copy-paste a list of addresses from an email.
This change makes it so that we no longer need to cut
Alexander Nestorov alexander...@gmail.com writes:
Ok, this is how it looks. If everything is ok, I'm sending it to the ML
Please, read Documentation/SubmittingPatches (you lack a sign-off and if
you think the patch is ready, you should Cc Junio). Also, it's better to
have the commit headers
jorge-juan.garcia-gar...@ensimag.imag.fr writes:
Changes since v1:
[...]
- did not change the two regexp into one, because it's faster with two
(I find it strange to describe non-change in a list of changes)
I don't think speed is an argument here: it's a one-time operation and
will be
On Tue, Jun 18, 2013 at 10:05:50PM -0700, David Aguilar wrote:
On Tue, Jun 18, 2013 at 6:55 PM, W. Trevor King wk...@tremily.us wrote:
-$ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \
+$ git clone --bare -l -s /pub/scm/.../torvalds/linux.git \
Hi,
after a couple of months of inactivity I recently updated my git clone
from the main repo, and later ran 'git gc', which, of course,
dutifully pruned the old reflog entries, leaving my reflogs quite
shallow:
$ git reflog master
0dbd8125 master@{0}: merge origin/master: Fast-forward
f3828dc0
On 2013-06-19 01:56, Ramkumar Ramachandra wrote:
From gitglossary(7):
ref
A 40-byte hex representation of a SHA-1 or a name that denotes a
particular object. They may be stored in a file under $GIT_DIR/refs/
directory, or in the $GIT_DIR/packed-refs file.
Do master~3 and
On Wed, Jun 19, 2013 at 08:36:25AM +0200, Michael Haggerty wrote:
I took Peff's suggestion to use gotos rather than an infinite loop in
the last patch, which means that there is no need for the old patch
03/04.
Thanks, this version looks good to me.
I'm sure the Pascal programmers of the
On 2013-06-19 11:31, Richard Hansen wrote:
On 2013-06-19 01:56, Ramkumar Ramachandra wrote:
From gitglossary(7):
ref
A 40-byte hex representation of a SHA-1 or a name that denotes a
particular object. They may be stored in a file under $GIT_DIR/refs/
directory, or in the
On 19 June 2013 01:00, Alexander Nestorov alexander...@gmail.com wrote:
Ok, this is how it looks. If everything is ok, I'm sending it to the ML
From 262bdfb5cc84fec7c9b74dc92bb604f9d168ef9a Mon Sep 17 00:00:00 2001
From: Alexander Nestorov alexander...@gmail.com
Date: Wed, 19 Jun 2013
Johannes Sixt j.s...@viscovery.net writes:
Am 6/18/2013 20:55, schrieb Ramkumar Ramachandra:
Now that the checkout invoked internally from rebase knows to honor
GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when rebase anotherbranch, rebase --onto branch,
etc.
W. Trevor King wk...@tremily.us writes:
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index a0727d7..8e5260f 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -274,7 +274,7 @@ $ git clone --bare -l /home/proj/.git /pub/scm/proj.git
*
Thanks, will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Richard Hansen rhan...@bbn.com writes:
The documentation contains a mix of the two spellings, and including
both makes it possible for users to search the glossary with their
spelling of choice.
Is it an option to instead find dashless form in our documentation
and turn all of them into
Richard Hansen rhan...@bbn.com writes:
Signed-off-by: Richard Hansen rhan...@bbn.com
---
Documentation/glossary-content.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 01365d9..a3cc003
Jeff King p...@peff.net writes:
On Wed, Jun 19, 2013 at 08:36:25AM +0200, Michael Haggerty wrote:
I took Peff's suggestion to use gotos rather than an infinite loop in
the last patch, which means that there is no need for the old patch
03/04.
Thanks, this version looks good to me.
I'm
Junio C Hamano gits...@pobox.com writes:
Excellent question, and I think this illustrates why the recent
reroll that uses an approach to use base_reflog_action is not
complete and needs further work (to put it mildly).
...
That essentially boils down to the very original suggestion I made
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Excellent question, and I think this illustrates why the recent
reroll that uses an approach to use base_reflog_action is not
complete and needs further work (to put it mildly).
...
That essentially boils
Matthieu Moy matthieu@grenoble-inp.fr writes:
Veres Lajos vla...@gmail.com writes:
I am trying to convert this pull request:
https://github.com/git/git/pull/42
to a proper patch email
Use git format-patch and/or git send-email to get the proper
formatting.
(Sorry If I miss something
Richard Hansen rhan...@bbn.com writes:
gitrevisions(7) implies that rev^{tag} should work,...
Does it? Is it possible that that should be fixed?
What does it even _mean_ to peel something to a TAG?
A commit, a tree or a blob cannot be peeled to a tag---none of them
can contain a tag.
When
Matthieu Moy matthieu@grenoble-inp.fr writes:
Alexander Nestorov alexander...@gmail.com writes:
Ok, this is how it looks. If everything is ok, I'm sending it to the ML
Please, read Documentation/SubmittingPatches (you lack a sign-off and if
you think the patch is ready, you should Cc
SZEDER Gábor sze...@ira.uka.de writes:
$ git log --oneline -1 master@{1}
fatal: Log for 'master' only has 1 entries.
Annoyed, I just copy-pasted the sha and got the job done.
However, I wonder why it didn't worked. 'git reflog' didn't print
master@{1} or any message for the oldest entry,
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for break-rewrites.
When this option is used, git-diff will not create hunks that simply
add or remove empty lines, but will still show
On Wed, Jun 19, 2013 at 09:51:21AM +0200, Michael Haggerty wrote:
Re-roll of mh/ref-races. Thanks to Peff, Junio, and Ramsay for
reviewing v1.
Thanks. I just read through them again. Everything looks good to me.
Patches 10 and 11 are missing my signoff, but obviously:
Signed-off-by: Jeff
On 2013-06-19 13:09, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
The documentation contains a mix of the two spellings, and including
both makes it possible for users to search the glossary with their
spelling of choice.
Is it an option to instead find dashless form in
On 2013-06-19 13:14, Junio C Hamano wrote:
object-type-ish does not have anything to do with a ref. Even
when an object is dangling in your object store without being
reachable from any of your refs, it keeps its own ish-ness.
Ah, so your personal definition of ref matches my personal
Michael Haggerty mhag...@alum.mit.edu writes:
Handle simple transactions for the packed-refs file at the
packed_ref_cache level via new functions lock_packed_refs(),
commit_packed_refs(), and rollback_packed_refs().
Only allow the packed ref cache to be modified (via add_packed_ref())
while
Ramkumar Ramachandra artag...@gmail.com writes:
The line
test_config push.default upstream
appears unnecessarily in two tests, as the final test_push_failure sets
push.default before pushing anyway.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5528-push-default.sh |
On Wed, Jun 19, 2013 at 11:48:01AM -0700, Junio C Hamano wrote:
SZEDER Gábor sze...@ira.uka.de writes:
$ git log --oneline -1 master@{1}
fatal: Log for 'master' only has 1 entries.
Annoyed, I just copy-pasted the sha and got the job done.
However, I wonder why it didn't worked.
Ramkumar Ramachandra artag...@gmail.com writes:
push.default::
+ Defines the action `git push` should take if no refspec is
+ explicitly given. Different values are well-suited for
+ specific workflows; for instance, in a purely central workflow
+ (i.e. the fetch source is
Ramkumar Ramachandra artag...@gmail.com writes:
When remote.pushdefault or branch.name.pushremote is set (a triangular
workflow feature), master@{u} != origin, and push.default is set to
`upstream` or `simple`:
$ git push
fatal: You are pushing to remote 'origin', which is not the
Ramkumar Ramachandra artag...@gmail.com writes:
Now that simple has been decoupled from upstream in setup_push_simple(),
remove the dead code in setup_push_upstream().
Good.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/push.c | 6 ++
1 file changed, 2
On 2013-06-19 14:38, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
gitrevisions(7) implies that rev^{tag} should work,...
Does it? Is it possible that that should be fixed?
Depends on whether you think ^{tag} is a useful feature or not; see below.
What does it even
On 2013-06-19 13:09, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
The documentation contains a mix of the two spellings, and including
both makes it possible for users to search the glossary with their
spelling of choice.
Is it an option to instead find dashless form in
On Wed, Jun 19, 2013 at 10:07:24AM -0700, Junio C Hamano wrote:
W. Trevor King wk...@tremily.us writes:
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index a0727d7..8e5260f 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -274,7
Richard Hansen rhan...@bbn.com writes:
On 2013-06-19 13:14, Junio C Hamano wrote:
object-type-ish does not have anything to do with a ref. Even
when an object is dangling in your object store without being
reachable from any of your refs, it keeps its own ish-ness.
Ah, so your personal
W. Trevor King wk...@tremily.us writes:
I think any doc rewrites should be outside the scope of this patch,
which should just replace references to linux-2.6.git with linux.git
(as it does).
OK.
Should the size updates from 2/2 (user-manual: Update download size
for Git and the kernel)
Richard Hansen rhan...@bbn.com writes:
Perhaps something like:
-[[def_tree-ish]]tree-ish::
+[[def_tree-ish]]tree-ish (sometimes misspelled treeish)::
would be satisfactory?
If it is a misspelling, I do not think we need to list both. An
entry tree-ish can be found if you were looking for
Ramkumar Ramachandra artag...@gmail.com writes:
The setup creates two bare repositories: repo1 and repo2, but
test_push_commit() hard-codes checking in repo1 for the actual output.
Generalize it and its caller, test_push_success(), to optionally accept
a third argument to specify the name of
Ramkumar Ramachandra artag...@gmail.com writes:
Introduce test_pushdefault_workflows(), and test that all push.default
modes work with central and triangular workflows as expected.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5528-push-default.sh | 36
Antoine Pelisse apeli...@gmail.com writes:
So here is a more thorough description of the option:
- real changes are interesting
- blank lines that are close enough (less than context size) to
interesting changes are considered interesting (recursive definition)
- context lines are used
On 2013-06-19 17:05, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
On 2013-06-19 13:14, Junio C Hamano wrote:
object-type-ish does not have anything to do with a ref. Even
when an object is dangling in your object store without being
reachable from any of your refs, it keeps
Richard Hansen rhan...@bbn.com writes:
Here's what I'm trying to say:
* Given the current definition of ref in gitglossary(7), claiming
that a foo-ish is a ref is not entirely incorrect.
Ahh. If you had quoted this a few exchanges ago:
[[def_ref]]ref::
A 40-byte hex
Signed-off-by: Veres Lajos vla...@gmail.com
---
git-p4.py|2 +-
git-svn.perl |2 +-
t/t7600-merge.sh |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 911bbce..88fcf23 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -3168,7
On 2013-06-19 18:36, Junio C Hamano wrote:
Ahh. If you had quoted [...] a few exchanges ago I would have
immediately understood what you were trying to say.
Sorry about that, my bad.
In today's world (after packed-refs was introduced), probably
A name that begins with refs/ (e.g.
From: R. Andrew Ohana andrew.oh...@gmail.com
This is preferable to just aborting when no
common ancestor is found since it handles merges
of intersecting branches.
This is incredibly useful functionality when
consolidating multiple repositories (potentially
after using filter-branch to fix
--
hello,
Heeft u behoefte aan een lening om uw omstandigheden te helpen?
Bent u een zakelijke man of een vrouw? Ben je in een financiële stress of
U wilt uw eigen bedrijf, maar geld hebt, heb je een lening te starten of nodig
hypothekeren om uw schulden te vereffenen, of betalen van je
Junio C Hamano gits...@pobox.com writes:
Without any configuration the current branch is pushed out, which
loosens the safety we implemented in the current 'safer upstream'.
I am not convinced this is a good change. I am not convinced this is
a bad change, either, yet, but this loosening
Richard Hansen rhan...@bbn.com writes:
On 2013-06-19 18:36, Junio C Hamano wrote:
Ahh. If you had quoted [...] a few exchanges ago I would have
immediately understood what you were trying to say.
Sorry about that, my bad.
In today's world (after packed-refs was introduced), probably
Junio C Hamano gits...@pobox.com writes:
or something like that.
Just for a completeness, in a patch form:
Documentation/config.txt | 66
1 file changed, 39 insertions(+), 27 deletions(-)
diff --git a/Documentation/config.txt
90 matches
Mail list logo
