Re: bug: HEAD vs. head on case-insensitive filesystems

> 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

Re: Dropping a merge from history -- rebase or filter-branch or ...?

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

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

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

Re: [PATCH 3/3] grep: recurse in-process using 'struct repository'

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

Re: [PATCH 2/3] setup: have the_repository use the_index

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

Re: [PATCH 2/3] setup: have the_repository use the_index

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 = _index }; https://public-inbox.org/git/20170710070342.txmlwwq6gvjkw...@sigill.intra.peff.net/

Re: [PATCH 3/3] grep: recurse in-process using 'struct repository'

On Tue, Jul 11, 2017 at 3:04 PM, Brandon Williams wrote: > + if (repo_submodule_init(, 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 */ > +

Re: [PATCH 2/3] setup: have the_repository use the_index

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

Re: [PATCH 1/3] repo_read_index: don't discard the index

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 /*

Re: [PATCH 1/3] repo_read_index: don't discard the index

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

[PATCH] RFC: Introduce '.gitorderfile'

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

[PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

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.

Re: "groups of files" in Git?

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,

Re: [PATCH 3/3] grep: recurse in-process using 'struct repository'

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 - >

Re: [RFC PATCH 3/3] sha1_file: add promised blob hook support

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 >

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

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

Re: "groups of files" in Git?

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

Re: [RFC PATCH 2/3] sha1-array: support appending unsigned char hash

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

[PATCH 1/3] repo_read_index: don't discard the index

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

[PATCH 3/3] grep: recurse in-process using 'struct repository'

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

[PATCH 2/3] setup: have the_repository use the_index

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

[PATCH 0/3] Convert grep to recurse in-process

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

Re: [RFC PATCH 1/3] promised-blob, fsck: introduce promised blobs

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 >

Greetings to you

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

Re: [RFC/WIP PATCH] object store classification

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.

Re: [PATCH] commit & merge: modularize the empty message validator

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.

Re: "groups of files" in Git?

> 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

Re: "groups of files" in Git?

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

Re: [RFC/WIP PATCH] object store classification

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

[RFC PATCH 3/3] sha1_file: add promised blob hook support

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

[RFC PATCH 2/3] sha1-array: support appending unsigned char hash

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

[RFC PATCH 1/3] promised-blob, fsck: introduce promised blobs

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

[RFC PATCH 0/3] Partial clone: promised blobs (formerly "missing blobs")

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

Re: git config --help not functional on bad config

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

Re: git config --help not functional on bad config

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

Re: git config --help not functional on bad config

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

Re: git config --help not functional on bad config

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 >>

Re: [RFC/WIP PATCH] object store classification

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

Re: "groups of files" in Git?

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

Re: [PATCH 1/7] api-builtin.txt: document SUPPORT_SUPER_PREFIX

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 > >>

Re: "groups of files" in Git?

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

Re: "groups of files" in Git?

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

Re: [PATCH 4/4] hook: add a simple first example

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.

Re: [PATCH 4/4] hook: add a simple first example

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

Re: [RFC/WIP PATCH] object store classification

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

Re: "groups of files" in Git?

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

Re: git config --help not functional on bad config

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

Re: "groups of files" in Git?

> 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

Re: "groups of files" in Git?

> 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 >

Re: "groups of files" in Git?

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

RE: "groups of files" in Git?

-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

Re: "groups of files" in Git?

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 >

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

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

Re: Weirdness with git change detection

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

Re: [PATCH 4/4] hook: add a simple first example

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

Re: Weirdness with git change detection

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

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

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

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

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) >> > +

"groups of files" in Git?

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

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

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

git config --help not functional on bad config

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

Re: [PATCH/RFC] commit & merge: modularize the empty message validator

Sorry, forgot to add the RFC suffix to [PATCH]. Please consider it's presence. -- Kaartic

[PATCH 4/4] hook: add a simple first example

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

[PATCH] commit & merge: modularize the empty message validator

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

[PATCH 3/4] hook: add sign-off using "interpret-trailers"

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

[PATCH 4/4] hook: add a simple first example

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

[PATCH 2/4] hook: name the positional variables

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 ---

[PATCH 1/4] hook: cleanup script

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

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

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

Re: [PATCH 2/7] git.c: let builtins opt for handling `pager.foo` themselves

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

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

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

Re: [PATCH 6/7] tag: make git tag -l consider new config `pager.tag.list`

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,

Re: [PATCH 3/7] git.c: provide setup_auto_pager()

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

Re: [PATCH 2/7] git.c: let builtins opt for handling `pager.foo` themselves

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

Re: [PATCH 4/4] hook: add a simple first example

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

Re: [PATCH 3/4] hook: add signature using "interpret-trailers"

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

Re: [PATCH 3/4] hook: add signature using "interpret-trailers"

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.

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

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

Re: [PATCH 7/7] tag: make git tag -l use pager by default

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`

Re: [PATCH 6/7] tag: make git tag -l consider new config `pager.tag.list`

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 =

Re: [PATCH 5/7] tag: handle `pager.tag`-configuration within the builtin

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

Re: [PATCH 3/7] git.c: provide setup_auto_pager()

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

Re: [PATCH 2/7] git.c: let builtins opt for handling `pager.foo` themselves

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

Re: [PATCH 0/7] tag: more fine-grained pager-configuration

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

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

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 >

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

> 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

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

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

[PATCH] gc: run pre-detach operations under lock

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 > ---

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

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.

Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

> 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:

Re: Weirdness with git change detection

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 > >

Re: Weirdness with git change detection

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

Re: Flurries of 'git reflog expire'

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

Re: [PATCH] use DIV_ROUND_UP

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

Re: Bug: Git checkout case Insensitive branch name compare

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

Re: Flurries of 'git reflog expire'

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

Re: Weirdness with git change detection

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

Re: Flurries of 'git reflog expire'

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

Re: Weirdness with git change detection

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,

[BUG] detached auto-gc does not respect lock for 'reflog expire', was Re: Flurries of 'git reflog expire'

[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

  1   2   >