Re: [PATCH 2/2] read-cache: use time_t instead of unsigned long

Hi, On Mon, 12 Nov 2018, Carlo Marcelo Arenas Belón wrote: > There are still some more possible improvements around this code but > they are orthogonal to this change : > > * migrate to approxidate_careful or parse_expiry_date > * maybe make sure only approxidate are used for expiration > > Cha

Re: [PATCH 2/2] read-cache: use time_t instead of unsigned long

On Tue, Nov 13, 2018 at 12:49 AM Johannes Schindelin wrote: > On Mon, 12 Nov 2018, Carlo Marcelo Arenas Belón wrote: >> > > if time_t can't represent a valid time keep the indexes for failsafe > > Is this sentence incomplete? What are those "indexes"? the indexes that are created when core.splitI

Re: [PATCH v2 2/2] rebase: Implement --merge via git-rebase--interactive

Hi Phillip, On Mon, 12 Nov 2018, Phillip Wood wrote: > It's good to see these patches progressing, I've just got a couple of > comments related to Johannes' points below > > On 12/11/2018 16:21, Johannes Schindelin wrote: > > Hi Elijah, > > > > On Wed, 7 Nov 2018, Elijah Newren wrote: > > > >>

Re: Regression: rebase -C1 fails in master

Hi Phillip, On Mon, 12 Nov 2018, Phillip Wood wrote: > I've just tried running > > bin-wrappers/git rebase -C1 @^ > > and I get > > error: unknown switch `1' Darn. I think this is the same problem as the `-S` switch problem, but in reverse: the built-in rebase used to require an argument for

Re: [PATCH 2/2] read-cache: use time_t instead of unsigned long

Carlo Marcelo Arenas Belón writes: > There are still some more possible improvements around this code but > they are orthogonal to this change : > > * migrate to approxidate_careful or parse_expiry_date > * maybe make sure only approxidate are used for expiration > > Changes in v2: > * improved

Re: [PATCH v3] remote: add --save-to-push option to git remote set-url

Denton Liu writes: > This adds the --save-to-push option to `git remote set-url` such that > when executed, we move the remote.*.url to remote.*.pushurl and set > remote.*.url to the given url argument. > > For example, if we have the following config: > > [remote "origin"] >

Re: [PATCH 8/9] sha1-file: use loose object cache for quick existence check

On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote: > On Mon, Nov 12 2018, Ævar Arnfjörð Bjarmason wrote: > >> On Mon, Nov 12 2018, Jeff King wrote: >> >>> On Mon, Nov 12, 2018 at 05:01:02PM +0100, Ævar Arnfjörð Bjarmason wrote: >>> > There's some obvious hand-waving in the paragraphs above

Re: [PATCH 1/5] rebase -r: demonstrate bug with conflicting merges

Hi Junio, On Tue, 13 Nov 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > From: Johannes Schindelin > > > > When calling `merge` on a branch that has already been merged, that > > `merge` is skipped quietly, but currently a MERGE_HEAD file is being > > left

Re: [PATCH 4/5] built-in rebase --skip/--abort: clean up stale .git/ files

Hi Junio, On Tue, 13 Nov 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > From: Johannes Schindelin > > > > The scripted version of the rebase used to execute `git reset --hard` > > when skipping or aborting. When we ported this to C, we did update the > > w

Re: [RFC PATCH] Using no- for options instead of duplication

On Tue, Nov 13 2018, Junio C Hamano wrote: > A tangetn that somebody might want to tackle. It would be > nice if we had a tool that takes a grep expression (like > '^--no' and '^\[no-' above) and shows histograms of the ages > of lines that match. It might tell us that

Hello,

Good day, I wish to establish a charity foundation to help the poor in your country under your care, Can you help to build this project in your country? Please contact me through my email address for more details Remain blessed in the lord, Your Sister, Mrs. Gera Levin

Re: [PATCH 1/5] rebase -r: demonstrate bug with conflicting merges

Johannes Schindelin writes: >> For a trivially small change/fix like this, it is OK and even >> preferrable to make 1+2 a single step, as applying t/ part only to >> try to see the breakage (or "am"ing everything and then "diff | >> apply -R" the part outside t/ for the same purpose) is easy enou

Re: [PATCH 1/2] refs: show --exclude failure with --branches/tags/remotes=glob

Hi Junio, On Tue, 13 Nov 2018, Junio C Hamano wrote: > Rafael Ascensão writes: > > > The documentation of `--exclude=` option from rev-list and rev-parse > > explicitly states that exclude patterns *should not* start with 'refs/' > > when used with `--branches`, `--tags` or `--remotes`. > > > >

[PATCH 0/1] rebase: understand -C again, refactor

Phillip Wood reported a problem where the built-in rebase did not understand options like -C1, i.e. it did not expect the option argument. While investigating how to address this best, I stumbled upon OPT_PASSTHRU_ARGV (which I was so far happily unaware of). Instead of just fixing the -C bug, I

[PATCH 1/1] rebase: really just passthru the `git am` options

From: Johannes Schindelin Currently, we parse the options intended for `git am` as if we wanted to handle them in `git rebase`, and then reconstruct them painstakingly to define the `git_am_opt` variable. However, there is a much better way (that I was unaware of, at the time when I mentored Pra

Re: [PATCH 1/5] rebase -r: demonstrate bug with conflicting merges

Hi Junio, On Tue, 13 Nov 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> For a trivially small change/fix like this, it is OK and even > >> preferrable to make 1+2 a single step, as applying t/ part only to > >> try to see the breakage (or "am"ing everything and then "diff | >

Re: [PATCH 1/5] rebase -r: demonstrate bug with conflicting merges

Johannes Schindelin writes: > You misunderstand. In this case it is crucial to read the regression test > first. The fix does not make much sense before one understands the > condition under which the order of the code statements matters. I am not sure what you mean. It sounds as if you want to

Re: [PATCH 1/1] rebase: really just passthru the `git am` options

"Johannes Schindelin via GitGitGadget" writes: > However, there is a much better way (that I was unaware of, at the time > when I mentored Pratik to implement these options): OPT_PASSTHRU_ARGV. > It is intended for exactly this use case, where command-line options > want to be parsed into a separ

Re: [RFC PATCH] Using no- for options instead of duplication

Ævar Arnfjörð Bjarmason writes: > This doesn't spew out a histogram, but you can use the various "git > grep/blame" one-liners (https://www.google.nl/search?q=git+grep+blame) > plus shell one-liner to get something useful: > > git grep -e '^--no-' -e '^--\[no-' -n | perl -F':' -anpe '$_=`git

Re: [PATCH v3 1/1] protocol: advertise multiple supported versions

stead...@google.com writes: > + if (tmp_allowed_versions[0] != config_version) > + for (int i = 1; i < nr_allowed_versions; i++) > + if (tmp_allowed_versions[i] == config_version) { > + enum protocol_version swap = > +

Re: [PATCH] remote-curl: die on server-side errors

On Mon, Nov 12, 2018 at 02:44:56PM -0800, stead...@google.com wrote: > When a smart HTTP server sends an error message via pkt-line, > remote-curl will fail to detect the error (which usually results in > incorrectly falling back to dumb-HTTP mode). > > This patch adds a check in discover_refs()

Re: [PATCH] remote-curl: die on server-side errors

stead...@google.com writes: > When a smart HTTP server sends an error message via pkt-line, > remote-curl will fail to detect the error (which usually results in > incorrectly falling back to dumb-HTTP mode). OK, that is a valid thing to worry about. > > This patch adds a check in discover_refs(

[PATCH 0/1] mingw: use CreateHardLink() directly

This is another tidbit from the stash of Git for Windows' patches: it avoids loading the function address of CreateHardLink() at runtime. This was done in case we were running on a Windows version that does not support that function, but we no longer support any of these Windows versions. Johannes

[PATCH 1/1] mingw: use `CreateHardLink()` directly

From: Johannes Schindelin The function `CreateHardLink()` is available in all supported Windows versions (even since Windows XP), so there is no more need to resolve it at runtime. Helped-by: Max Kirillov Signed-off-by: Johannes Schindelin --- compat/mingw.c | 14 +- 1 file change

Re: [PATCH 04/10] fast-export: avoid dying when filtering by paths and old tags exist

On Mon, Nov 12, 2018 at 10:50:43PM +, brian m. carlson wrote: > On Sun, Nov 11, 2018 at 01:44:43AM -0500, Jeff King wrote: > > > + git fast-export --tag-of-filtered-object=rewrite --all -- bar > > > >output && > > > + grep -A 1 refs/tags/v0.0.0.0.0.0.1 output | grep -E ^from.0

Re: [PATCH 10/10] fast-export: add --always-show-modify-after-rename

On Mon, Nov 12, 2018 at 10:08:10AM -0800, Elijah Newren wrote: > > I would do: > > > >git log --raw $( > > git cat-file --batch-check='%(objectsize:disk) %(objectname)' > > --batch-all-objects | > > sort -rn | head -3 | > > awk '{print "--find-object=" $2 }' > >) > > > > I'

Re: [PATCH v2 2/2] branch: Mark and colorize a branch differently if it is checked out in a linked worktree

On Mon, Nov 12, 2018 at 06:07:18PM +, Rafael Ascensão wrote: > On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote: > > just adding a bunch of color variants. It would be nice if we could just > > do this with a run-time parse_color("bold red") or whatever, but we use > > these as static

[PATCH 1/1] do_git_config_sequence(): fall back to git_dir if commondir is NULL

From: Johannes Schindelin Just some defensive programming. Signed-off-by: Johannes Schindelin --- config.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config.c b/config.c index 4051e38823..279d0d7077 100644 --- a/config.c +++ b/config.c @@ -1676,6 +1676,8 @@ static int do_git_config_

Re: [PATCH 1/1] rebase: really just passthru the `git am` options

Hi Johannes Thanks for looking at this. Unfortunately using OPT_PASSTHRU_ARGV seems to break the error reporting Running bin/wrappers/git rebase --onto @ @^^ -Cbad Gives git encountered an error while preparing the patches to replay these revisions: 67f673aa4a580b9e407b1ca505abf1f

[PATCH 0/1] Some left-over add-on for bw/config-h

Back when bw/config-h was developed (and backported to Git for Windows), I came up with this patch. It seems to not be strictly necessary, but I like the safety of falling back to the Git directory when no common directory is configured (for whatever reason). Johannes Schindelin (1): do_git_conf

[PATCH 1/1] bundle: refuse to create empty bundle

From: =?UTF-8?q?Ga=C3=ABl=20Lhez?= When an user tries to create an empty bundle via `git bundle create ` where `` resolves to an empty list (for example, like `master..master`), the command fails and warns the user about how it does not want to create empty bundle. However, the `.lock` file was

[PATCH 0/1] bundle: fix issue when bundles would be empty

And yet another patch coming through Git for Windows... Gaël Lhez (1): bundle: refuse to create empty bundle bundle.c| 7 --- t/t5607-clone-bundle.sh | 4 2 files changed, 8 insertions(+), 3 deletions(-) base-commit: 8858448bb49332d353febc078ce4a3abcc962efe Published

Re: [PATCH 1/3] eoie: default to not writing EOIE section

On 11/12/2018 8:05 PM, Junio C Hamano wrote: Jonathan Nieder writes: Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension, 2018-10-10) Git defaults to writing the new EOIE section when writing out an index file. Usually that is a good thing because it improves threaded performance

What's cooking in git.git (Nov 2018, #04; Tue, 13)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes described

Re: [PATCH 1/3] read-cache: use shared perms when writing shared index

On Thu, 22 Jun 2017 12:51:54 -0700 Junio wrote: > > Let's fix that by using create_tempfile() instead of mks_tempfile() > > to create the shared index file. > > > > ... > > - fd = mks_tempfile(&temporary_sharedindex, > > git_path("sharedindex_XX")); > > + fd = create_tempfile(&tempo

Re: [PATCH 2/3] ieot: default to not writing IEOT section

On 11/12/2018 7:39 PM, Jonathan Nieder wrote: As with EOIE, popular versions of Git do not support the new IEOT extension yet. When accessing a Git repository written by a more modern version of Git, they correctly ignore the unrecognized section, but in the process they loudly warn

Re: [PATCH 3/3] index: do not warn about unrecognized extensions

On 11/12/2018 7:40 PM, Jonathan Nieder wrote: Documentation/technical/index-format explains: 4-byte extension signature. If the first byte is 'A'..'Z' the extension is optional and can be ignored. This allows gracefully introducing a new index extension without having to rely on

[RFC/PATCH] read-cache: write all indexes with the same permissions

Change the code that writes out the shared index to use create_tempfile() instead of mks_tempfile(); The create_tempfile() function is used to write out the main .git/index (via .git/index.lock) using lock_file(). The create_tempfile() function respects the umask, whereas the mks_tempfile() functi

Re: [PATCH 2/3] ieot: default to not writing IEOT section

On Tue, Nov 13, 2018 at 2:12 AM Jonathan Nieder wrote: > > Junio C Hamano wrote: > > > How about > > > > hint: ignoring an optional IEOT extension > > > > to make it clear that it is totally harmless? > > > > With that, we can add advise.unknownIndexExtension=false to turn all > > of them of

Re: [PATCH] Makefile: add pending semantic patches

On Fri, Nov 09, 2018 at 01:58:01PM -0800, Stefan Beller wrote: > On Thu, Nov 8, 2018 at 9:18 PM Junio C Hamano wrote: > > Are they wrong changes (e.g. a carelessly written read_cache() to > > read_index(&the_index) conversion may munge the implementation of > > read_cache(...) { return read_index(

[PATCH v4] commit: add a commit.allowEmpty config variable

From: tanushree27 when we cherrypick an existing commit it doesn't change anything and therefore it fails prompting to reset (skip commit) or commit using --allow-empty attribute and then continue. Add commit.allowEmpty configuration variable as a convenience to skip this process. Add tests to

Re: [PATCH] coccicheck: introduce 'pending' semantic patches

On Fri, Nov 09, 2018 at 04:10:52PM -0800, Stefan Beller wrote: > From: SZEDER Gábor > > Teach `make coccicheck` to avoid patches named "*.pending.cocci" and > handle them separately in a new `make coccicheck-pending` instead. > This means that we can separate "critical" patches from "FYI" patches

Re: [PATCH v2 2/2] rebase: Implement --merge via git-rebase--interactive

Hi Dscho, Thanks for the detailed review! I'll try to get back to all your comments, but for now I feel bad that I didn't see and respond to at least one sooner... On Mon, Nov 12, 2018 at 8:21 AM Johannes Schindelin wrote: > > Thank you for this pleasant read. I think there is still quite a bit

Re: [RFC/PATCH] read-cache: write all indexes with the same permissions

On Tue, Nov 13, 2018 at 4:32 PM Ævar Arnfjörð Bjarmason wrote: > I won't have time to finish this today, as noted in > https://public-inbox.org/git/874lcl2e9t@evledraar.gmail.com/ > there's a pretty major bug here in that we're now writing out literal > sharedindex_XX files. It's not the

Re: [PATCH 10/10] fast-export: add --always-show-modify-after-rename

On Tue, Nov 13, 2018 at 6:45 AM Jeff King wrote: > It is an expensive log command, but it's the same expense as running > fast-export, no? And I think maybe that is the disconnect. I would expect an expensive log command to generally be the same expense as running fast-export, yes. But I would e

[PATCH] po/it.po: Remove space between the dashes and start of an option's name in the Italian translation

This is a really trivial change, but it is quite annoying to see this diff --git a/po/it.po b/po/it.po index 908021944..4d87faeee 100644 --- a/po/it.po +++ b/po/it.po @@ -566,7 +566,7 @@ msgstr "è già in corso un'operazione di cherry-pick o di revert" #: sequencer.c:740 msgid "try \"git cherr

Re: [RFC/PATCH] read-cache: write all indexes with the same permissions

On Tue, Nov 13 2018, Duy Nguyen wrote: > On Tue, Nov 13, 2018 at 4:32 PM Ævar Arnfjörð Bjarmason > wrote: >> I won't have time to finish this today, as noted in >> https://public-inbox.org/git/874lcl2e9t@evledraar.gmail.com/ >> there's a pretty major bug here in that we're now writing out l

[PATCH v2 1/1] checkout: disambiguate dwim tracking branches and local files

When checkout dwim is added in [1], it is restricted to only dwim when certain conditions are met and fall back to default checkout behavior otherwise. It turns out falling back could be confusing. One of the conditions to turn git checkout frotz to git checkout -b frotz origin/frotz is

[PATCH v2 0/1] disambiguate dwim tracking branches and local files

v2 leaves "pathspec with wildcard" case alone. The behavior in this case remains as before. --no-guess is now made visible in "git checkout -h" and the man page. PS. Based on git-checkout.txt I don't think any user can work out that "git checkout branch --" can be used to disambiguate. And updat

Re: [RFC] cherry-pick notes to find out cherry-picks from the origin

On Wed, Oct 24, 2018 at 05:24:01AM -0700, Tejun Heo wrote: > Ping, thanks. Ping again. Any comments? Wasn't this the direction you guys were suggesting? Thanks. -- tejun

Git Test Coverage Report (Tuesday, Nov 13)

Here is the test coverage report for today. Thanks, -Stolee [1] https://dev.azure.com/git/git/_build/results?buildId=256&view=logs --- pu: a849d4c48bb308cdf3f9d7dc84251d92b4d7ff03 jch: e3cb78b4131db2f98330ff110525db31c6abff16 next: 17fedb746fde9e40924a6ce11c0976a097eb126b master: d166e6afe5f25

Re: [PATCH 2/3] ieot: default to not writing IEOT section

Hi again, Junio C Hamano wrote: > Then removing the message is throwing it with bathwater. First > think about which part of the message is confusiong and then make it > less confusing. > > How about > > hint: ignoring an optional IEOT extension > > to make it clear that it is totally harm

Re: [PATCH 2/3] ieot: default to not writing IEOT section

Hi, Ben Peart wrote: > On 11/12/2018 7:39 PM, Jonathan Nieder wrote: >> As with EOIE, popular versions of Git do not support the new IEOT >> extension yet. When accessing a Git repository written by a more >> modern version of Git, they correctly ignore the unrecognized section, >> but in the pr

Re: [PATCH 1/3] eoie: default to not writing EOIE section

Hi, Ben Peart wrote: > While I can understand the user confusion the warning about ignoring an > extension could cause I guess I'm a little surprised that people would see > it that often. To see the warning means they are running a new version of > git in the same repo as they are running an ol

[PATCH v2] checkout: print something when checking out paths

One of the problems with "git checkout" is that it does so many different things and could confuse people specially when we fail to handle ambiguation correctly. One way to help with that is tell the user what sort of operation is actually carried out. When switching branches, we always print some

Re: [PATCH v3 1/1] protocol: advertise multiple supported versions

On Mon, Nov 12, 2018 at 01:49:05PM -0800, stead...@google.com wrote: > diff --git a/protocol.c b/protocol.c > index 5e636785d1..54d2ab991b 100644 > --- a/protocol.c > +++ b/protocol.c > +void get_client_protocol_version_advertisement(struct strbuf *advert) > +{ > + int tmp_nr = nr_allowed_ver

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On 11/4/2018 6:44 PM, brian m. carlson wrote: +int hash_algo_by_name(const char *name) +{ + int i; + if (!name) + return GIT_HASH_UNKNOWN; + for (i = 1; i < GIT_HASH_NALGOS; i++) + if (!strcmp(name, hash_algos[i].name)) + return

Re: [PATCH v5 02/12] sha1-file: provide functions to look up hash algorithms

On Tue, Nov 13, 2018 at 7:42 PM Derrick Stolee wrote: > > On 11/4/2018 6:44 PM, brian m. carlson wrote: > > +int hash_algo_by_name(const char *name) > > +{ > > + int i; > > + if (!name) > > + return GIT_HASH_UNKNOWN; > > + for (i = 1; i < GIT_HASH_NALGOS; i++) > > +

Re: [PATCH] Makefile: use CXXFLAGS for linking fuzzers

On 2018.11.13 12:12, Junio C Hamano wrote: > stead...@google.com writes: > > > OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in > > CFLAGS causes lots of build warnings. Using separate CXXFLAGS avoids > > this. > > We are not a C++ shop, so allow me to show ignorance about h

[PATCH 1/1] win32: replace pthread_cond_*() with much simpler code

From: Loo Rong Jie The Win32 CONDITION_VARIABLE has better performance and is easier to maintain, as the code is a lot shorter now (the semantics of the CONDITION_VARIABLE matches the pthread_cond_t very well). Note: CONDITION_VARIABLE is not available in Windows XP and below, but the declared m

[PATCH 0/1] win32: modernize pthread_cond_*() shims

And yet another patch from Git for Windows' cache of treasures. It was challenging to emulate the functions related to pthread_cond_t as long as we tried to maintain support for Windows XP, which has nothing close to that feature. Now that we require Windows Vista or later, we can make use of the

[PATCH v5 0/3] range-diff fixes

Trivial updates since v4 addressing the feedback on that iteration. Hopefully this is the last one, range-diff with the last version: 1: 5399e57513 = 1: f225173f43 range-diff doc: add a section about output stability 2: e56975df6c = 2: 77804ac641 range-diff: fix regression in passing along d

[PATCH v5 1/3] range-diff doc: add a section about output stability

The range-diff command is already advertised as porcelain, but let's make it really clear that the output is completely subject to change, particularly when it comes to diff options such as --stat. Right now that option doesn't work, but fixing that is the subject of a later change. Signed-off-by:

[PATCH v5 2/3] range-diff: fix regression in passing along diff options

In 73a834e9e2 ("range-diff: relieve callers of low-level configuration burden", 2018-07-22) we broke passing down options like --no-patch, --stat etc. Fix that regression, and add a test asserting the pre-73a834e9e2 behavior for some of these diff options. As noted in a change leading up to this

[PATCH v5 3/3] range-diff: make diff option behavior (e.g. --stat) consistent

Make the behavior when diff options (e.g. "--stat") are passed consistent with how "diff" behaves. Before 73a834e9e2 ("range-diff: relieve callers of low-level configuration burden", 2018-07-22) running range-diff with "--stat" would produce stat output and the diff output, as opposed to how "diff

Re: What's cooking in git.git (Nov 2018, #04; Tue, 13)

On Tue, Nov 13 2018, Junio C Hamano wrote: > * ab/pack-tests-cleanup (2018-10-31) 3 commits > (merged to 'next' on 2018-11-03 at b4a39595bb) > + index-pack tests: don't leave test repo dirty at end > + pack-objects tests: don't leave test .git corrupt at end > + pack-objects test: modernize

Re: [PATCH 2/3] ieot: default to not writing IEOT section

On 11/13/2018 1:18 PM, Jonathan Nieder wrote: Hi, Ben Peart wrote: On 11/12/2018 7:39 PM, Jonathan Nieder wrote: As with EOIE, popular versions of Git do not support the new IEOT extension yet. When accessing a Git repository written by a more modern version of Git, they correctly ignore

Re: [PATCH 1/1] rebase: really just passthru the `git am` options

Hi Phillip, On Tue, 13 Nov 2018, Phillip Wood wrote: > Thanks for looking at this. Unfortunately using OPT_PASSTHRU_ARGV seems to > break the error reporting > > Running > bin/wrappers/git rebase --onto @ @^^ -Cbad > > Gives > git encountered an error while preparing the patches to repl

Re: Re* [PATCH v3 1/1] protocol: advertise multiple supported versions

On Mon, Nov 12, 2018 at 7:24 PM Junio C Hamano wrote: > > Stefan Beller writes: > > >> + if (have_advertised_versions_already) > >> + BUG(_("attempting to register an allowed protocol version > >> after advertisement")); > > > > If this is a real BUG (due to wrong program flo

Re: [PATCH v4] commit: add a commit.allowEmpty config variable

Hi, On Tue, 13 Nov 2018, Tanushree Tumane wrote: > From: tanushree27 > > when we cherrypick an existing commit it doesn't change anything and > therefore it fails prompting to reset (skip commit) or commit using > --allow-empty attribute and then continue. This is a nice paragraph, but it migh

Re: [PATCH 1/1] bundle: refuse to create empty bundle

On Tue, Nov 13, 2018 at 7:09 AM Gaël Lhez via GitGitGadget wrote: > > From: =?UTF-8?q?Ga=C3=ABl=20Lhez?= > > When an user tries to create an empty bundle via `git bundle create > ` where `` resolves to an empty list (for > example, like `master..master`), the command fails and warns the user > a

[PATCH v4 2/7] i18n: remote.c: mark error(...) messages for translation

Mark up the error(...) messages in remote.c for translation. The likes of "unable to push to unqualified destination" are relatively big parts of the UI, i.e. error messages shown when "git push" fails. I don't think any of these are plumbing, an the entire test suite passes when running the tests

[PATCH v4 7/7] push doc: document the DWYM behavior pushing to unqualified

Document the DWYM behavior that kicks in when pushing to an unqualified reference. This behavior was added in f88395ac23 ("Renaming push.", 2005-08-03) and f8aae12034 ("push: allow unqualified dest refspecs to DWIM", 2008-04-23), and somewhat documented in bb9fca80ce ("git-push: Update descriptio

[PATCH v4 6/7] push: test that doesn't DWYM if is unqualified

Add a test asserting that "git push origin :" where is a branch, tag, tree or blob in refs/remotes/* doesn't DWYM when is unqualified. This has never been the case, but there haven't been any tests for this behavior. See f88395ac23 ("Renaming push.", 2005-08-03), bb9fca80ce ("git-push: Update de

[PATCH v4 3/7] push: improve the error shown on unqualified push

Improve the error message added in f8aae12034 ("push: allow unqualified dest refspecs to DWIM", 2008-04-23), which before this change looks like this: $ git push avar v2.19.0^{commit}:newbranch -n error: unable to push to unqualified destination: newbranch The destination refspec neith

[PATCH v4 0/7] fixes for unqualified push

I've finally re-rolled this. There wasn't consensus for the change to add DWYM behavior to refs/remotes/*, so I've dropped it, 7/7 is still there testing the current behavior of what we do with that now, since we didn't have any tests for that. This should address all feedback on v3, except I have

[PATCH v4 5/7] push: add an advice on unqualified push

Add an advice to the recently improved error message added in f8aae12034 ("push: allow unqualified dest refspecs to DWIM", 2008-04-23). Now with advice.pushUnqualifiedRefName=true (on by default) we show a hint about how to proceed: $ ./git-push avar v2.19.0^{commit}:newbranch -n error: T

[PATCH v4 4/7] push: move unqualified refname error into a function

A follow-up change will extend this error message with the advice facility. Doing so would make the indentation too deeply nested for comfort. So let's split this into a helper function. There's no changes to the wording here. Just code moving & re-indentation, and re-flowing the "TRANSLATORS" com

[PATCH v4 1/7] remote.c: add braces in anticipation of a follow-up change

The CodingGuidelines say "When there are multiple arms to a conditional and some of them require braces, enclose even a single line block in braces for consistency.". Fix the code in match_explicit() to conform. While I'm at it change the if/else if/else in guess_ref() to use braces. This is not c

Re: [PATCH 1/1] rebase: really just passthru the `git am` options

Hi Johannes On 13/11/2018 19:21, Johannes Schindelin wrote: Hi Phillip, On Tue, 13 Nov 2018, Phillip Wood wrote: Thanks for looking at this. Unfortunately using OPT_PASSTHRU_ARGV seems to break the error reporting Running bin/wrappers/git rebase --onto @ @^^ -Cbad Gives git encoun

[PATCH v3] index-pack: add ability to disable SHA-1 collision check

Add a new core.checkCollisions setting. On by default, it can be set to 'false' to disable the check for existing objects in sha1_object(). As noted in the documentation being added here this is done out of paranoia about future SHA-1 collisions and as a canary (redundant to "git fsck") for local

Re: Migration to Git LFS inflates repository multiple times

On Mon, 12 Nov 2018 at 00:47, Mateusz Loskot wrote: > > Hi, > > I'm posting here for the first time and I hope it's the right place to ask > questions about Git LFS. > > TL;TR: Is this normal a repository migrated to Git LFS inflates multiple times > and how to deal with it? FYI, answers to my qu

Re: [PATCH 1/1] bundle: refuse to create empty bundle

Hello, I don't know why I receive these message (and especially now given the time at which I pushed this) but I suppose someone (Johannes Schindelin ?) probably pushed back my original commit from git for windows github to GIT git repository. If you think "bundle: cleanup lock files on error" is

[PATCH] push: change needlessly ambiguous example in error

Change an example push added in b55e677522 ("push: introduce new push.default mode "simple"", 2012-04-24) to always mean the same thing whether the current setting happens to be "simple" or not. This error is only emitted under "simple", but message is explaining to the user that they can get two

Re: [PATCH 2/3] ieot: default to not writing IEOT section

Hi again, Ben Peart wrote: > On 11/13/2018 1:18 PM, Jonathan Nieder wrote: >> Ben Peart wrote: >>> Why introduce a new setting to disable writing the IEOT extension instead of >>> just using the existing index.threads setting? If index.threads=1 then the >>> IEOT extension isn't written which (I

Donation

A Donation Of 1 Million British Pounds To You In Good Faith

Re: [PATCH 1/1] bundle: refuse to create empty bundle

On Tue, Nov 13, 2018 at 12:33 PM Gaël Lhez wrote: > > Hello, > > I don't know why I receive these message (and especially now given the time > at which I pushed this) but I suppose someone (Johannes Schindelin ?) > probably pushed back my original commit from git for windows github to GIT > git

Re: [PATCH v4] commit: add a commit.allowEmpty config variable

On Tue, Nov 13 2018, Johannes Schindelin wrote: [Comments on the v4 patch also inline, found it easier to reply just to this one] > On Tue, 13 Nov 2018, Tanushree Tumane wrote: > >> From: tanushree27 >> >> when we cherrypick an existing commit it doesn't change anything and >> therefore it fai

[PATCH] diff: align move detection error handling with other options

This changes the error handling for the options --color-moved-ws and --color-moved-ws to be like the rest of the options. Move the die() call out of parse_color_moved_ws into the parsing of command line options. As the function returns a bit field, change its signature to return an unsigned instea

rebase-in-C stability for 2.20

On Tue, Nov 13 2018, Phillip Wood wrote: > Hi Johannes > > On 13/11/2018 19:21, Johannes Schindelin wrote: >> Hi Phillip, >> >> On Tue, 13 Nov 2018, Phillip Wood wrote: >> >>> Thanks for looking at this. Unfortunately using OPT_PASSTHRU_ARGV seems to >>> break the error reporting >>> >>> Running

Re: [PATCH] push: change needlessly ambiguous example in error

On Tue, Nov 13 2018, Matthieu Moy wrote: > Ævar Arnfjörð Bjarmason" wrote: > >> Let's use "git push HEAD" which always means push the current >> branch name to that remote, instead of "git push >> " which will do that under "simple", but is not >> guaranteed to do under "upstream". > > Probab

Re: [PATCH] push: change needlessly ambiguous example in error

Ævar Arnfjörð Bjarmason" wrote: > Let's use "git push HEAD" which always means push the current > branch name to that remote, instead of "git push > " which will do that under "simple", but is not > guaranteed to do under "upstream". Probably a good idea indeed. One potential objection though

Re: [PATCH] remote-curl: die on server-side errors

On 2018.11.13 12:02, Junio C Hamano wrote: > stead...@google.com writes: > > > When a smart HTTP server sends an error message via pkt-line, > > remote-curl will fail to detect the error (which usually results in > > incorrectly falling back to dumb-HTTP mode). > > > > This patch adds a check in d

Re: git-scm.com GUI client links

+cc: git@vger.kernel.org, git-secur...@googlegroups.com -> bcc Hi! Paul J Sanchez wrote: > Over the weekend I saw a link to a Mac git client I had not seen > before: Aurees. When I went to the linked site to download a copy, > my antivirus software (Sophos) warned me that it contains malware. >

Re: [PATCH] remote-curl: die on server-side errors

On 2018.11.13 09:26, Jeff King wrote: > On Mon, Nov 12, 2018 at 02:44:56PM -0800, stead...@google.com wrote: > > > When a smart HTTP server sends an error message via pkt-line, > > remote-curl will fail to detect the error (which usually results in > > incorrectly falling back to dumb-HTTP mode).

Re: [PATCH] remote-curl: die on server-side errors

On 2018.11.13 23:30, Junio C Hamano wrote: > stead...@google.com writes: > > > When a smart HTTP server sends an error message via pkt-line, > > remote-curl will fail to detect the error (which usually results in > > incorrectly falling back to dumb-HTTP mode). > > OK, that is a valid thing to wo

Re: [PATCH v3 1/1] protocol: advertise multiple supported versions

On 2018.11.13 13:01, Junio C Hamano wrote: > stead...@google.com writes: > > > Currently the client advertises that it supports the wire protocol > > version set in the protocol.version config. However, not all services > > support the same set of protocol versions. When connecting to > > git-rece

Re: [PATCH v3 1/1] protocol: advertise multiple supported versions

On 2018.11.13 19:28, SZEDER Gábor wrote: > On Mon, Nov 12, 2018 at 01:49:05PM -0800, stead...@google.com wrote: > > > diff --git a/protocol.c b/protocol.c > > index 5e636785d1..54d2ab991b 100644 > > --- a/protocol.c > > +++ b/protocol.c > > > +void get_client_protocol_version_advertisement(struct

how often do you check in and with what tool(s)?

Hello, i use Git Bash and check in very frequently. it appears there is a range from "extreme often" to "extreme very seldom". Examples: {me, extreme often, Windows} very granular, with a brief yet appropriate comment [like narrating a story] per commit-i change a few lines of code, Alt+Tab to

Re: [PATCH 02/10] git-fast-export.txt: clarify misleading documentation about rev-list args

On Sat, Nov 10, 2018 at 11:17 PM Elijah Newren wrote: > > On Sat, Nov 10, 2018 at 10:36 PM Jeff King wrote: > > > > On Sat, Nov 10, 2018 at 10:23:04PM -0800, Elijah Newren wrote: > > > > > Signed-off-by: Elijah Newren > > > --- > > > Documentation/git-fast-export.txt | 3 ++- > > > 1 file chang

  1   2   3   >