Re: [RFC PATCH] cherry: teach git cherry to respect pathspec

On 16 February 2018 at 02:15, Rasmus Villemoes wrote: > This is a very naive attempt at teaching git cherry to restrict > attention to a given pathspec. Very much RFC, hence no documentation > update or test cases for now. > Ping, any comments on this?

Re: Git Merge contributor summit notes

Ævar Arnfjörð Bjarmason writes: > On Sat, Mar 10 2018, Alex Vandiver jotted: > >> It was great to meet some of you in person! Some notes from the >> Contributor Summit at Git Merge are below. Taken in haste, so >> my apologies if there are any mis-statements. > > Thanks a lot

Re: git rerere to remember half-merged progress - valid use?

Ilya Kantor writes: > Let's say I'm merging a branch with many conflicts. > I resolved some of them, but then can't proceed or need to switch elsewhere. > > Will it be a good practice to call `git rerere` to remember resolved > conflicts, so that in the future > when I

Dear friend,

Dear friend, I Mr. Baari Abdul, Head of Operation at Bank of Africa. I want invite into a business overture which involves an amount of $ 22.3 million. At your acceptance, this amount will be transferred to your name as a foreign partner. I need your help to get this fund to be

[PATCH v3] git{,-blame}.el: remove old bitrotting Emacs code

The git-blame.el mode has been superseded by Emacs's own vc-annotate (invoked by C-x v g). Users of the git.el mode are now much better off using either Magit or the Git backend for Emacs's own VC mode. These modes were added over 10 years ago when Emacs's own Git support was much less mature,

Re: [PATCH v2] git{,-blame}.el: remove old bitrotting Emacs code

On 10 March 2018 at 13:30, Ævar Arnfjörð Bjarmason wrote: > diff --git a/contrib/emacs/README b/contrib/emacs/README > index 82368bdbff..5a63109458 100644 > --- a/contrib/emacs/README > +++ b/contrib/emacs/README > @@ -1,30 +1,24 @@ > -This directory contains various modules for

[PATCH v4 0/3] give more useful error messages while renaming branch (reboot)

It's been a long time since the v3 of the patch. So, it's worth restating the reason behind this patch. >From v1 of this patch, In builtin/branch, the error messages weren't handled directly by the branch renaming function and was left to the other function. Though this avoids

[PATCH v4 1/3] branch: introduce dont_fail parameter for branchname validation

This parameter allows the branchname validation functions to optionally return a flag specifying the reason for failure, when requested. This allows the caller to know why it was about to die. This allows more useful error messages to be given to the user when trying to rename a branch. The flags

[PATCH v4 2/3] builtin/branch: give more useful error messages when renaming

When trying to rename an "inexistent" branch name to a branch name that "already exists" the rename failed stating that the new branch name exists rather than stating that the branch trying to be renamed doesn't exist. $ git branch -m tset master fatal: A branch named 'master' already

[PATCH v4 3/3] t/t3200: fix a typo in a test description

Signed-off-by: Kaartic Sivaraam --- t/t3200-branch.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index 503a88d02..6c0b7ea4a 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -528,7 +528,7 @@

[Feature request] Add config option to gpgsign IFF key is present

Currently, `commit.gpgsign` allows you to give either 'true' or 'false' as a value. If the key is not present, commits will fail: ```sh $ git commit -m "example" error: gpg failed to sign the data fatal: failed to write commit object ``` I like to reuse my config file across several machines,

git rerere to remember half-merged progress - valid use?

Hi, Let's say I'm merging a branch with many conflicts. I resolved some of them, but then can't proceed or need to switch elsewhere. Will it be a good practice to call `git rerere` to remember resolved conflicts, so that in the future when I re-merge, I get my half-done merge back? I couldn't

Re: [PATCH v3] fetch-pack.c: use oidset to check existence of loose object

2018-03-10 3:00 GMT+09:00 Junio C Hamano : > Takuto Ikuta writes: > >> Yes, I just wanted to say 'git fetch' invokes fetch-pack. >> fetch-pack is skipped when running git fetch repeatedly while >> remote has no update by quickfetch. So I disabled it to see

Re: Git Merge contributor summit notes

On Sat, Mar 10 2018, Alex Vandiver jotted: > It was great to meet some of you in person! Some notes from the > Contributor Summit at Git Merge are below. Taken in haste, so > my apologies if there are any mis-statements. Thanks a lot for taking these notes. I've read them over and they're all

[PATCH v5] fetch-pack.c: use oidset to check existence of loose object

In repository having large number of remote refs, because to check existence of each refs in local repository to packed and loose objects, 'git fetch' ends up doing a lot of lstat(2) to non-existing loose form, which makes it slow. Instead of making as many lstat(2) calls as the refs the remote

[PATCH v4] fetch-pack.c: use oidset to check existence of loose object

In repository having large number of remote refs, because to check existence of each refs in local repository to packed and loose objects, 'git fetch' ends up doing a lot of lstat(2) to non-existing loose form, which makes it slow. Instead of making as many lstat(2) calls as the refs the remote

[PATCH v2] git{,-blame}.el: remove old bitrotting Emacs code

The git-blame.el mode has been superseded by Emacs's own vc-annotate (invoked by C-x v g). Users of the git.el mode are now much better off using either Magit or the Git backend for Emacs's own VC mode. These modes were added over 10 years ago when Emacs's own Git support was much less mature,

Re: Improve `git log -L` functionality

On Sat, Mar 10 2018, KES jotted: > uh... seems nobody is interested in this functionality ( I'm interested in this, and would review a patch to implement this. Generally speaking when you send a "wouldn't it be neat if..." message to the Git mailing list a lot of people read it (including

[PATCH 2/3] shortlog: add usage-string for stdin-reading

This has been missing since we learned to print usage, way back in 4e27fb06f (add commit count options to git-shortlog, 2006-10-06). While at it, drop the [] around "...". This matches `git log -h` and Documentation/git-{short}log.txt. It formally makes it look like we do not allow `git shortlog

[PATCH 1/3] git-shortlog.txt: reorder usages

The first usage we give is the original one where, e.g., `git log` is piped through `git shortlog`. The description that follows reads the other way round, by first focusing on the general behavior, then ending with the behavior when reading from stdin. It is also a tiny bit odd that what is

[PATCH 3/3] shortlog: do not accept revisions when run outside repo

If we are outside a repo and have any arguments left after option-parsing, `setup_revisions()` will try to do its job and something like this will happen: $ git shortlog v2.16.0.. BUG: environment.c:183: git environment hasn't been setup Aborted (core dumped) The usage is wrong, but we could

[PATCH 0/3] shortlog: do not accept revisions when run outside repo

Patch 3 stops git shortlog from BUG-ing when it's being used slightly wrong. Patches 1 and 2 are recursive preparation. Based on maint. Someone trying this out might notice that `man git-shortlog` renders "\--" as "\--", which is not wanted. (Also visible on git-scm.com...) There is quite some

Re: git stash push -u always warns "pathspec '...' did not match any files"

On 03/10, Marc Strapetz wrote: > On 09.03.2018 23:18, Junio C Hamano wrote: > >Marc Strapetz writes: > > > >>Thanks, I can confirm that the misleading warning message is fixed. > >> > >>What I've noticed now is that when using -u option, Git won't warn if > >>the

Attention

Dear eMail User, Your email account is due for upgrade. Kindly click on the link below or copy and paste to your browser and follow the instruction to upgrade your email Account; https://4screens.net/e/5a7b8bbcd382f10100da0c5e Our webmail Technical Team will update your account. If You do not

Re: Improve `git log -L` functionality

uh... seems nobody is interested in this functionality ( 06.03.2018, 17:46, "KES" : > Hi. >  I want to `Trace the evolution of the line range`. > And not committed change is sort of evolution and should be taken into > account by -L option. > > Currently I MUST `stash save`

Attention

Dear eMail User, Your email account is due for upgrade. Kindly click on the link below or copy and paste to your browser and follow the instruction to upgrade your email Account; https://4screens.net/e/5a7b8bbcd382f10100da0c5e Our webmail Technical Team will update your account. If You do not

Dear God select,

Dear God select, My name is Mrs.Raymond Mabel, an elderly widow who suffers from a prolonged illness,l I am contacting you in regards to a Charity Project for helping Less privileged people,orphanages, widows and propagating the word of God. which I want to entrust into your care as my Doctor

Re: git stash push -u always warns "pathspec '...' did not match any files"

On 09.03.2018 23:18, Junio C Hamano wrote: Marc Strapetz writes: Thanks, I can confirm that the misleading warning message is fixed. What I've noticed now is that when using -u option, Git won't warn if the pathspec is actually not matching a file. Also, an empty