On 25 August 2016 at 07:56, Karthik Nayak wrote:
>
> I'm thinking more on the lines of `%(upstream)` being an atom and the
> `:track` being an option under that atom. I like sub-atom though ;)
>
On second thought maybe "quark" is better :P
> On Thu, Aug 25, 2016 at 12:03 AM, Jeff King wrote:
>>
Dear Git Developers,
First of all, thanks for this great project, it has made my life a lot easier
as a developer!
I'm writing this email to suggest some improvements to git submodules. In my
eyes how git handles submodules could be improved to be more intuitive to a
novice and require less manua
On Wed, Aug 24, 2016 at 11:35 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> It's not wonderful, but it's in line with how git-checkout stops caring
>> about ambiguity after the first argument can be resolved as a ref
>> (there's even a test for it, t2010.6).
>
> But that is justi
W dniu 20.08.2016 o 23:29, Eric Wong pisze:
> Jakub Narębski wrote:
>> Other version control systems
>>
>> 20. What other version control systems (SCM) do you use beside Git?
>>(multiple choice, with other)
>>
>> Explanation: "using" version control system here means using
>> it to active
From: Lars Schneider
Generate more interesting large test files with pseudo random characters
in between and reuse these test files in multiple tests. Run tests
formerly marked as EXPENSIVE every time but with a smaller data set.
Signed-off-by: Lars Schneider
---
t/t0021-conversion.sh | 48 +++
From: Lars Schneider
packet_write() should be called packet_write_fmt() as the string
parameter can be formatted.
Suggested-by: Junio C Hamano
Signed-off-by: Lars Schneider
---
builtin/archive.c| 4 ++--
builtin/receive-pack.c | 4 ++--
builtin/remote-ext.c | 4 ++--
builtin/
From: Lars Schneider
packet_write_fmt() would die in case of a write error even though for
some callers an error would be acceptable. Add packet_write_fmt_gently()
which writes a formatted pkt-line and returns `0` for success and `-1`
for an error.
Signed-off-by: Lars Schneider
---
pkt-line.c
From: Lars Schneider
packet_write_stream_with_flush_from_fd() and
packet_write_stream_with_flush_from_buf() write a stream of packets. All
content packets use the maximal packet size except for the last one.
After the last content packet a `flush` control packet is written.
packet_read_till_flus
From: Lars Schneider
apply_filter() returns a boolean that tells the caller if it
"did convert or did not convert". The variable `ret` was used throughout
the function to track errors whereas `1` denoted success and `0`
failure. This is unusual for the Git source where `0` denotes success.
Renam
From: Lars Schneider
Git's clean/smudge mechanism invokes an external filter process for
every single blob that is affected by a filter. If Git filters a lot of
blobs then the startup time of the external filter processes can become
a significant part of the overall Git execution time.
In a prel
From: Lars Schneider
Consider the case of a file that requires filtering and is present in
branch A but not in branch B. If A is the current HEAD and we checkout B
then the following happens:
1. ce_compare_data() opens the file
2. index_fd() detects that the file requires to run a clean filter
From: Lars Schneider
set_packet_header() converts an integer to a 4 byte hex string. Make
this function locally available so that other pkt-line functions can
use it.
Signed-off-by: Lars Schneider
---
pkt-line.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff -
From: Lars Schneider
packet_write_fmt() has two shortcomings. First, it uses format_packet()
which lets the caller only send string data via "%s". That means it
cannot be used for arbitrary data that may contain NULs. Second, it will
always die on error.
Add packet_write_gently() which writes ar
Hi Dakota,
On Wed, 24 Aug 2016, Dakota Hawkins wrote:
> On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin
> wrote:
> >
> > On Tue, 23 Aug 2016, Dakota Hawkins wrote:
> >
> >> I use GFW almost exclusively, but I pretty much always consult the
> >> upstream documentation anyway (because I find
Hi Junio,
On Wed, 24 Aug 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> In any case, in the ideal future, I would imagine that we would want
> >> to have "cat-file blob" to enable "--filters" by default; that would
> >> make cat-file and hash-objects a pair of symmetric operat
From: Lars Schneider
The goal of this series is to avoid launching a new clean/smudge filter
process for each file that is filtered.
A short summary about v1 to v5 can be found here:
https://git.github.io/rev_news/2016/08/17/edition-18/
This series is also published on web:
https://github.com/l
From: Lars Schneider
Use `test_config` to set the config, check that files are empty with
`test_must_be_empty`, compare files with `test_cmp`, and remove spaces
after ">" and "<".
Signed-off-by: Lars Schneider
---
t/t0021-conversion.sh | 62 +--
From: Lars Schneider
Git filter driver commands with spaces (e.g. `filter.sh foo`) are hard to
read in error messages. Quote them to improve the readability.
Signed-off-by: Lars Schneider
---
convert.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/convert.c b
I was not talking about the cost of correcting mistakes. Running --filters
is potentially very costly. Just so you understand what I am talking
about: I have a report that says that checking out a sizeable worktree
with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
is horr
From: Lars Schneider
packet_flush() would die in case of a write error even though for some
callers an error would be acceptable. Add packet_flush_gently() which
writes a pkt-line flush packet and returns `0` for success and `-1` for
failure.
Signed-off-by: Lars Schneider
---
pkt-line.c | 6 ++
Hi Eric,
On Mon, 22 Aug 2016, Eric Wong wrote:
> Johannes Schindelin wrote:
>
> > I just want developers who are already familiar with Git, and come up with
> > an improvement to Git itself, to be able to contribute it without having
> > to pull out their hair in despair.
>
> We want the same t
Hi Arif,
On Thu, 25 Aug 2016, Arif Khokar wrote:
> On 08/24/2016 09:04 AM, Johannes Schindelin wrote:
> >
> > On Mon, 22 Aug 2016, Philip Oakley wrote:
>
> >> I do note that dscho's patches now have the extra footer (below the
> >> three dashes) e.g.
> >>
> >> Published-As: https://github.com/ds
Hi Eric,
On Wed, 24 Aug 2016, Eric Wong wrote:
> Johannes Schindelin wrote:
>
> > Now, with somebody like me who would lose a lot when destroying trust,
> > it is highly unlikely. But it is possible that in between the hundreds
> > of sincere contributors a bad apple tries to sneak in bad stuff
I think I understand this from the git-push man page, but I want to make
sure:
I have two branches, master and develop.
If I am (accidentally) sitting on master, and issue 'git push origin
develop', does this properly push develop to remote develop, or does it
push master to remote develop (w
I think I understand this from the git-push man page, but I want to make
sure:
I have two branches, master and develop.
If I am (accidentally) sitting on master, and issue 'git push origin
develop', does this properly push develop to remote develop, or does it
push master to remote develop (w
Hi Kuba,
On Mon, 22 Aug 2016, Jakub Narębski wrote:
> W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze:
>
> > So unfortunately this thread has devolved. Which is sad. Because all I
> > wanted is to have a change in Git's submission process that would not
> > exclude *so many* developers. Tha
Hi Torsten,
On Thu, 25 Aug 2016, Torsten Bögershausen wrote:
> > I was not talking about the cost of correcting mistakes. Running --filters
> > is potentially very costly. Just so you understand what I am talking
> > about: I have a report that says that checking out a sizeable worktree
> > with
Dear Git users,
It is my pleasure to announce that Git for Windows 2.9.3(2) is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.9.3 (August 13th 2016)
New Features
• Comes with Git Credential Manager v1.6.1.
• The feature introduced with Git for W
From: Lars Schneider
According to LARGE_PACKET_MAX in pkt-line.h the maximal length of a
pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and
therefore the pkt-line data component must not exceed 65516 bytes.
Signed-off-by: Lars Schneider
---
Documentation/technical/protocol-c
It is remarkable that libgit.a did not sport this function yet... Let's
move it into a more prominent (and into an actually reusable) spot:
wt-status.[ch].
Signed-off-by: Johannes Schindelin
---
builtin/pull.c | 75 +-
wt-status.c| 74 +
When converting the pull command to a builtin, the
require_clean_work_tree() function was renamed and the pull-specific
parts hard-coded.
This makes it impossible to reuse the code, so let's modify the code to
make it more similar to the original shell script again.
Signed-off-by: Johannes Schind
In cmd_pull(), when verifying that there are no changes preventing a
rebasing pull, we diligently pass the prefix parameter to the
die_on_unclean_work_tree() function which in turn diligently passes it
to the has_unstaged_changes() and has_uncommitted_changes() functions.
The casual reader might n
This is the 5th last patch series of my work to accelerate interactive
rebases in particular on Windows.
Basically, all it does is to make reusable some functions that were
ported over from git-pull.sh but made private to builtin/pull.c.
An earlier attempt included only the first patch, and someh
W dniu 22.08.2016 o 01:59, Andrew Ardill pisze:
> On 21 August 2016 at 04:56, Jakub Narębski wrote:
>> 25. What [channel(s)] do you use to request/get help about Git [(if any)]
>
> It may also be useful to ask how people hear news about git, such as
> when a new release comes out. Not sure if wor
The function would otherwise pretend to work fine, but totally ignore
the working directory.
Signed-off-by: Johannes Schindelin
---
wt-status.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/wt-status.c b/wt-status.c
index 792dda9..33dd76f 100644
--- a/wt-status.c
+++ b/wt-status.c
@
They will be used in the upcoming rebase helper.
Signed-off-by: Johannes Schindelin
---
wt-status.c | 4 ++--
wt-status.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 33dd76f..1c3fabf 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1762,7
Sometimes we are *actually* interested in those changes... For
example when an interactive rebase wants to continue with a staged
submodule update.
Signed-off-by: Johannes Schindelin
---
builtin/pull.c | 2 +-
wt-status.c| 16 +---
wt-status.h| 7 ---
3 files changed, 1
From: Torsten Bögershausen
Update the documentation about text=auto:
text=auto now follows the core.autocrlf handling when files are not
normalized in the repository.
For a cross platform project recommend the usage of attributes for
line-ending conversions.
Signed-off-by: Torsten Bögershausen
From: Torsten Bögershausen
The man page for `git ls-files --eol` mentions the combination
of text attributes "text=auto eol=lf" or "text=auto eol=crlf" as not
supported yet, but may be in the future.
Now they are supported
Signed-off-by: Torsten Bögershausen
---
Documentation/git-ls-files.txt
From: Torsten Bögershausen
Sorry for posting this so late:
While reviewing another patch I realized that the eol related
documentation was not updated as it should be.
Torsten Bögershausen (2):
git ls-files: text=auto eol=lf is supported in Git 2.10
gitattributes: Document the unified "auto"
On Thu, Aug 25, 2016 at 2:28 AM, Michael Haggerty wrote:
> On 08/24/2016 11:39 PM, Jeff King wrote:
>> On Wed, Aug 24, 2016 at 04:52:33PM -0400, Alex Nauda wrote:
>>
>>> Elastic File System (EFS) is Amazon's scalable filesystem product that
>>> is exposed to the OS as an NFS mount. We're using EFS
Duy Nguyen writes:
> On Wed, Aug 24, 2016 at 11:35 PM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> It's not wonderful, but it's in line with how git-checkout stops caring
>>> about ambiguity after the first argument can be resolved as a ref
>>> (there's even a test for it, t20
+cc Jacob and Lars who work with submodules as well.
On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander
wrote:
>
> Right now updating a submodule in a topic branch and merging it into master
> will not change the submodule index in master leading to at least two commit
> for the same change (one
"Hedges Alexander" writes:
> Right now updating a submodule in a topic branch and merging it into master
> will not change the submodule index in master leading to at least two commit
> for the same change (one in any active branch).
I stopped reading here because I am not getting this.
I gues
Ed Greenberg writes:
> I think I understand this from the git-push man page, but I want to
> make sure:
>
> I have two branches, master and develop.
>
> If I am (accidentally) sitting on master, and issue 'git push origin
> develop', does this properly push develop to remote develop, or does
> it
> +int packet_write_fmt_gently(int fd, const char *fmt, ...)
> +{
> + static struct strbuf buf = STRBUF_INIT;
> + va_list args;
> +
> + strbuf_reset(&buf);
> + va_start(args, fmt);
> + format_packet(&buf, fmt, args);
format_packet also takes care of tracing the conten
Pranit Bauva writes:
> +static int bisect_terms(struct bisect_terms *terms, const char **argv, int
> argc)
> +{
> + int i;
> +
> + if (get_terms(terms)) {
> + fprintf(stderr, _("no terms defined\n"));
> + return -1;
> + }
> + if (argc == 0) {
> +
Thank you for your reply Jeff. I have moved on to installing GitLab. It has
been a success so far.
Thanks,
Dave
-Original Message-
From: Jeff King [mailto:p...@peff.net]
Sent: Wednesday, August 24, 2016 1:00 PM
To: David McGough
Cc: git@vger.kernel.org
Subject: Re: Smart HTTP push pe
On Thu, Aug 25, 2016 at 4:07 AM, wrote:
> From: Lars Schneider
>
> packet_write_stream_with_flush_from_fd() and
> packet_write_stream_with_flush_from_buf() write a stream of packets. All
> content packets use the maximal packet size except for the last one.
> After the last content packet a `flu
On Thu, Aug 25, 2016 at 10:50:23AM -0700, Junio C Hamano wrote:
> Ed Greenberg writes:
>
> > I think I understand this from the git-push man page, but I want to
> > make sure:
> >
> > I have two branches, master and develop.
> >
> > If I am (accidentally) sitting on master, and issue 'git push o
On 25 Aug 2016, at 20:12, Stefan Beller wrote:
>> +int packet_write_fmt_gently(int fd, const char *fmt, ...)
>> +{
>> + static struct strbuf buf = STRBUF_INIT;
>> + va_list args;
>> +
>> + strbuf_reset(&buf);
>> + va_start(args, fmt);
>> + format_packet(&buf, fmt, ar
On Thu, Aug 25, 2016 at 4:07 AM, wrote:
> From: Lars Schneider
>
> According to LARGE_PACKET_MAX in pkt-line.h the maximal length of a
> pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and
> therefore the pkt-line data component must not exceed 65516 bytes.
>
> Signed-off-by: L
Pranit Bauva writes:
> +static int bisect_start(struct bisect_terms *terms, int no_checkout,
> + const char **argv, int argc)
> +{
> + int i, has_double_dash = 0, must_write_terms = 0, bad_seen = 0;
> + int flags, pathspec_pos;
> + struct string_list revs = STRING_
On Thu, Aug 25, 2016 at 4:07 AM, wrote:
> From: Lars Schneider
>
> Generate more interesting large test files
How are the large test files more interesting?
(interesting in the notion of covering more potential bugs?
easier to debug? better to maintain, or just a pleasant read?)
> with pseudo
> On 25 Aug 2016, at 20:59, Stefan Beller wrote:
>
>> On Thu, Aug 25, 2016 at 4:07 AM, wrote:
>> From: Lars Schneider
>>
>> According to LARGE_PACKET_MAX in pkt-line.h the maximal length of a
>> pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and
>> therefore the pkt-line d
Junio C Hamano writes:
>> +for (i = 0; i < revs.nr; i++) {
>> +if (bad_seen)
>> +string_list_append(&states, terms->term_good.buf);
>> +else {
>> +bad_seen = 1;
>> +string_list_append(&states, terms->term_bad.
> On 25 Aug 2016, at 21:17, Stefan Beller wrote:
>
>> On Thu, Aug 25, 2016 at 4:07 AM, wrote:
>> From: Lars Schneider
>>
>> Generate more interesting large test files
>
> How are the large test files more interesting?
> (interesting in the notion of covering more potential bugs?
> easier t
Pranit Bauva writes:
> A lot of parts of bisect.c uses exit() and these signals are then
> trapped in the `bisect_start` function. Since the shell script ceases
> its existence it would be necessary to convert those exit() calls to
> return statements so that errors can be reported efficiently in
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> Sorry for posting this so late:
> While reviewing another patch I realized that the eol related
> documentation was not updated as it should be.
>
> Torsten Bögershausen (2):
> git ls-files: text=auto eol=lf is supported in Git 2.10
> git
On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
> I am not so sure about that. If there is an existing place that is
> buggy, shouldn't we fix that, instead of spreading the same bug
> (assuming that it is a bug in the first place, which I do not have a
> strong opinion on, at least not y
On Tue, Aug 23, 2016 at 10:47 AM, Stefan Beller wrote:
> On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
>> I am not so sure about that. If there is an existing place that is
>> buggy, shouldn't we fix that, instead of spreading the same bug
>> (assuming that it is a bug in the first pla
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> The man page for `git ls-files --eol` mentions the combination
> of text attributes "text=auto eol=lf" or "text=auto eol=crlf" as not
> supported yet, but may be in the future.
> Now they are supported
Thanks. I'll finish the sentence with a
On Thu, Aug 25, 2016 at 1:39 PM, Jacob Keller wrote:
> On Tue, Aug 23, 2016 at 10:47 AM, Stefan Beller wrote:
>> On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
>>> I am not so sure about that. If there is an existing place that is
>>> buggy, shouldn't we fix that, instead of spreading
tbo...@web.de writes:
> +If you want to ensure that text files that any contributor introduces to
> +the repository have their line endings normalized, you could set the
> +`text` attribute to "auto" for _all_ files.
> +
> +
> +*text=auto
> +
> +
Stefan Beller writes:
> +cc Jacob and Lars who work with submodules as well.
>
> On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander
> wrote:
>>
>> Right now updating a submodule in a topic branch and merging it into master
>> will not change the submodule index in master leading to at least two
On Thu, Aug 25, 2016 at 1:50 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +cc Jacob and Lars who work with submodules as well.
>>
>> On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander
>> wrote:
>>>
>>> Right now updating a submodule in a topic branch and merging it into master
>>> will
Johannes Schindelin writes:
> To be truly useful, the sequencer should never die() but always return
> an error.
>
> Signed-off-by: Johannes Schindelin
> ---
Instead of dying there, you let the caller high up in the callchain
to notice the error and handle it (by dying). The eventual caller
of
Stefan Beller writes:
>>> So you roughly do
>>>
>>> git checkout -b new-topic
>>> # change the submodule to point at the latest upstream version:
>>> git submodule update --remote
>>> git commit -a -m "update submodule"
>>> git checkout master
>>> git merge new-topic
>>>
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> packet_write_fmt() would die in case of a write error even though for
> some callers an error would be acceptable. Add packet_write_fmt_gently()
> which writes a formatted pkt-line and returns `0` for success and `-1`
> for an error.
>
>
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> packet_write_fmt() has two shortcomings. First, it uses format_packet()
> which lets the caller only send string data via "%s". That means it
> cannot be used for arbitrary data that may contain NULs. Second, it will
> always die on erro
On Thu, Aug 25, 2016 at 1:46 PM, Stefan Beller wrote:
> On Thu, Aug 25, 2016 at 1:39 PM, Jacob Keller wrote:
>> On Tue, Aug 23, 2016 at 10:47 AM, Stefan Beller wrote:
>>> On Tue, Aug 23, 2016 at 10:25 AM, Junio C Hamano wrote:
I am not so sure about that. If there is an existing place tha
Stefan Beller writes:
> So the API provided by these read/write functions is intended
> to move a huge chunks of data. And as it puts the data on the wire one
> packet after the other without the possibility to intervene and e.g. send
> a side channel progress bar update, I would question the des
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> packet_write_stream_with_flush_from_fd() and
> packet_write_stream_with_flush_from_buf() write a stream of packets. All
> content packets use the maximal packet size except for the last one.
> After the last content packet a `flush` cont
Jacob Keller writes:
> So we should support the gitlink to a repository stored at
> without stuff inside the .git/modules, and we should support submodule
> gitlinks with a proper .gitmodules setup. I don't think we should
> die() but we should error properly so I will introduce a _gently()
> va
On Thu, Aug 25, 2016 at 3:38 PM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> So we should support the gitlink to a repository stored at
>> without stuff inside the .git/modules, and we should support submodule
>> gitlinks with a proper .gitmodules setup. I don't think we should
>> die() bu
Johannes Schindelin writes:
> To be truly useful, the sequencer should never die() but always return
> an error.
>
> Signed-off-by: Johannes Schindelin
> ---
> sequencer.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
Instead of dying there, you let the caller high u
Johannes Schindelin writes:
> To be truly useful, the sequencer should never die() but always return
> an error.
>
> Signed-off-by: Johannes Schindelin
> ---
I am still looking at sequencer.c in 'master', but I do not think
that the sole caller of this function, walk_revs_populate_todo(),
is pr
Johannes Schindelin writes:
> To be truly useful, the sequencer should never die() but always return
> an error.
>
> Signed-off-by: Johannes Schindelin
> ---
> sequencer.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
Instead of dying there, you let the caller high up
> On 25 Aug 2016, at 20:46, Stefan Beller wrote:
>
>> On Thu, Aug 25, 2016 at 4:07 AM, wrote:
>> From: Lars Schneider
>>
>> packet_write_stream_with_flush_from_fd() and
>> packet_write_stream_with_flush_from_buf() write a stream of packets. All
>> content packets use the maximal packet size
From: Junio C Hamano
"diff/log --stat" has a logic that determines the display columns
available for the diffstat part of the output and apportions it for
pathnames and diffstat graph automatically.
5e71a84a (Add output_prefix_length to diff_options, 2012-04-16)
added the output_prefix_length fi
From: Jacob Keller
A future patch will add a new format for displaying the difference of
a submodule. Make it easier by changing how we store the current
selected format. Replace the DIFF_OPT flag with an enumeration, as each
format will be mutually exclusive.
Signed-off-by: Jacob Keller
---
d
From: Jacob Keller
Currently, do_submodule_path will attempt locating the .git directory by
using read_gitfile on /.git. If this fails it just assumes the
/.git is actually a git directory.
This is good because it allows for handling submodules which were cloned
in a regular manner first before
From: Jacob Keller
Add an extension to git-diff and git-log (and any other graph-aware
displayable output) such that "--line-prefix=" will print the
additional line-prefix on every line of output.
To make this work, we have to fix a few bugs in the graph API that force
graph_show_commit_msg to b
From: Jacob Keller
Since we're going to be changing this function in a future patch, lets
go ahead and convert this to use object_id now.
Signed-off-by: Jacob Keller
---
diff.c | 2 +-
submodule.c | 16
submodule.h | 2 +-
3 files changed, 10 insertions(+), 10 deletions
From: Jacob Keller
A future patch is going to add a new submodule diff format which
displays an inline diff of the submodule changes. To make this easier,
and to ensure that both submodule diff formats use the same initial
header, factor out show_submodule_header() function which will print the
c
From: Jacob Keller
Teach git-diff and friends a new format for displaying the difference
of a submodule. The new format is an inline diff of the contents of the
submodule between the commit range of the update. This allows the user
to see the actual code change caused by a submodule update.
Add
From: Jacob Keller
Modify the changes to do_submodule_path so that we properly call
gitmodules_config() before the lookup of submodule_from_path. This may
need to be modified so that we only call it the first time as I'm not
sure what sort of performance hit we'll see. Note that we only need this
From: Jacob Keller
Similar to is_null_oid(), and is_empty_blob_sha1() add an
empty_tree_oid along with helper function is_empty_tree_oid(). For
completeness, also add an "is_empty_tree_sha1()",
"is_empty_blob_sha1()", "is_empty_tree_oid()" and "is_empty_blob_oid()"
helpers.
To ensure we only get
On 08/25/2016 06:01 PM, Alex Nauda wrote:
> On Thu, Aug 25, 2016 at 2:28 AM, Michael Haggerty
> wrote:
>> On 08/24/2016 11:39 PM, Jeff King wrote:
>>> On Wed, Aug 24, 2016 at 04:52:33PM -0400, Alex Nauda wrote:
>>>
Elastic File System (EFS) is Amazon's scalable filesystem product that
i
On Thu, Aug 25, 2016 at 3:31 PM, Junio C Hamano wrote:
> What is wrong about that? 4*80k = 320kB overhead for length fields
> to transfer 5GB worth of data? I do not think it is worth worrying
> about it.
>
> But I am more surprised by seeing that "why not a single huge
> packet" suggestion imme
On Thu, Aug 25, 2016 at 1:31 PM, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> From: Torsten Bögershausen
>>
>> Sorry for posting this so late:
>> While reviewing another patch I realized that the eol related
>> documentation was not updated as it should be.
>>
>> Torsten Bögershausen (2):
>
Not directly-related to the survey questions, but can you ensure
it's accessible to folks without JavaScript/graphics, and
perhaps also ensure it is on a host that is Tor-friendly?
Graphics setups often require non-Free firmware or drivers for
acceptable performance; and there are also visually-im
Hello,
>> On Thu, Aug 25, 2016 at 12:03 AM, Jeff King wrote:
>>>
>>> Ah, right. I was feeling like this was all vaguely familiar. I think
>>> it would be better to push forward kn/ref-filter-branch-list.
>>> According to the last "what's cooking", I think that topic is waiting
>>> on more review.
Hi,
Jakub Narębski wrote:
> Andrew Ardill pisze:
> > Jakub Narębski wrote:
> >> 25. What [channel(s)] do you use to request/get help about Git [(if any)]
> >
> > It may also be useful to ask how people hear news about git, such as
> > when a new release comes out. Not sure if worth a separate qu
94 matches
Mail list logo
