On Fri, Jul 15, 2016 at 12:36 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Thu, Jul 14, 2016 at 01:43:57PM -0700, Junio C Hamano wrote:
>>
>>> As we are not yet moving everything to size_t but still using ulong
>>> internally when talking about the size of object, platforms with
>>> 32-b
On Sat, Jul 16, 2016 at 08:10:15AM +0200, Duy Nguyen wrote:
> But you did spot a problem. What if UC extension is loaded _after_
> watchman one? Then index->untracked_cache would have nothing in there
> and invalidation is no-op when we do it (at watchmain ext loading
> time). We can't control exte
On Thu, Jul 14, 2016 at 5:21 PM, Duy Nguyen wrote:
>> On Thu, Jul 14, 2016 at 12:11 AM, Ben Peart wrote:
>>> I’ve been chasing down an issue where it looks like the untracked cache
>>> logic doesn’t work correctly in the index-helper/watchman patch series.
>>> It’s also entirely possible that I’m
On Thu, Jul 14, 2016 at 9:38 AM, Lars Schneider
wrote:
>
> On 13 Jul 2016, at 22:43, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>>> It is somewhat disturbing that nobody seems to be regularly building
>>> on 32-bit platforms these days, which is the only reason I can think
>>> of why t
On Fri, Jul 15, 2016 at 11:28 PM, Eric Wong wrote:
> Konstantin Khomoutov wrote:
>> Ben Peart wrote:
>> > > Lars Schneider wrote:
>> > >
>> > > We could dynamically load libraries but this would force us to
>> > > freeze the ABI as mentioned by Duy:
>> > > http://article.gmane.org/gmane.comp.ver
[+cc Shawn, who participated in the original discussion, as I don't
think Colby really works on git any more]
On Fri, Jul 15, 2016 at 01:44:14PM -0700, Parker Moore wrote:
> From: Parker Moore
>
> This fixes contrib/persistent-https builds for Go v1.7+ and is
> compatible with Go v1.5+.
>
>
Similar to $EMPTY_TREE this makes it easier to recognize this special
SHA-1 and change hash later.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t1011-read-tree-sparse-checkout.sh | 8
t/t1700-split-index.sh | 24
t/t3102-ls-tree-wildcards.sh
If a subdirectory contains nothing but i-t-a entries, we generate an
empty tree object and add it to its parent tree. Which is wrong. Such
a subdirectory should not be added.
Note that this has a cascading effect. If subdir 'a/b/c' contains
nothing but i-t-a entries, we ignore it. But then if 'a/b
v4 removes the leading underscore from _EMPTY_BLOB and _EMPTY_TREE and
updates 4/4 slightly like this.
diff --git a/cache-tree.c b/cache-tree.c
index 2d50640..f28b1f4 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -325,6 +325,7 @@ static int update_one(struct cache_tree *it,
const
This is a special SHA1. Let's keep it at one place, easier to replace
later when the hash change comes, easier to recognize.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t-basic.sh| 2 +-
t/t1100-commit-tree-options.sh | 2 +-
t/t4010-diff-pathspec.sh| 2 --
t/t4054-
Commit 3cf773e (cache-tree: fix writing cache-tree when CE_REMOVE is
present - 2012-12-16) skips i-t-a entries when building trees objects
from the index. Unfortunately it may skip too much.
The code in question checks if an entry is an i-t-a one, then no tree
entry will be written. But it does no
Am 15.07.2016 um 6:03 nachm. schrieb Junio C Hamano :
> Junio C Hamano writes:
>> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
>>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>>>
I pulled out the source for version 2.9.1 and briefly skimmed how
run_commit and
p
Am 15.07.2016 um 5:19 nachm. schrieb Junio C Hamano :
>
> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>>
>>> I pulled out the source for version 2.9.1 and briefly skimmed how
>>> run_commit and
>>> prepare_to_commit work. It se
On Fri, Jul 15, 2016 at 11:19:23AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > + /*
> > +* If non-zero, send error messages to this descriptor rather
> > +* than stderr. The descriptor is closed before check_connected
> > +* returns.
> > +*/
> > + int err_fd;
>
>
On Fri, Jul 15, 2016 at 11:13:40AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The number of variants of check_everything_connected has
> > grown over the years, so that the "real" function takes
> > several possibly-zero, possibly-NULL arguments. We hid the
> > complexity behind some
On Fri, Jul 15, 2016 at 11:00:52AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> > index b82bcc3..88d95a7 100644
> > --- a/builtin/rev-list.c
> > +++ b/builtin/rev-list.c
> > @@ -9,6 +9,7 @@
> > #include "log-tree.h"
> > #include
When blaming files, changes in the work tree are taken into account
and displayed as being "Not Committed Yet".
However, when blaming a file that is not known to the current HEAD,
git blame fails with `no such path 'foo' in HEAD`, even when the file
was git add'ed.
This would seem uninteresting w
Somehow, this test was using:
{
echo A
echo B
} > file
block to feed file contents. This changes those to the form most common
in git test scripts:
cat >file <<-\EOF
A
B
EOF
Signed-off-by: Mike Hommey
---
t/t8003-blame-corner-cases.sh | 34 +-
1
> I suspect that this would be useful without copy detection. If you
> "git mv fileA fileB" (optionally followed by "edit fileB"), fileB
> would not be in HEAD but you should be able to trace the lineage of
> the lines in it back through the renaming event, and this change
> also allows that use c
Junio C Hamano writes:
> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>>
>>> I pulled out the source for version 2.9.1 and briefly skimmed how
>>> run_commit and
>>> prepare_to_commit work. It seems that Git already understands
Konstantin Khomoutov wrote:
> Ben Peart wrote:
> > > Lars Schneider wrote:
> > >
> > > We could dynamically load libraries but this would force us to
> > > freeze the ABI as mentioned by Duy:
> > > http://article.gmane.org/gmane.comp.version-control.git/298463
> > >
> >
> > I wouldn’t be too q
The latest maintenance release Git v2.9.2 is now available at
the usual places. This is only a fix to the test suite; there is
no change in the actual code produced for your daily use of Git.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public reposi
On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote:
> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
>
>> I pulled out the source for version 2.9.1 and briefly skimmed how run_commit
>> and
>> prepare_to_commit work. It seems that Git already understands that a
>> pre-commit
>> hook ca
Junio C Hamano writes:
> I suspect that the above change needs to be updated further if the
> user wants to run "blame path" during a conflicted renaming merge,
> i.e.
>
> 0. Before two histories diverged, there was old_path.
> 1. Our side updated contents of that file and kept it at old_path.
Mike Hommey writes:
> When blaming files, changes in the work tree are taken into account
> and displayed as being "Not Committed Yet".
>
> However, when blaming a file that is not known to the current HEAD,
> git blame fails with `no such path 'foo' in HEAD`, even when the file
> was git add'ed.
From: Parker Moore
This fixes contrib/persistent-https builds for Go v1.7+ and is
compatible with Go v1.5+.
Running `make all` in `contrib/persistent-https` results in a failure
on Go 1.7 and above.
Specifically, the error is:
go build -o git-remote-persistent-https \
-ldflags "-X main.
Am 15.07.2016 um 09:46 schrieb Andrey Vagin:
On Thu, Jul 14, 2016 at 10:56 PM, Johannes Sixt wrote:
IOW: These special files are invisible for Git unless it already knows the
names. The latter case is outside 'git clean's domain, and the former case
really means that special files in the workin
Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller :
> I pulled out the source for version 2.9.1 and briefly skimmed how run_commit
> and
> prepare_to_commit work. It seems that Git already understands that a
> pre-commit
> hook can change the index, and it rereads the index before running the
Jeff King writes:
> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
> index 1cba120..54f2cfb 100644
> --- a/builtin/index-pack.c
> +++ b/builtin/index-pack.c
> @@ -1626,6 +1626,7 @@ int cmd_index_pack(int argc, const char **argv, const
> char *prefix)
> struct pack_idx_option opts
The command "setfiletype" will not override an existing filetype. This was
never a problem for me previously, but since upgrading from VIM 7.3 to 7.4
the filetype for StGit's files is explicitly set to "text", preventing the
stgit ftdetect plugin overriding it. Use "setlocal filetype=" instead to
e
Hi Jeff.
Hmmm. You are the master of blind guessing - spot on.
Also, that is kind of embaressing to me. However, should your way cross mine,
you hereby have a voucer for a drink after your choice as long as it is beer.
Thanks,
Morten.
> Just a blind guess, but might you have two files with n
Jeff King writes:
> + /*
> + * If non-zero, send error messages to this descriptor rather
> + * than stderr. The descriptor is closed before check_connected
> + * returns.
> + */
> + int err_fd;
Theoretically speaking it may be possible that a caller may want to
write
Jeff King writes:
> The number of variants of check_everything_connected has
> grown over the years, so that the "real" function takes
> several possibly-zero, possibly-NULL arguments. We hid the
> complexity behind some wrapper functions, but this doesn't
> scale well when we want to add new opt
Jeff King writes:
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index b82bcc3..88d95a7 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -9,6 +9,7 @@
> #include "log-tree.h"
> #include "graph.h"
> #include "bisect.h"
> +#include "progress.h"
>
> static const char
On 15.07.2016, at 1:28 nachm., Junio C Hamano wrote:
> Earlier you said you are working on a patch series. Since you have
> already looked at the codepath already, perhaps you may want to try
> a patch series to add the missing error-return instead, if you are
> interested?
Definitely intereste
Andrew Keller writes:
> On 15.07.2016, at 1:02 nachm., Junio C Hamano wrote:
>
>> Expected outcome is an error saying "do not modify the index inside
>> pre-commit hook", and a rejection. It was meant as a verification
>> mechansim (hence it can be bypassed with --no-verify), not as a way
>> to
On Fri, Jul 15, 2016 at 3:43 AM, Jeff King wrote:
>
> Signed-off-by: Jeff King
Read-entirely-by Stefan ;)
Thanks!
> @@ -319,10 +331,60 @@ static void rp_error(const char *err, ...)
> static int copy_to_sideband(int in, int out, void *arg)
> {
> char data[128];
While looking at this
On 15.07.2016, at 1:02 nachm., Junio C Hamano wrote:
> Expected outcome is an error saying "do not modify the index inside
> pre-commit hook", and a rejection. It was meant as a verification
> mechansim (hence it can be bypassed with --no-verify), not as a way
> to make changes that the user did
Johannes Schindelin writes:
> The entire point of the previous patch was to make sure that we look at
> abbreviated patch IDs (using the diff *headers* only, but avoiding
> to load the blobs into memory and diff them) first, and only look at
> full patch IDs when the abbreviated patch IDs were no
Andrew Keller writes:
> I have observed an interesting scenario. Here are example reproduction steps:
>
> 1. new repository
> 2. create new pre-commit hook that invokes `git mv one two`
> 3. touch one
> 4. git add one
> 5. git commit
>
> Expected outcome: In the commit message template, I expect
On Fri, 15 Jul 2016 16:18:28 + (UTC)
Ben Peart wrote:
> > Thanks for this great summary of the problem, Christian!
> >
> > I think a generic plugin mechanism would be great but how would we
> > do it?
>
> I’m also very glad to see the discussion about coming up with a good
> pattern for how
Johannes Schindelin writes:
> So what are your plans with 2.9.2? I ask because I do not want to engineer
> a 2.9.1 release just to see that 2.9.2 is out and having to spend the same
> amount of time for another release ;-)
Essentially unchanged from what I said in $gmane/299446 a few days
ago.
Hi everyone,
I have observed an interesting scenario. Here are example reproduction steps:
1. new repository
2. create new pre-commit hook that invokes `git mv one two`
3. touch one
4. git add one
5. git commit
Expected outcome: In the commit message template, I expect to see “Changes to
be co
Lars Schneider gmail.com> writes:
>
> Thanks for this great summary of the problem, Christian!
>
> I think a generic plugin mechanism would be great but how would we do it?
I’m also very glad to see the discussion about coming up with a good pattern
for
how git can interact with external cod
The entire point of the previous patch was to make sure that we look at
abbreviated patch IDs (using the diff *headers* only, but avoiding
to load the blobs into memory and diff them) first, and only look at
full patch IDs when the abbreviated patch IDs were not for the
--cherry-pick test.
Let's
Jeff King peff.net> writes:
>
> On Fri, Jul 15, 2016 at 02:46:28PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > On Fri, Jul 15, 2016 at 2:18 PM, Jeff King peff.net> wrote:
> > > Some features, like the index-helper, aren't quite so easy. One reason
> > > is that its data needs to persist as a c
On Wed, Jul 13, 2016 at 8:59 PM, Johannes Schindelin
wrote:
>> No.
>
> Oh? So you do not see that we are already heading into serious trouble
> ourselves?
I do see problems, that have solutions. But I have not yet seen that
we are heading to a dead end.
>> I prefer we have a single interface for
On Fri, 15 Jul 2016, Ævar Arnfjörð Bjarmason wrote:
> I.e. it allows pushing a series which is a series of two commits which:
>
> 1. Change the forbidden file(s)
> 2. Undo changes to the forbidden file(s)
That’s precisely allowed.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4,
Hi Mike,
On Fri, 15 Jul 2016, Mike Hommey wrote:
> diff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh
> index a9b266f..2812d7c 100755
> --- a/t/t8003-blame-corner-cases.sh
> +++ b/t/t8003-blame-corner-cases.sh
> @@ -41,12 +41,12 @@ test_expect_success setup '
> test_
Hi Junio,
On Thu, 14 Jul 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yeah, that is what I was trying to get at, but you stated it much more
> > clearly. LONG_IS_64BIT is good. I wonder if the "git version
> > --build-options" should be "sizeof-long", too. It's shorter, and
> > indicat
On Thu, Jul 14, 2016 at 8:44 PM, Junio C Hamano wrote:
> On Thu, Jul 14, 2016 at 11:27 AM, Junio C Hamano wrote:
>> Thorsten Glaser writes:
>>
>>> if test x"0" != x"$(comm -23z \
>>> <(git ls-tree -r -z "$old" "$subdir" | sort -z) \
>>> <(git ls-tree -r -z "$new" "$subd
On Fri, Jul 15, 2016 at 03:37:32PM +0200, Torsten Bögershausen wrote:
> > So off_t is probably better. We do need to be careful, though, when
> > allocating objects. E.g., this:
> >
> > off_t size;
> > struct git_istream *stream;
> > void *buf;
> >
> > stream = open_istream(sha1, &type,
On 07/15/2016 12:38 AM, Jeff King wrote:
On Thu, Jul 14, 2016 at 03:30:58PM -0700, Junio C Hamano wrote:
If we move to time_t everywhere, I think we'll need an extra
TIME_T_IS_64BIT, but we can cross that bridge when we come to it.
Likewise I think we'll need SIZE_T_IS_64BIT eventually (for
On Fri, Jul 15, 2016 at 02:46:28PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jul 15, 2016 at 2:18 PM, Jeff King wrote:
> > Some features, like the index-helper, aren't quite so easy. One reason
> > is that its data needs to persist as a cache between multiple git
> > invocations. In general
When blaming files, changes in the work tree are taken into account
and displayed as being "Not Committed Yet".
However, when blaming a file that is not known to the current HEAD,
git blame fails with `no such path 'foo' in HEAD`, even when the file
was git add'ed.
This would seem uninteresting w
On Fri, Jul 15, 2016 at 2:18 PM, Jeff King wrote:
> Some features, like the index-helper, aren't quite so easy. One reason
> is that its data needs to persist as a cache between multiple git
> invocations. In general, I think it would be nice to solve that by
> communicating via on-disk files, rat
On Fri, Jul 15, 2016 at 08:37:59AM -0400, Jeff King wrote:
> On Fri, Jul 15, 2016 at 09:32:45PM +0900, Mike Hommey wrote:
>
> > > > +test_expect_success 'blame wholesale copy and more in the index' '
> > > > +
> > > > + {
> > > > + echo ABC
> > > > + echo DEF
> >
On Fri, Jul 15, 2016 at 09:32:45PM +0900, Mike Hommey wrote:
> > > +test_expect_success 'blame wholesale copy and more in the index' '
> > > +
> > > + {
> > > + echo ABC
> > > + echo DEF
> > > + echo
> > > + echo
> > > + echo GHIJK
> > > + } >horse
On Fri, Jul 15, 2016 at 12:45:15PM +0200, Johannes Schindelin wrote:
> Hi Mike,
>
> On Fri, 15 Jul 2016, Mike Hommey wrote:
>
> > When blaming files, changes in the work tree are taken into account
> > and displayed as being "Not Committed Yet".
> >
> > However, when blaming a file that is not k
On Fri, Jul 15, 2016 at 08:46:03AM +0200, Christian Couder wrote:
> One way to extend it for better performance is to require that the
> configured command should be able to deal with a number or a stream of
> files or objects (instead of just one objec/file) that are passed to
> it. It looks like
> On Jul 13, 2016, at 3:32 PM, Junio C Hamano wrote:
>
> Benjamin Fritsch writes:
>
>> I read the Changelog for 2.9 and couldn’t find any reference to changed key
>> handling. Is there anything that I can add to the `git clone` command to get
>> the old behavior?
>
> I do not think this has
Hi Kevin,
congratulations for your first patch on the Git mailing list!
On Thu, 14 Jul 2016, Kevin Willford wrote:
> When limiting the list in a revision walk using cherry pick, patch ids are
> calculated by producing the diff of the content of the files. This would
> be more efficent by using
Hi Andrey,
On Fri, 15 Jul 2016, Andrey Vagin wrote:
> What will be wrong if 'git status' will reports these [fifo/socket] files?
`git status` is intended to give you an idea what to commit next. And...
> What will be wrong if 'git add' will returns an error instead of
> skipping them silently?
Hi Mike,
On Fri, 15 Jul 2016, Mike Hommey wrote:
> When blaming files, changes in the work tree are taken into account
> and displayed as being "Not Committed Yet".
>
> However, when blaming a file that is not known to the current HEAD,
> git blame fails with `no such path 'foo' in HEAD`, even w
After a client has sent us the complete pack, we may spend
some time processing the data and running hooks. If the
client asked us to be quiet, receive-pack won't send any
progress data during the index-pack or connectivity-check
steps. And hooks may or may not produce their own progress
output. In
If the connectivity check encounters a problem when
receiving a push, the error output goes to receive-pack's
stderr, whose destination depends on the protocol used
(ssh tends to send it to the user, though without a "remote"
prefix; http will generally eat it in the server's error
log).
The infor
When we receive a large push, the server side of the
connection may spend a lot of time (30s or more for a full
push of linux.git) walking the object graph without
producing any output. Let's give the user some indication
that we're actually working.
Signed-off-by: Jeff King
---
builtin/receive-
When we receive a large push, the server side may have to
spend a lot of CPU processing the incoming packfile.
During the "receiving" phase, we are typically network
bound, and the client is writing its own progress to the
user. But during the delta resolution phase, we may spend
minutes (e.g., fo
The index-pack command has two progress meters: one for
"receiving objects", and one for "resolving deltas". You get
neither by default, or both with "-v".
But for a push through receive-pack, we would want only the
"resolving deltas" phase, _not_ the "receiving objects"
progress. There are two re
Because the initial connectivity check for a cloned
repository can be slow, 0781aa4 (clone: let the user know
when check_everything_connected is run, 2013-05-03) added a
"fake" progress meter; we simply say "Checking connectivity"
when it starts, and "done" at the end, with nothing between.
Since
Connectivity checks have to traverse the entire object graph
in the worst case (e.g., a full clone or a full push). For
large repositories like linux.git, this can take 30-60
seconds, during which time git may produce little or no
output.
Let's add the option of showing progress, which is taken
ca
Unless the "quiet" flag is given, check_connected sends any
errors to the stderr of the caller (because the child
rev-list inherits that descriptor). However, server-side
callers may want to send these over a sideband channel
instead. Let's make that possible.
Signed-off-by: Jeff King
---
conne
The number of variants of check_everything_connected has
grown over the years, so that the "real" function takes
several possibly-zero, possibly-NULL arguments. We hid the
complexity behind some wrapper functions, but this doesn't
scale well when we want to add new options.
If we add more wrapper
It's easy to ask rev-list to do a traversal that may take
many seconds (e.g., by calling "--objects --all"). In theory
you can monitor its progress by the output you get to
stdout, but this isn't always easy.
Some operations, like "--count", don't make any output until
the end.
And some callers,
This avoids the magic "9" array-size which we must avoid
overflowing, making further patches simpler.
Signed-off-by: Jeff King
---
connected.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/connected.c b/connected.c
index 7560a31..a3bfc4e 100644
--- a/
The check_everything_connected function takes a "quiet"
parameter which does two things if non-zero:
1. redirect rev-list's stderr to /dev/null to avoid
showing errors to the user
2. pass "--quiet" to rev-list
Item (1) is obviously useful. But item (2) is
surprisingly not. For rev-list,
If you push a large number of objects, the server side may have to chew
CPU for a long time processing the input (delta resolution, connectivity
check, and whatever any hooks choose to do). During this time, you get
no feedback that anything is happening, unless the hooks feel like
writing somethin
On Fri, Jul 15, 2016 at 10:45:47AM +0200, Morten W. J. wrote:
> I have a repository hosted on a GitLab server on my LAN and when I clone that
> repository to a linux box and a windows box I get different files!
>
> It is very hard to explain in words, so I have recorded my desktop while
> repro
Hi All.
I have experienced something weird today.
I have a repository hosted on a GitLab server on my LAN and when I clone that
repository to a linux box and a windows box I get different files!
It is very hard to explain in words, so I have recorded my desktop while
reproducing it, which I c
Christian Couder writes:
> If people think that evolution is better than intelligent design, and
> want each current topic/work to just implement what is best for it,
> then that's ok for me. If on the other hand standardizing on some ways
> to interact with external processes could be helpful to
On Fri, Jul 15, 2016 at 08:46:03AM +0200, Christian Couder wrote:
> Hi,
>
> It seems to me that there are many current topics/patch series in
> flight that are about making Git interact with external code/processes
> and that it could be interesting to step back a bit and see if we
> could find a
On Thu, Jul 14, 2016 at 10:56 PM, Johannes Sixt wrote:
> Am 15.07.2016 um 04:42 schrieb Andrey Vagin:
>>
>> Currently git-clean removes only links and files, but
>> there can be special files like fifo, sockets, devices.
>>
>> I think git-clean has to remove them too.
>
>
> I think that is not nec
> On 15 Jul 2016, at 08:46, Christian Couder wrote:
>
> [...]
>
> The current topics/work I can think of are:
>
> - the ref backend work by Michael based on Ronnie Sahlberg's and others' work,
> - the smudge/clean filters work by Joey and Lars,
> - the watchman/index helper work by David, Duy
83 matches
Mail list logo
