On Mon, Jan 19, 2015 at 02:54:13PM +0100, Michael J Gruber wrote:
Josh Triplett schrieb am 19.01.2015 um 02:29:
I'd like to use git-log to generate a Debian changelog file (with one
entry per commit), which has entries like this:
package-name (version-number) unstable; urgency=low
On Mon, Jan 19, 2015 at 10:51 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ae6791d..7371a5f 100644
--- a/Documentation/config.txt
+++
On Mon, Jan 19, 2015 at 9:20 AM, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
I have tried to fix this before: see 568950388be2, but it doesn't
really work.
I don't know how it happend, but that commit makes interactive rebase to
respect core.abbrev only during --edit-todo, but
Robert, Peff and Junio.
Thank you all for your feedback. It's clear now what sort of analysis I should
aim towards.
Thanks,
Zoltan
--
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
Hi Eric,
On 2015-01-19 23:44, Eric Sunshine wrote:
On Mon, Jan 19, 2015 at 10:51 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
diff --git a/Documentation/config.txt b/Documentation/config.txt
index
From: Collins, Margaret
Sent: Monday, January 19, 2015 5:28 PM
To: margaret.coll...@iammorrison.com
Subject: donation
Liliane bettencourt donation to you, reply my email for more details (
bettencourtlia...@hotmail.com
Jason Pyeron schrieb am 16.01.2015 um 21:05:
-Original Message-
From: Junio C Hamano
Sent: Friday, January 16, 2015 14:53
Jonathan Nieder jrnie...@gmail.com writes:
would there be interest in accepting a patch for
%Gs - the raw GPG text from the commit
%Gf - the key fingerprint
Alexander Kuleshov schrieb am 17.01.2015 um 08:35:
This patch adds support -d/--dry-run option for branch(es) deletion.
If -d/--dry-run option passed to git branch -d branch..., branch(es)
will not be removed, instead just print list of branches that are
to be removed.
For example:
$
I have tried to fix this before: see 568950388be2, but it doesn't
really work.
I don't know how it happend, but that commit makes interactive rebase to
respect core.abbrev only during --edit-todo, but not the initial todo
list edit.
For this time I've included a test-case to avoid this
Josh Triplett schrieb am 19.01.2015 um 02:29:
I'd like to use git-log to generate a Debian changelog file (with one
entry per commit), which has entries like this:
package-name (version-number) unstable; urgency=low
* ...
-- Example Person per...@example.org RFC822-date
Since I'm
This option avoids unpacking each and all objects, and just verifies the
connectivity. In particular with large repositories, this speeds up the
operation, at the expense of missing corrupt blobs and ignoring
unreachable objects, if any.
Signed-off-by: Johannes Schindelin
At the moment, the git-fsck's integrity checks are targeted toward the
end user, i.e. the error messages are really just messages, intended for
human consumption.
Under certain circumstances, some of those errors should be allowed to
be turned into mere warnings, though, because the cost of
There are legacy repositories out there whose older commits and tags
have issues that prevent pushing them when 'receive.fsckObjects' is set.
One real-life example is a commit object that has been hand-crafted to
list two authors.
Often, it is not possible to fix those issues without disrupting
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by specifying `invalid-tag-name` and
`missing-tagger-entry` to the receive.fsck.error config setting.
Incidentally, the missing tagger warning is now really shown as a warning
(as opposed to being reported
The optional new config option `receive.fsck.skiplist` specifies the path
to a file listing the names, i.e. SHA-1s, one per line, of objects that
are to be ignored by `git receive-pack` when `receive.fsckObjects = true`.
This is extremely handy in case of legacy repositories where it would
cause
Just like the diff machinery, we are about to introduce more settings,
therefore it makes sense to carry them around as a (pointer to a) struct
containing all of them.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/fsck.c | 20 +--
builtin/index-pack.c
Instead of specifying whether a message by the fsck machinery constitutes
an error or a warning, let's specify an identifier relating to the
concrete problem that was encountered. This is necessary for upcoming
support to be able to demote certain errors to warnings.
In the process, simplify the
Some legacy code has objects with non-fatal fsck issues; To enable the
user to ignore those issues, let's print out the ID (e.g. when
encountering missing-email, the user might want to call `git config
receive.fsck.warn missing-email`).
Signed-off-by: Johannes Schindelin
When fsck_commit() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Note that some problems are too problematic to simply ignore. For
example, when the header
When fsck_ident() identifies a problem with the ident, it should still
advance the pointer to the next line so that fsck can continue in the
case of a mere warning.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
fsck.c | 49 +++--
1
An fsck issue in a legacy repository might be so common that one would
like not to bother the user with mentioning it at all. With this change,
that is possible by setting the respective error to ignore.
This change abuses the warn=missing-email test to verify that ignore
is also accepted and
This problem has been detected in the wild, and is the primary reason
to introduce an option to demote certain fsck errors to warnings. Let's
offer to ignore this particular problem specifically.
Technically, we could handle such repositories by setting
receive.fsck.warn = missing-committer, but
Some kinds of errors are intrinsically unrecoverable (e.g. errors while
uncompressing objects). It does not make sense to allow demoting them to
mere warnings.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
fsck.c | 13 +++--
This function will be used in the next commits to allow the user to
ask fsck to handle specific problems differently, e.g. demoting certain
errors to warnings. It has to handle partial strings because we would
like to be able to parse, say, 'missing-email,missing-tagger-entry'
command lines.
To
For example, missing emails in commit and tag objects can be demoted to
mere warnings with
git config receive.fsck.warn = missing-email
The value is actually a comma-separated list, and there is a
corresponding receive.fsck.error setting.
In case that the same key is listed in multiple
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
Documentation/config.txt | 25 +
1 file changed, 25 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ae6791d..7371a5f 100644
--- a/Documentation/config.txt
+++
We already have support in `git receive-pack` to deal with some legacy
repositories which have non-fatal issues.
Let's make `git fsck` itself useful with such repositories, too, by
allowing users to ignore known issues, or at least demote those issues
to mere warnings.
Example: `git -c
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
t/t5504-fetch-receive-strict.sh | 20
1 file changed, 20 insertions(+)
diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
index 69ee13c..d491172 100755
---
When fsck_tag() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Just like fsck_commit(), there are certain problems that could hide other
issues with the same tag
On Fri, 16 Jan 2015 14:29:17 +, Andreas Krey wrote:
...
=== /tmp/tmp-ws-20150116-11355-v7zfcc
searching to describe HEAD
lightweight4 r2.4/bl-0
lightweight4 r2.4/bl-1
traversed 5 commits
r2.4/bl-0-4-g689e350
Apparently, this comes because two of the commit have the
Hi, this is Jeff Wu from China.
We are a wholesaler of pet products.
Main products are pet clothes, leash, harness, collar, bag and accessory.
Please let me know if you are interested to buy from us, thanks!
I will send the price lists and website to you then.
Best regards,
Jeff Wu
--
To
When parsing an URL, older Git versions did handle
URLs like ssh://2001:db8::1/repo.git the same way as
ssh://[2001:db8::1]/repo.git
Commit 83b058 broke the parsing of IPV6 adresses without []:
It was written in mind that the fist ':' in a URL was the beginning of a
port number, while the old
The URL for ssh may have include a username before the hostname,
like ssh://user@host/repo.
When literal IPV6 addresses are used together with a username,
the substring user@[::1] must be converted into user@::1.
Make that conversion visible for the user, and write userandhost
in the diagnostics
Test the parsing of literall IPV6 addresses more systematically:
- with and without brackets (e.g. ::1 [::1])
- with brackets and port number: (e.g. [::1]:22)
- with username (e.g. user@::1)
- with username and brackets:
Because user@[::1] was not supported on older Git version,
[user@::1] had
I have found that `git config --global` does not pick up any include
directives in the git config file.
For instance, my ~/.gitconfig contains the following:
[include]
path = /home/garrison/gitconfig-include
And ~/gitconfig-include in turn contains
[user]
name = Jim
On Mon, Jan 19, 2015 at 11:37:10AM -0800, Jim Garrison wrote:
I have found that `git config --global` does not pick up any include
directives in the git config file.
That's by design. You asked for the entries in a specific file, and we
do not follow any includes by default in that case. You
I have a directory with nested submodules, such as:
supermodule/submodule/sub-submodule/sub-sub-submodule
When I cd to supermodule and do:
git push --recurse-submodule=check (or on-demand),
git only pushes the submodule, but not the sub-submodule etc.
Maybe this is expected behavior and not a
On Sunday, January 18, 2015, Yi EungJun semtlen...@gmail.com wrote:
Add an Accept-Language header which indicates the user's preferred
languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
Examples:
LANGUAGE= -
LANGUAGE=ko:en - Accept-Language: ko, en;q=0.9, *;q=0.1
38 matches
Mail list logo
