Dennis Kaarsemaker writes:
> On za, 2016-04-02 at 20:41 -0700, Junio C Hamano wrote:
>> I think by now it is very clear that nobody active in the Git
>> development community tests RPM binaries built with git.spec.in we
>> have in our tree. I suspect RPM based distros are using their own
>> RPM b
On Fri, Apr 01, 2016 at 09:06:20AM -0700, Junio C Hamano wrote:
>Ye Xiaolong writes:
>
>> On Thu, Mar 31, 2016 at 10:43:48AM -0700, Junio C Hamano wrote:
>>>Xiaolong Ye writes:
>>>
Introduce --base=auto to record the base commit info automatically, the
base_commit
will be the merg
Jeff King writes:
> On Mon, Apr 04, 2016 at 05:58:37PM -0700, Junio C Hamano wrote:
>
>> +count_expand ()
>> +{
>
> This function takes a lot of unnamed arguments that we process with
> "shift". It might be nice to give a brief comment describing them.
> ...
>> +test_expand --pretty=fuller
>> +te
Jeff King writes:
> On Mon, Apr 04, 2016 at 09:10:46PM -0400, Eric Sunshine wrote:
>
>> > + count=$1 ;# expected tabs
>>
>> Why semicolon before the hash here and above?
>
> I am in the habit of doing this, too. I have a vague recollection of
> getting bitten by a shell that treated:
>
>
Hello,
On Sun, Apr 3, 2016 at 9:44 AM, Jeff King wrote:
> On Sun, Apr 03, 2016 at 02:54:22PM +1200, Phil Sainty wrote:
>
>> Given the following symbolic reference:
>>
>> $ git symbolic-ref refs/heads/m refs/heads/master
>>
>>
>> Correct in 2.6.6:
>>
>> $ PATH=~/git/git-2.6.6:$PATH git branch
>>
On Fri, Apr 01, 2016 at 09:00:20AM -0700, Junio C Hamano wrote:
>Ye Xiaolong writes:
>
>> On Thu, Mar 31, 2016 at 10:38:04AM -0700, Junio C Hamano wrote:
>>
>>>The contents of this look OK, but does it format correctly via
>>>AsciiDoc? I suspect that only the first paragraph up to "of this
>>>sha
On Mon, Apr 4, 2016 at 11:00 PM, Eric Sunshine wrote:
> On Mon, Apr 4, 2016 at 8:45 AM, Pranit Bauva wrote:
>> Okay I will do the change. I was previously unaware about the use of
>> '\' before EOF. I googled it now. But I am still confused about its
>> use in this scenario. Upto what I understoo
On Mon, Apr 4, 2016 at 9:46 PM, Santiago Torres wrote:
> Eric Sunshine wrote:
>> > +test_expect_success GPG 'verify multiple tags' '
>> > + tags="fourth-signed sixth-signed seventh-signed" &&
>> > + for i in $tags; do
>> > + git verify-tag -v --raw $i || return 1
>> > +
On Mon, Apr 4, 2016 at 10:10 PM, Santiago Torres wrote:
> On Mon, Apr 04, 2016 at 10:00:17PM -0400, Eric Sunshine wrote:
>> On Mon, Apr 4, 2016 at 6:22 PM, wrote:
>> > - return gpg_verify_tag(name, GPG_VERIFY_VERBOSE);
>> > + return gpg_verify_tag(sha1, GPG_VERIFY_VERBOSE);
>>
>> So,
Could we have block comments in gitconfig?
It's a nice-to-have supported in most languages.
eg:
#{
commented out block
#}
or other intuitive syntax
--
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:
On Mon, Apr 04, 2016 at 05:58:37PM -0700, Junio C Hamano wrote:
> +count_expand ()
> +{
This function takes a lot of unnamed arguments that we process with
"shift". It might be nice to give a brief comment describing them.
> +test_expand ""
> +test_expand --pretty
> +test_expand --pretty=short
>
On Mon, Apr 04, 2016 at 10:00:17PM -0400, Eric Sunshine wrote:
> On Mon, Apr 4, 2016 at 6:22 PM, wrote:
> > tag.c: Change gpg_verify_tag argument to sha1
>
> s/Change/change/
Sorry I've been consistently missing these...
>
> > The gpg_verify_tag function resolves the ref for any existing obje
On Mon, Apr 04, 2016 at 09:10:46PM -0400, Eric Sunshine wrote:
> > + count=$1 ;# expected tabs
>
> Why semicolon before the hash here and above?
I am in the habit of doing this, too. I have a vague recollection of
getting bitten by a shell that treated:
echo foo # bar
or something simi
On Mon, Apr 4, 2016 at 6:22 PM, wrote:
> tag.c: Change gpg_verify_tag argument to sha1
s/Change/change/
> The gpg_verify_tag function resolves the ref for any existing object.
> However, git tag -v resolves to only tag-refs. We can provide support
> for sha1 by moving the refname resolution cod
On Mon, Apr 04, 2016 at 05:58:33PM -0700, Junio C Hamano wrote:
> So here is the fifth and hopefully the final try. Previous round
> are at $gmane/289694, $gmane/289166, $gmane/288987 and
> $gmane/290222.
With the exception of two minor nits on the final patch, this looks good
to me. Thanks for
>
> The bulk of this description is merely repeating what the patch itself
> already says, thus is redundant. The entire commit message could
> probably be collapsed to:
>
> t7030: test verify-tag with multiple tags
>
> git-verify-tag accepts multiple tags as arguments, however,
> ex
On Mon, Apr 04, 2016 at 09:39:29PM -0400, Eric Sunshine wrote:
> On Mon, Apr 4, 2016 at 6:22 PM, wrote:
> > Instead of running the verify-tag plumbing command, we use the
> > pgp_verify_tag(). This avoids the usage of an extra fork call. To do
> > this, we extend the number of parameters that tag
On Mon, Apr 4, 2016 at 6:22 PM, wrote:
> Instead of running the verify-tag plumbing command, we use the
> pgp_verify_tag(). This avoids the usage of an extra fork call. To do
> this, we extend the number of parameters that tag.c takes, and
> verify-tag passes. Redundant calls done in the pgp_veri
On Mon, Apr 4, 2016 at 6:22 PM, wrote:
> tag.c: Replace varialbe name for readability
s/Replace/replace/
s/varialbe/variable/
> The run_gpg_verify function has two variables size, and len. This may
> come off as confusing when reading the code. We clarify which one
> pertains to the length of t
On Mon, Apr 4, 2016 at 6:22 PM, wrote:
> t/t7030-verify-tag.sh: Adds validation for multiple tags
Rewrite:
t7030: test verify-tag with multiple tags
The leading "t/" and the trailing "-*.sh" were dropped since they add no value.
> The verify-tag command supports mutliple tag names as an a
On Mon, Apr 4, 2016 at 8:58 PM, Junio C Hamano wrote:
> The test prepares a simple commit with HT on its log message lines,
> and makes sure that
>
> - formats that should or should not expand tabs by default do or do
>not expand tabs respectively,
>
> - with explicit --expand-tabs= and shor
So here is the fifth and hopefully the final try. Previous round
are at $gmane/289694, $gmane/289166, $gmane/288987 and
$gmane/290222.
This round is different from v4 in the following ways.
* wording changes, grammo- and typo-fixes in the documentation
(thanks to Eric Sunshine and Jeff King)
The test prepares a simple commit with HT on its log message lines,
and makes sure that
- formats that should or should not expand tabs by default do or do
not expand tabs respectively,
- with explicit --expand-tabs= and short-hands --expand-tabs
(equivalent to --expand-tabs=8) and --no-e
When the local convention of the project is to use tab width that is
not 8, it may make sense to allow "git log --expand-tabs=" to
tweak the output to match it.
Signed-off-by: Junio C Hamano
---
Documentation/pretty-options.txt | 9 ++---
commit.h | 2 +-
pretty.c
"git log --pretty={medium,full,fuller}" and "git log" by default
prepend 4 spaces to the log message, so it makes sense to enable
the new "expand-tabs" facility by default for these formats.
Add --no-expand-tabs option to override the new default.
The change alone breaks a test in t4201 that runs
From: Linus Torvalds
A commit log message sometimes tries to line things up using tabs,
assuming fixed-width font with the standard 8-place tab settings.
Viewing such a commit however does not work well in "git log", as
we indent the lines by prefixing 4 spaces in front of them.
This should all
惠轶群 wrote:
> 2016-03-28 6:00 GMT+08:00 Eric Wong :
> > While Gmail provides SMTP access, it was (last I was told)
> > incompatible with two-factor auth; so I've encountered users
> > unable to send patches with their normal 2FA-enabled accounts.
>
> That's the origin of this idea of `mailto`.
>
On Sun, Apr 3, 2016 at 8:58 PM, Eric Sunshine wrote:
> The fact that the 32 new tests are nearly identical suggests strongly
> that the testing should instead either be table-driven or be done via
> for-loops to systematically cover all cases. Not only would either of
> these approaches be easier
On Mon, Apr 4, 2016 at 6:38 PM, Eric Sunshine wrote:
> On Mon, Apr 4, 2016 at 4:07 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
Given that the ifndef/endif block immediately before this part is
also about excluding -p/-u/--patch when formatting the documentation
for format-p
On Mon, Apr 4, 2016 at 4:07 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>>> Given that the ifndef/endif block immediately before this part is
>>> also about excluding -p/-u/--patch when formatting the documentation
>>> for format-patch, perhaps the attached may be a smaller equivalent?
>>
>
From: Santiago Torres
The verify_signed_buffer comand might cause a SIGPIPE signal when the
gpg child process terminates early (due to a bad keyid, for example) and
git tries to write to it afterwards. Previously, ignoring SIGPIPE was
done on the builtin/verify-tag.c command to avoid this issue.
From: Santiago Torres
The gpg_verify_tag function resolves the ref for any existing object.
However, git tag -v resolves to only tag-refs. We can provide support
for sha1 by moving the refname resolution code out of gpg_verify_tag and
allow for the object's sha1 as an argument.
Signed-off-by: Sa
This is a follow up of [1], [2], and [3]:
v4 (this):
Thanks Eric, Peff, and Hannes for the feedback.
* I relocated the sigchain_push call so it comes after the error on
gpg-interface (thanks Hannnes for catching this).
* I updated the unit test to match the discussion on [3]. Now it generat
From: Santiago Torres
Instead of running the verify-tag plumbing command, we use the
pgp_verify_tag(). This avoids the usage of an extra fork call. To do
this, we extend the number of parameters that tag.c takes, and
verify-tag passes. Redundant calls done in the pgp_verify_tag function
are remov
From: Santiago Torres
The verify-tag command supports mutliple tag names as an argument.
However, no previous tests try to verify multiple tags at once. This
test runs the verify-tag command against three tags separately and then
compares the result against the invocation with the same three tags
From: Santiago Torres
The PGP verification routine for tags could be accessed by other
commands that require it. We do this by moving it to the common tag.c
code. We rename the verify_tag() function to gpg_verify_tag() to avoid
conflicts with the mktag.c function.
Signed-off-by: Santiago Torres
From: Santiago Torres
The run_gpg_verify function has two variables size, and len. This may
come off as confusing when reading the code. We clarify which one
pertains to the length of the tag headers by renaming len to
payload_length.
Signed-off-by: Santiago Torres
---
Note: this used t
elena petrashen wrote:
> On Thu, Mar 31, 2016 at 6:31 PM, Remi Galan Alfonso
> wrote:
> > Elena Petrashen wrote:
> >> +void delete_branch_advice(const char *name, const char *ref)
> >> +{
> >> +const char fmt[] =
> >> +"\nNote: to restore the deleted branch:\n\ngit branch %s %s\n
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The tip of 'next' has been rewound
Hi Junio,
On Mon, 4 Apr 2016, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > Although I am convinced that the change is not necessary for
> > correctness, I can buy the justification that we should produce forward
> > slashes for consistency. There are a number of occasions where we
> > pr
> On 15 Mar 2016, at 06:45, Torsten Bögershausen wrote:
>
> >I created a test case but git diff exits with 0 if it does not recognize the
> >file >path so the test case always succeeds. Can you give me a hint or one
> >>example test case?
>
> The most clean (?) is to compare "git diff" NFC an
File paths containing decomposed unicode chars passed to diff
command are not converted to precomposed unicode form.
As a result, no diff is displayed when feeding such a file path to the
diff command.
Opposite to most builtin commands, the diff builtin is missing the
parse_options call, which in
I found an issue where file paths containing decomposed unicode chars
are not converted to precomposed unicode form when passed to the diff
command family.
As a result, no diff is displayed.
With the help of Torsten Bögershausen and Junio C Hamano I came up
with the following patch to fix the is
On Thu, Mar 31, 2016 at 6:31 PM, Remi Galan Alfonso
wrote:
> Elena Petrashen wrote:
>> +void delete_branch_advice(const char *name, const char *ref)
>> +{
>> +const char fmt[] =
>> +"\nNote: to restore the deleted branch:\n\ngit branch %s %s\n";
>
> Shouldn't that be marked for tr
Hi Lars,
thank you so much for reaching out to me! and thank you for your
suggestions too, I'm changing my application to reflect those. It does
really make sense to start the discussion earlier then I scheduled,
and add some extra ideas that could be completed after the
whitelist/blacklist. Proba
On Mon, Apr 04, 2016 at 02:24:48PM -0400, Santiago Torres wrote:
> > I think it can be part of this series, but doesn't have to be. As I
> > understand it, the current code is just handing the name to the `git
> > verify-tag` process, so if we continue to do so, that would be OK.
>
> IIRC, the cu
Eric Sunshine writes:
>> Given that the ifndef/endif block immediately before this part is
>> also about excluding -p/-u/--patch when formatting the documentation
>> for format-patch, perhaps the attached may be a smaller equivalent?
>
> Perhaps. I kept self-contained to make it easier to add new
On Mon, Apr 4, 2016 at 3:32 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> @@ -28,10 +28,12 @@ ifdef::git-diff[]
>> endif::git-diff[]
>> endif::git-format-patch[]
>>
>> +ifndef::git-format-patch[]
>> -s::
>>
Eric Sunshine writes:
> Documentation/diff-options.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 306b7e3..6eb591f 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -28,
Eric Sunshine writes:
> Although I'm the one who brought up the idea of "automating" these
> tests, I'm not convinced that it's an improvement in this case, but I
> don't feel so strongly that I'd forbid it.
Another option is to define helper functions to shorten the "manual"
tests, e.g. define:
On Mon, Apr 04, 2016 at 09:38:54AM -0400, Jeff King wrote:
> On Mon, Apr 04, 2016 at 12:12:04AM -0400, Santiago Torres wrote:
>
> > > As a side note, it might actually be an improvement for pgp_verify_tag
> > > to take a sha1 (so that git-tag is sure that it is verifying the same
> > > object that
Mehul Jain writes:
> On Mon, Apr 4, 2016 at 10:22 PM, Matthieu Moy
> wrote:
>> I think it would be much simpler to drop the loop, and write instead
>> something like (untested):
>
> I tested it (with few minor changes), and worked fine.
>
> test_autostash () {
> OLDIFS=$IFS
> IFS
On za, 2016-04-02 at 20:41 -0700, Junio C Hamano wrote:
> I think by now it is very clear that nobody active in the Git
> development community tests RPM binaries built with git.spec.in we
> have in our tree. I suspect RPM based distros are using their own
> RPM build recipe without paying any atte
Sebastian Schuberth writes:
>>> -It is also permitted for a notes ref to point directly to a tree
>>> -object, in which case the history of the notes can be read with
>>> +It is also permitted for a notes ref to point to any other object in
>>> +the object store besides commit objects, that is an
Ivan Pozdeev writes:
> ---
> compat/poll/poll.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
As Eric pointed out, please sign-off your patch.
> diff --git a/compat/poll/poll.c b/compat/poll/poll.c
> index db4e03e..5eb0280 100644
> --- a/compat/poll/poll.c
> +++ b/compat/poll/poll.
Saxon Knight writes:
> I recently did a git stash save "working on main", and in the
> feedback, I noticed that "On" was capitalized ("...state On
> master...").
> I don't think this is intentional, so I figured I'd try to let someone know.
>
> Here is the output (quotes included by me):
>
> "Sav
On Mon, Apr 4, 2016 at 1:36 PM, Mehul Jain wrote:
> On Mon, Apr 4, 2016 at 10:22 PM, Matthieu Moy
> wrote:
>> I think it would be much simpler to drop the loop, and write instead
>> something like (untested):
>
> I tested it (with few minor changes), and worked fine.
>
> test_autostash () {
>
Eric Engestrom writes:
> I went by word-count: "through" was way more common than "thru", so
> I kept the fix.
That is not a "fix" (as it is not touching "mistakes") but "making
them consistent". I do not personally feel strongly against such a
change, but please leave them out of "Subject: [PA
On Mon, Apr 4, 2016 at 10:22 PM, Matthieu Moy
wrote:
> I think it would be much simpler to drop the loop, and write instead
> something like (untested):
I tested it (with few minor changes), and worked fine.
test_autostash () {
OLDIFS=$IFS
IFS='='
set -- $*
IFS=$O
Jeff King writes:
> Imagine a merge where one side changes the content of a path and the
> other changes the mode. Here's a minimal reproduction:
>
> git init repo && cd repo &&
>
> echo base >file &&
> git add file &&
> git commit -m base &&
>
> echo changed >file &&
> git commit -am
On Mon, Apr 4, 2016 at 9:46 AM, Sebastian Schuberth
wrote:
> On Fri, Apr 1, 2016 at 2:16 PM, Johan Herland wrote:
>>> 3) Recursively list all blobs / trees (git-ls-tree) and look whether an
>>> object's hash is conatined in our table to get its notes.
>>>
>>> In particular 3) could be expensive f
Ping?
On Sun, Mar 27, 2016 at 5:26 PM, Eric Sunshine wrote:
> git-format-patch recognizes -s as shorthand only for --signoff, however,
> its documentation shows -s as shorthand for both --signoff and
> --no-patch. Resolve this confusion by suppressing the bogus -s shorthand
> for --no-patch.
>
>
On Mon, Apr 4, 2016 at 8:45 AM, Pranit Bauva wrote:
> Okay I will do the change. I was previously unaware about the use of
> '\' before EOF. I googled it now. But I am still confused about its
> use in this scenario. Upto what I understood, it is used where you
> want to expand a variable, substit
Signed-off-by: Ivan Pozdeev
---
compat/poll/poll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index db4e03e..5eb0280 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -441,7 +441,7 @@ poll (struct pollfd *pfd, nfds_t nfd
On Mon, Apr 4, 2016 at 10:30 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Mehul Jain writes:
>>
>>> -test_rebase_autostash () {
>>> +test_pull_autostash () {
>>> git reset --hard before-rebase &&
>>> echo dirty >new_file &&
>>> git add new_file &&
>>> -git pull --reba
Matthieu Moy writes:
> Mehul Jain writes:
>
>> -test_rebase_autostash () {
>> +test_pull_autostash () {
>> git reset --hard before-rebase &&
>> echo dirty >new_file &&
>> git add new_file &&
>> -git pull --rebase --autostash . copy &&
>> +git pull $@ . copy &&
>
> Not stri
On Mon, Apr 4, 2016 at 1:01 PM, Matthieu Moy
wrote:
> Mehul Jain writes:
>
>> -test_rebase_autostash () {
>> +test_pull_autostash () {
>> git reset --hard before-rebase &&
>> echo dirty >new_file &&
>> git add new_file &&
>> - git pull --rebase --autostash . copy &&
>> +
Mehul Jain writes:
> On Mon, Apr 4, 2016 at 12:58 AM, Eric Sunshine
> wrote:
>> On Fri, Apr 1, 2016 at 6:27 AM, Mehul Jain wrote:
>>> In test_autostash() there's a line
>>>
>>> echo test_cmp_rev HEAD^ copy &&
>>>
>>> Originally it should have been
>>>
>>> test_cmp_rev HEAD^ copy &&
>>>
Elia Pinto writes:
>> My impression is that using GIT_TRACE_* is the more mainstream
>> trend, and it may be beneficial to work any new debugging aid like
>> this one to fit within that mechanism.
>
> I thought about it, and I agree with you. The idea could be
>
> - Call the variable GIT_TRACE_CU
On Mon, Apr 4, 2016 at 12:58 AM, Eric Sunshine wrote:
> On Fri, Apr 1, 2016 at 6:27 AM, Mehul Jain wrote:
>> In test_autostash() there's a line
>>
>> echo test_cmp_rev HEAD^ copy &&
>>
>> Originally it should have been
>>
>> test_cmp_rev HEAD^ copy &&
>>
>> but this raise following error
Sebastian Schuberth writes:
> Done, I'll send a patch shortly. But I wanted to list the supported
> object types explicitly, in particular as many guide in the net are
> unclear that only annotated tags are object, and lightweight ones are
> not.
I'd really hate to see an explicit list of what o
Matthieu Moy writes:
> I'm not sure how important it is in this case, but it was in the case of
> setup_unpack_trees_porcelain which I took inspiration from when we
> discussed this (actually, in setup_unpack_trees_porcelain, there's isn't
> any translation even in porcelain).
OK, so paraphrase:
2016-04-01 17:35 GMT+02:00 Junio C Hamano :
> Elia Pinto writes:
>
>> Implements the GIT_CURL_DEBUG environment variable to allow a greater
>> degree of detail of GIT_CURL_VERBOSE, in particular the complete
>> transport header and all the data payload exchanged.
>> It might be useful if a particu
Johannes Sixt writes:
> Although I am convinced that the change is not necessary for
> correctness, I can buy the justification that we should produce forward
> slashes for consistency. There are a number of occasions where we
> present paths to the user, and we do show forward-slashes in all cas
On Sun, Apr 03, 2016 at 09:38:34PM -0400, Eric Sunshine wrote:
> I think Peff meant that a simple grep would suffice; no need for
> test_i18ngrep. In other words (reproducing Peff's example), something
> like this:
>
> tags="fourth-signed sixth-signed seventh-signed" &&
> for i in $tags;
On Mon, Apr 04, 2016 at 12:12:04AM -0400, Santiago Torres wrote:
> > As a side note, it might actually be an improvement for pgp_verify_tag
> > to take a sha1 (so that git-tag is sure that it is verifying the same
> > object that it is printing), but that refactoring should probably come
> > separ
2016-04-01 16:56 GMT+02:00 Ramsay Jones :
>
>
> On 01/04/16 11:44, Elia Pinto wrote:
>> Implements the GIT_CURL_DEBUG environment variable to allow a greater
>> degree of detail of GIT_CURL_VERBOSE, in particular the complete
>> transport header and all the data payload exchanged.
>> It might be us
On Mon, Apr 4, 2016 at 2:30 AM, Eric Sunshine wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva wrote:
>> Signed-off-by: Pranit Bauva
>> ---
>> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
>> @@ -7,7 +7,7 @@ test_description='our own option parser'
>>
>> . ./test-lib.sh
2016-04-01 17:03 GMT+02:00 Ramsay Jones :
>
>
> On 01/04/16 11:44, Elia Pinto wrote:
>> Implements the GIT_CURL_DEBUG environment variable to allow a greater
>> degree of detail of GIT_CURL_VERBOSE, in particular the complete
>> transport header and all the data payload exchanged.
>> It might be us
Explicitly name the supported object types, and ensure patches cannot be
misinterpreted as non-objects that can have notes attached.
Signed-off-by: Sebastian Schuberth
---
Documentation/git-notes.txt | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-n
On Fri, Apr 1, 2016 at 6:47 PM, Junio C Hamano wrote:
> DESCRIPTION
> ---
> Adds, removes, or reads notes attached to objects, without touching
> the objects themselves.
>
> This says "notes attached to objects" and "the objects themselves".
> They do not limit the target
Dear Git users,
It is my pleasure to announce that Git for Windows 2.8.1 is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.8.0 (March 29th 2016)
New Features
??? Comes with Git v2.8.1.
??? The Git for Windows project updated its contributor guid
On Fri, Apr 1, 2016 at 5:31 PM, Junio C Hamano wrote:
> Sebastian Schuberth writes:
>
>> Signed-off-by: Sebastian Schuberth
>> ---
>> Documentation/git-notes.txt | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/git-notes.txt b/Documentation/git-not
Karthik Nayak writes:
> cc'ing Matthieu since this patch was initially written by him.
>
> On Thu, Mar 31, 2016 at 3:28 AM, Junio C Hamano wrote:
>> Karthik Nayak writes:
>>
>>> +static struct ref_msg {
>>> + const char *gone;
>>> + const char *ahead;
>>> + const char *behind;
>>> +
On Fri, Apr 1, 2016 at 2:16 PM, Johan Herland wrote:
>> 3) Recursively list all blobs / trees (git-ls-tree) and look whether an
>> object's hash is conatined in our table to get its notes.
>>
>> In particular 3) could be expensive for repos with a lot of files as we're
>> looking at all of them j
Mehul Jain writes:
> -test_rebase_autostash () {
> +test_pull_autostash () {
> git reset --hard before-rebase &&
> echo dirty >new_file &&
> git add new_file &&
> - git pull --rebase --autostash . copy &&
> + git pull $@ . copy &&
Not strictly needed here, but I'd write
86 matches
Mail list logo