Does it make sense to show tips on blame?

Hi! I'm having fun with difflame. I added support for an option called 'tips' which would display 1-line summary of a block of added lines that belong to the same revision, in order to provide context while reading difflame output without having to run an additional git show command. Output is

[PATCH v2 4/4] show-ref: Inline show_one

As the small function is now only called from a single place, there is no point in keeping it as a separate function any longer. Signed-off-by: Vladimir Panteleev --- builtin/show-ref.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git

[PATCH v2 1/4] show-ref: Allow --head to work with --verify

Previously, when --verify was specified, show-ref would use a separate code path which ignored --head. Thus, "git show-ref HEAD" used with "--verify" (because the user is not interested in seeing refs/remotes/origin/HEAD), and used with "--head" (because the user does not want HEAD to be filtered

[PATCH v2 3/4] show-ref: Optimize show_ref a bit

The inner `if (verify)' check was not being used before the preceding commit, as show_ref was never being called from a code path where verify was non-zero. Adding a `!verify' check to the outer if skips an unnecessary string comparison when verify is non-zero, and show_ref is already called with

[PATCH v2 2/4] show-ref: Allow -d to work with --verify

Use the same output machinery when --verify is absent or present, which allows tag dereferencing (-d) to work with --verify. This is useful when the user wishes to avoid the costly iteration of refs. Signed-off-by: Vladimir Panteleev --- builtin/show-ref.c | 3 +--

[PATCH v2] show-ref: Allow -d, --head to work with --verify

This is the second take for "[PATCH] show-ref: Allow --head to work with --verify". Thanks to Junio for his extensive feedback.

Re: [PATCH] show-ref: Allow --head to work with --verify

On 2017-01-20 23:29, Junio C Hamano wrote: By the way, I have no strong preference between "read-ref, check quiet and show-one" and "show-ref", so if you make --verify to consistently call "show_ref()" for both refs/heads/master and HEAD, that is also perfectly fine. This sounds like a good

Re: Idea: Add a filter option to 'git rebase'

Am 20.01.2017 um 23:28 schrieb Philip Oakley: > A recent question on stackoverflow > http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase > sought to remove automatically commits that could be identified by > relevant words in the commit message. > > I had

Re: [PATCH v2 2/2] grep: use '/' delimiter for paths

On 01/20, Junio C Hamano wrote: > Stefan Hajnoczi writes: > > > If the tree contains a sub-directory then git-grep(1) output contains a > > colon character instead of a path separator: > > > > $ git grep malloc v2.9.3:t > > v2.9.3:t:test-lib.sh: setup_malloc_check ()

Re: [PATCH] show-ref: Allow --head to work with --verify

Junio C Hamano writes: > If two codepaths are called "I don't see a meaningful difference", > then it is really better to share the same code. Today, they may > happen to behave identically. When we need to update the behaviour > of one, we'd be forced to update the other

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Fri, Jan 20, 2017 at 1:58 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Jeff King writes: >> And in my current understanding of submodules the check in .gitmodules ought to be enough, too. >>> >>> Yeah, that probably

Re: [PATCH] show-ref: Allow --head to work with --verify

Vladimir Panteleev writes: > --quiet will still work correctly with the current patch, because > show_ref already checks quiet. Granted, the original --verify code > used show_one and not show_ref; however, I don't see a meaningful > difference between calling show_ref

Re: [PATCH v2 0/2] grep: make output consistent with revision syntax

Stefan Hajnoczi writes: > v2: > * Use obj->type instead of re-parsing name for delimiter >(Followed Brandon's suggestion but named the variable 'delim' since that >name is used in other places and 'del' is used for deletion.) > * Add tests > * Update Patch 1

Re: [PATCH] show-ref: Allow --head to work with --verify

Junio C Hamano writes: > Your log message for the patch needs to be updated by summarizing > the above better. Here is my attempt. "git show-ref HEAD" used with "--verify" (because the user is not interested in seeing refs/remotes/origin/HEAD), and used with

Re: [RFC 2/2] grep: use '/' delimiter for paths

Jeff King writes: > It's not ignored; just as with git-log, it's a pathspec to limit the > diff. E.g.: > > $ git show --name-status v2.9.3 > ... > M Documentation/RelNotes/2.9.3.txt > M Documentation/git.txt > M GIT-VERSION-GEN > > $ git show

Re: [PATCH] show-ref: Allow --head to work with --verify

On 2017-01-20 19:03, Junio C Hamano wrote: and viewed in the wider context, I notice that quiet is not honored in the added code. I think that is easily fixable by replacing this hunk with something like: --quiet will still work correctly with the current patch, because show_ref already

Re: [PATCH] show-ref: Allow --head to work with --verify

Junio C Hamano writes: >> My use case was the following series of steps: >> ... long and readable if a bit too verbose description ... > Your log message for the patch needs to be updated by summarizing > the above better. That raises the number of things to improve in the

Idea: Add a filter option to 'git rebase'

A recent question on stackoverflow http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase sought to remove automatically commits that could be identified by relevant words in the commit message. I had thought that the ubiquitous `git filter-branch` should be

Re: [PATCH] show-ref: Allow --head to work with --verify

Vladimir Panteleev writes: > Hi Junio, > > On 2017-01-20 19:03, Junio C Hamano wrote: >> Having said all that, using --verify on HEAD does not make much >> sense, because if HEAD is missing in .git/, I do not think Git >> considers that directory as a Git repository to

Re: [PATCH v2 1/2] grep: only add delimiter if there isn't one already

Stefan Hajnoczi writes: > git-grep(1) output does not follow git's own syntax: > > $ git grep malloc v2.9.3:t/ > v2.9.3:t/:test-lib.sh: setup_malloc_check () { > $ git show v2.9.3:t/:test-lib.sh > fatal: Path 't/:test-lib.sh' does not exist in 'v2.9.3' > > This

Re: [PATCH v2 2/2] grep: use '/' delimiter for paths

Stefan Hajnoczi writes: > If the tree contains a sub-directory then git-grep(1) output contains a > colon character instead of a path separator: > > $ git grep malloc v2.9.3:t > v2.9.3:t:test-lib.sh: setup_malloc_check () { > $ git show v2.9.3:t:test-lib.sh >

Re: [PATCH] log: new option decorate reflog of remote refs

On Fri, Jan 20, 2017 at 6:30 AM, Jeff King wrote: >> Imposing order between options could cause confusion, I think, if you >> remove --decorate-reflog leaving --remotes on by accident, now you get >> --remotes with a new meaning. We could go with something like >>

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Fri, Jan 20, 2017 at 01:58:02PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > Jeff King writes: > > > >>> And in my current understanding of submodules the check in > >>> .gitmodules ought to be enough, too. > >> > >> Yeah, that probably makes

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

Junio C Hamano writes: > Jeff King writes: > >>> And in my current understanding of submodules the check in >>> .gitmodules ought to be enough, too. >> >> Yeah, that probably makes sense. You can have a gitlink without a >> .gitmodules file, but I don't quite

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Fri, Jan 20, 2017 at 01:41:54PM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> And in my current understanding of submodules the check in > >> .gitmodules ought to be enough, too. > > > > Yeah, that probably makes sense. You can have a gitlink without a > >

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

Jeff King writes: >> And in my current understanding of submodules the check in >> .gitmodules ought to be enough, too. > > Yeah, that probably makes sense. You can have a gitlink without a > .gitmodules file, but I don't quite know what that would mean in terms > of submodules (I

Re: [PATCH] show-ref: Allow --head to work with --verify

And to clarify: On 2017-01-20 20:26, Vladimir Panteleev wrote: On 2017-01-20 19:03, Junio C Hamano wrote: Having said all that, using --verify on HEAD does not make much sense, because if HEAD is missing in .git/, I do not think Git considers that directory as a Git repository to begin with.

Re: [PATCH] show-ref: Allow --head to work with --verify

Hi Junio, On 2017-01-20 19:03, Junio C Hamano wrote: Having said all that, using --verify on HEAD does not make much sense, because if HEAD is missing in .git/, I do not think Git considers that directory as a Git repository to begin with. So from that point of view, I am not sure what value

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Fri, Jan 20, 2017 at 12:00 PM, Jeff King wrote: > On Fri, Jan 20, 2017 at 11:53:01AM -0800, Stefan Beller wrote: > >> > One alternative would be to make the check cheaper. Could we reliably >> > tell from the submodule.foo.* block in the config that path "foo" is a >> >

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Fri, Jan 20, 2017 at 11:53:01AM -0800, Stefan Beller wrote: > > One alternative would be to make the check cheaper. Could we reliably > > tell from the submodule.foo.* block in the config that path "foo" is a > > submodule? I think that would work after "submodule init" but not right > > after

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Fri, Jan 20, 2017 at 11:42 AM, Jeff King wrote: > On Fri, Jan 20, 2017 at 11:33:45AM -0800, Stefan Beller wrote: > >> > I'd rather see it in the commands themselves. Especially given the >> > "ideal" in your status example, which requires command-specific >> > knowledge. >> >>

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Fri, Jan 20, 2017 at 11:33:45AM -0800, Stefan Beller wrote: > > I'd rather see it in the commands themselves. Especially given the > > "ideal" in your status example, which requires command-specific > > knowledge. > > So you rather want to go bottom up, i.e. add it to each command

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Fri, Jan 20, 2017 at 11:17 AM, Jeff King wrote: > On Thu, Jan 19, 2017 at 11:30:23AM -0800, Stefan Beller wrote: > >> Now let's ask the same question for "git -C sub status ." (which is a >> command that is only reading and not writing to the repository) >> >> 1) If the

Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard

On Fri, Jan 20, 2017 at 11:16:15AM -0800, Jacob Keller wrote: > > I recently taught urxvt to recognize sha1s and grab them via keyboard > > hints, and I'm finding it quite useful. Here's what it looks like if > > you're interested: > > > > http://peff.net/git-hints.gif > > > > The hints

Re: [RFC/PATCH] Disallow commands from within unpopulated submodules.

On Thu, Jan 19, 2017 at 11:30:23AM -0800, Stefan Beller wrote: > Now let's ask the same question for "git -C sub status ." (which is a > command that is only reading and not writing to the repository) > > 1) If the submodule is populated, the user clearly intended to know >more about the

Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard

On Fri, Jan 20, 2017 at 8:09 AM, Jeff King wrote: > On Fri, Jan 20, 2017 at 05:22:49PM +0700, Nguyễn Thái Ngọc Duy wrote: > >> OK This patch is horrible. Though the idea is cool and I've found it >> very useful. So here it is. Perhaps the idea may be revised a bit >> that's more

Re: [PATCH] show-ref: Allow --head to work with --verify

Vladimir Panteleev writes: > This patch adds --head support to show-ref's --verify logic, by > explicitly checking if the "HEAD" ref is specified when --head is > present. > @@ -207,6 +207,8 @@ int cmd_show_ref(int argc, const char **argv, const char > *prefix) >

Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard

Jeff King writes: > Not really a comment on your patch itself, but I think a lot of people > solve this at a higher level, either in their terminal or via a tool > like tmux. > > I recently taught urxvt to recognize sha1s and grab them via keyboard > hints, and I'm finding it

Re: [RFC 1/2] grep: only add delimiter if there isn't one already

Stefan Hajnoczi writes: > v2.9.3::Makefile may convey that the user originally provided v2.9.3: > but is that actually useful information? You are either asking a wrong question, or asking a wrong person (i.e. Git) the question. The real question is why the user added a

Re: merge maintaining history

Jakub Narębski writes: > Then you would have the above history in repositories that fetched > refs/replace/*, and the one below if replacement info is absent: > >original A<-B<-C<-D<-E<-F<---M > \ / >first branch b<-c<-d<-e

[PATCH v2 0/2] grep: make output consistent with revision syntax

v2: * Use obj->type instead of re-parsing name for delimiter (Followed Brandon's suggestion but named the variable 'delim' since that name is used in other places and 'del' is used for deletion.) * Add tests * Update Patch 1 commit description with a more relevant example * PATCH instead

[PATCH v2 1/2] grep: only add delimiter if there isn't one already

git-grep(1) output does not follow git's own syntax: $ git grep malloc v2.9.3:t/ v2.9.3:t/:test-lib.sh: setup_malloc_check () { $ git show v2.9.3:t/:test-lib.sh fatal: Path 't/:test-lib.sh' does not exist in 'v2.9.3' This patch avoids emitting the unnecessary ':' delimiter if the name

[PATCH v2 2/2] grep: use '/' delimiter for paths

If the tree contains a sub-directory then git-grep(1) output contains a colon character instead of a path separator: $ git grep malloc v2.9.3:t v2.9.3:t:test-lib.sh: setup_malloc_check () { $ git show v2.9.3:t:test-lib.sh fatal: Path 't:test-lib.sh' does not exist in 'v2.9.3' This patch

[PATCH] show-ref: Allow --head to work with --verify

Previously, when --verify was specified, --head was being ignored, and "show-ref --verify --head HEAD" would always print "fatal: 'HEAD' - not a valid ref". As such, when using show-ref to look up any ref (including HEAD) precisely by name, one would have to special-case looking up the HEAD ref.

Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard

On Fri, Jan 20, 2017 at 05:22:49PM +0700, Nguyễn Thái Ngọc Duy wrote: > OK This patch is horrible. Though the idea is cool and I've found it > very useful. So here it is. Perhaps the idea may be revised a bit > that's more suitable for more than one user. > > The problem is old, SHA-1 name is

Re: fatal: bad revision 'git rm -r --ignore-unmatch -- folder'

I've finally found the correct command after some significant research: git filter-branch --tag-name-filter cat --index-filter "git rm -r --cached --ignore-unmatch ${file_path}/${file_name}" --prune-empty --force -- --all On Fri, Jan 20, 2017 at 4:23 PM, jean-christophe manciot

Re: [RFC] stash --continue

Hi Marc, On Fri, 20 Jan 2017, Marc Branchaud wrote: > On 2017-01-19 04:30 PM, Johannes Schindelin wrote: > > > > At this point I will stop commenting on this issue, as I have said all > > that I wanted to say about it, at least once. If I failed to get my > > points across so far, I simply won't

Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard

Hi Duy, On Fri, 20 Jan 2017, Duy Nguyen wrote: > On Fri, Jan 20, 2017 at 5:46 PM, Johannes Schindelin > wrote: > > Why not introduce a flag to "git log" that shows a keyboard-friendly name > > similar to what `git name-rev` would have said, except that the name would

Re: [RFC] stash --continue

On 2017-01-19 04:30 PM, Johannes Schindelin wrote: At this point I will stop commenting on this issue, as I have said all that I wanted to say about it, at least once. If I failed to get my points across so far, I simply won't be understood. Yes, we're obviously looking at this from

ATTANTION SIR/MADAM

Am Dr. Aisha Gaddafi, the daughter of late Libyan president, I need a partner or an investor that will help me in investing the sum of $87.5 million USD in his or her country, the funds is deposited here in Burkina Faso where I am staying for the moment with my family, I would like to know

Re: [RFC 0/2] grep: make output consistent with revision syntax

On Fri, Jan 20, 2017 at 02:18:32PM +, Stefan Hajnoczi wrote: > > Are there cases you know that aren't covered by your patches? > > From Patch 2/2: > > This patch does not cope with @{1979-02-26 18:30:00} syntax and treats > it as a path because it contains colons. > > If we use

Re: [PATCH] log: new option decorate reflog of remote refs

On Fri, Jan 20, 2017 at 05:55:21PM +0700, Duy Nguyen wrote: > > We already have very flexible ref-selectors like --remotes, --branches, > > etc. The generalization of this would perhaps be something like: > > > > git log --decorate-reflog --remotes --branches > > > > where "--decorate-reflog"

Re: [RFC 2/2] grep: use '/' delimiter for paths

On Fri, Jan 20, 2017 at 02:12:12PM +, Stefan Hajnoczi wrote: > I find : vs -- confusing: > > | : | -- > --+--+- > git grep | OK | OK > --+--+- >

Re: [RFC 0/2] grep: make output consistent with revision syntax

On Thu, Jan 19, 2017 at 11:59:59AM -0500, Jeff King wrote: > On Thu, Jan 19, 2017 at 03:03:45PM +, Stefan Hajnoczi wrote: > > > git-grep(1)'s output is not consistent with git-rev-parse(1) revision > > syntax. > > > > This means you cannot take "rev:path/to/file.c: foo();" output from > >

Re: [RFC 2/2] grep: use '/' delimiter for paths

On Thu, Jan 19, 2017 at 10:29:34AM -0800, Brandon Williams wrote: > On 01/19, Stefan Hajnoczi wrote: > > If the tree contains a sub-directory then git-grep(1) output contains a > > colon character instead of a path separator: > > > > $ git grep malloc v2.9.3:t > > v2.9.3:t:test-lib.sh:

Re: [RFC 2/2] grep: use '/' delimiter for paths

On Thu, Jan 19, 2017 at 10:54:02AM -0800, Junio C Hamano wrote: > Stefan Hajnoczi writes: > > > If the tree contains a sub-directory then git-grep(1) output contains a > > colon character instead of a path separator: > > > > $ git grep malloc v2.9.3:t > >

Re: [RFC 1/2] grep: only add delimiter if there isn't one already

On Thu, Jan 19, 2017 at 10:39:02AM -0800, Junio C Hamano wrote: > Stefan Hajnoczi writes: > > > git-grep(1) output does not follow git's own syntax: > > > > $ git grep malloc v2.9.3: > > v2.9.3::Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc > > $ git show

Re: [RFC PATCH 0/5] Localise error headers

On Fri, Jan 20, 2017 at 8:23 PM, Duy Nguyen wrote: > I've tested it a bit. Seems to work ok. Oops. Didn't notice that the "fatal:" bit is still untranslated but Micheal's patch can handle that. -- Duy

Re: [PATCH] git-prompt.sh: add submodule indicator

I'm not well-versed in submodules, so I won't comment on whether this is the right way to determine that a repository is a submodule, but I was surprised to see how much you have to work to find this out. My comments will mostly focus on how to eliminate or at least limit the scope of subshells

Re: [RFC PATCH 0/5] Localise error headers

On Wed, Jan 11, 2017 at 06:37:25AM -0500, Jeff King wrote: > > To find a good example, "git grep die" giving me some food of though: > > > > die_errno(..) should always take a string marked up for translation, > > because the errno string is translated? > > Yes, I would think die_errno() is a

Re: [RFC PATCH 0/5] Localise error headers

On Thu, Jan 12, 2017 at 1:08 AM, Junio C Hamano wrote: > Jeff King writes: > >> Yes, I would think die_errno() is a no-brainer for translation, since >> the strerror() will be translated. >> >>> apply.c:die(_("internal error")); >>> >>> That

How To Write Thesis Proposal in Best Way

Writing a winning Thesis Proposal is considered to be very difficult task by the students.But now you don't need to be worried about thesis proposal writing DissertationHelp.ae has

Re: merge maintaining history

W dniu 19.01.2017 o 22:42, Junio C Hamano pisze: > "David J. Bakeman" writes: [...] >> Thanks I think that's close but it's a little more complicated I think >> :<( I don't know if this diagram will work but lets try. >> >> original A->B->C->D->E->F >> \ >>

Re: The design of refs backends, linked worktrees and submodules

On Thu, Jan 19, 2017 at 8:30 PM, Michael Haggerty wrote: > I kindof think that it would have been a better design to store the > references for all linked worktrees in the main repository's ref-store. > For example, the "bisect" refs for a worktree named "" could have > been

Re: Git: new feature suggestion

W dniu 20.01.2017 o 01:26, Linus Torvalds pisze: > On Thu, Jan 19, 2017 at 1:48 PM, Jakub Narębski wrote: >> W dniu 19.01.2017 o 19:39, Linus Torvalds pisze: >>> >>> You can do it in tig, but I suspect a more graphical tool might be better. >> >> Well, we do have "git gui

Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard

On Fri, Jan 20, 2017 at 5:46 PM, Johannes Schindelin wrote: > Why not introduce a flag to "git log" that shows a keyboard-friendly name > similar to what `git name-rev` would have said, except that the name would > be generated using the name(s) specified on the

Re: [PATCH] log: new option decorate reflog of remote refs

On Fri, Jan 20, 2017 at 12:23 AM, Jeff King wrote: > I think it's a neat idea, but the actual option: > >> +--decorate-remote-reflog[=]:: >> + Decorate `` most recent reflog entries on remote refs, up >> + to the specified number of entries. By default, only the most >> +

Re: Git: new feature suggestion

Hi Stefan, Às 10:03 PM de 1/19/2017, Stefan Beller escreveu: > On Thu, Jan 19, 2017 at 1:51 PM, Joao Pinto wrote: >> Às 7:16 PM de 1/19/2017, Linus Torvalds escreveu: >>> On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto >>> wrote: I am

Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard

Hi Duy, On Fri, 20 Jan 2017, Nguyễn Thái Ngọc Duy wrote: > OK This patch is horrible. Yeah ;-) > Though the idea is cool and I've found it very useful. So here it is. > Perhaps the idea may be revised a bit that's more suitable for more than > one user. Why not introduce a flag to "git log"

Re: [PATCH v3 14/21] read-cache: touch shared index files when used

On Fri, Jan 20, 2017 at 2:00 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Mon, Jan 9, 2017 at 9:34 PM, Junio C Hamano wrote: >>> Duy Nguyen writes: >>> On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano

[PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard

OK This patch is horrible. Though the idea is cool and I've found it very useful. So here it is. Perhaps the idea may be revised a bit that's more suitable for more than one user. The problem is old, SHA-1 name is not keyboard-friendly, even in abbreviated form. And recent change has made abbrev