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 common approach/mechanism for at least some of these
current topics.
(This is
On Thu, Jul 14, 2016 at 11:30 AM, Johannes Schindelin
wrote:
> When reporting broken links between commits/trees/blobs, it would be
> quite helpful at times if the user would be told how the object is
> supposed to be reachable.
>
> With the new --name-objects option, git-fsck will try to do exact
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 necessary. If you do
mkfifo fifo && sudo mknod zero c 1 5
then 'git statu
On 07/14/2016 06:48 PM, Johannes Sixt wrote:
Am 30.06.2016 um 11:09 schrieb Jeff King:
+/*
+ * This is the max value that a ustar size header can specify, as it
is fixed
+ * at 11 octal digits. POSIX specifies that we switch to extended
headers at
+ * this size.
+ */
+#define USTAR_MAX_SIZE 07
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
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.
Signed-off-by: Andrey Vagin
---
cache.h | 8
dir.c | 4
2 files changed, 12 insertions(+)
diff --git a/cache.h b/cache.h
index
On Thu, Jul 14, 2016 at 12:58:47PM +0200, Johannes Schindelin wrote:
> Hi Mike,
>
> On Thu, 14 Jul 2016, Mike Hommey wrote:
>
> > On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:
> > > Hi Junio,
> > >
> > > On Wed, 13 Jul 2016, Junio C Hamano wrote:
> > >
> > > > Does Travis
Duy Nguyen gmail.com> writes:
>
> On Wed, Jul 13, 2016 at 11:59 PM, David Turner novalis.org>
wrote:
> > On 07/12/2016 02:24 PM, Duy Nguyen wrote:
> >>
> >> Just thinking out loud. I've been thinking about this more about this.
> >> After the move from signal-based to unix socket for communica
On Thu, Jul 14, 2016 at 3:46 PM, Jeff King wrote:
> On Thu, Jul 14, 2016 at 02:49:45PM -0700, Stefan Beller wrote:
>
>> We limit the push options for now
>> * to not exceed an arbitrary count, and
>> * to not exceed an arbitrary size.
>>
>> This serves two purposes:
>> * DoS protection (i.e. one c
On Thu, Jul 14, 2016 at 02:49:45PM -0700, Stefan Beller wrote:
> We limit the push options for now
> * to not exceed an arbitrary count, and
> * to not exceed an arbitrary size.
>
> This serves two purposes:
> * DoS protection (i.e. one connection can add no more than 32kB
> now)
> * We need to
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 real 32-bit
> > systems; LLP64
Stefan Beller writes:
> Jeff,
>
> here is the more idiomatic way.
>
> Thanks,
> Stefan
Looks good to me. Thanks.
--
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://vger.kernel.org/majordomo-info.
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-bit long will not be able to produce tar archive with 4GB+ file,
>
Jeff King writes:
> 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 real 32-bit
> systems; LLP64 systems like Windows will then be able to run the test)
Johannes Sixt writes:
> My first thought was that this is not warranted because t0006 is about
> commit time stamps, but the huge-tar breakage is file sizes, and the
> cases should be treated differently.
>
> But on second thought, under the hood, both boil down to the size of
> unsigned long in
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-bit long will not be able to produce tar archive with 4GB+ file,
> and cannot grok 0
Kevin Willford writes:
> 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 a patch id looking at the paths that were
> changed in the commits and only if all the file c
The pre/post receive hook may be interested in more information from the
user. This information can be transmitted when both client and server
support the "push-options" capability, which when used is a phase directly
after update commands ended by a flush pkt.
Similar to the atomic option, the se
This implements everything that is required on the client side to make use
of push options from the porcelain push command.
Signed-off-by: Stefan Beller
---
Documentation/git-push.txt | 8 +++-
builtin/push.c | 21 ++---
send-pack.c| 27 ++
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how
The functions `mk_repo_pair` as well as `test_refs` are borrowed from
t5543-atomic-push, with additional hooks installed.
Signed-off-by: Stefan Beller
---
t/t5545-push-options.sh | 103
1 file changed, 103 insertions(+)
create mode 100755 t/t5545
Jeff,
here is the more idiomatic way.
Thanks,
Stefan
diff to v6:
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 9bb9afc..3c9360a 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -1499,11 +1499,8 @@ static struct command *read_head_info(struct sha1_array
*s
On Thu, Jul 14, 2016 at 2:35 PM, Jeff King wrote:
> On Thu, Jul 14, 2016 at 02:24:54PM -0700, Stefan Beller wrote:
>
>> # interdiff to v5:
>> [...giant deletion...]
>
> Much nicer. :)
>
>> +static struct string_list *read_push_options(void)
>> +{
>> + struct string_list *ret = xmalloc(sizeof(*
On Thu, Jul 14, 2016 at 02:24:54PM -0700, Stefan Beller wrote:
> # interdiff to v5:
> [...giant deletion...]
Much nicer. :)
> +static struct string_list *read_push_options(void)
> +{
> + struct string_list *ret = xmalloc(sizeof(*ret));
This struck me as a little non-idiomatic for our code b
On Thu, Jul 14, 2016 at 10:52:55PM +0200, Johannes Sixt wrote:
> > Dscho? I'll revert the merge of 'js/t0006-for-v2.9.2' out of
> > 'next' so that we can replace it with your newer version, but it
> > needs to be massaged to lose the strong linkage with "time", as
> > it is no longer "is our time
The pre/post receive hook may be interested in more information from the
user. This information can be transmitted when both client and server
support the "push-options" capability, which when used is a phase directly
after update commands ended by a flush pkt.
Similar to the atomic option, the se
Am 14.07.2016 um 19:08 schrieb Junio C Hamano:
Johannes Sixt writes:
Am 14.07.2016 um 17:47 schrieb Johannes Schindelin:
On Thu, 30 Jun 2016, Jeff King wrote:
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. Fo
So here is the final reroll from me for now that targets 'maint'
(eventually).
Jeff King (1):
t0006: skip "far in the future" test when unsigned long is not long
enough
Junio C Hamano (1):
archive-tar: huge offset and future timestamps would not work on
32-bit
archive-tar.c |
From: Jeff King
Git's source code refers to timestamps as unsigned longs. On 32-bit
platforms, as well as on Windows, unsigned long is not large enough
to capture dates that are "absurdly far in the future".
While we can fix this issue properly by replacing unsigned long with
a larger type, we
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-bit long will not be able to produce tar archive with 4GB+ file,
and cannot grok 0777UL as a constant. Disable the extended
header feature and do not test
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
> indicates our assumption that we are talking about all longs, not just
> u
On Thu, Jul 14, 2016 at 01:22:01PM -0700, Junio C Hamano wrote:
> > Also, shouldn't it be checking against 0x?
>
> Correct. Somehow I thought I was checking with LONG_MAX. Will correct.
>
> > An easier check would be "sizeof()", but I guess we can't use that in a
> > preprocessor direc
Jeff King writes:
>> +#if ULONG_MAX == 0x7FFF
>> +#define USTAR_MAX_SIZE ULONG_MAX
>> +#define USTAR_MAX_MTIME ULONG_MAX
>> +#else
>> #define USTAR_MAX_SIZE 0777UL
>> #define USTAR_MAX_MTIME 0777UL
>> +#endif
>>
>> /* writes out the whole block, but only if it is full */
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 a patch id looking at the paths that were
changed in the commits and only if all the file changed are the same fall
back to
On Thu, Jul 14, 2016 at 01:03:35PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > OK, how about this on top of a replacement for js/t0006-for-v2.9.2
> > that I'll send out as a reply to this message?
>
> which is this one, which is largely from your $gmane/299310.
Mostly OK, but t
On Thu, Jul 14, 2016 at 01:00:08PM -0700, Junio C Hamano wrote:
> > There's tons of discussion in:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/297409
> >
> > but frankly it is not worth your time to read it. These tests are about
> > overflowing the tar limits, which can only
Junio C Hamano writes:
> OK, how about this on top of a replacement for js/t0006-for-v2.9.2
> that I'll send out as a reply to this message?
I won't repeat the patch body, but I had to write a log message, so
here is what I tentatively committed (not queued yet).
Subject: archive-tar: huge off
Jeff King writes:
> packet_read() does NUL-terminate for you. It gets the extra bytes
> because it doesn't store the 4-byte size in the output (whereas the
> client does not ever send anything over LARGE_PACKET_MAX, _including_
> those bytes, so we always have room to store its result in our
> LA
Junio C Hamano writes:
> OK, how about this on top of a replacement for js/t0006-for-v2.9.2
> that I'll send out as a reply to this message?
which is this one, which is largely from your $gmane/299310.
-- >8 --
From: Jeff King
Date: Mon, 11 Jul 2016 19:54:18 -0400
Subject: [PATCH] t0006: skip
Jeff King writes:
> On Thu, Jul 14, 2016 at 05:47:41PM +0200, Johannes Schindelin wrote:
>
>> On Thu, 30 Jun 2016, Jeff King wrote:
>>
>> > The ustar format only has room for 11 (or 12, depending on
>> > some implementations) octal digits for the size and mtime of
>> > each file. For values larg
On Thu, Jul 14, 2016 at 12:07:15PM -0700, Junio C Hamano wrote:
> > Although as you remarked in another email, this would not pose a problem for
> > the shell variable, so we could also drop it to allow multi line
> > options. will do.
>
> One thing to note is that I do not think there is a guara
Johannes Schindelin writes:
> The two topics that are in 'pu' and conflict with this series are
> 'jh/clean-smudge-annex' and 'bc/cocci'.
>
> It also conflicted with 'va/i18n-even-more', but that one was merged to
> 'master'.
>
> Now, I think it would be okay to wait for 'bc/cocci' to go to 'mast
On Thu, Jul 14, 2016 at 12:20 PM, Junio C Hamano wrote:
> In v1.8.5 days, 7f2ea5f0 (diff: allow lowercase letter to specify
> what change class to exclude, 2013-07-17) taught the "--diff-filter"
> mechanism to take lowercase letters as exclusion, but we forgot to
> document it.
>
> Signed-off-by:
In v1.8.5 days, 7f2ea5f0 (diff: allow lowercase letter to specify
what change class to exclude, 2013-07-17) taught the "--diff-filter"
mechanism to take lowercase letters as exclusion, but we forgot to
document it.
Signed-off-by: Junio C Hamano
---
Documentation/diff-options.txt | 3 +++
1 file
Thorsten Glaser writes:
> On Thu, 14 Jul 2016, Junio C Hamano wrote:
>
>> Can't this become simpler, e.g.
>>
>> if ! git diff-tree --quiet "$old" "$new" -- "$subdir"
>
> Thought about diff-tree, but additions are permitted,
diff-tree -r --diff-filter=a "$old" "$new" -- "$subdir"
Stefan Beller writes:
>>> + lf = strchr(line, '\n');
>>> + if (lf)
>>> + *lf = '\0';
>>
>> packet_read_line() -> packet_read_line_generic() calls packet_read()
>> with PACKET_READ_CHOMP_NEWLINE flag bit; do we need this check?
>
> This check was not abo
> packet_read_line() calls packet_read_line_generic() that calls
> packet_read() with the fixed packet_buffer[] that is sized to be
> LARGE_PACKET_MAX.
>
> Can this check even trigger?
I thought when len == LARGE_PACKET_MAX,
this could trigger. Though on inspection of packet_read,
we already reje
On Thu, Jul 14, 2016 at 11:44 AM, 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" "$sub
On Thu, 14 Jul 2016, Junio C Hamano wrote:
> Can't this become simpler, e.g.
>
> if ! git diff-tree --quiet "$old" "$new" -- "$subdir"
Thought about diff-tree, but additions are permitted,
and diffing the actual file content has overhead too.
Just counting the number of object hashes remo
On Thu, Jul 14, 2016 at 11:48:58AM -0700, Stefan Beller wrote:
> > Hmm. So that is a downside for people who have implemented separate
> > DoS protection only in that upgrading git will open a new "hole"
> > that they need to plug. But that is their problem, not upstream
> > git's.
> >
> > -Peff
>
On Thu, Jul 14, 2016 at 11:41 AM, Jeff King wrote:
> On Thu, Jul 14, 2016 at 10:39:16AM -0700, Stefan Beller wrote:
>
>> Jeff wrote:
>> > Junio wrote:
>> >> I think those extra knobs can come later. If we are not going to
>> >> limit with max_options in the end, however, wouldn't it be more
>> >>
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" "$subdir" | sort -z) | wc -c)"; then
>> echo >&2 'Untou
On Thu, Jul 14, 2016 at 10:39:16AM -0700, Stefan Beller wrote:
> Jeff wrote:
> > Junio wrote:
> >> I think those extra knobs can come later. If we are not going to
> >> limit with max_options in the end, however, wouldn't it be more
> >> natural for the initial iteration without any configuration
On Thu, Jul 14, 2016 at 09:18:18AM -0700, Junio C Hamano wrote:
> I added a few missing Cc: and quoted the whole patch here to those
> who were involved; I think this update is correct, but just trying
> to make sure people know.
>
> Not limited to this particular topic, there probably are some t
Stefan Beller writes:
> +static struct string_list *read_push_options(void)
> +{
> + struct string_list *ret = xmalloc(sizeof(*ret));
> + string_list_init(ret, 1);
> +
> + while (1) {
> + char *line, *lf;
> + int len;
> +
> + line = packet_read_line
Thorsten Glaser writes:
> Although I’m ordinarily loath to write GNU bash scripts, this
> helps avoiding temporary files. This works:
>
> -cutting here may damage your screen surface-
> #!/bin/bash
> export LC_ALL=C
> subdir=x/y
> while IFS=' ' read -r old new name; do
> test x"$nam
On Thu, Jul 14, 2016 at 06:45:47PM +0200, Johannes Sixt wrote:
> Am 14.07.2016 um 17:47 schrieb Johannes Schindelin:
> > On Thu, 30 Jun 2016, Jeff King wrote:
> > > The ustar format only has room for 11 (or 12, depending on
> > > some implementations) octal digits for the size and mtime of
> > > e
On Thu, Jul 14, 2016 at 05:47:41PM +0200, Johannes Schindelin wrote:
> On Thu, 30 Jun 2016, Jeff King wrote:
>
> > The ustar format only has room for 11 (or 12, depending on
> > some implementations) octal digits for the size and mtime of
> > each file. For values larger than this, we have to add
Torsten Bögershausen writes:
>> There's less redundant work going on than at first seems, because
>> .gitattribute files are only read once and cached. Verified by strace.
>>
> OK, I think I missed that work (not enough time for Git at the moment)
> Junio, please help me out, do we have a cache h
On Thu, Jul 14, 2016 at 10:11:18AM -0700, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > Am 30.06.2016 um 11:09 schrieb Jeff King:
> >> +/*
> >> + * This is the max value that a ustar size header can specify, as it is
> >> fixed
> >> + * at 11 octal digits. POSIX specifies that we switch t
On Thu, 14 Jul 2016, Stefan Beller wrote:
> go roughly like
Thanks, that did the trick!
Although I’m ordinarily loath to write GNU bash scripts, this
helps avoiding temporary files. This works:
-cutting here may damage your screen surface-
#!/bin/bash
export LC_ALL=C
subdir=x/y
while IF
This implements everything that is required on the client side to make use
of push options from the porcelain push command.
Signed-off-by: Stefan Beller
---
Documentation/git-push.txt | 8 +++-
builtin/push.c | 21 ++---
send-pack.c| 27 ++
The functions `mk_repo_pair` as well as `test_refs` are borrowed from
t5543-atomic-push, with additional hooks installed.
Signed-off-by: Stefan Beller
---
t/t5545-push-options.sh | 103
1 file changed, 103 insertions(+)
create mode 100755 t/t5545
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how
Jeff wrote:
> Junio wrote:
>> I think those extra knobs can come later. If we are not going to
>> limit with max_options in the end, however, wouldn't it be more
>> natural for the initial iteration without any configuration not to
>> have hard-coded max_options at all?
>
> Yeah, I am OK with addi
The pre/post receive hook may be interested in more information from the
user. This information can be transmitted when both client and server
support the "push-options" capability, which when used is a phase directly
after update commands ended by a flush pkt.
Similar to the atomic option, the se
Johannes Sixt writes:
> Am 30.06.2016 um 11:09 schrieb Jeff King:
>> +/*
>> + * This is the max value that a ustar size header can specify, as it is
>> fixed
>> + * at 11 octal digits. POSIX specifies that we switch to extended headers at
>> + * this size.
>> + */
>> +#define USTAR_MAX_SIZE 0777
Johannes Sixt writes:
> Am 14.07.2016 um 17:47 schrieb Johannes Schindelin:
>> On Thu, 30 Jun 2016, Jeff King wrote:
>>> The ustar format only has room for 11 (or 12, depending on
>>> some implementations) octal digits for the size and mtime of
>>> each file. For values larger than this, we have
Johannes Schindelin writes:
> Note that this patch opts for decorating the objects with plain strings
> instead of full-blown structs (à la `struct rev_name` in the code of
> the `git name-rev` command), for several reasons:
>
> - the code is much simpler than if it had to work with structs that
On Thu, Jul 14, 2016 at 8:31 AM, Thorsten Glaser wrote:
> Hi *,
>
> is there a way, for example with some sort of pre-receive hook,
> to prevent some files from being overwritten by a push?
pre-receive hooks are a thing!
pre-receive
This hook is invoked by git-receive-pack on the remote
Am 30.06.2016 um 11:09 schrieb Jeff King:
+/*
+ * This is the max value that a ustar size header can specify, as it is fixed
+ * at 11 octal digits. POSIX specifies that we switch to extended headers at
+ * this size.
+ */
+#define USTAR_MAX_SIZE 0777UL
This is too large by one bit for
Am 14.07.2016 um 17:47 schrieb Johannes Schindelin:
On Thu, 30 Jun 2016, Jeff King wrote:
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify
Johannes Schindelin writes:
> In many places, we refer to objects via their SHA-1s. Let's abstract
> that into a function.
>
> For the moment, it does nothing else than what we did previously: print
> out the 40-digit hex string. But that will change over the course of the
> next patches.
>
> Sig
Johannes Schindelin writes:
> Example output:
>
> ...
> broken link fromtree b5eb6ff... (refs/stash@{}~37:)
> toblob ec5cf80...
The objective makes sense, and their progression is very nicely
structured. I can "smell" that these are going in the right
di
Johannes Schindelin writes:
> When we tried to fix in 58461bd (t1308: do not get fooled by symbolic
> links to the source tree, 2016-06-02) an obscure case where the user
> cd's into Git's source code via a symbolic link, a regression was
> introduced that affects all test runs on Windows.
Thank
On Thu, Jul 14, 2016 at 5:53 PM, Johannes Schindelin
wrote:
> Hi Duy,
>
> On Thu, 14 Jul 2016, Nguyễn Thái Ngọc Duy wrote:
>
>> Helped-by: Jeff King
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>
> This commit message is quite a bit short on details.
Because it's fully documented in config.txt.
> I
Hi Junio,
On Wed, 13 Jul 2016, Junio C Hamano wrote:
> Moving of [64BIT_TIME] lazy_prereq to test-lib might be an upside if we
> were planning to add a test that depends on the system having or not
> having 64-bit timestamp elsewhere, but I do not think of a reason why
> such a new test cannot go
Big typo..
On Thu, Jul 14, 2016 at 5:56 PM, Duy Nguyen wrote:
> For giant-scale repos, you probably want something more efficient than
> a script like this. And the good thing is you have freedom to do
> whatever you want. You can run one daemon per repo, you can run one
> daemon per system... In
On Wed, Jul 13, 2016 at 11:59 PM, David Turner wrote:
> On 07/12/2016 02:24 PM, Duy Nguyen wrote:
>>
>> Just thinking out loud. I've been thinking about this more about this.
>> After the move from signal-based to unix socket for communication, we
>> probably are better off with a simpler design t
Hi Duy,
On Thu, 14 Jul 2016, Nguyễn Thái Ngọc Duy wrote:
> Helped-by: Jeff King
> Signed-off-by: Nguyễn Thái Ngọc Duy
This commit message is quite a bit short on details. I still fail to see
what use case this would benefit, and I already start to suspect that the
change would open a can of wo
Johannes Schindelin writes:
> Oh, and v14 has a bug that I reported already:
> http://article.gmane.org/gmane.comp.version-control.git/298949
These two lines are the most helpful kind of response to "What's
cooking" report. Highly appreciated.
The value of the report to me primarily is to make
Hi Peff,
sorry for the very, very late reply.
On Thu, 30 Jun 2016, Jeff King wrote:
> The ustar format only has room for 11 (or 12, depending on
> some implementations) octal digits for the size and mtime of
> each file. For values larger than this, we have to add pax
> extended headers to speci
Johannes Schindelin writes:
> + ret = add_cache_entry(ce, options);
> + if (refresh) {
>
> Should we really refresh, even if ret < 0?
As we stopped calling make_cache_entry() with REFRESH flag on, we
can change this not to refresh if we want to, and I think we can
skip refresh withou
Hi *,
is there a way, for example with some sort of pre-receive hook,
to prevent some files from being overwritten by a push?
Use case:
In some project, we use Flyway to manage the database schema,
and Jenkins to automatically build master’s HEAD after each
push (and install it, thus activating
Helped-by: Jeff King
Signed-off-by: Nguyễn Thái Ngọc Duy
---
The diff from v3 is mostly clarification in code and document.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 18623ee..d971334 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.tx
When reporting broken links between commits/trees/blobs, it would be
quite helpful at times if the user would be told how the object is
supposed to be reachable.
With the new --name-objects option, git-fsck will try to do exactly
that: name the objects in a way that shows how they are reachable.
If fsck_options->name_objects is initialized, and if it already has
name(s) for the object(s) that are to be the starting point(s) for
fsck_walk(), then that function will now add names for the objects
that were walked.
This will be highly useful for teaching git-fsck to identify root causes
for b
In many places, we refer to objects via their SHA-1s. Let's abstract
that into a function.
For the moment, it does nothing else than what we did previously: print
out the 40-digit hex string. But that will change over the course of the
next patches.
Signed-off-by: Johannes Schindelin
---
builti
When using experimental features (such as worktrees), it is quite
possible to end up with a repository that is a little bit corrupted. In
this developer's case, the auto gc run during interactive rebases in
worktrees completely messed up the reflogs.
The symptoms are broken links between commits/t
...and somehow I forgot to CC git@vger, g
On Thu, Jul 14, 2016 at 5:14 PM, Duy Nguyen wrote:
> Bug reports should always be in public (so people are aware of it)
> unless it's security exploit of course.
>
> I have not read this mail yet, but I will in a couple of hours, hopefully.
>
> On
With the following steps content from one file ends up in another file
by using 'git rebase' (and clobbers the original content).
It is rather straight forward and I discovered this behaviour when
trying to replay http://gitforteams.com/resources/rebasing.html .
The special thing is, that both f
When we tried to fix in 58461bd (t1308: do not get fooled by symbolic
links to the source tree, 2016-06-02) an obscure case where the user
cd's into Git's source code via a symbolic link, a regression was
introduced that affects all test runs on Windows.
The original patch introducing the test cas
Hi Junio,
On Tue, 12 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > This is the second iteration of the long-awaited re-roll of the attempt to
> > avoid spawning merge-recursive from the builtin am and use merge_recursive()
> > directly instead.
>
> This is actually the th
Hi Junio,
On Wed, 13 Jul 2016, Junio C Hamano wrote:
> * dt/index-helper (2016-07-06) 21 commits
> - index-helper: indexhelper.exitAfter config
> - trace: measure where the time is spent in the index-heavy operations
> - index-helper: optionally automatically run
> - index-helper: autorun mod
Hi Junio,
On Wed, 13 Jul 2016, Junio C Hamano wrote:
> * jc/renormalize-merge-kill-safer-crlf (2016-07-12) 2 commits
> - merge: avoid "safer crlf" during recording of merge results
I like the verbose commit message, it really makes it easier to understand
the issue as well as the solution. As t
Hi Junio,
On Wed, 13 Jul 2016, Junio C Hamano wrote:
> * js/t0006-for-v2.9.2 (2016-07-12) 1 commit
> - t0006: skip "far in the future" test when unsigned long is not long enough
>
> A test merged to v2.9.1 forgot that the feature it was testing
> would not work on a platform with 32-bit time_
Hi,
On Fri, 3 Jun 2016, Torsten Bögershausen wrote:
> On 06/03/2016 08:53 AM, Johannes Sixt wrote:
> > Am 03.06.2016 um 08:10 schrieb Jeff King:
> > > On Fri, Jun 03, 2016 at 08:05:56AM +0200, Johannes Sixt wrote:
> > >
> > > > > -name=$(pwd)/.gitconfig
> > > > > +name=$HOME/.gitconfig
>
Dr. Alex Morgan
Drift / regionsjef
Santander Bank Plc,
47-48 Piccadilly
PICCADILLY
W1J0DT
London, Storbritannia
Hei venn,
Jeg er Dr. Alex Morgan, fra Harlesden North West London, leder for regnskap
Revisjonen og formell senior programmerer sjef hos Deutsche bank, her i England
(Santander Bank P
Hi Mike,
On Thu, 14 Jul 2016, Mike Hommey wrote:
> On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:
> > Hi Junio,
> >
> > On Wed, 13 Jul 2016, Junio C Hamano wrote:
> >
> > > Does Travis CI testing have an option to run our tests on some
> > > 32-bit platforms?
> >
> > AFAI
On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:
> Hi Junio,
>
> On Wed, 13 Jul 2016, Junio C Hamano wrote:
>
> > Does Travis CI testing have an option to run our tests on some
> > 32-bit platforms?
>
> AFAIR Docker does not support 32-bit, and IIRC that's what Travis uses.
>
1 - 100 of 107 matches
Mail list logo
