Re: What's cooking in git.git (Aug 2016, #07; Thu, 18)

On Fri, Aug 19, 2016 at 7:33 PM, Junio C Hamano wrote: > On Fri, Aug 19, 2016 at 4:46 PM, Stefan Beller wrote: >>> >>> * sb/submodule-clone-rr (2016-08-17) 8 commits >>> >>> I spotted a last-minute bug in v5, which is not a very good sign >>> (it shows

Re: Most recent revision that contains a string

Nikolaus Rath wrote: > What's the easiest way to find the most recent revision (of any file in > the repository, including those that have been deleted in the current > HEAD) that contains a given string? I normally do something like: git log -r --raw -p -SSTRING

Re: Adding more namespace support to git

On Sat, Aug 20, 2016 at 08:07:00PM +0100, Richard wrote: > I work on a git server called gitano. > We've been using and recommending cgit for the web UI. > > I've been working on adding git namespace support to both, > so that we can separate administrative branches from code branches. > >

Re: Most recent revision that contains a string

On Sat, Aug 20, 2016 at 02:41:35PM -0700, Nikolaus Rath wrote: > Hello, > > What's the easiest way to find the most recent revision (of any file in > the repository, including those that have been deleted in the current > HEAD) that contains a given string? > > I was hoping that "git grep" would

Re: git rm --cached should be git rm --cache or git rm --stage

From: "Zenaan Harkness" On Sat, Aug 20, 2016 at 08:14:25PM +0100, Philip Oakley wrote: From: "Zenaan Harkness" > > Please CC me :) > or perhaps something like: > "does not unstage a file, it actually stages the removal of the > file(s) from the repo

Extending "extended SHA1" syntax to traverse through gitlinks?

Currently, if you have a branch "somebranch" that contains a gitlink "somecommit", you can write "somebranch:somecommit" to refer to the commit, just like a tree or blob. ("man git-rev-parse" defines this syntax in the "SPECIFYING REVISIONS" section.) You can use this anywhere you can use a

Re: git rm --cached should be git rm --cache or git rm --stage

On Sat, Aug 20, 2016 at 08:14:25PM +0100, Philip Oakley wrote: > From: "Zenaan Harkness" > > > > Please CC me :) > > or perhaps something like: > > "does not unstage a file, it actually stages the removal of the > > file(s) from the repo (assuming it was already committed

Most recent revision that contains a string

Hello, What's the easiest way to find the most recent revision (of any file in the repository, including those that have been deleted in the current HEAD) that contains a given string? I was hoping that "git grep" would do this (like in Mercurial), but as far as I can tell it only greps through

Re: [RFC] Proposed questions for "Git User's Survey 2016"

Jakub Narębski wrote: > Other version control systems > > 20. What other version control systems (SCM) do you use beside Git? >(multiple choice, with other) > > Explanation: "using" version control system here means using > it to actively contribute (propose changes

Re: [PATCH v4] config: add conditional include

W dniu 19.08.2016 o 15:54, Jeff King pisze: > On Sat, Aug 13, 2016 at 03:40:59PM +0700, Duy Nguyen wrote: > >> Ping.. > > There was some discussion after v4. I think the open issues are: > > - the commit message is rather terse (it should describe motivation, > and can refer to the docs

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

W dniu 19.08.2016 o 17:03, Jeff King pisze: [...] > There is nothing wrong with building tooling around your workflow. If we > had a GitHub-based workflow, I'd build tooling around that, too. One of > the things I _like_ about a mail-based workflow is how easy it is to > build that tooling, and

Re: git rm --cached should be git rm --cache or git rm --stage

From: "Zenaan Harkness" Please CC me :) From man git-rm: --cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone. This wording is unclear and dangerous, and ought be cleaned up somehow.

Adding more namespace support to git

I work on a git server called gitano. We've been using and recommending cgit for the web UI. I've been working on adding git namespace support to both, so that we can separate administrative branches from code branches. Because git is not namespace aware for anything but git-upload-pack and

[RFC] Proposed questions for "Git User's Survey 2016"

Hello, As I wrote previously here, I am thinking about returning to doing the Git User's Survey this year. Message-ID: <577e6f32.7020...@gmail.com> https://marc.info/?l=git=146790381602547=2 https://public-inbox.org/git/577E6F32.7020007%40gmail.com/ The previous email, which did not

Re: [L10N] Kickoff of translation for Git 2.10.0 round 1

On samedi 20 août 2016 11:03:00 CEST Junio C Hamano wrote: > Jean-Noël AVILA writes: > > 1. In config.c, the changes to the function die_bad_number tried to > > flatten the translated strings (no message building logic). I think it > > went too far, and the reason of the

Proposal to add a shortcut for --force-with-lease

"--force" have currently two shortcuts: "-f" and "+", hence more ergonomic. But I expect it's better for users to use "--force-with-lease" by default for overriding remote branches (e.g. cleaning up a pull request), as it rarely fails in normal situations. I propose adding some shortcut for

Re: [L10N] Kickoff of translation for Git 2.10.0 round 1

Jean-Noël AVILA writes: > 1. In config.c, the changes to the function die_bad_number tried to flatten > the > translated strings (no message building logic). I think it went too far, and > the reason of the failure can be factorized so that we don't have to > retranslate

Re: git rm --cached should be git rm --cache or git rm --stage

Zenaan Harkness writes: > From man git-rm: > > --cached > Use this option to unstage and remove paths only from the index. > Working tree files, whether modified or not, will be left alone. > > This wording is unclear and dangerous, and ought be cleaned up somehow. I

Re: [L10N] Kickoff of translation for Git 2.10.0 round 1

Hi all, Before anyone tries to localize this round, I'd like to make some preliminary comments: 1. In config.c, the changes to the function die_bad_number tried to flatten the translated strings (no message building logic). I think it went too far, and the reason of the failure can be

git rm --cached should be git rm --cache or git rm --stage

Please CC me :) >From man git-rm: --cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone. This wording is unclear and dangerous, and ought be cleaned up somehow. Probably also the option name should

Re: git rm --cached should be git rm --cache or git rm --stage

Please CC me :) > From man git-rm: > > --cached > Use this option to unstage and remove paths only from the index. > Working tree files, whether modified or not, will be left alone. > > > This wording is unclear and dangerous, and ought be cleaned up somehow. > > Probably also the

Re: [PATCH v9 0/8] submodule show inline diff

On Fri, Aug 19, 2016 at 5:02 PM, Stefan Beller wrote: > On Fri, Aug 19, 2016 at 4:34 PM, Jacob Keller > wrote: >> - strbuf_git_path(buf, "%s/%s", "modules", path); >> + /* >> +* Lookup the submodule name