Hello,
A new release is available fixing a few bugs and improving TTY management.
What is Tig?
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a Git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for
Jonathan Nieder writes:
>> Regarding finding a better name, I would want to hear from others,
>> I am happy with --find-object, though I can see --pickaxe-object
>> or --object--filter to be a good narrative as well.
>
> Drat, I was hoping for an opinion.
I think it would make it a better compan
On 14/12/2017 23:27, Igor Djordjevic wrote:
>
> As you basically have a flow where two users (you and cron job) can
> edit same files at the same time, desired outcome might be a bit
> ambiguous, especially when scheduled execution of those files is
> added to the mix.
This said, and without h
On Thu, Dec 14, 2017 at 12:10 AM, Lars Schneider
wrote:
>
>> On 12 Dec 2017, at 19:43, SZEDER Gábor wrote:
>>
>> On Tue, Dec 12, 2017 at 7:00 PM, Lars Schneider
>> wrote:
>>>
On 12 Dec 2017, at 00:34, SZEDER Gábor wrote:
While the build logic was embedded in our '.travis.yml', Tr
Hi Brian,
Bennett, Brian wrote:
> Thank you for your fast response,
>
> I haven't done a build of this type before (so I could
> test the patch first) so I'm trying to do that and get
> this far:
...
> I don't want to drag out testing the patch, so if either
> of you are able to quickly guide me
In particular when local tags are used (or tags that are pushed to some
fork) to build Git, it is very hard to figure out from which particular
revision a particular Git executable was built. It gets worse when those
tags are deleted, or even updated.
Let's just report an exact, unabbreviated comm
From: Eric Sunshine
It can be helpful for bug reports to include information about the
environment in which the bug occurs. "git version --build-options" can
help to supplement this information. In addition to the size of 'long'
already reported by --build-options, also report the host's CPU type
In Git for Windows, we ask users to paste the output of said command
into their bug reports, with the idea that this frequently helps
identify where the problems are coming from.
There are some obvious missing bits of information in said output,
though, and this patch series tries to fill the gaps
Hi Junio,
On Fri, 8 Dec 2017, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> >> We need to be careful, though, to report when the current commit cannot be
> >> determined, e.g. when building from a tarball without any associated Git
> >> repository.
> >
> > This means that on Debian, it wo
Hi Jonathan,
On Fri, 8 Dec 2017, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
>
> > In particular when local tags are used (or tags that are pushed to some
> > fork) to build Git, it is very hard to figure out from which particular
> > revision a particular Git executable was built.
>
>
Lars Schneider writes:
> That way you could control the encoding for a text file specific
> for each path similar to the "mode bits". That also means you could
> change the encoding of a file while the blob content stays the same.
That is exactly why I said that I doubt it makes sense.
When you
Hi,
Stefan Beller wrote:
> On Thu, Dec 14, 2017 at 1:22 PM, Jonathan Nieder wrote:
>> - what about mode changes? If the file became executable but the
>> blob content didn't change, does that commit match?
>
> ./git log --find-object=$(git rev-parse ba67504f:t/perf/p3400-rebase.sh)
>
> claims
Jonathan Nieder writes:
> Putting it in context, we have:
>
> pickaxe options:
> -S: detect changes in occurence count of a string
> -G: grep lines in diff for a string
>
> --pickaxe-all:
> do not filter the diff when the patch matches pickaxe
>
On Thu, Dec 14, 2017 at 1:22 PM, Jonathan Nieder wrote:
> - what about mode changes? If the file became executable but the
> blob content didn't change, does that commit match?
./git log --find-object=$(git rev-parse ba67504f:t/perf/p3400-rebase.sh)
claims it does find the mode change (commi
Hi Josef,
I`m not a Git expert, and I know less of Subversion, but following
your explanation, I might try to help, at least until more
experienced people join.
On 14/12/2017 14:09, Josef Wolf wrote:
>
> Every machine has a working copy of the repository in a specific
> directory. A cron job
Jonathan Tan writes:
> Move the definition of the transport-specific functions provided by
> transports, whether declared in transport.c or transport-helper.c, into
> an internal header. This means that transport-using code (as opposed to
> transport-declaring code) can no longer access these fun
Jonathan Tan writes:
> Prior to commit a2d725b7bdf7 ("Use an external program to implement
> fetching with curl", 2009-08-05), if Git was compiled with NO_CURL, the
> get_refs_list and fetch methods in struct transport might not be
> populated, hence the checks in clone and fetch. After that comm
We working with the (enormous) Windows repo, we observed
a performance problem in the ahead-behind computation and
were considering a few options.
We had a local repo with a local branch that was 150K
commits behind the upstream branch[*]. There was a ~20
second different in the run times for t
Note that this is built on jt/transport-no-more-rsync.
I have found the transport mechanism relatively complicated, so here is
some more effort in the hope of making it more readily understood.
Patch 1 is probably good to go in as-is.
Patch 2 is a modification of the transport API by making cert
Move the definition of the transport-specific functions provided by
transports, whether declared in transport.c or transport-helper.c, into
an internal header. This means that transport-using code (as opposed to
transport-declaring code) can no longer access these functions (without
importing the i
Prior to commit a2d725b7bdf7 ("Use an external program to implement
fetching with curl", 2009-08-05), if Git was compiled with NO_CURL, the
get_refs_list and fetch methods in struct transport might not be
populated, hence the checks in clone and fetch. After that commit, all
transports populate get
On Thu, Dec 14, 2017 at 10:19 PM, Jeff Hostetler wrote:
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -714,9 +714,9 @@ ifdef::git-rev-list[]
> +
> The form '--filter=blob:none' omits all blobs.
> +
> -The form '--filter=blob:limit=[kmg]' omits blobs
On Thu, Dec 14, 2017 at 1:16 PM, David A. Wheeler wrote:
> "David A. Wheeler" writes:
>> > Why is "index" better? It is a confusing name, one that has many
>> > other unrelated meanings. In particular, many projects managed by
>> > git also have an index, but few have a staging area.
>
> On Thu,
Junio C Hamano wrote:
> Jonathan Nieder writes:
>>> * sb/diff-blobfind (2017-12-12) 1 commit
>>> (merged to 'next' on 2017-12-13 at 9a27a20c5f)
>>> + diffcore: add a filter to find a specific blob
>>>
>>> "git diff" family of commands learned --blobfind= that
>>> allows you to limit the outp
Hi,
Stefan Beller wrote:
> Junio hinted at a different approach of solving this problem, which this
> patch implements. Teach the diff machinery another flag for restricting
> the information to what is shown. For example:
>
> $ ./git log --oneline --find-object=v2.0.0:Makefile
> b2feb64309 R
From: Jeff Hostetler
Here is V7 of the list-object filtering, rev-list, and pack-objects.
This is an incremental patch series to be applied on top of the V6
incremental patch which is already in 'next'.
This version fixes some formatting of the help text as suggested
by Christian.
Jeff Hostetl
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
Documentation/rev-list-options.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 8d8b7f4..b7237b9 100644
--- a/Documentation/rev-li
From: Jeff Hostetler
Design document for partial clone feature.
Signed-off-by: Jeff Hostetler
---
Documentation/technical/partial-clone.txt | 324 ++
1 file changed, 324 insertions(+)
create mode 100644 Documentation/technical/partial-clone.txt
diff --git a/Docume
From: Jeff Hostetler
This patch contains V3 os the partial clone design document.
It incorporates feedback from Philip that I missed before
sending V2 and today's comments from Junio.
Jeff Hostetler (1):
partial-clone: design doc
Documentation/technical/partial-clone.txt | 324 ++
From: Kaartic Sivaraam
Date: Mon, 27 Nov 2017 22:51:03 +0530
Signed-off-by: Kaartic Sivaraam
Signed-off-by: Junio C Hamano
---
git-rebase.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 5526b17a36..e5adb596a0 100755
--- a/git-rebas
From: Kaartic Sivaraam
Date: Mon, 27 Nov 2017 22:51:04 +0530
Attempting to rebase when the HEAD is detached and is already
up to date with upstream (so there's nothing to do), the
following message is shown
Current branch HEAD is up to date.
which is clearly wrong as HEAD is not a branc
Junio C Hamano writes:
> I think you only sent 3/3 in newer rounds, which made it not to
> apply to my tree. If you meant to drop changes in 1/3 and 2/3,
> perhaps because they were needless churn, then 3/3 needs to be
> updated not to depend on the changes these two made.
Here is what I recons
> On December 14, 2017 8:10 AM, Josef Wolf wrote:
> Subject: Need help migrating workflow from svn to git.
>
> Hello folks,
>
> I am wondering whether/how my mode of work for a specific project
> (currently based on SVN) could be transferred to git.
>
> I have a repository for maintaining config
Jonathan Nieder writes:
>> * sb/diff-blobfind (2017-12-12) 1 commit
>> (merged to 'next' on 2017-12-13 at 9a27a20c5f)
>> + diffcore: add a filter to find a specific blob
>>
>> "git diff" family of commands learned --blobfind= that
>> allows you to limit the output only to a change that invol
Hi,
Junio C Hamano wrote:
> * sb/diff-blobfind (2017-12-12) 1 commit
> (merged to 'next' on 2017-12-13 at 9a27a20c5f)
> + diffcore: add a filter to find a specific blob
>
> "git diff" family of commands learned --blobfind= that
> allows you to limit the output only to a change that involves
On 12/14/2017 1:24 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
+- On the client these incomplete packfiles are marked as "promisor pacfiles"
s/pacfiles/packfiles/
+ These "promisor packfiles" consist of a ".promisor" file with
+ arbitrary contents (like the ".keep" files), in addi
Matthieu Moy writes:
> I don't think you should talk about "Git contributors", which can be
> read as "contributors to the git.git codebase". "Git users" would make
> more sense, or perhaps you meant "contributors to Git projects". But
> actually, I don't think this kind of documentation should f
Thank you for your fast response,
I haven't done a build of this type before (so I could test the patch first) so
I'm trying to do that and get this far:
1. git clone https://github.com/msysgit/msysgit.git "c:\temp\git\guitbuild"
2. git clone https://github.com/git-for-windows/git.git
"c:\temp\g
On 12/13/2017 8:17 AM, Philip Oakley wrote:
From: "Junio C Hamano"
"Philip Oakley" writes:
+ These filtered packfiles are incomplete in the traditional sense
because
+ they may contain trees that reference blobs that the client does
not have.
Is a comment needed here noting that curren
Junio C Hamano wrote:
> Todd Zullinger writes:
>> I wanted to check if this minor patch series had slipped
>> under your radar.
>
> Totally. Queued.
>
> As they come with Ack by the area maintainer, I'll fast-track them
> down to 'master' (other topics typically cook at least for a week in
> 'n
Sorry, I didn't see this message in my inbox when I posted V2 of the
design doc. I'll address questions here and update the doc as necessary.
On 12/12/2017 6:31 PM, Philip Oakley wrote:
From: "Jeff Hostetler"
From: Jeff Hostetler
First draft of design document for partial clone feature.
On Thu, Dec 14 2017, Junio C. Hamano jotted:
> Stefan Beller writes:
>
>> Anyway I think spending list band width on good documentation is
>> not bandwidth wasted.
>
> I agree with that. I do not consider the proposed change "good".
The case you're talking about upthread is something which we
"David A. Wheeler" writes:
> On December 14, 2017 1:50:00 PM EST, Junio C Hamano wrote:
>>I agree with that. I do not consider the proposed change "good".
>
> Why is "index" better? It is a confusing name, one that has many
> other unrelated meanings. In particular, many projects managed by
>
On December 14, 2017 1:50:00 PM EST, Junio C Hamano wrote:
>I agree with that. I do not consider the proposed change "good".
Why is "index" better? It is a confusing name, one that has many other
unrelated meanings. In particular, many projects managed by git also have an
index, but few have
Stefan Beller writes:
> Anyway I think spending list band width on good documentation is
> not bandwidth wasted.
I agree with that. I do not consider the proposed change "good".
Thanks.
Todd Zullinger writes:
> I wanted to check if this minor patch series had slipped
> under your radar.
Totally. Queued.
As they come with Ack by the area maintainer, I'll fast-track them
down to 'master' (other topics typically cook at least for a week in
'next').
Thanks for pinging.
Jeff Hostetler writes:
> + There are various filters available to accomodate different situations.
s/accomodate/accommodate/
I'll squash in this and /pacfile/packfile/ typofix while queuing.
Thanks.
Jeff Hostetler writes:
> +- On the client these incomplete packfiles are marked as "promisor pacfiles"
s/pacfiles/packfiles/
> + These "promisor packfiles" consist of a ".promisor" file with
> + arbitrary contents (like the ".keep" files), in addition to
> + their ".pack" and ".idx" files.
>
On Thu, Dec 14, 2017 at 10:08 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Wed, Dec 13, 2017 at 6:46 AM, David A. Wheeler
>> wrote:
>>> On December 13, 2017 12:40:12 AM EST, Jacob Keller
>>> wrote:
I know we've used various terms for this concept across a lot of the
Hi Junio,
I wanted to check if this minor patch series had slipped
under your radar. If it's waiting patiently in your queue
for other topics to advance, that's fine, of course. :)
Finished patches: <20171201155653.29553-1-...@pobox.com> and
<20171201155653.29553-2-...@pobox.com>.
Thanks,
--
On Thu, Dec 14, 2017 at 5:43 AM, Łukasz Stelmach wrote:
> It was <2017-12-14 czw 10:42>, when Eric Sunshine wrote:
>> No need to re-send. If you consult Junio's latest "What's cooking"[1],
>> you'll find that your patch has already graduated from his 'pu' branch
>> to 'next' and is slated to gradu
Ævar Arnfjörð Bjarmason writes:
> On Wed, Dec 13, 2017 at 6:46 AM, David A. Wheeler
> wrote:
>> On December 13, 2017 12:40:12 AM EST, Jacob Keller
>> wrote:
>>>I know we've used various terms for this concept across a lot of the
>>>documentation. However, I was under the impression that we mo
Kaartic Sivaraam writes:
> With the `--branch` option, the command takes a name and checks if
> -it can be used as a valid branch name (e.g. when creating a new
> -branch). The rule `git check-ref-format --branch $name` implements
> -may be stricter than what `git check-ref-format refs/heads/$n
On Thu, Dec 14 2017, David A. Wheeler jotted:
> On December 13, 2017 7:54:04 AM EST, "Ævar Arnfjörð Bjarmason"
> wrote:
>>After your patch the majority of the docs will still talk about
>>"index", is this part of some larger series, perhaps it would be good
>>to see it all at once...
>
> Yes, t
On December 13, 2017 7:54:04 AM EST, "Ævar Arnfjörð Bjarmason"
wrote:
>After your patch the majority of the docs will still talk about
>"index", is this part of some larger series, perhaps it would be good
>to see it all at once...
Yes, this would be part of a larger series.
I'm happy to do the
On Wed, Dec 13 2017, Junio C. Hamano jotted:
>
> * ab/simplify-perl-makefile (2017-12-11) 1 commit
> (merged to 'next' on 2017-12-13 at 1b791d2503)
> + Makefile: replace perl/Makefile.PL with simple make rules
>
> The build procedure for perl/ part has been greatly simplified by
> weaning ou
Christian Couder writes:
>> Aside from portability of 'uname -o' Eric raised, I wonder if the
>> platform information is still useful even when perf-subsection is
>> specified. With the above code, we can identify that a single
>> result is for (say) MacOS only when we are not limiting to a sing
Kaartic Sivaraam writes:
> It seems my series that fixes an error message in 'git-rebase'[1]
> (apart from a little cleanups) is missing. I guess I addressed the
> issue that was raised in 3/3 as a v3 for that patch[2]. Are any more
> changes needed?
>
> [1]: <20171127172104.5796-1-kaartic.sivar.
From: Jeff Hostetler
First draft of design document for partial clone feature.
Signed-off-by: Jeff Hostetler
---
Documentation/technical/partial-clone.txt | 259 ++
1 file changed, 259 insertions(+)
create mode 100644 Documentation/technical/partial-clone.txt
diff
From: Jeff Hostetler
This patch contains V2 of the partial clone design document.
It incorporates suggestions from the mailing list on V1 and
elaborates on a few topics.
Jeff Hostetler (1):
partial-clone: design doc
Documentation/technical/partial-clone.txt | 259
Dear Partner,
Please consider this mail serious despite the fact that you did not
expect it. Hope you are doing well. I am Mr, Nodian Omera, The Manager
of head opérations department of our bank in Burkina Faso. I
discovered a risk-free deal of US$9.9 million from my department which
was left uncl
"BENSOUSSAN--BOHM DANIEL p1507430"
wrote:
> Added a new file about triangular workflow for a clearer organization.
"for a clearer organization" is an explanation of why you are doing
things this way compared to your previous email.
But this is the commit message, and its wording shoud make sen
"PAYRE NATHAN p1508475" wrote:
> - print $c2 $_;
> }
> +
> close $c;
Nit: this added newline does not seem necessary to me. Nothing
serious, but this kind of thing tend to distract the reader when
reviewing the patch.
> + foreach my $key (keys %parsed_email) {
> +
I am Mr.Sheng Li Hung, from china I got your information while search for
a reliable person, I have a very profitable business proposition for you
and i can assure you that you will not regret been part of this mutual
beneficial transaction after completion. Kindly get back to me for more
details o
Hello folks,
I am wondering whether/how my mode of work for a specific project
(currently based on SVN) could be transferred to git.
I have a repository for maintaining configuration of hosts. This repository
contains several hundered scripts. Most of those scripts are don't depend on
each other.
It seems my series that fixes an error message in 'git-rebase'[1]
(apart from a little cleanups) is missing. I guess I addressed the
issue that was raised in 3/3 as a v3 for that patch[2]. Are any more
changes needed?
[1]: <20171127172104.5796-1-kaartic.sivar...@gmail.com>
[2]: <20171201060935.197
When the N-th previous thing checked out syntax (@{-N}) is used
with '--branch' option of check-ref-format the result may not be
the name of a branch that currently exists or ever existed. This
is because @{-N} is used to refer to the N-th last checked out
"thing", which might be a commit object na
The existing code mixes parsing of email header with regular
expression and actual code. Extract the parsing code into a new
subroutine "parse_header_line()". This improves the code readability
and make parse_header_line reusable in other place.
"parsed_header_line()" and "filter_body()" could be
Added a new file about triangular workflow for a clearer organization.
With a more precise documentation, any new Git contributors
will spend less time on understanding this doc and the way Git works.
Based-on-patch-by: Jordan DE GEA
Signed-off-by: Michael Haggerty
Signed-off-by: Jordan DE GEA
It was <2017-12-14 czw 10:42>, when Eric Sunshine wrote:
> On Thu, Dec 14, 2017 at 4:32 AM, Łukasz Stelmach
> wrote:
>> Convert author's name and e-mail address from the UTF-8 (or any other)
>> encoding in load_last_commit function the same way commit message is
>> converted.
>>
>> Amending commi
2017-12-11 22:12 GMT+01:00 Matthieu Moy :
> "PAYRE NATHAN p1508475" wrote:
>> + my %parsed_email;
>> + $parsed_email{'body'} = '';
>> + while (my $line = <$c>) {
>> + next if $line =~ m/^GIT:/;
>> + parse_header_line($line, \%parsed_email);
>> + if
On Thu, Dec 14, 2017 at 4:32 AM, Łukasz Stelmach wrote:
> Convert author's name and e-mail address from the UTF-8 (or any other)
> encoding in load_last_commit function the same way commit message is
> converted.
>
> Amending commits in git-gui without such conversion breaks UTF-8
> strings. For e
Convert author's name and e-mail address from the UTF-8 (or any other)
encoding in load_last_commit function the same way commit message is
converted.
Amending commits in git-gui without such conversion breaks UTF-8
strings. For example, "\305\201ukasz" (as written by git cat-file) becomes
"\303\2
On Wed, Dec 13, 2017 at 9:54 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> If you want to be able to use this helper to specify a default value
>> of an empty string (which the orignal that used $4 did), then the
>> previous hunk must be corrected so that it does not unconditionally
>>
On Wed, Dec 13, 2017 at 9:40 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> Signed-off-by: Christian Couder
>> ---
>> t/perf/run | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/t/perf/run b/t/perf/run
>> index 43e4de49ef..bbd703dc4f 100755
>> --- a/t/p
On Wed, Dec 13, 2017 at 9:33 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> my $resultsdir = "test-results";
>> +my $results_section = "";
>> if (exists $ENV{GIT_PERF_SUBSECTION} and $ENV{GIT_PERF_SUBSECTION} ne "") {
>> $resultsdir .= "/" . $ENV{GIT_PERF_SUBSECTION};
>> +
On Wed, Dec 13, 2017 at 7:25 PM, Eric Sunshine wrote:
> On Wed, Dec 13, 2017 at 10:13 AM, Christian Couder
> wrote:
>> Codespeed (https://github.com/tobami/codespeed/) is an open source
>> project that can be used to track how some software performs over
>> time. It stores performance test result
78 matches
Mail list logo
