> I was going to point you to the recent thread in
>
> http://public-inbox.org/git/87ziclb2pa@gmail.com/
>
> but I see you already participated there. So if your mail here is
> "here's a summary of how HEAD/head don't quite work", then OK, that
> might be handy. But I think the ultimate res
Hi Martin,
>From the sound of it you really just want to revert the merge of the
pull requests. A really good description of options for this is at
https://git-scm.com/blog/2010/03/02/undoing-merges.html
There is also a section there about bringing the changes back in at a
future date, depending
On Tue, Jul 11, 2017 at 07:24:07AM +0200, Johannes Sixt wrote:
> Am 11.07.2017 um 02:05 schrieb brian m. carlson:
> > I have tried compiling Git with a C++ compiler, so that I could test
> > whether that was a viable alternative for MSVC in case its C++ mode
> > supported features its C mode did no
Hi,
Brandon Williams wrote:
> Convert grep to use 'struct repository' which enables recursing into
> submodules to be handled in-process.
\o/
This will be even nicer with the changes described at
https://public-inbox.org/git/20170706202739.6056-1-sbel...@google.com/.
Until then, I fear it will
Brandon Williams writes:
> Have the index state which is stored in 'the_repository' be a pointer to
> the in-core instead 'the_index'. This makes it easier to begin
> transitioning more parts of the code base to operate on a 'struct
> repository'.
>
> Signed-off-by: Brandon Williams
> ---
> se
On Tue, Jul 11, 2017 at 5:00 PM, Jonathan Nieder wrote:
> /* The main repository */
> -static struct repository the_repo;
> +static struct repository the_repo = { .index = &the_index };
https://public-inbox.org/git/20170710070342.txmlwwq6gvjkw...@sigill.intra.peff.net/
specifically said we'd no
On Tue, Jul 11, 2017 at 3:04 PM, Brandon Williams wrote:
> + if (repo_submodule_init(&submodule, superproject, path))
> + return 0;
What happens if we go through the "return 0", do we rather want to
print an error ?
> + /* add objects to alternates */
> + add_to_
Hi,
Brandon Williams wrote:
> Have the index state which is stored in 'the_repository' be a pointer to
> the in-core instead 'the_index'. This makes it easier to begin
> transitioning more parts of the code base to operate on a 'struct
> repository'.
>
> Signed-off-by: Brandon Williams
> ---
>
On Tue, Jul 11, 2017 at 3:04 PM, Brandon Williams wrote:
> Have 'repo_read_index()' behave more like the other read_index family of
> functions and don't discard the index if it has already been populated.
instead rely on the quick return of read_index_from which has
/* istate->initialized c
Brandon Williams wrote:
> Have 'repo_read_index()' behave more like the other read_index family of
> functions and don't discard the index if it has already been populated.
>
> Signed-off-by: Brandon Williams
> ---
> repository.c | 2 --
> 1 file changed, 2 deletions(-)
How did you discover thi
Conceptually the file order as set with command line -O or via the config
'diff.orderFile' is interesting to both the author (when I run a quick git
diff locally) as well as reviewer (a patch floating on the mailing list),
so it is not just the author who should be responsible for getting their
co
The option -G of p4 (python marshal output) gives more context about the
data being output. That's useful when using the command "change -o" as
we can distinguish between warning/error line and real change description.
Some p4 triggers in the server side generate some warnings when
executed. Unfor
For starters, let me say that I consider myself a mere advanced
beginner Git user, and I haven`t used Perforce ever before (did some
reading now), but still, for what it`s worth, here are my thoughts,
please bare with me :)
Do feel free to correct me if I miss something.
On 11/07/2017 19:39, L
On Tue, Jul 11, 2017 at 3:04 PM, Brandon Williams wrote:
> Convert grep to use 'struct repository' which enables recursing into
> submodules to be handled in-process.
>
> Signed-off-by: Brandon Williams
> ---
> Documentation/git-grep.txt | 7 -
> builtin/grep.c | 390
> +--
On Tue, Jul 11, 2017 at 12:48 PM, Jonathan Tan wrote:
> Teach sha1_file to invoke a hook whenever a blob is requested and
> unavailable but is promised. The hook is a shell command that can be
> configured through "git config"; this hook takes in a list of hashes and
> writes (if successful) the c
Hi Luke,
My bad as I didn't check that case.
It was p4CmdList as you said. the default value of the new field
skip_info (set to True) ignores any info messages. and the script is
waiting for a valid message.
If I set it to False, then it does return an info entry and it accepts
the submit change
Nikolay Shustov wrote:
> With Perforce, I can have multiple changelists opened, that group the
> changed files as needed.
>
> With Git I cannot seem to finding the possibility to figure out how to
> achieve the same result. And the problem is that putting change sets
> on different Git branches (or
On Tue, Jul 11, 2017 at 12:48 PM, Jonathan Tan wrote:
> In a subsequent patch, sha1_file will need to append object names in the
> form of "unsigned char *" to oid arrays. Teach sha1-array support for
> that.
>
> Signed-off-by: Jonathan Tan
This breaks the oid/sha1 barrier?
I would have expecte
Have 'repo_read_index()' behave more like the other read_index family of
functions and don't discard the index if it has already been populated.
Signed-off-by: Brandon Williams
---
repository.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/repository.c b/repository.c
index edca90740..8e60
Convert grep to use 'struct repository' which enables recursing into
submodules to be handled in-process.
Signed-off-by: Brandon Williams
---
Documentation/git-grep.txt | 7 -
builtin/grep.c | 390 +
cache.h| 1 -
gi
Have the index state which is stored in 'the_repository' be a pointer to
the in-core instead 'the_index'. This makes it easier to begin
transitioning more parts of the code base to operate on a 'struct
repository'.
Signed-off-by: Brandon Williams
---
setup.c | 1 +
1 file changed, 1 insertion(+
This series utilizes the new 'struct repository' in order to convert grep to be
able to recurse into submodules in-process much like how ls-files was converted
to recuse in-process. The result is a much smaller code footprint due to not
needing to compile an argv array of options to be used when l
On Tue, Jul 11, 2017 at 12:48 PM, Jonathan Tan wrote:
> Currently, Git does not support repos with very large numbers of blobs
> or repos that wish to minimize manipulation of certain blobs (for
> example, because they are very large) very well, even if the user
> operates mostly on part of the re
Greetings My Dear Friend,
Before I introduce myself, I wish to inform you that this letter is
not a hoax mail and I urge you to treat it serious. This letter must
come to you as a big surprise, but I believe it is only a day that
people meet and become great friends and business partners. Please I
Stefan Beller writes:
>> At the implementation level, it should have a
>> hashtable (lazily populated) for all the objects in a single
>> $GIT_OBJECT_DIRECTORY, grafts/replace info, and a set of pointers to
>> other object-store instances that are its alternate object stores.
>
> So one repositor
Kaartic Sivaraam writes:
> In the context of "git merge" the meaning of an "empty message"
> is one that contains no line of text. This is not in line with
> "git commit" where an "empty message" is one that contains only
> whitespaces and/or signed-off-by lines. This could cause surprises
> to u
> On Tue, Jul 11, 2017 at 1:39 PM, Lars Schneider
> wrote:
>>
>>> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:
>>>
>>> Hi,
>>> I have been recently struggling with migrating my development workflow
>>> from Perforce to Git, all because of the following thing:
>>>
>>> I have to work on seve
Hi,
I will choose a bit of a less diplomatic path here. Instead of trying to
tell you how you can make git fit your needs, I would say that you
shouldn't. I've two arguments:
1.
It's always painful when you try to use a tool in some way it's not
intended or used to work. If you're doing something
On Tue, Jul 11, 2017 at 11:46 AM, Junio C Hamano wrote:
> Brandon Williams writes:
>
>>> the_repository -> the_object_store
>>> but the object store is a complex beast having different hash tables
>>> for the different alternates.
>>
>> After looking at the patch and some of the comments he
Teach sha1_file to invoke a hook whenever a blob is requested and
unavailable but is promised. The hook is a shell command that can be
configured through "git config"; this hook takes in a list of hashes and
writes (if successful) the corresponding objects to the repo's local
storage.
This is mean
In a subsequent patch, sha1_file will need to append object names in the
form of "unsigned char *" to oid arrays. Teach sha1-array support for
that.
Signed-off-by: Jonathan Tan
---
sha1-array.c | 7 +++
sha1-array.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/sha1-array.c b/sha1-ar
Currently, Git does not support repos with very large numbers of blobs
or repos that wish to minimize manipulation of certain blobs (for
example, because they are very large) very well, even if the user
operates mostly on part of the repo, because Git is designed on the
assumption that every blob r
These patches are part of a set of patches implementing partial clone,
as you can see here:
https://github.com/jonathantanmy/git/tree/partialclone
In that branch, clone with batch checkout works, as you can see in the
README. The code and tests are generally done, but some patches are
still missi
On Tue, Jul 11, 2017 at 12:13:59PM -0700, Stefan Beller wrote:
> > There are other die calls hidden deeper. For instance:
> >
> > $ git -c core.ignorecase=foo help config
> > fatal: bad numeric config value 'foo' for 'core.ignorecase': invalid unit
> >
> > Those ones are hard to fix without ch
On Tue, Jul 11, 2017 at 12:08 PM, Jeff King wrote:
> On Tue, Jul 11, 2017 at 12:05:01PM -0700, Stefan Beller wrote:
>
>> > diff --git a/builtin/help.c b/builtin/help.c
>> > index 334a8494a..c42dfc9e9 100644
>> > --- a/builtin/help.c
>> > +++ b/builtin/help.c
>> > @@ -273,7 +273,7 @@ static int git
On Tue, Jul 11, 2017 at 12:05:01PM -0700, Stefan Beller wrote:
> > diff --git a/builtin/help.c b/builtin/help.c
> > index 334a8494a..c42dfc9e9 100644
> > --- a/builtin/help.c
> > +++ b/builtin/help.c
> > @@ -273,7 +273,7 @@ static int git_help_config(const char *var, const char
> > *value, void *
On Tue, Jul 11, 2017 at 10:53 AM, Jeff King wrote:
> On Tue, Jul 11, 2017 at 03:49:21PM +0100, Peter Krefting wrote:
>
>> That's fine. However, when trying to look for help, it is not that useful:
>>
>> $ git config --help
>> error: malformed value for branch.autosetuprebase
>> fatal: bad co
Brandon Williams writes:
>> the_repository -> the_object_store
>> but the object store is a complex beast having different hash tables
>> for the different alternates.
>
> After looking at the patch and some of the comments here I think that
> this is probably the best approach with a few t
Thank you for #3.
As for 1+2, the documentation says:
"Each line in gitattributes file is of form:
pattern attr1 attr2 ...
...
When the pattern matches the path in question, the attributes listed
on the line are given to the path."
My understanding is that to have the bunch of the files in the
On 07/11, Martin Ågren wrote:
> On 11 July 2017 at 00:50, Brandon Williams wrote:
> > On 07/10, Martin Ågren wrote:
> >> Commit 74866d75 ("git: make super-prefix option", 2016-10-07) introduced
> >> SUPPORT_SUPER_PREFIX as a builtin flag without documenting it in
> >> api-builtin.txt. The next pat
On Tue, Jul 11, 2017 at 11:10 AM, Nikolay Shustov
wrote:
> Thank you for the explanation. The example about backend and frontend
> is relevant even though I normally have to deal with more layers at
> the same time.
>
> However, in my case I have the thing that you have already tried to
> address,
Thank you for the explanation. The example about backend and frontend
is relevant even though I normally have to deal with more layers at
the same time.
However, in my case I have the thing that you have already tried to
address, partially: the changes always align with file boundaries BUT
not wit
On Tue, 2017-07-11 at 09:03 -0700, Junio C Hamano wrote:
> But does it even be useful to enable it?
Just for the note, I thought it was considered useful (at least to
someone) due to it's presence in the sample script.
On Tue, 2017-07-11 at 09:03 -0700, Junio C Hamano wrote:
> But does it even be useful to enable it? The commented out "git
> status" output already lists the modified paths, so I do not think
> anything is gained by adding 'diff --cached --name-status' there.
The script *doesn't* add the output of
On 07/10, Stefan Beller wrote:
> On Fri, Jul 7, 2017 at 9:50 AM, Junio C Hamano wrote:
> > Ben Peart writes:
> >
> >> For more API/state design purity, I wonder if there should be an
> >> object_store structure that is passed to each of the object store APIs
> >> instead of passing the repository
Thank you for the idea, however I am having troubles with basically
maintaining the uncommitted groups of files: I would prefer the clear
distinction that "those files belong to feature A" and "these files
belong to feature B", before I commit anything. Committing separately
every change for featur
On Tue, Jul 11, 2017 at 03:49:21PM +0100, Peter Krefting wrote:
> That's fine. However, when trying to look for help, it is not that useful:
>
> $ git config --help
> error: malformed value for branch.autosetuprebase
> fatal: bad config variable 'branch.autosetuprebase' in file '.git/config
> The way of Git is that a commit (snapshot) by definition describes a
> set of files (The set of all files in the project). So If you need two
> features
> there at the same time, you probably want it in the same commit.
Thank you, but if I wanted these two features to be in the same
commit, I w
> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:
>
> Hi,
> I have been recently struggling with migrating my development workflow
> from Perforce to Git, all because of the following thing:
>
> I have to work on several features in the same code tree parallel, in
> the same Perforce workspace
Nikolay Shustov writes:
> I have to work on several features in the same code tree parallel, in
> the same Perforce workspace. The major reason why I cannot work on one
> feature then on another is just because I have to make sure that the
> changes in the related areas of the product play togeth
-Original Message-
On July 11, 2017 11:45 AM Nikolay Shustov wrote:
>I have been recently struggling with migrating my development workflow from
>Perforce to Git, all because of the following thing:
>I have to work on several features in the same code tree parallel, in the same
>Perforce
On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov
wrote:
> Hi,
> I have been recently struggling with migrating my development workflow
> from Perforce to Git, all because of the following thing:
>
> I have to work on several features in the same code tree parallel, in
> the same Perforce workspace
Jeff King writes:
>> I see you CC'ed Peff who's passionate in this area, so these patches
>> are in good hands already ;-) I briefly skimmed your patches myself,
>> and did not spot anything glaringly wrong.
>
> Heh, I don't think of "paging tag output" as one of my passions, but you
> may be rig
Junio C Hamano writes:
> Peter Eckersley writes:
>
>> I have a local git repo that's in some weird state where changes
>> appear to be detected by "git diff" and prevent operations like "git
>> checkout" from switching branches, but those changes are not removed
>> by a "git reset --hard" or "gi
Kaartic Sivaraam writes:
> I'm was trying to ask, "Is there any way to change the second example
> (diff --name-status) to make it work with "commit --amend" so that it
> could be uncommented by default ?"
But does it even be useful to enable it? The commented out "git
status" output already li
Peter Eckersley writes:
> I have a local git repo that's in some weird state where changes
> appear to be detected by "git diff" and prevent operations like "git
> checkout" from switching branches, but those changes are not removed
> by a "git reset --hard" or "git stash".
>
> Here's an example
Lars Schneider writes:
> Thanks for the explanation! I looked at the Git release calendar [1] and
> realized that 2.14-rc0 is scheduled for this Thursday. My assumption was
> that either on this date 2.14 will be cut from the tip of master or master
> would not change significantly after the rc0
Jeff King writes:
> On Tue, Jul 11, 2017 at 10:28:08AM +0200, Lars Schneider wrote:
>
>> > On 11 Jul 2017, at 00:48, Junio C Hamano wrote:
>> >
>> > * ls/filter-process-delayed (2017-06-30) 7 commits
>> > (merged to 'next' on 2017-07-05 at a35e644082)
>> > + convert: add "status=delayed" to fi
Hi,
I have been recently struggling with migrating my development workflow
from Perforce to Git, all because of the following thing:
I have to work on several features in the same code tree parallel, in
the same Perforce workspace. The major reason why I cannot work on one
feature then on another
Ben Peart writes:
>> If this patch can survive a few releases without complaint,
>> then we can feel more confident that designated initializers
>> are widely supported by our user base. It also is an
>> indication that other C99 features may be supported, but not
>> a guarantee (e.g., gcc had d
So, I set the wrong value for a configuration option, and git tells me:
$ git config branch.autoSetupRebase false
$ git log
error: malformed value for branch.autosetuprebase
fatal: bad config variable 'branch.autosetuprebase' in file '.git/config' at
line 24
That's fine. However, when t
Sorry, forgot to add the RFC suffix to [PATCH]. Please consider it's
presence.
--
Kaartic
Add a simple example that replaces an outdated example
that was removed. This ensures that there's at the least
a simple example that illustrates what could be done
using the hook just by enabling it.
Also, update the documentation.
Signed-off-by: Kaartic Sivaraam
---
Documentation/githooks.txt
In the context of "git merge" the meaning of an "empty message"
is one that contains no line of text. This is not in line with
"git commit" where an "empty message" is one that contains only
whitespaces and/or signed-off-by lines. This could cause surprises
to users who are accustomed to the meanin
The sample hook to prepare the commit message before
a commit allows users to opt-in to add the sign-off
to the commit message. The sign-off is added at a place
that isn't consistent with the "-s" option of "git commit".
Further, it could go out of view in certain cases.
Add the sign-off in a way
Add a simple example that replaces an outdated example
that was removed. This ensures that there's at the least
a simple example that illustrates what could be done
using the hook just by enabling it.
Also, update the documentation.
Signed-off-by: Kaartic Sivaraam
---
Documentation/githooks.txt
It's always nice to have named variables instead of
positional variables as they communicate their purpose
well.
Appropriately name the positional variables of the hook
to make it easier to see what's going on.
Signed-off-by: Kaartic Sivaraam
---
templates/hooks--prepare-commit-msg.sample | 9 +
Prepare the 'preare-commit-msg' sample script for
upcoming changes. Preparation includes removal of
an example that has outlived it's purpose. The example
is the one that comments the "Conflicts:" part of a
merge commit message. It isn't relevant anymore as
it's done by default since 261f315b ("mer
On Tue, Jul 11, 2017 at 03:50:39PM +0200, Martin Ågren wrote:
> > Would it makes sense to just have git-tag respect pager.tag in listing
> > mode, and otherwise ignore it completely?
>
> Yes. I doubt anyone would notice, and no-one should mind with the
> change (famous last words).
>
> It does m
On Tue, Jul 11, 2017 at 03:46:08PM +0200, Martin Ågren wrote:
> > Can this ever trigger in execv_dashed_external()? We should only get
> > there if get_builtin() returned NULL in the first place. Otherwise, we'd
> > run and exited via handle_builtin().
>
> I can trigger it with this:
>
> $ git -
On 11 July 2017 at 12:19, Jeff King wrote:
> On Mon, Jul 10, 2017 at 11:55:13PM +0200, Martin Ågren wrote:
>
>> Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such
>> as "Vim: Warning: Output is not to a terminal" and a garbled terminal.
>> A user who makes use of `git tag -a` an
On 11 July 2017 at 12:41, Jeff King wrote:
> On Mon, Jul 10, 2017 at 11:55:19PM +0200, Martin Ågren wrote:
>
>> diff --git a/builtin/tag.c b/builtin/tag.c
>> index e0f129872..e96ef7d70 100644
>> --- a/builtin/tag.c
>> +++ b/builtin/tag.c
>> @@ -446,6 +446,8 @@ int cmd_tag(int argc, const char **ar
On 11 July 2017 at 12:37, Jeff King wrote:
> On Mon, Jul 10, 2017 at 11:55:16PM +0200, Martin Ågren wrote:
>
>> +void setup_auto_pager(const char *cmd, int def)
>> +{
>> + if (use_pager != -1)
>> + return;
>
> I think you probably also want to return early here if pager_in_use()
>
On 11 July 2017 at 12:24, Jeff King wrote:
> On Mon, Jul 10, 2017 at 11:55:15PM +0200, Martin Ågren wrote:
>
>> To allow individual builtins to make more informed decisions about when
>> to respect `pager.foo`, introduce a flag IGNORE_PAGER_CONFIG. If the flag
>> is set, do not check `pager.foo`.
On Mon, 2017-07-10 at 13:02 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
> > I made an attempt to make the second example work with amending
> > with the aim of making it suitable for usage out of the box. It
> > seems that it's not easy to make it work as the status of a file
>
Note: Re-attempting to send mail due to rejection
On Mon, 2017-07-10 at 16:13 +0100, Ramsay Jones wrote:
>
> Again, s/signature/sign-off/g, or similar (including subject line).
>
Thanks! Forgot that in the course of splitting the patches and
modifying them.
--
Kaartic
On Mon, 2017-07-10 at 16:13 +0100, Ramsay Jones wrote:
>
> Again, s/signature/sign-off/g, or similar (including subject line).
>
Thanks! Forgot that in the course of splitting the patches and
modifying them.
On Mon, Jul 10, 2017 at 03:42:14PM -0700, Junio C Hamano wrote:
> > A review would be much appreciated. Comments on the way I
> > structured the series would be just as welcome as ones on the
> > final result.
>
> I see you CC'ed Peff who's passionate in this area, so these patches
> are in good
On Mon, Jul 10, 2017 at 11:55:20PM +0200, Martin Ågren wrote:
> The previous patch introduced `pager.tag.list`. Its default was to use
> the value of `pager.tag` or, if that was also not set, to fall back to
> "off".
>
> Change that fallback value to "on". Let the default value for
> `pager.tag`
On Mon, Jul 10, 2017 at 11:55:19PM +0200, Martin Ågren wrote:
> diff --git a/builtin/tag.c b/builtin/tag.c
> index e0f129872..e96ef7d70 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -446,6 +446,8 @@ int cmd_tag(int argc, const char **argv, const char
> *prefix)
>
> argc = parse_
On Mon, Jul 10, 2017 at 11:55:18PM +0200, Martin Ågren wrote:
> Use the mechanisms introduced in two earlier patches to ignore
> `pager.tag` in git.c and let the `git tag` builtin handle it on its own.
>
> This is in preparation for the next patch, where we will want to handle
> slightly differen
On Mon, Jul 10, 2017 at 11:55:16PM +0200, Martin Ågren wrote:
> +void setup_auto_pager(const char *cmd, int def)
> +{
> + if (use_pager != -1)
> + return;
I think you probably also want to return early here if pager_in_use()
is true. If a script runs "git tag -l", you wouldn't wan
On Mon, Jul 10, 2017 at 11:55:15PM +0200, Martin Ågren wrote:
> To allow individual builtins to make more informed decisions about when
> to respect `pager.foo`, introduce a flag IGNORE_PAGER_CONFIG. If the flag
> is set, do not check `pager.foo`. This applies to two code-paths -- one
> in run_bui
On Mon, Jul 10, 2017 at 11:55:13PM +0200, Martin Ågren wrote:
> Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such
> as "Vim: Warning: Output is not to a terminal" and a garbled terminal.
> A user who makes use of `git tag -a` and `git tag -l` will probably
> choose not to confi
On Tue, Jul 11, 2017 at 11:18:17AM +0200, Lars Schneider wrote:
> Thanks for the explanation! I looked at the Git release calendar [1] and
> realized that 2.14-rc0 is scheduled for this Thursday. My assumption was
> that either on this date 2.14 will be cut from the tip of master or master
> would
> On 11 Jul 2017, at 11:11, Jeff King wrote:
>
> On Tue, Jul 11, 2017 at 10:28:08AM +0200, Lars Schneider wrote:
>
>>> On 11 Jul 2017, at 00:48, Junio C Hamano wrote:
>>>
>>> * ls/filter-process-delayed (2017-06-30) 7 commits
>>> (merged to 'next' on 2017-07-05 at a35e644082)
>>> + convert: a
On Tue, Jul 11, 2017 at 10:28:08AM +0200, Lars Schneider wrote:
> > On 11 Jul 2017, at 00:48, Junio C Hamano wrote:
> >
> > * ls/filter-process-delayed (2017-06-30) 7 commits
> > (merged to 'next' on 2017-07-05 at a35e644082)
> > + convert: add "status=delayed" to filter process protocol
> > +
On Tue, Jul 11, 2017 at 03:25:36AM -0400, Jeff King wrote:
> Annoyingly, the lock code interacts badly with daemonizing because that
> latter will fork to a new process. So the simple solution like:
>
> diff --git a/builtin/gc.c b/builtin/gc.c
> index 2ba50a287..79480124a 100644
> --- a/builtin/g
On 3 July 2017 at 23:57, Miguel Torroja wrote:
> The option -G of p4 (python marshal output) gives more context about the
> data being output. That's useful when using the command "change -o" as
> we can distinguish between warning/error line and real change description.
>
> Some p4 triggers in th
> On 11 Jul 2017, at 00:48, Junio C Hamano wrote:
>
> * ls/filter-process-delayed (2017-06-30) 7 commits
> (merged to 'next' on 2017-07-05 at a35e644082)
> + convert: add "status=delayed" to filter process protocol
> + convert: refactor capabilities negotiation
> + convert: move multiple file f
On Tue, Jul 11, 2017 at 10:20:43AM +0200, Torsten Bögershausen wrote:
> > No problem. I actually think it would be interesting if Git could
> > somehow detect and warn about this situation. But the obvious way to do
> > that would be to re-run the clean filter directly after checkout. And
> > doin
On 11/07/17 09:34, Jeff King wrote:
On Tue, Jul 11, 2017 at 12:31:25AM -0700, Peter Eckersley wrote:
I did try to test that hypothesis by editing the filter to be a no-op,
but it's possible I go that wrong. My apologies for bugging the list!
Actually I like this kind of feedback, to see how
On Tue, Jul 11, 2017 at 12:35:50AM -0700, Bryan Turner wrote:
> That's a few of the reasons we've switched over. I'd imagine most
> hosting providers take a similarly "hands on" approach to controlling
> their GC. Beyond a certain scale, it seems almost unavoidable. Git
> never has more than a rep
On Mon, Jul 10, 2017 at 07:08:38PM +0200, René Scharfe wrote:
> > So I think it's a true mechanical conversion, but I have to admit the
> > original is confusing. Without digging I suspect it's correct, though,
> > just because a simple bug here would mean that our ewah bitmaps totally
> > don't w
On Mon, Jul 10, 2017 at 01:15:40PM -0700, kinchit raja wrote:
> Bugs Details:
>
> Git checkout case Insensitive branch name compare
Right, this is known. Branch names (and all ref names) are case
sensitive in Git. Storage on a case-insensitive filesystem may lead to
confusion if you mix the case
On Mon, Jul 10, 2017 at 9:45 PM, Andreas Krey wrote:
> On Thu, 06 Jul 2017 10:01:05 +, Bryan Turner wrote:
>
>> I also want to add that Bitbucket Server 5.x includes totally
>> rewritten GC handling. 5.0.x automatically disables auto GC in all
>> repositories and manages it explicitly, an
On Tue, Jul 11, 2017 at 12:31:25AM -0700, Peter Eckersley wrote:
> I did try to test that hypothesis by editing the filter to be a no-op,
> but it's possible I go that wrong. My apologies for bugging the list!
No problem. I actually think it would be interesting if Git could
somehow detect and wa
On Thu, Jul 06, 2017 at 10:01:05AM -0700, Bryan Turner wrote:
> I also want to add that Bitbucket Server 5.x includes totally
> rewritten GC handling. 5.0.x automatically disables auto GC in all
> repositories and manages it explicitly, and 5.1.x fully removes use of
> "git gc" in favor of running
I did try to test that hypothesis by editing the filter to be a no-op,
but it's possible I go that wrong. My apologies for bugging the list!
On 11 July 2017 at 00:06, Jeff King wrote:
> On Tue, Jul 11, 2017 at 06:15:17AM +0200, Torsten Bögershausen wrote:
>
>> On 11/07/17 01:45, Peter Eckersley w
[Updating the subject since I think this really is a bug].
On Tue, Jul 11, 2017 at 06:45:53AM +0200, Andreas Krey wrote:
> > I also want to add that Bitbucket Server 5.x includes totally
> > rewritten GC handling. 5.0.x automatically disables auto GC in all
> > repositories and manages it explici
1 - 100 of 102 matches
Mail list logo
