[no subject]

Herzlichen Glückwunsch, Sie haben € 650.000,00 bei den monatlichen Gewinnspielen von Euro Millions / Google Promo am März 2018 gewonnen. Kontaktieren Sie unseren Schadenversicherer E-Mail: eurosilli...@gmail.com 1. Vollständiger Name: 2. Adresse: 3. Sex: 4. Alter: 5. Beruf: 6. Telefon:

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

On 13 March 2018 at 22:46, Junio C Hamano wrote: > Martin Ågren writes: > >> in order to decide whether we should read from stdin. (So yes, after >> this patch, we will still silently ignore stdin for confused usage such >> as `git log v2.15.0.. | git

[GSoC][PATCH 1/2] git-ci: add .pylintrc file

Hello Mr. Diamand, I have added the .pylintrc configuration file into the repository. It still reports several warnings as you said. Here is the link for my build: https://travis-ci.org/VietHTran/git/jobs/353135582 Do you think I should edit the .pylintrc in order for it to also ignore the

[GSoC][PATCH 2/2] git-ci: update .pylintrc to ignore current warning

pylint's check for unused variables, global statements, redefined builtins, undefined loop variables, and unused imports are disabled. The current configuration allows git-p4.py to pass the check in Travis CI in my forked repository. Here is the link for the successful built:

Re: [PATCH v5 04/13] csum-file: add CSUM_KEEP_OPEN flag

On 3/13/2018 5:42 PM, Junio C Hamano wrote: Derrick Stolee writes: On 2/26/2018 9:32 PM, Derrick Stolee wrote: This patch is new to the series due to the interactions with the lockfile API and the hashfile API. I need to ensure the hashfile writes the hash value at the end

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Sergey, On 13/03/2018 17:10, Sergey Organov wrote: > > > Hi Sergey, I've been following this discussion from the sidelines, > > though I haven't had time to study all the posts in this thread in > > detail. I wonder if it would be helpful to think of rebasing a merge as > > merging the

[GSoC][PATCH] git-ci: use pylint to analyze the git-p4 code

Hello Mr. Diamand, I see. Initially, I also thought of using .pylintrc but I don’t know which error should be ignored and which should be fixed so I decided to adhere 100% to the convention and fix each type of errors in different patches. Thank you for your help, Viet Signed-off-by: Viet

Re: [PATCH] Documentation/githooks: Clarify the behavior of post-checkout hook

Hi, Magne Land wrote: > From: Magne Land > > This can happen when using 'git rebase -i’: > could not detach HEAD > > Based on discovering this Stack Overflow discussion: > https://stackoverflow.com/questions/25561485/git-rebase-i-with-squash-cannot-detach-head > --- >

Re: allow "~" to be present in a tag name

Hi Michal, Michal Novotny wrote: > currently, if I try to create a tag that has tilde "~" in name, an > error is raised. E.g. > > $ git tag rpkg-util-1.4~rc1 > fatal: 'rpkg-util-1.4~rc1' is not a valid tag name. As Ævar mentioned, this is disallowed to prevent a collision with Git's revision

Re: Opinions on changing add/add conflict resolution?

On Tue, Mar 13, 2018 at 4:14 PM, Elijah Newren wrote: > > Someone in the future might hate us if they use conflictstyle=diff3, > and have a recursive merge, FWIW I already always use diff3 style and see the nested markers, and I already hate it, so you are no worse off ;-)

REPLY BACK PLEASE

-- Hello dear, How are you doing today? I got your contact from a directory and picked interest to communicate you by faith, though we have not met before, I believe we can achieve something together. My husband died few years ago after battling with brain cancer, before his death, he deposited

Re: Opinions on changing add/add conflict resolution?

On Tue, Mar 13, 2018 at 3:56 PM, Jonathan Nieder wrote: > Elijah Newren wrote: > >> However, my question here about what to write to the working tree for >> a rename/rename(2to1) conflict in one particular corner case still >> remains. Should a two-way merge be performed even

RE: recent glob expansion breakage on Windows?

I do not remember what version I was using before. I am suddenly wondering if I previously sent single patches instead of using wildcard (which works fine). The only person I have found doing patch series here on windows uses the directory method (put patch files there, list directory name on

Re: Opinions on changing add/add conflict resolution?

On Tue, Mar 13, 2018 at 3:52 PM, Junio C Hamano wrote: > Elijah Newren writes: > >> However, my question here about what to write to the working tree for >> a rename/rename(2to1) conflict in one particular corner case still >> remains. > > Hmph, is it a bad

Re: Opinions on changing add/add conflict resolution?

Hi, Elijah Newren wrote: > However, my question here about what to write to the working tree for > a rename/rename(2to1) conflict in one particular corner case still > remains. Should a two-way merge be performed even if it may result in > nested sets of conflict markers, or is that a

Re: Opinions on changing add/add conflict resolution?

Elijah Newren writes: > However, my question here about what to write to the working tree for > a rename/rename(2to1) conflict in one particular corner case still > remains. Hmph, is it a bad idea to model this after what recursive merge strategy does? I think what is written

Re: Opinions on changing add/add conflict resolution?

On Tue, Mar 13, 2018 at 3:26 PM, Junio C Hamano wrote: > Elijah Newren writes: > >> Cool, thanks for the context. I'm happy to go down this path, but >> there is one question I'd like your opinion on: what if the >> intermediate content merges have conflicts

你好！你好吗？

Re: Opinions on changing add/add conflict resolution?

Elijah Newren writes: > Cool, thanks for the context. I'm happy to go down this path, but > there is one question I'd like your opinion on: what if the > intermediate content merges have conflicts themselves? If that > question isn't clear, let me be more precise... I think

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

Ævar Arnfjörð Bjarmason writes: > I sent a v3 a few days ago which addressed this, it's at > 20180310184545.16950-1-ava...@gmail.com Thanks, I did look at that version but did not act on it immediately and then forgot about it. Queued.

Re: Fwd: Opinions on changing add/add conflict resolution?

Elijah Newren writes: > As currently implemented, yes. However, I was more concerned the idea > of handling files differently based on whether or not they were > similar, rather than on what the precise definition of "similar" is > for this context. > > As far as the

Re: git-log bug: --grep and -number args are at odds

On Tue, Mar 13 2018, Alexander Mills jotted: > $ git log -50 ### I get 50 results > > $ git log -50 --grep="*" ### I get a lot more than 50... > > shouldn't `-50` minimize the results length to 50 or fewer? On what git version? On my 2.16.2.804.g6dcf76e118 on git.git this works as

Re: [PATCH v4 20/35] upload-pack: introduce fetch server command

On 03/13, Jonathan Tan wrote: > On Wed, 28 Feb 2018 15:22:37 -0800 > Brandon Williams wrote: > > > +output = *section > > +section = (acknowledgments | packfile) > > + (flush-pkt | delim-pkt) > > + > > +acknowledgments = PKT-LINE("acknowledgments" LF) > > +

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

Martin Ågren writes: > in order to decide whether we should read from stdin. (So yes, after > this patch, we will still silently ignore stdin for confused usage such > as `git log v2.15.0.. | git shortlog v2.16.0..`. But at least that does > not crash.) $ git log -p

Re: [PATCH v5 04/13] csum-file: add CSUM_KEEP_OPEN flag

Derrick Stolee writes: > On 2/26/2018 9:32 PM, Derrick Stolee wrote: >> This patch is new to the series due to the interactions with the lockfile API >> and the hashfile API. I need to ensure the hashfile writes the hash value at >> the end of the file, but keep the file

git-log bug: --grep and -number args are at odds

$ git log -50 ### I get 50 results $ git log -50 --grep="*" ### I get a lot more than 50... shouldn't `-50` minimize the results length to 50 or fewer? -alex -- Alexander D. Mills ! New cell phone number: (415)766-8243 alexander.d.mi...@gmail.com

Re: [PATCH v4 12/35] serve: introduce git-serve

On 03/02, Junio C Hamano wrote: > Brandon Williams writes: > > > + Capabilities > > +~~ > > + > > +There are two different types of capabilities: normal capabilities, > > +which can be used to to convey information or alter the behavior of a > > +request, and

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

Martin Ågren wrote: > On 13 March 2018 at 20:56, Jonathan Nieder wrote: >> Martin Ågren wrote: >>> (So yes, after >>> this patch, we will still silently ignore stdin for confused usage such >>> as `git log v2.15.0.. | git

Re: [PATCH v4 12/35] serve: introduce git-serve

On 03/02, Junio C Hamano wrote: > Brandon Williams writes: > > +static int is_command(const char *key, struct protocol_capability > > **command) > > +{ > > + const char *out; > > + > > + if (skip_prefix(key, "command=", )) { > > + struct protocol_capability *cmd

Re: [PATCH v4 13/35] ls-refs: introduce ls-refs server command

On 03/02, Junio C Hamano wrote: > Brandon Williams writes: > > > + ls-refs > > +- > > + > > +`ls-refs` is the command used to request a reference advertisement in v2. > > +Unlike the current reference advertisement, ls-refs takes in arguments > > +which can be used to

Re: [PATCH v4 13/35] ls-refs: introduce ls-refs server command

On 03/05, Jeff King wrote: > On Mon, Mar 05, 2018 at 10:21:55AM -0800, Brandon Williams wrote: > > > > Hmm, so this would accept stuff like "refs/heads/*/foo" but quietly > > > ignore the "/foo" part. > > > > Yeah that's true...this should probably not do that. Since > > "refs/heads/*/foo"

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

On 13 March 2018 at 20:56, Jonathan Nieder wrote: > Hi, > > Martin Ågren wrote: > >> (So yes, after >> this patch, we will still silently ignore stdin for confused usage such >> as `git log v2.15.0.. | git shortlog

[PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git

Add a INSTALL_SYMLINKS option which if enabled, changes the default hardlink installation method to one where the relevant binaries in libexec/git-core are symlinked back to ../../bin, instead of being hardlinked. This new option also overrides the behavior of the existing NO_*_HARDLINKS

[PATCH 2/3] Makefile: add a gitexecdir_relative variable

This variable will be e.g. "libexec/git-core" if gitexecdir=/tmp/git/libexec/git-core is given. It'll be used by a subsequent change. This is stolen from the yet-to-be integrated (needs resubmission) "Makefile: add Perl runtime prefix support" patch on the mailing list. See

[PATCH 1/3] Makefile: fix broken bindir_relative variable

Change the bindir_relative variable to work like the other *_relative variables, which are computed as a function of the absolute path. Before this change, supplying e.g. bindir=/tmp/git/binaries to the Makefile would yield a bindir_relative of just "bin", as opposed to "binaries". This logic was

[PATCH 0/3] Makefile: add a INSTALL_SYMLINKS option

On Tue, Mar 13 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> Related to this, I came across this bug report >> https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is >> wondering why we're installing N copies of the git binary, presumably >>

Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?

On Tue, Mar 13 2018, Stan Hu jotted: > To be clear, this is how I think we got into this state: > > We have worktrees that are created to squash and rebase a branch. They were > left around inadvertently for one reason or another. > > Since we were using git v2.14.3, a git gc would prune

[GSoC] [PATCH] test: avoid pipes in git related commands for test suite

This patch removes the necessity of pipes in git related commands for test suite. Exit code of the upstream in a pipe is ignored so, it's use should be avoided. The fix for this is to write the output of the git command to a file and test the exit codes of both the commands being linked by

[PATCH] Documentation/githooks: Clarify the behavior of post-checkout hook

From: Magne Land This can happen when using 'git rebase -i’: could not detach HEAD Based on discovering this Stack Overflow discussion: https://stackoverflow.com/questions/25561485/git-rebase-i-with-squash-cannot-detach-head --- Documentation/githooks.txt | 4 +++- 1

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

Hi, Martin Ågren wrote: > 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

Re: [PATCH v4 01/35] pkt-line: introduce packet_read_with_status

On 03/13, Jonathan Tan wrote: > On Wed, 28 Feb 2018 15:22:18 -0800 > Brandon Williams wrote: > > > + if (len < 0) { > > die("protocol error: bad line length character: %.4s", linelen); > > - if (!len) { > > + } else if (!len) { > >

Re: [PATCH v4 04/35] upload-pack: convert to a builtin

On 03/13, Jonathan Tan wrote: > On Wed, 28 Feb 2018 15:22:21 -0800 > Brandon Williams wrote: > > > In order to allow for code sharing with the server-side of fetch in > > protocol-v2 convert upload-pack to be a builtin. > > > > Signed-off-by: Brandon Williams

Re: [PATCH v4 01/35] pkt-line: introduce packet_read_with_status

On Wed, 28 Feb 2018 15:22:18 -0800 Brandon Williams wrote: > + if (len < 0) { > die("protocol error: bad line length character: %.4s", linelen); > - if (!len) { > + } else if (!len) { > packet_trace("", 4, 0); > - return

RE: Why don't we symlink libexec/git-core/* to bin/git?

On March 13, 2018 2:37 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > Related to this, I came across this bug report > > https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is > > wondering why we're installing N copies of the git binary,

Re: [RFC 0/4] ref-filter: remove printing from formatting logic

Hi Olga On 13 March 2018 at 11:25, Оля Тележная wrote: > The main idea of the patch is, if you want to format the output by > ref-filter, you should have an ability to work with errors by yourself > if you want to. > So I decided not to touch signature of

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

Martin Ågren writes: > 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

Re: [RFC 3/4] ref-filter: change parsing function error handling

On 13 March 2018 at 11:16, Olga Telezhnaya wrote: > Continue removing any printing from ref-filter formatting logic, > so that it could be more general. > > Change the signature of parse_ref_filter_atom() by changing return value, > adding previous return value to

Re: [RFC 2/4] ref-filter: add return value && strbuf to handlers

On 13 March 2018 at 11:16, Olga Telezhnaya wrote: > -static void append_atom(struct atom_value *v, struct ref_formatting_state > *state) > +static int append_atom(struct atom_value *v, struct ref_formatting_state > *state, > + struct strbuf *err) >

Re: [RFC 1/4] ref-filter: start adding strbufs with errors

On 13 March 2018 at 11:16, Olga Telezhnaya wrote: > This is a first step in removing any printing from > ref-filter formatting logic, so that it could be more general. > Everything would be the same for show_ref_array_item() users. > But, if you want to deal with errors

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

Takuto Ikuta writes: > +struct loose_object_iter { > + struct oidset *loose_object_set; > + struct ref *refs; > +}; > + > +/* > + * If the number of refs is not larger than the number of loose objects, > + * this function stops inserting and returns false. > + */ >

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

On Tue, Mar 13 2018, Junio C. Hamano jotted: > Martin Ågren writes: > >>> +Emacs's own support for Git got better than what was offered by these >>> +modules, or was superseded by popular 3rd-party Git modes such as >>> +Magit. >> >> This somehow reads like "Emacs's own

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

Martin Ågren writes: >> +Emacs's own support for Git got better than what was offered by these >> +modules, or was superseded by popular 3rd-party Git modes such as >> +Magit. > > This somehow reads like "Emacs's own support ... was superseded ...". > Maybe that's what

Re: Why don't we symlink libexec/git-core/* to bin/git?

Ævar Arnfjörð Bjarmason writes: > Related to this, I came across this bug report > https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is > wondering why we're installing N copies of the git binary, presumably > they're building with NO_INSTALL_HARDLINKS. > ... > But

Re: Bug, git rebase -i does not abort correctly

On Friday 26 January 2018 02:54 PM, Duy Nguyen wrote: > > Sort of. It smells bad design to me when a mistake can easily become a > feature. But with your help, I think I should be able to disable this > feature on my local build. Thanks. > In case you're still facing this issue, it just struck

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Johannes Schindelin writes: > So essentially, what your cherry-pick'able commits are is a way to store > what rerere would have stored (i.e. the set of merge conflicts together > with their resolution)? If rerere would have stored, I wouldn't have separate band-aid

Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?

To be clear, this is how I think we got into this state: We have worktrees that are created to squash and rebase a branch. They were left around inadvertently for one reason or another. Since we were using git v2.14.3, a git gc would prune dangling objects because it never saw that a worktree

Re: Opinions on changing add/add conflict resolution?

On Mon, Mar 12, 2018 at 10:30 PM, Junio C Hamano wrote: > While I do not think it is a bad idea to add an optional way to write the > contents of conflicted stages out to separate files, I do not think it is a > good idea to change what happens to add/add conflict by default.

Re: Rename of file is causing changes to be lost

On Tue, Mar 13, 2018 at 11:51 AM, Elijah Newren wrote: > Anyway, I recorded this at > https://bugs.chromium.org/p/git/issues/detail?id=11. Sorry I don't > have a workaround, but I'll try to eventually get back to this and fix > it. Thank you for taking the time to verify this

[GSoC][Project Idea] Multipart and resumable download while using git clone or pull

Hi, My name is Varun Garg and am a student in Software Engineering. During 2017 I participated in GSoC at Eclipse Foundation [1] and still contribute occasionally [2]. I have also submitted a micro project here last year[3]. I would like to add functionality of "Multipart and resumable

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

Takuto Ikuta writes: >> During fetch, everything_local() tries to mark common part by >> walking the refs the other side advertised upon the first contact, >> so it is correct that the number of checks is not reduced in a fetch >> that does not fetch many refs, but the

Re: [GSoC] [PATCH] travis-ci: added clang static analysis

I'm extremely sorry, I forgot to attach my travis-ci job build with my previous message. Here it is : https://travis-ci.org/SiddharthaMishra/git/jobs/349478746#L1204. I also apologize for not trimming the email properly in the previous message. Sorry for the inconvenience, Siddhartha

Re: [GSoC] [PATCH] travis-ci: added clang static analysis

On Mon, Mar 12, 2018 at 3:49 PM, Lars Schneider wrote: > Hi, > > That looks interesting but I agree with Dscho that we should not limit > this to master/maint. > > I assume you did run this on TravisCI already? Can you share a link? > I assume you did find errors? Can we

Re: Opinions on changing add/add conflict resolution?

On Mon, Mar 12, 2018 at 5:38 PM, Elijah Newren wrote: > I feel the analogy to merging binary files breaks down here in more > than one way: Actually, after mulling this over, I'm going to retract the "more than" piece of this sentence. I'm trying to figure out how to retract

Re: Opinions on changing add/add conflict resolution?

On Tue, Mar 13, 2018 at 2:59 AM, Ævar Arnfjörð Bjarmason wrote: > On Tue, Mar 13 2018, Elijah Newren jotted: >> However, I'm far more concerned with the three collision conflict types >> having consistent behavior than I am with changing add/add conflict >> handling. And if

[PATCH] sha1_file: restore OBJECT_INFO_QUICK functionality

Support for the OBJECT_INFO_QUICK flag in sha1_object_info_extended() was added in commit dfdd4afcf9 ("sha1_file: teach sha1_object_info_extended more flags", 2017-06-26) in order to support commit e83e71c5e1 ("sha1_file: refactor has_sha1_file_with_flags", 2017-06-26), but it was inadvertently

Re: Rename of file is causing changes to be lost

On Thu, Mar 8, 2018 at 8:01 AM, Robert Dailey wrote: > I'm on Windows and core.ignorecase is set to 'true' when I clone/init > a repository. I've got a branch where I started making changes to a > file AND renamed it only to change its case. The changes I've made > were

Re: [PATCH v4 04/35] upload-pack: convert to a builtin

On Wed, 28 Feb 2018 15:22:21 -0800 Brandon Williams wrote: > In order to allow for code sharing with the server-side of fetch in > protocol-v2 convert upload-pack to be a builtin. > > Signed-off-by: Brandon Williams I suggested updating the commit message

Re: [PATCH v4 35/35] remote-curl: don't request v2 when pushing

On Wed, 28 Feb 2018 15:22:52 -0800 Brandon Williams wrote: > In order to be able to ship protocol v2 with only supporting fetch, we > need clients to not issue a request to use protocol v2 when pushing > (since the client currently doesn't know how to push using protocol v2).

Re: [PATCH v4 31/35] http: allow providing extra headers for http requests

On Wed, 28 Feb 2018 15:22:48 -0800 Brandon Williams wrote: > Add a way for callers to request that extra headers be included when > making http requests. > > Signed-off-by: Brandon Williams Likewise, Reviewed-by: Jonathan Tan

Re: [PATCH v4 29/35] remote-curl: create copy of the service name

On Wed, 28 Feb 2018 15:22:46 -0800 Brandon Williams wrote: > Make a copy of the service name being requested instead of relying on > the buffer pointed to by the passed in 'const char *' to remain > unchanged. > > Currently, all service names are string constants, but a

Re: [PATCH v2 2/3] add -p: allow line selection to be inverted

Phillip Wood writes: > On 08/03/18 17:53, Junio C Hamano wrote: >> Phillip Wood writes: >> >>> and use a leading '-' for inversion. I'm tempted to keep supporting 'n-' >>> to mean everything from 'n' to the last line though. >> >> Thanks

Re: [PATCH v4 27/35] transport-helper: introduce stateless-connect

On Wed, 28 Feb 2018 15:22:44 -0800 Brandon Williams wrote: > +'stateless-connect':: > + Experimental; for internal use only. > + Can attempt to connect to a remote server for communication > + using git's wire-protocol version 2. This establishes a > +

Re: [PATCH v4 20/35] upload-pack: introduce fetch server command

On Wed, 28 Feb 2018 15:22:37 -0800 Brandon Williams wrote: > +output = *section > +section = (acknowledgments | packfile) > + (flush-pkt | delim-pkt) > + > +acknowledgments = PKT-LINE("acknowledgments" LF) > + (nak | *ack) > +

Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Phillip, Phillip Wood writes: [...] > Hi Sergey, I've been following this discussion from the sidelines, > though I haven't had time to study all the posts in this thread in > detail. I wonder if it would be helpful to think of rebasing a merge as > merging the

Re: [PATCH v4 16/35] transport: convert transport_get_remote_refs to take a list of ref patterns

On Wed, 28 Feb 2018 15:22:33 -0800 Brandon Williams wrote: > Convert 'transport_get_remote_refs()' to optionally take a list of ref > patterns. > > Signed-off-by: Brandon Williams [snip] > -const struct ref *transport_get_remote_refs(struct transport

Re: [PATCH v4 08/35] connect: discover protocol version outside of get_remote_heads

On Wed, 28 Feb 2018 15:22:25 -0800 Brandon Williams wrote: > In order to prepare for the addition of protocol_v2 push the protocol > version discovery outside of 'get_remote_heads()'. This will allow for > keeping the logic for processing the reference advertisement for >

Re: [GSoC][PATCH] git-ci: use pylint to analyze the git-p4 code

On 13 March 2018 at 03:36, Viet Hung Tran wrote: > Hello Mr. Schneider, > > Here is my link for the passed CI build I tested on my fork: > https://travis-ci.org/VietHTran/git/builds/35210 > > In order to test .travis.yml configuration alone, I used a sample python >

Re: Rename of file is causing changes to be lost

On Thu, Mar 8, 2018 at 10:01 AM, Robert Dailey wrote: > I'm on Windows and core.ignorecase is set to 'true' when I clone/init > a repository. I've got a branch where I started making changes to a > file AND renamed it only to change its case. The changes I've made > were

Will Coverity for FOSS be in scheduled maintenance mode forever?

Hi Coverity (now Synopsys) team, I probably managed to miss important mails such as announcing that the Coverity service for FOSS projects would be unavailable for some time. Since February 20th, this seems to be the case (all attempts at even looking at past results redirects to

Why don't we symlink libexec/git-core/* to bin/git?

On Thu, Mar 08 2018, Daniel Jacques jotted: >> It would be great to have this rebooted now that my perl cleanup efforts >> have un-blocked this. Will be happy to help review & test the next >> iteration. > > Yes, I was just thinking the same thing. I wanted to make sure the Perl > changes had

Re: [PATCH v2 2/3] add -p: allow line selection to be inverted

On 08/03/18 17:53, Junio C Hamano wrote: > Phillip Wood writes: > >> and use a leading '-' for inversion. I'm tempted to keep supporting 'n-' >> to mean everything from 'n' to the last line though. > > Thanks for double checking. It would be a better endgame to

Re: allow "~" to be present in a tag name

On Tue, Mar 13, 2018 at 11:09 AM, Ævar Arnfjörð Bjarmason wrote: > > On Tue, Mar 13 2018, Michal Novotny jotted: > >> On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason >> wrote: >>> >>> On Tue, Mar 13 2018, Michal Novotny jotted: >>> Hello,

Re: Bug in "revision.c: --all adds HEAD from all worktrees" ?

On Mon, Mar 12, 2018 at 10:39 PM, Ævar Arnfjörð Bjarmason wrote: > Now, obviously the root cause is that the repo is corrupt through some > other bug (since fixed?), but the error message here is really bad, and > should at least say "fatal: bad object HEAD in worktree blah" or

...

, My name is Lindsey and I'm glad to get In Touch with you after view you profile for serious relationship,age does not matter but love and care,

[RFC 0/4] ref-filter: remove printing from formatting logic

The main idea of the patch is, if you want to format the output by ref-filter, you should have an ability to work with errors by yourself if you want to. So I decided not to touch signature of show_ref_array_item(), but to move all printing (I mean errors) to it. So that we could invoke

[RFC 4/4] ref-filter: add return value to parsers

Continue removing any printing from ref-filter formatting logic, so that it could be more general. Change the signature of parsers by adding return value and strbuf parameter for error message. Signed-off-by: Olga Telezhnaia --- ref-filter.c | 177

[RFC 3/4] ref-filter: change parsing function error handling

Continue removing any printing from ref-filter formatting logic, so that it could be more general. Change the signature of parse_ref_filter_atom() by changing return value, adding previous return value to function parameter and also adding strbuf parameter for error message. Signed-off-by: Olga

[RFC 1/4] ref-filter: start adding strbufs with errors

This is a first step in removing any printing from ref-filter formatting logic, so that it could be more general. Everything would be the same for show_ref_array_item() users. But, if you want to deal with errors by your own, you could invoke format_ref_array_item(). It means that you need to

[RFC 2/4] ref-filter: add return value && strbuf to handlers

Continue removing any printing from ref-filter formatting logic, so that it could be more general. Change the signature of handlers by adding return value and strbuf parameter for errors. Signed-off-by: Olga Telezhnaia --- ref-filter.c | 71

Re: allow "~" to be present in a tag name

On Tue, Mar 13 2018, Michal Novotny jotted: > On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason > wrote: >> >> On Tue, Mar 13 2018, Michal Novotny jotted: >> >>> Hello, >>> >>> currently, if I try to create a tag that has tilde "~" in name, an >>> error is raised.

Re: Opinions on changing add/add conflict resolution?

On Tue, Mar 13 2018, Elijah Newren jotted: > Hi, > > On Mon, Mar 12, 2018 at 3:19 PM, Ævar Arnfjörð Bjarmason > wrote: > >> >> Does this mean that e.g. in this case of merging two files, one >> containing "foo" and one containing "bar": >> >> ( >> rm -rf

Re: allow "~" to be present in a tag name

On Tue, Mar 13, 2018 at 10:07 AM, Ævar Arnfjörð Bjarmason wrote: > > On Tue, Mar 13 2018, Michal Novotny jotted: > >> Hello, >> >> currently, if I try to create a tag that has tilde "~" in name, an >> error is raised. E.g. >> >> $ git tag rpkg-util-1.4~rc1 >> fatal:

Re: allow "~" to be present in a tag name

On Tue, Mar 13 2018, Michal Novotny jotted: > Hello, > > currently, if I try to create a tag that has tilde "~" in name, an > error is raised. E.g. > > $ git tag rpkg-util-1.4~rc1 > fatal: 'rpkg-util-1.4~rc1' is not a valid tag name. > > Now, actually it would be very cool if tilde was allowed

allow "~" to be present in a tag name

Hello, currently, if I try to create a tag that has tilde "~" in name, an error is raised. E.g. $ git tag rpkg-util-1.4~rc1 fatal: 'rpkg-util-1.4~rc1' is not a valid tag name. Now, actually it would be very cool if tilde was allowed in a tag name because we would like to use it for tagging

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Buga, Igor Djordjevic writes: [...] > I don`t know, I`m thinking if we are looking at todo list from > different perspectives - to you, it seems to be a sequence of > commands to create something new (yes, from something that already > exists, but that`s