* Re: [RFC 2/2] grep: use '/' delimiter for paths
From: Stefan Hajnoczi @ 2017-01-20 14:17 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, gitster
In-Reply-To: <20170119182934.GH10641@google.com>
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
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: 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 attempts to use the correct delimiter:
> >
> > $ 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
> > (success)
> >
> > This patch does not cope with @{1979-02-26 18:30:00} syntax and treats
> > it as a path because it contains colons.
> >
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> > builtin/grep.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/builtin/grep.c b/builtin/grep.c
> > index 3643d8a..06f8b47 100644
> > --- a/builtin/grep.c
> > +++ b/builtin/grep.c
> > @@ -493,7 +493,8 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,
> >
> > /* Add a delimiter if there isn't one already */
> > if (name[len - 1] != '/' && name[len - 1] != ':') {
> > - strbuf_addch(&base, ':');
> > + /* rev: or rev:path/ */
> > + strbuf_addch(&base, strchr(name, ':') ? '/' : ':');
>
> As Jeff mentioned it may be better to base which character gets appended
> by checking the obj->type field like this maybe:
>
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 69dab5dc5..9dfe11dc7 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -495,7 +495,8 @@ static int grep_object(struct grep_opt *opt, const struct pathspec *pathspec,
> /* Add a delimiter if there isn't one already */
> if (name[len - 1] != '/' && name[len - 1] != ':') {
> /* rev: or rev:path/ */
> - strbuf_addch(&base, strchr(name, ':') ? '/' : ':');
> + char del = obj->type == OBJ_COMMIT ? ':' : '/';
> + strbuf_addch(&base, del);
Nice, that also solves the false positive with @{1979-02-26 18:30:00}.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [RFC 2/2] grep: use '/' delimiter for paths
From: Stefan Hajnoczi @ 2017-01-20 14:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqpoji2851.fsf@gitster.mtv.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]
On Thu, Jan 19, 2017 at 10:54:02AM -0800, Junio C Hamano wrote:
> Stefan Hajnoczi <stefanha@redhat.com> 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
> > fatal: Path 't:test-lib.sh' does not exist in 'v2.9.3'
>
> I am slightly less negative on this compared to 1/2, but not by a
> big margin. The user wanted to feed a subtree to the command,
> instead of doing the more natural
>
> $ git grep -e malloc v2.9.3 -- t
I find <rev>:<path> vs <rev> -- <path> confusing:
| <rev>:<path> | <rev> -- <path>
----------+----------------------+---------------------
git grep | OK | OK
----------+----------------------+---------------------
git show | OK | <path> ignored
----------+----------------------+---------------------
git log | no output | OK
----------+----------------------+---------------------
Neither syntax always does what I expect. If git show <rev> -- <path>
honored <path> then I could use that syntax consistently.
Sorry for going on a tangent. Does it seem reasonable to handle <path>
in git-show(1) as a UI convenience?
> So again, "contains a colon character" is not coming from what Git
> does, but the user gave Git "a colon character" when she didn't have
> to.
>
> Having said that, if we wanted to start ignoring what the end-user
> said in the initial input like 1/2 and 2/2 does (i.e. "this specific
> tree object" as an input), I think the approach to solve for 1/2 and
> 2/2 should be the same. I think we should decide to do a slash
> instead of a colon, not because v2.9.3: has colon at the end and
> v2.9.3:t has colon in it, but because both of these are both bare
> tree objects. The patches presented does not seem to base their
> decision on the actual object type but on the textual input, which
> seems wrong.
Yes, reparsing the name is ugly and I hoped to get feedback with this
RFC. Thanks for the quick review!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [RFC 1/2] grep: only add delimiter if there isn't one already
From: Stefan Hajnoczi @ 2017-01-20 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqtw8u28u1.fsf@gitster.mtv.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
On Thu, Jan 19, 2017 at 10:39:02AM -0800, Junio C Hamano wrote:
> Stefan Hajnoczi <stefanha@redhat.com> 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 v2.9.3::Makefile
> > fatal: Path ':Makefile' does not exist in 'v2.9.3'
> >
> > This patch avoids emitting the unnecessary ':' delimiter if the name
> > already ends with ':' or '/':
> >
> > $ git grep malloc v2.9.3:
> > v2.9.3:Makefile: COMPAT_CFLAGS += -Icompat/nedmalloc
> > $ git show v2.9.3:Makefile
> > (succeeds)
>
> I am mildly negative on this one. I suspect that the above example
> is a made-up one and you might have a more compelling real-world use
> case in mind, but at least the above does not convince me.
Another trailing delimiter example:
$ git grep malloc v2.9.3:t/
v2.9.3:t/:test-lib.sh: setup_malloc_check () {
After Patch 1/2:
v2.9.3:t/test-lib.sh: setup_malloc_check () {
> The end-user explicitly gave the extra ':' because she wanted to
> feed the tree object, not a tag that leads to the tree, for some
> reason. I think the output should respect that and show how she
> spelled the starting point. IOW, it is not "':' added unnecessarily
> by Git". It is ':' added by the end-user for whatever reason.
v2.9.3::Makefile may convey that the user originally provided v2.9.3:
but is that actually useful information? I don't see what the user will
do with this information (and they should already know since they
provided the command-line).
v2.9.3:Makefile can be copy-pasted or extracted by scripts for further
git commands. That is useful.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/5] Localise error headers
From: Duy Nguyen @ 2017-01-20 13:31 UTC (permalink / raw)
To: Jeff King; +Cc: Stefan Beller, Michael J Gruber, git@vger.kernel.org
In-Reply-To: <20170120132322.GA23030@ash>
On Fri, Jan 20, 2017 at 8:23 PM, Duy Nguyen <pclouds@gmail.com> 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
^ permalink raw reply
* Re: [PATCH] git-prompt.sh: add submodule indicator
From: SZEDER Gábor @ 2017-01-20 13:35 UTC (permalink / raw)
To: Benjamin Fuchs; +Cc: Stefan Beller, git, felipe.contreras, ville.skytta
In-Reply-To: <1484870858-6336-1-git-send-email-email@benjaminfuchs.de>
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 and command executions, because fork()s and
exec()s are rather expensive on Windows.
On Fri, Jan 20, 2017 at 1:07 AM, Benjamin Fuchs <email@benjaminfuchs.de> wrote:
> I expirienced that working with submodules can be confusing. This indicator
> will make you notice very easy when you switch into a submodule.
> The new prompt will look like this: (sub:master)
> Adding a new optional env variable for the new feature.
>
> Signed-off-by: Benjamin Fuchs <email@benjaminfuchs.de>
> ---
> contrib/completion/git-prompt.sh | 37 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
Tests?
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 97eacd7..4c82e7f 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -93,6 +93,10 @@
> # directory is set up to be ignored by git, then set
> # GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
> # repository level by setting bash.hideIfPwdIgnored to "false".
> +#
> +# If you would like __git_ps1 to indicate that you are in a submodule,
> +# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before
> +# the branch name.
>
> # check whether printf supports -v
> __git_printf_supports_v=
> @@ -284,6 +288,32 @@ __git_eread ()
> test -r "$f" && read "$@" <"$f"
> }
>
> +# __git_is_submodule
> +# Based on:
> +# http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule
> +__git_is_submodule ()
Use the '__git_ps1' prefix in the function name, like the other
functions.
> +{
> + local git_dir parent_git module_name path
> + # Find the root of this git repo, then check if its parent dir is also a repo
> + git_dir="$(git rev-parse --show-toplevel)"
1. This is a somewhat misleading variable name, because git_dir (with
or without underscore or dash) refers to the path to the .git
directory of a repository through the codebase, documentation and
CLI options, not the top-level directory of the worktree.
2. In a bare repository or in the .git directory of a "regular"
repository '--show-toplevel' doesn't output anything, leading to
an empty $module_name below, which ultimately results in no
submodule indicator.
As fas as behavior is concerned, this is good in the bare
repository case, because as I understand it there is no such thing
as a bare submodule. I'm not sure whether the submodule indicator
should be displayed in the ".git dir of a submodule" case. I
leave it up to you and Stefan to discuss.
However, the info about whether we are in a bare repository or
.git dir is already availabe in certain variables, so we know
upfront when the current repository can't be a submodule. In
those cases this function should not be called only to spend
several subshells and command executions to figure out what we
already knew anyway.
3. The path to the .git directory of the current repository
is already available in the (not particularly descriptively named)
$g variable from __git_ps1. Perhaps you could use that variable
instead, thus avoiding a subshell and executing a git command
here.
> + module_name="$(basename "$git_dir")"
This is executed even when there is no repository in the parent
directories, but it's only needed when there _is_ a repo up there.
Please move it into the conditional below, to avoid a subshell and
command execution in the main code path.
Since this $git_dir comes directly from our own 'git rev-parse' do we
have to be prepared for a Windows-style path there? If it were always
a UNIX-style path, then we could strip all directories with shell
parameter expansion, eliminating both the subshell and the basename
execution.
> + parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2> /dev/null)"
Style nit: no space after redirection, i.e. it should be '2>/dev/null'.
More importantly, I don't think you really need this variable:
1. The existence of a parent git repository can be determined from
'git rev-parse's exit code alone.
2. When you run 'git submodule' below, you don't have to cd to the
_top-level_ directory of the parent repository's worktree. You
just have to cd to _any_ directory in the parent, and you can do
that with 'git -C "$git_dir/.." submodule ...', without knowing
the parent's top-level directory.
This means that you don't need 'git rev-parse's output, thus there is
no need for the command substitution. Yet another subshell spared! :)
However, then you have to be careful with changing directories, and
should write it as 'git -C "$git_dir/.." rev-parse ...'.
> + if [[ -n $parent_git ]]; then
Unquoted path.
> + # List all the submodule paths for the parent repo
> + while read path
> + do
> + if [[ "$path" != "$module_name" ]]; then continue; fi
> + if [[ -d "$git_dir/../$path" ]]; then return 0; fi
> + done < <(cd $parent_git && git submodule --quiet foreach 'echo $path' 2> /dev/null)
Unquoted path and space after redirection again.
This loop will get confused if one of the submodule paths contains a
newline, though probably no one in their right mind would do something
like that. Is it even possible to have a submodule name with newline
in it?
I wonder whether it would be possible to move the conditions from the
loop body to the shell command evaluated by 'submodule foreach', thus
eliminating the loop entirely and making submodule detection
newline-safe. Or whether it's worth the trouble...
> + fi
> + return 1
Indent with spaces, please use tabs instead.
> +}
> +
> +__git_ps1_submodule ()
> +{
> + __git_is_submodule && printf "sub:"
> +}
This function is unnecessary.
First, it's so short that it's body can be safely inlined in its
caller. Second, it _prints_ its output to stdout, forcing the
caller to use a command substitution. You can simply assign the value
to $sub based on __git_ps1_is_submodule()'s return value.
> +
> # __git_ps1 accepts 0 or 1 arguments (i.e., format string)
> # when called from PS1 using command substitution
> # in this mode it prints text to add to bash PS1 prompt (includes branch name)
> @@ -513,8 +543,13 @@ __git_ps1 ()
> b="\${__git_ps1_branch_name}"
> fi
>
> + local sub=""
Thank you for _not_ introducing yet another one letter variable name
:)
> + if [ -n "${GIT_PS1_SHOWSUBMODULE}" ]; then
> + sub="$(__git_ps1_submodule)"
> + fi
> +
> local f="$w$i$s$u"
> - local gitstring="$c$b${f:+$z$f}$r$p"
> + local gitstring="$c$sub$b${f:+$z$f}$r$p"
>
> if [ $pcmode = yes ]; then
> if [ "${__git_printf_supports_v-}" != yes ]; then
> --
> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 0/5] Localise error headers
From: Duy Nguyen @ 2017-01-20 13:23 UTC (permalink / raw)
To: Jeff King; +Cc: Stefan Beller, Michael J Gruber, git@vger.kernel.org
In-Reply-To: <20170111113725.avl3wetwrfezdni2@sigill.intra.peff.net>
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 no-brainer for translation, since
> the strerror() will be translated.
I agree. And the main (*) changes are relative simple too. I've tested
it a bit. Seems to work ok.
-- 8< --
diff --git a/Makefile b/Makefile
index d861bd9985..6f88c6cac5 100644
--- a/Makefile
+++ b/Makefile
@@ -2102,7 +2102,7 @@ XGETTEXT_FLAGS = \
--msgid-bugs-address="Git Mailing List <git@vger.kernel.org>" \
--from-code=UTF-8
XGETTEXT_FLAGS_C = $(XGETTEXT_FLAGS) --language=C \
- --keyword=_ --keyword=N_ --keyword="Q_:1,2"
+ --keyword=_ --keyword=N_ --keyword="Q_:1,2" --keyword=die_errno
XGETTEXT_FLAGS_SH = $(XGETTEXT_FLAGS) --language=Shell \
--keyword=gettextln --keyword=eval_gettextln
XGETTEXT_FLAGS_PERL = $(XGETTEXT_FLAGS) --language=Perl \
diff --git a/usage.c b/usage.c
index 17f52c1b5c..c022726f9c 100644
--- a/usage.c
+++ b/usage.c
@@ -159,7 +159,7 @@ void NORETURN die_errno(const char *fmt, ...)
}
va_start(params, fmt);
- die_routine(fmt_with_err(buf, sizeof(buf), fmt), params);
+ die_routine(fmt_with_err(buf, sizeof(buf), _(fmt)), params);
va_end(params);
}
-- 8< --
(*) We would need another patch to remove _() from die_errno(_(..)).
But that's something I expect coccinelle to be excel at.
--
Duy
^ permalink raw reply related
* Re: [RFC PATCH 0/5] Localise error headers
From: Duy Nguyen @ 2017-01-20 13:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Stefan Beller, Michael J Gruber, git@vger.kernel.org
In-Reply-To: <xmqq1sw9piz5.fsf@gitster.mtv.corp.google.com>
On Thu, Jan 12, 2017 at 1:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> 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 is funny, too. I think we should substitute that with
>>>
>>> die("BUG: untranslated, but what went wrong instead")
>>
>> Yep. We did not consistently use "BUG:" in the early days. I would say
>> that "BUG" lines do not need to be translated. The point is that nobody
>> should ever see them, so it seems like there is little point in giving
>> extra work to translators.
>
> In addition, "BUG: " is relatively recent introduction to our
> codebase. Perhaps having a separate BUG(<string>) function help the
> distinction further?
I was going to write the same thing. On top of that I wonder if have
enough "if (something) die("BUG:")" to justify stealing BUG_ON() from
kernel (better than assert since the condition will always be
evaluated).
--
Duy
^ permalink raw reply
* Re: merge maintaining history
From: Jakub Narębski @ 2017-01-20 11:37 UTC (permalink / raw)
To: Junio C Hamano, David J. Bakeman; +Cc: Jacob Keller, Git mailing list
In-Reply-To: <xmqq37gezpz8.fsf@gitster.mtv.corp.google.com>
W dniu 19.01.2017 o 22:42, Junio C Hamano pisze:
> "David J. Bakeman" <nakuru@comcast.net> 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
>> \
>> first branch b->c->d->e
>>
>> new repo e->f->g->h
>>
>> Now I need to merge h to F without loosing b through h hopefully. Yes e
>> was never merged back to the original repo and it's essentially gone now
>> so I can't just merge to F or can I?
>
> With the picture, I think you mean 'b' is forked from 'B' and the
> first branch built 3 more commits on top, leading to 'e'.
>
> You say "new repo" has 'e' thru 'h', and I take it to mean you
> started developing on top of the history that leads to 'e' you built
> in the first branch, and "new repo" has the resulting history that
> leads to 'h'.
>
> Unless you did something exotic and non-standard, commit 'e' in "new
> repo" would be exactly the same as 'e' sitting on the tip of the
> "first branch", so the picture would be more like:
>
>> original A->B->C->D->E->F
>> \
>> first branch b->c->d->e
>> \
>> new repo f->g->h
>
> no?
On the other hand Git has you covered even if you did something
non-standard, like starting new repo from the _state_ of 'e', that
is you have just copied files and created new repository, having
'e' (or actually 'e*') as an initial commit.
original A<-B<-C<-D<-E<-F
\
first branch b<-c<-d<-e
new repo e*<-f<-g<-h
Note that arrows are in reverse direction, as it is newer commit
pointing to its parents, not vice versa.
Assuming that you have everything in a single repository, by adding
both original and new repo as "remotes", you can use 'git replace'
command to replace 'e*' with 'e'.
original A<-B<-C<-D<-E<-F
\
first branch b<-c<-d<-e
\
new repo \-f<-g<-h
(with refs/replace)
> Then merging 'h' into 'F' will pull everything you did since
> you diverged from the history that leads to 'F', resulting in a
> history of this shape:
>
>> original A->B->C->D->E->F----------M
>> \ /
>> first branch b->c->d->e /
>> \ /
>> new repo f->g->h
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 /
/
new repo e*<-f->g->h
But as Junio said it is highly unlikely that you are in this situation.
HTH
--
Jakub Narębski
^ permalink raw reply
* Re: The design of refs backends, linked worktrees and submodules
From: Duy Nguyen @ 2017-01-20 11:22 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Git Mailing List
In-Reply-To: <341999fc-4496-b974-c117-c18a2fca1358@alum.mit.edu>
On Thu, Jan 19, 2017 at 8:30 PM, Michael Haggerty <mhagger@alum.mit.edu> 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 "<name>" could have
> been stored under "refs/worktrees/<name>/bisect/*". Then either:
>
> * teach the associated tools to read/write references there directly
> (probably with DWIM rules to make command-line use easier), or
> * treat these references as if they were actually at a standard place
> like `refs/worktree/bisect/*`; i.e., users would need to know that they
> were per-worktree references, but wouldn't need to worry about the true
> locations, or
> * treat these references as if they were actually in their traditional
> locations (though it is not obvious how this scheme could be expanded to
> cover new per-worktree references).
Well. In one direction, we store everything at one place and construct
different slices of view of the unified store. On the other far end,
we have plenty of one-purpose stores, then combine them as we need.
It's probably personal taste, but I prefer the latter.
Making a single big store could bring us closer to the "big number"
problem. Yeah we will have to handle million of refs anyway, someday.
That does not mean we're free to increase the number of refs a few
more times. Then there are separate stores by nature like submodules
(caveat: I haven't checked out your submodule-hash branch), or the
problem with multiple repos sharing objects/info/alternates.
> This is a topic that I have thought a lot about. I definitely like this
> direction. In fact I've dabbled around with some first steps; see branch
> `submodule-hash` in my fork on GitHub [1]. That branch associates a
> `ref_store` more closely with the directory where the references are
> stored, as opposed to having a 1:1 relationship between `ref_store`s and
> submodules.
Thanks. Will check it out.
> Let me braindump some more information about this topic.
> ...
Juicy stuff :D It's hard to know these without staring really long and
hard at refs code. Thank you.
> I've taken some stabs at picking these apart into separate ref stores,
> but haven't had time to make very satisfying progress. By the time of
> GitMerge I might have a better feeling for whether I can devote some
> time to this project.
I think sending WIP patches to the list from time to time is also
helpful, even if it's not perfect. For one thing I would know you were
doing (or thinking at least, which also counts) and not stepping on
each other. On my part I'm not attempting to make any more changes (*)
until after I've read your branches.
(*) I took git_path() out of refs code and was surprised that multi
worktree broke. Silly me. Wrong first step.
--
Duy
^ permalink raw reply
* Re: Git: new feature suggestion
From: Jakub Narębski @ 2017-01-20 11:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Konstantin Khomoutov, Joao Pinto, Git Mailing List,
CARLOS.PALMINHA@synopsys.com
In-Reply-To: <CA+55aFz5Rnt8U3bpvgoHQSfjPrnxnMfWUGBbHW2XKiagKXga5w@mail.gmail.com>
W dniu 20.01.2017 o 01:26, Linus Torvalds pisze:
> On Thu, Jan 19, 2017 at 1:48 PM, Jakub Narębski <jnareb@gmail.com> 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 blame".
>
> Does that actually work for people? Because it really doesn't for me.
>
> And I'm not just talking about the aesthetics of the thing, but the
> whole experience, and the whole "dig into parent" which just gives me
> an error message.
Strange. I had been using "git gui blame" _because_ of its "dig to parent"
functionality, and it worked for me just fine.
The other thing that I like about "git gui blame" is that it shows both
the commit that moved the fragment of code (via "git blame"), and the
commit that created the fragment of code (via "git blame -C -C -w", I think).
Anyway, all of this (sub)discussion is about archeology, but what might
be more important is automatic rename handling when integrating changes,
be it git-am, git-merge, or something else...
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard
From: Duy Nguyen @ 2017-01-20 11:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.20.1701201138520.3469@virtualbox>
On Fri, Jan 20, 2017 at 5:46 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> 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 command-line?
>
> Example:
>
> git log 8923d2d0 upstream/pu
>
> commit 8923d2d00192ceb1107078484cccf537cb51c1b5 (8923d2d0)
> ...
> commit 9f500d6cf5eaa49391d6deca85fc864e5bd23415 (8923d2d0^)
> ...
> commit f79c24a291a58845b08cfec7573e22cc153693e1 (8923d2d0~2)
> ...
> commit c921c5bb63baaa16dc760de9549da55c8c89dc9c (upstream/pu)
> ...
> commit 16793ba6b6333ba0cdee1adb53d979c3fbdb17bc (upstream/pu^)
> ...
>
> Granted, this is still a little more cumbersome to type than @h1, but
> then, you can skip those round-robin games as well as the possibly
> backwards-incompatible extension of the rev syntax.
I mentioned name-rev a few paragraphs down. No, I want the sweet and
short @h1 (or something like that). name-rev does not qualify. I don't
feel comfortable typing 8923d2d0 without looking at the keyboard, and
that's a lot of movement on the keyboard. upstream/pu is a bit
better, but still very long (at least for me). Yes TAB-ing does help,
but not enough. Then you'll get the dreadful "^2~1^3" dance.
--
Duy
^ permalink raw reply
* Re: [PATCH] log: new option decorate reflog of remote refs
From: Duy Nguyen @ 2017-01-20 10:55 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20170119172310.6meuj6ksxloeee2t@sigill.intra.peff.net>
On Fri, Jan 20, 2017 at 12:23 AM, Jeff King <peff@peff.net> wrote:
> I think it's a neat idea, but the actual option:
>
>> +--decorate-remote-reflog[=<n>]::
>> + Decorate `<n>` most recent reflog entries on remote refs, up
>> + to the specified number of entries. By default, only the most
>> + recent reflog entry is decorated.
>
> seems weirdly limited and non-orthogonal. What happens when somebody
> wants to decorate other reflogs besides refs/remotes?
>
> 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" applies to the next ref selector and then is
> reset, the same way --exclude is. And it includes those refs _only_ for
> decoration, not for traversal. So you could do:
>
> git log --decorate-reflog --remotes --remotes
>
> if you wanted to see use those as traversal roots, too (if this is
> common, it might even merit another option for "decorate and show").
>
> That's just off the top of my head, so maybe there are issues. I was
> just surprised to see the "-remote" part in your option name.
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
--decodate-reflog=remote, but that clashes with the number of reflog
entries and we may need a separator, like --decorate-reflog=remote,3.
Or we could add something to --decorate= in addition to
short|full|auto|no. Something like --decorate=full,reflog or
--decorate=full,reflog=remote,entries=3 if I want 3 reflog entries.
My hesitant to go that far is because I suspect decorating reflog
won't be helpful for non-remotes. But I'm willing to make more changes
if it opens door to master.
--
Duy
^ permalink raw reply
* Re: Git: new feature suggestion
From: Joao Pinto @ 2017-01-20 10:44 UTC (permalink / raw)
To: Stefan Beller, Joao Pinto
Cc: Linus Torvalds, Konstantin Khomoutov, Git Mailing List,
CARLOS.PALMINHA@synopsys.com
In-Reply-To: <CAGZ79kZ3g+J5=ZmP8zDCK8zBwMc7SwLdmgyB3Sab8qkTE=enhQ@mail.gmail.com>
Hi Stefan,
Às 10:03 PM de 1/19/2017, Stefan Beller escreveu:
> On Thu, Jan 19, 2017 at 1:51 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> Às 7:16 PM de 1/19/2017, Linus Torvalds escreveu:
>>> On Thu, Jan 19, 2017 at 10:54 AM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>>
>>>> I am currently facing some challenges in one of Linux subsystems where a rename
>>>> of a set of folders and files would be the perfect scenario for future
>>>> development, but the suggestion is not accepted, not because it's not correct,
>>>> but because it makes the maintainer life harder in backporting bug fixes and new
>>>> features to older kernel versions and because it is not easy to follow the
>>>> renamed file/folder history from the kernel.org history logs.
>>>
>>> Honestly, that's less of a git issue, and more of a "patch will not
>>> apply across versions" issue.
>>>
>>> No amount of rename detection will ever fix that, simply because the
>>> rename hadn't even _happened_ in the old versions that things get
>>> backported to.
>>>
>>> ("git cherry-pick" can do a merge resolution and thus do "backwards"
>>> renaming too, so tooling can definitely help, but it still ends up
>>> meaning that even trivial patches are no longer the _same_ trivial
>>> patch across versions).
>>>
>>> So renaming things increases maintainer workloads in those situations
>>> regardless of any tooling issues.
>>>
>>> (You may also be referring to the mellanox mess, where this issue is
>>> very much exacerbated by having different groups working on the same
>>> thing, and maintainers having very much a "I will not take _anything_
>>> from any of the groups that makes my life more complicated" model,
>>> because those groups fucked up so much in the past).
>>>
>>> In other words, quite often issues are about workflows rather than
>>> tools. The networking layer probably has more of this, because David
>>> actually does the backports himself, so he _really_ doesn't want to
>>> complicate things.
>>
>> I totally understand David' side! Synopsys is a well-known IP Vendor, and for a
>> long time its focus was the IP only. Knowadays the strategy has changed and
>> Synopsys is very keen to help in Open Source, namelly Linux, developing the
>> drivers for new IP Cores and participating in the improvement of existing ones.
>> I am part of the team that has that job.
>>
>> In USB and PCI subystems developers created common Synopsys drivers (focused on
>> the HW IP) and so today they are massively used by all the SoC that use Synopsys
>> IP.
>>
>> In the network subsystem, there are some drivers that target the same IP but
>> were made by different companies. stmmac is an excelent driver for Synopsys MAC
>> 10/100/1000/QOS IPs, but there was another driver made by AXIS driver that also
>> targeted the QOS IP. We detected that issue and merged the AXIS specific driver
>> ops to stmmac, and nowadays, AXIS uses stmmac. So less drivers to maintain!
>>
>> The idea that was rejected consisted of renaming stmicro/stmmac to dwc/stmmac
>> and to have dwc (designware controllers) as the official driver spot for
>> Synopsys Ethernet IPs.
>> There is another example of duplication, which is AMD' and Samsung' XGMAC
>> driver, targeting the same Synopsys XGMAC IP.
>>
>> I am giving this examples because although the refactor adds work for
>> backporting, it reduces the maintenance since we would have less duplicated
>> drivers as we have today.
>
> This sounds as if the code in question would only receive backports
> for a specific
> time (determined by HW lifecycle, maintenance life cycle and such).
>
> So I wonder if this could be solved by not just renaming but
> additionally adding a
> symbolic link, such that the files in question seem to appear twice on
> the file system.
> Then backports ought to be applicable (hoping git-am doesn't choke on symlinks),
> and after a while once the there no backports any more (due to life
> cycle reasons),
> remove the link?
>
> This also sounds like a kind of problem, that others have run into before,
> how did they solve it?
I am currently involved in the PCI host/ refactor process and that will cause a
total reorganization of the folder, because a new PCIe Endpoint is comming up
from Texas Instruments. Bjorn (PCI Maintainer) is ok with it.
The network subsystem, is a very busy one, with lots of activity, and so I
understand David Miller' point, because he already has work overload, but we
have to find a way to improve it and prepare for the future.
I think this a hot topic, that should be discussed, since it might hold back the
evolution of some subystems.
Thanks,
Joao
>
> Thanks,
> Stefan
>
>>
>> Thanks,
>> Joao
>>
>>
>>> Linus
>>>
>>
^ permalink raw reply
* Re: [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard
From: Johannes Schindelin @ 2017-01-20 10:46 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20170120102249.15572-1-pclouds@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]
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" 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 command-line?
Example:
git log 8923d2d0 upstream/pu
commit 8923d2d00192ceb1107078484cccf537cb51c1b5 (8923d2d0)
...
commit 9f500d6cf5eaa49391d6deca85fc864e5bd23415 (8923d2d0^)
...
commit f79c24a291a58845b08cfec7573e22cc153693e1 (8923d2d0~2)
...
commit c921c5bb63baaa16dc760de9549da55c8c89dc9c (upstream/pu)
...
commit 16793ba6b6333ba0cdee1adb53d979c3fbdb17bc (upstream/pu^)
...
Granted, this is still a little more cumbersome to type than @h1, but
then, you can skip those round-robin games as well as the possibly
backwards-incompatible extension of the rev syntax.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v3 14/21] read-cache: touch shared index files when used
From: Duy Nguyen @ 2017-01-20 10:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, git, Ævar Arnfjörð Bjarmason,
Christian Couder
In-Reply-To: <xmqqlgu627uj.fsf@gitster.mtv.corp.google.com>
On Fri, Jan 20, 2017 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Mon, Jan 9, 2017 at 9:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Duy Nguyen <pclouds@gmail.com> writes:
>>>
>>>> On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> Christian Couder <christian.couder@gmail.com> writes:
>>>>>
>>>>>> So what should we do if freshen_file() returns 0 which means that the
>>>>>> freshening failed?
>>>>>
>>>>> You tell me ;-) as you are the one who is proposing this feature.
>>>>
>>>> My answer is, we are not worse than freshening loose objects case
>>>> (especially since I took the idea from there).
>>>
>>> I do not think so, unfortunately. Loose object files with stale
>>> timestamps are not removed as long as objects are still reachable.
>>
>> But there are plenty of unreachable loose objects, added in index,
>> then got replaced with new versions. cache-tree can create loose trees
>> too and it's been run more often, behind user's back, to take
>> advantage of the shortcut in unpack-trees.
>
> I am not sure if I follow. Aren't objects reachable from the
> cache-tree in the index protected from gc?
I think the problem is loose objects created then gc run just before
they are referenced (e.g. index written down). But I think I may be
following a wrong road. If mtime is in fact to deal with race
conditions, applying the same idea here is wrong because we have a
different problem here.
> Not that I think freshening would actually fail in a repository
> where you can actually write into to update the index or its refs to
> make a difference (iow, even if we make it die() loudly when shared
> index cannot be "touched" because we are paranoid, no real life
> usage will trigger that die(), and if a repository does trigger the
> die(), I think you would really want to know about it).
--
Duy
^ permalink raw reply
* [PATCH/TOY] Shortcuts to quickly refer to a commit name with keyboard
From: Nguyễn Thái Ngọc Duy @ 2017-01-20 10:22 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
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 form longer,
harder to type. Most of the time I just go with copy/paste with the
mouse, which I don't like. name-rev helps a bit, but it's still long
to type (especially with all the ^ and ~ that requires holding shift
down).
So, this patch adds an option --mark-commits to git-log. Whenever a
commit SHA-1 is printed on screen, it gets a new shortcut in form of
<at-sign><one-letter><number> e.g. @h2. The number keeps increasing
during one git-log, so you'll get @h1, @h2, @h3 and so on. Typing @h3
gets you back to the associated SHA-1.
Different git-log runs will change the <one-letter> part. So the
second git-log run may give you @j1, @j2, @j3... This is useful
because sometimes you want to run more than one command, then
reference back to commits from the first command.
There's a limited number of letters to be used here. I limit it to the
letters on the home row to avoid moving fingers too much. Which means
after like 9 runs, @h is recycled for something new. Not great if you
have "git blah blah @h2" in bash history and keep recalling it from
time to time.
So, whenever you use a shortcut, the shortcut is kept in a "database"
and will not be recycled for quite some time. When @h is recycled,
you'll get @h1, then @h3 and so on if @h2 has just been used recently.
This makes sure recently used shortcuts live on.
That's it. I have to say typing 3-4 characters is really nice. I kinda
want to reduce the number of keystokes further down, but it's been good
enough that I'm not so pissed to spend time tuning it further.
This shortcut format violates the extended sha1 syntax, I think. In
order have any chance of entering git, we'll have to deal with that
first.
---
Makefile | 1 +
commit.h | 1 +
log-tree.c | 7 +++
pretty.c | 5 ++
rev-counter.c (new) | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++
rev-counter.h (new) | 10 ++++
revision.c | 4 ++
revision.h | 1 +
sha1_name.c | 8 +++
9 files changed, 203 insertions(+)
create mode 100644 rev-counter.c
create mode 100644 rev-counter.h
diff --git a/Makefile b/Makefile
index de5a030256..28948bd9eb 100644
--- a/Makefile
+++ b/Makefile
@@ -788,6 +788,7 @@ LIB_OBJS += replace_object.o
LIB_OBJS += rerere.o
LIB_OBJS += resolve-undo.o
LIB_OBJS += revision.o
+LIB_OBJS += rev-counter.o
LIB_OBJS += run-command.o
LIB_OBJS += send-pack.o
LIB_OBJS += sequencer.o
diff --git a/commit.h b/commit.h
index b06db4d5d9..8f67687208 100644
--- a/commit.h
+++ b/commit.h
@@ -155,6 +155,7 @@ struct pretty_print_context {
struct string_list *mailmap;
int color;
struct ident_split *from_ident;
+ int mark_commits;
/*
* Fields below here are manipulated internally by pp_* functions and
diff --git a/log-tree.c b/log-tree.c
index 78a5381d0e..f49366b376 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -11,6 +11,7 @@
#include "gpg-interface.h"
#include "sequencer.h"
#include "line-log.h"
+#include "rev-counter.h"
static struct decoration name_decoration = { "object names" };
static int decoration_loaded;
@@ -593,6 +594,9 @@ void show_log(struct rev_info *opt)
}
opt->shown_one = 1;
+ if (opt->mark_commits)
+ mark_commit(&commit->object.oid);
+
/*
* If the history graph was requested,
* print the graph, up to this commit's line
@@ -615,6 +619,8 @@ void show_log(struct rev_info *opt)
put_revision_mark(opt, commit);
fputs(find_unique_abbrev(commit->object.oid.hash, abbrev_commit),
stdout);
+ if (opt->mark_commits)
+ printf(" @%s", oid_to_commit_mark(&commit->object.oid));
if (opt->print_parents)
show_parents(commit, abbrev_commit);
if (opt->children.name)
@@ -687,6 +693,7 @@ void show_log(struct rev_info *opt)
ctx.output_encoding = get_log_output_encoding();
if (opt->from_ident.mail_begin && opt->from_ident.name_begin)
ctx.from_ident = &opt->from_ident;
+ ctx.mark_commits = opt->mark_commits;
pretty_print_commit(&ctx, commit, &msgbuf);
if (opt->add_signoff)
diff --git a/pretty.c b/pretty.c
index c3ec430220..14e0022085 100644
--- a/pretty.c
+++ b/pretty.c
@@ -10,6 +10,7 @@
#include "color.h"
#include "reflog-walk.h"
#include "gpg-interface.h"
+#include "rev-counter.h"
static char *user_format;
static struct cmt_fmt_map {
@@ -1127,6 +1128,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
case 'H': /* commit hash */
strbuf_addstr(sb, diff_get_color(c->auto_color, DIFF_COMMIT));
strbuf_addstr(sb, oid_to_hex(&commit->object.oid));
+ if (c->pretty_ctx->mark_commits)
+ strbuf_addf(sb, " @%s", oid_to_commit_mark(&commit->object.oid));
strbuf_addstr(sb, diff_get_color(c->auto_color, DIFF_RESET));
return 1;
case 'h': /* abbreviated commit hash */
@@ -1137,6 +1140,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
}
strbuf_addstr(sb, find_unique_abbrev(commit->object.oid.hash,
c->pretty_ctx->abbrev));
+ if (c->pretty_ctx->mark_commits)
+ strbuf_addf(sb, " @%s", oid_to_commit_mark(&commit->object.oid));
strbuf_addstr(sb, diff_get_color(c->auto_color, DIFF_RESET));
c->abbrev_commit_hash.len = sb->len - c->abbrev_commit_hash.off;
return 1;
diff --git a/rev-counter.c b/rev-counter.c
new file mode 100644
index 0000000000..60ab991fe1
--- /dev/null
+++ b/rev-counter.c
@@ -0,0 +1,166 @@
+#include "cache.h"
+#include "strbuf.h"
+#include "commit.h"
+#include "commit-slab.h"
+
+define_commit_slab(counter, char *);
+struct counter counter = COMMIT_SLAB_INIT(1, counter);
+
+static unsigned commit_counter;
+static int run_counter;
+int latest_fd = -1;
+struct strbuf recent = STRBUF_INIT;
+
+/* home row, except 'l' which looks too much like '1' */
+const char *starter = "asdfghjk";
+
+static void start_marking(void)
+{
+ char buf[64];
+ ssize_t len;
+
+ len = readlink(git_path("rev-counter/latest"), buf, sizeof(buf));
+ if (len == -1) {
+ if (errno != ENOENT)
+ die_errno("failed to open rev-counter/latest");
+ } else {
+ char ch, *p;
+ sscanf(buf, "%c", &ch);
+ p = strchrnul(starter, ch);
+ run_counter = ((p - starter) + 1) % strlen(starter);
+ }
+
+ if (!is_directory(git_path("rev-counter")))
+ mkdir(git_path("rev-counter"), 0755);
+ latest_fd = open(git_path("rev-counter/%c", starter[run_counter]),
+ O_RDWR | O_CREAT | O_TRUNC, 0644);
+ if (latest_fd == -1)
+ die_errno("failed to create new rev-counter");
+
+ sprintf(buf, "%c", starter[run_counter]);
+ (void)unlink(git_path("rev-counter/latest"));
+ if (symlink(buf, git_path("rev-counter/latest")))
+ die_errno("failed to update rev-counter/latest");
+}
+
+static int strbuf_find_commit_mark(const struct strbuf *sb,
+ const char *mark,
+ struct object_id *oid)
+{
+ const char *p, *end;
+ int ret = -1;
+
+ end = sb->buf + sb->len;
+ p = sb->buf;
+ while (p < end && ret < 0) {
+ const char *next = strchrnul(p, '\n');
+
+ if (next - p > 41 &&
+ p[40] == ' ' &&
+ p + 41 + strlen(mark) == next &&
+ !strncmp(p + 41, mark, strlen(mark)) &&
+ !get_oid_hex(p, oid))
+ ret = 0;
+
+ p = next;
+ if (*p == '\n')
+ p++;
+ }
+ return ret;
+}
+
+void update_commit_counter(void)
+{
+ static int read_recent;
+ struct object_id oid;
+ char buf[16];
+
+ if (!read_recent) {
+ strbuf_read_file(&recent, git_path("rev-counter/recent"), 0);
+ read_recent = 1;
+
+ if (recent.len > 1000 * 45) { /* prune time? */
+ int fd;
+ const char *p = strchr(recent.buf + 1000 * 45, '\n');
+ strbuf_remove(&recent, 0, p + 1 - recent.buf);
+ if (!is_directory(git_path("rev-counter")))
+ mkdir(git_path("rev-counter"), 0755);
+ fd = open(git_path("rev-counter/recent"),
+ O_CREAT | O_TRUNC | O_RDWR, 0644);
+ write_or_die(fd, recent.buf, recent.len);
+ close(fd);
+ }
+ }
+
+ do {
+ commit_counter++;
+ sprintf(buf, "%c%u", starter[run_counter], commit_counter);
+ } while (!strbuf_find_commit_mark(&recent, buf, &oid));
+}
+
+void mark_commit(const struct object_id *oid)
+{
+ struct commit *c;
+ char buf[64];
+ char **val;
+
+ if (latest_fd < 0)
+ start_marking();
+
+ if (!(c = lookup_commit(oid->hash)))
+ return;
+
+ update_commit_counter();
+ sprintf(buf, "%s %u\n", oid_to_hex(oid), commit_counter);
+ write_or_die(latest_fd, buf, strlen(buf));
+
+ sprintf(buf, "%c%u", starter[run_counter], commit_counter);
+ val = counter_at(&counter, c);
+ *val = xstrdup(buf);
+}
+
+const char *oid_to_commit_mark(const struct object_id *oid)
+{
+ struct commit *c;
+ char **val;
+
+ if (!(c = lookup_commit(oid->hash)) ||
+ !(val = counter_peek(&counter, c)))
+ return NULL;
+
+ return *val;
+}
+
+int commit_mark_to_oid(const char *mark, struct object_id *oid)
+{
+ char buf[16];
+ int ret, c;
+ char r_ch;
+ struct strbuf sb = STRBUF_INIT;
+
+ if (sscanf(mark, "%c%u", &r_ch, &c) != 2 ||
+ !strchr(starter, r_ch) ||
+ strbuf_read_file(&sb, git_path("rev-counter/%c", r_ch), 0) < 0)
+ return -1;
+
+ sprintf(buf, "%u", c);
+ ret = strbuf_find_commit_mark(&sb, buf, oid);
+ strbuf_release(&sb);
+
+ if (!ret) {
+ char line[80];
+ static int fd;
+
+ if (!fd) {
+ if (!is_directory(git_path("rev-counter")))
+ mkdir(git_path("rev-counter"), 0755);
+ fd = open(git_path("rev-counter/recent"),
+ O_CREAT | O_RDWR | O_APPEND, 0644);
+ if (fd == -1)
+ die("failed to open rev-counter/recent");
+ }
+ sprintf(line, "%s %s\n", oid_to_hex(oid), mark);
+ write_or_die(fd, line, strlen(line));
+ }
+ return ret;
+}
diff --git a/rev-counter.h b/rev-counter.h
new file mode 100644
index 0000000000..ab2e8d8803
--- /dev/null
+++ b/rev-counter.h
@@ -0,0 +1,10 @@
+#ifndef __REV_COUNTER_H__
+#define __REV_COUNTER_H__
+
+struct object_id;
+
+void mark_commit(const struct object_id *oid);
+const char *oid_to_commit_mark(const struct object_id *oid);
+int commit_mark_to_oid(const char *mark, struct object_id *oid);
+
+#endif
diff --git a/revision.c b/revision.c
index 2f60062876..1e32e91b9f 100644
--- a/revision.c
+++ b/revision.c
@@ -1998,6 +1998,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->limited = 1;
} else if (!strcmp(arg, "--ignore-missing")) {
revs->ignore_missing = 1;
+ } else if (!strcmp(arg, "--mark-commits")) {
+ revs->mark_commits = 1;
+ } else if (!strcmp(arg, "--no-mark-commits")) {
+ revs->mark_commits = 0;
} else {
int opts = diff_opt_parse(&revs->diffopt, argv, argc, revs->prefix);
if (!opts)
diff --git a/revision.h b/revision.h
index 9fac1a607d..94e5b70ff5 100644
--- a/revision.h
+++ b/revision.h
@@ -146,6 +146,7 @@ struct rev_info {
unsigned int track_linear:1,
track_first_time:1,
linear:1;
+ unsigned int mark_commits:1;
struct date_mode date_mode;
int expand_tabs_in_log; /* unset if negative */
diff --git a/sha1_name.c b/sha1_name.c
index ca7ddd6f2c..d3e1ff3921 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -7,6 +7,7 @@
#include "refs.h"
#include "remote.h"
#include "dir.h"
+#include "rev-counter.h"
static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *);
@@ -485,6 +486,13 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1,
}
return 0;
}
+ if (len > 2 && str[0] == '@' && isalpha(str[1]) && isdigit(str[2])) {
+ struct object_id oid;
+ if (!commit_mark_to_oid(str + 1, &oid)) {
+ hashcpy(sha1, oid.hash);
+ return 0;
+ }
+ }
/* basic@{time or number or -number} format to query ref-log */
reflog_len = at = 0;
--
2.11.0.157.gd943d85
^ permalink raw reply related
* Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]
From: Stefan Beller @ 2017-01-20 1:22 UTC (permalink / raw)
To: Brian J. Davis; +Cc: Brandon Williams, git@vger.kernel.org, David Turner
In-Reply-To: <e6c5567a-2032-c598-97c8-08518f86b611@gmail.com>
>> Between the init and the update step you can modify the URLs.
>> These commands are just a repetition from the first email, but the
>> git commands can be viewed as moving from one state to another
>> for submodules; submodules itself can be seen as a state machine
>> according to that proposed documentation. Maybe such a state machine
>> makes it easier to understand for some people.
>
>
> "Between the init and the update step you can modify the URLs." Yes I can
> and have to... wish it was not this way.
So how would yo u rather want to do it?
look at the .gitmodules file beforehand and then run a "submodule update" ?
Or a thing like
git -c url.https://internal.insteadOf git://github.com/ \
-c submodule.record-rewritten-urls submodule update
(no need for init there as theoretically there is not
need for such an intermediate step)
>> [remote "origin"]
>> url = https://github.com/..
>> [remote "inhouse"]
>> url = https://inhouse.corp/..
>>
>> But where do we clone it from?
>> (Or do we just do a "git init" on that submodule and fetch
>> from both remotes? in which order?)
>
> origin by default and inhouse if specified. There is already a implied
> default (origin). The idea was not to do both but rather what is specified.
> Origin and inhouse are just names for remotes. If one wanted a
> "--all-remotes" could pull from everywhere in the Ether if feature was to be
> implemented.
How is origin implied to be the default?
Should there be an order (e.g. if you cannot find it at inhouse get it
from github,
if they are down, get it from kernel.org)
^ permalink raw reply
* Re: [PATCH] git-prompt.sh: add submodule indicator
From: Stefan Beller @ 2017-01-20 0:28 UTC (permalink / raw)
To: Benjamin Fuchs
Cc: git@vger.kernel.org, szeder.dev, felipe.contreras, ville.skytta
In-Reply-To: <1484870858-6336-1-git-send-email-email@benjaminfuchs.de>
On Thu, Jan 19, 2017 at 4:07 PM, Benjamin Fuchs <email@benjaminfuchs.de> wrote:
> I expirienced that working with submodules can be confusing. This indicator
> will make you notice very easy when you switch into a submodule.
> The new prompt will look like this: (sub:master)
> Adding a new optional env variable for the new feature.
>
> Signed-off-by: Benjamin Fuchs <email@benjaminfuchs.de>
Thanks for making submodules better :)
Relevant tangent, just posted today:
https://public-inbox.org/git/20170119193023.26837-1-sbeller@google.com/T/#u
> ---
> contrib/completion/git-prompt.sh | 37 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 97eacd7..4c82e7f 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -93,6 +93,10 @@
> # directory is set up to be ignored by git, then set
> # GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
> # repository level by setting bash.hideIfPwdIgnored to "false".
> +#
> +# If you would like __git_ps1 to indicate that you are in a submodule,
> +# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before
> +# the branch name.
>
> # check whether printf supports -v
> __git_printf_supports_v=
> @@ -284,6 +288,32 @@ __git_eread ()
> test -r "$f" && read "$@" <"$f"
> }
>
> +# __git_is_submodule
> +# Based on:
> +# http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule
> +__git_is_submodule ()
> +{
> + local git_dir parent_git module_name path
> + # Find the root of this git repo, then check if its parent dir is also a repo
> + git_dir="$(git rev-parse --show-toplevel)"
> + module_name="$(basename "$git_dir")"
> + parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2> /dev/null)"
I wonder if we want to have better plumbing commands for submodules
here as well:
Here we only check if we have an embedded git repository, which may not be a
submodule. It could be a standalone repo that just happens to be inside another.
It could be a fake submodule [1], though I think the last time I
brought these up,
the upstream Git community considered these fake submodules are bug not worth
fixing.
And this doesn't cover the case that I addressed in the RFC-ish patch above:
$ git submodule deinit --all
$ cd <submodule> && git status
# in an ideal world this tells you:
# "You are in an un-populated submodule. To change the submodule state..."
So I guess this is a good first approximation that actually gets most
of the cases right,
thereby helping a lot of people. But I wonder about these cornercases as well?
[1] debuggable.com/posts/git-fake-submodules:4b563ee4-f3cc-4061-967e-0e48cbdd56cb
Thanks,
Stefan
^ permalink raw reply
* Re: Git: new feature suggestion
From: Linus Torvalds @ 2017-01-20 0:26 UTC (permalink / raw)
To: Jakub Narębski
Cc: Konstantin Khomoutov, Joao Pinto, Git Mailing List,
CARLOS.PALMINHA@synopsys.com
In-Reply-To: <b96b71b9-f8a2-d039-6e8a-c64e7aac02a0@gmail.com>
On Thu, Jan 19, 2017 at 1:48 PM, Jakub Narębski <jnareb@gmail.com> 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 blame".
Does that actually work for people? Because it really doesn't for me.
And I'm not just talking about the aesthetics of the thing, but the
whole experience, and the whole "dig into parent" which just gives me
an error message.
Linus
^ permalink raw reply
* [PATCH] git-prompt.sh: add submodule indicator
From: Benjamin Fuchs @ 2017-01-20 0:07 UTC (permalink / raw)
To: git; +Cc: szeder.dev, felipe.contreras, ville.skytta, email
I expirienced that working with submodules can be confusing. This indicator
will make you notice very easy when you switch into a submodule.
The new prompt will look like this: (sub:master)
Adding a new optional env variable for the new feature.
Signed-off-by: Benjamin Fuchs <email@benjaminfuchs.de>
---
contrib/completion/git-prompt.sh | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 97eacd7..4c82e7f 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -93,6 +93,10 @@
# directory is set up to be ignored by git, then set
# GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
# repository level by setting bash.hideIfPwdIgnored to "false".
+#
+# If you would like __git_ps1 to indicate that you are in a submodule,
+# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before
+# the branch name.
# check whether printf supports -v
__git_printf_supports_v=
@@ -284,6 +288,32 @@ __git_eread ()
test -r "$f" && read "$@" <"$f"
}
+# __git_is_submodule
+# Based on:
+# http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule
+__git_is_submodule ()
+{
+ local git_dir parent_git module_name path
+ # Find the root of this git repo, then check if its parent dir is also a repo
+ git_dir="$(git rev-parse --show-toplevel)"
+ module_name="$(basename "$git_dir")"
+ parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2> /dev/null)"
+ if [[ -n $parent_git ]]; then
+ # List all the submodule paths for the parent repo
+ while read path
+ do
+ if [[ "$path" != "$module_name" ]]; then continue; fi
+ if [[ -d "$git_dir/../$path" ]]; then return 0; fi
+ done < <(cd $parent_git && git submodule --quiet foreach 'echo $path' 2> /dev/null)
+ fi
+ return 1
+}
+
+__git_ps1_submodule ()
+{
+ __git_is_submodule && printf "sub:"
+}
+
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
# when called from PS1 using command substitution
# in this mode it prints text to add to bash PS1 prompt (includes branch name)
@@ -513,8 +543,13 @@ __git_ps1 ()
b="\${__git_ps1_branch_name}"
fi
+ local sub=""
+ if [ -n "${GIT_PS1_SHOWSUBMODULE}" ]; then
+ sub="$(__git_ps1_submodule)"
+ fi
+
local f="$w$i$s$u"
- local gitstring="$c$b${f:+$z$f}$r$p"
+ local gitstring="$c$sub$b${f:+$z$f}$r$p"
if [ $pcmode = yes ]; then
if [ "${__git_printf_supports_v-}" != yes ]; then
--
2.7.4
^ permalink raw reply related
* Re: [RFC for GIT] pull-request: add praise to people doing QA
From: Jacob Keller @ 2017-01-20 0:13 UTC (permalink / raw)
To: Joe Perches
Cc: Jeff King, Wolfram Sang, Junio C Hamano, Git mailing list,
linux-kernel@vger.kernel.org
In-Reply-To: <1484870777.2707.2.camel@perches.com>
On Thu, Jan 19, 2017 at 4:06 PM, Joe Perches <joe@perches.com>
wrote:>> This sounds interesting to me! When I have some more time to
take a
>> look at this i might see if I can revive it.
>
> Can the terminology please be standardized to what
> was once called bylines?
>
> https://patchwork.kernel.org/patch/9307703/
>
I am fairly certain we've settled on "trailers" at this point. I don't
have an objection to either name, but most of the code today uses
trailers.
Thanks,
Jake
^ permalink raw reply
* Re: [RFC for GIT] pull-request: add praise to people doing QA
From: Joe Perches @ 2017-01-20 0:06 UTC (permalink / raw)
To: Jacob Keller, Jeff King
Cc: Wolfram Sang, Junio C Hamano, Git mailing list,
linux-kernel@vger.kernel.org
In-Reply-To: <CA+P7+xo5N66a8-PeNRLBgwRN3rJZRbQuDnx8wCnW7L-0tz10Fg@mail.gmail.com>
On Thu, 2017-01-19 at 15:42 -0800, Jacob Keller wrote:
> On Thu, Jan 19, 2017 at 1:20 PM, Jeff King <peff@peff.net> wrote:
> > On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote:
> >
> > > > As to the implementation, I am wondering if we can make this somehow
> > > > work well with the "trailers" code we already have, instead of
> > > > inventing yet another parser of trailers.
> > > >
> > > > In its current shape, "interpret-trailers" focuses on "editing" an
> > > > existing commit log message to tweak the trailer lines. That mode
> > > > of operation would help amending and rebasing, and to do that it
> > > > needs to parse the commit log message, identify trailer blocks,
> > > > parse out each trailer lines, etc.
> > > >
> > > > There is no fundamental reason why its output must be an edited
> > > > original commit log message---it should be usable as a filter that
> > > > picks trailer lines of the selected trailer type, like "Tested-By",
> > > > etc.
> > >
> > > I didn't know about trailers before. As I undestand it, I could use
> > > "Tested-by" as the key, and the commit subject as the value. This list
> > > then could be parsed and brought into proper output shape. It would
> > > simplify the subject parsing, but most things my AWK script currently
> > > does would still need to stay or to be reimplemented (extracting names
> > > from tags, creating arrays of tags given by $name). Am I correct?
> > >
> > > All under the assumption that trailers work on a range of commits. I
> > > have to admit that adding this to git is beyond my scope.
> >
> > This sounds a lot like the shortlog-trailers work I did about a year
> > ago:
> >
> > http://public-inbox.org/git/20151229073832.GN8842@sigill.intra.peff.net/
> >
> > http://public-inbox.org/git/20151229075013.GA9191@sigill.intra.peff.net/
> >
> > Nobody seemed to really find it useful, so I didn't pursue it.
> >
> > Some of the preparatory patches in that series bit-rotted in the
> > meantime, but you can play with a version based on v2.7.0 by fetching
> > the "shortlog-trailers-historical" branch from
> > https://github.com/peff/git.git.
> >
> > And then things like:
> >
> > git shortlog --ident=tested-by --format='...tested a patch by %an'
> >
> > work (and you can put whatever commit items you want into the --format,
> > including just dumping the hash if you want to do more analysis).
> >
> > -Peff
>
> This sounds interesting to me! When I have some more time to take a
> look at this i might see if I can revive it.
Can the terminology please be standardized to what
was once called bylines?
https://patchwork.kernel.org/patch/9307703/
^ permalink raw reply
* Post-merge hook
From: Ilesh Mistry @ 2017-01-19 23:54 UTC (permalink / raw)
To: git@vger.kernel.org
Hello
I have been looking around for this, but I can't seem to find any examples of how to use the git post-merge hook. Can you help me please?
I want to do something really simple in the sense of pulling locally and once pulled and merged any conflicts (if any) then run a command line code. But run this code after any merge conflicts are resolved.
Can you help me by pointing me into the right direction on how I can resolve this please?
Thanks
Ilesh
Sent from my iPhone
Ilesh Mistry
Kentico Technical Architect
T 01572 822 278
www.mmtdigital.co.uk <http://www.mmtdigital.co.uk>
RAR Digital Awards Winner 2016: Best Web Development Agency in the UK
RAR Digital Awards Winner 2016: Best Software Development Agency in the UK
RAR Digital Awards Winner 2016: Best Analytics Agency in the UK
RAR Digital Awards Winner 2015: Best Web Design Agency in the UK
Econsultancy 2016 Top 100 Agency
The Drum Digital Census 2015: Elite Agency Top 10
Participation in this email correspondence denotes acceptance of
terms and conditions available on request or from our website,
unless a separate contract has been agreed.
Registered Office: 1A Uppingham Gate, Ayston Road, Uppingham, Rutland, LE15 9NY
Company Number: 3681297
VAT Registration: 638 5654 05
^ permalink raw reply
* Re: [PATCH v4 2/5] name-rev: extend --refs to accept multiple patterns
From: Jacob Keller @ 2017-01-19 23:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jacob Keller, Git mailing list, Johannes Sixt,
Johannes Schindelin
In-Reply-To: <xmqqfukezrmh.fsf@gitster.mtv.corp.google.com>
On Thu, Jan 19, 2017 at 1:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.e.keller@intel.com> writes:
>
>> From: Jacob Keller <jacob.keller@gmail.com>
>>
>> Teach git name-rev to take multiple --refs stored as a string list of
>> patterns. The list of patterns will be matched inclusively, and each ref
>> only needs to match one pattern to be included. A ref will only be
>> excluded if it does not match any of the given patterns. Additionally,
>> if any of the patterns would allow abbreviation, then we will abbreviate
>> the ref, even if another pattern is more strict and would not have
>> allowed abbreviation on its own.
>>
>> Add tests and documentation for this change. The tests expected output
>> is dynamically generated, but this is in order to avoid hard-coding
>> a commit object id in the test results (as the expected output is to
>> simply leave the commit object unnamed).
>
> Makes sense.
>
> I do not see anything that requires "... generated, but" there,
> though, as if it is a bad thing to do to prepare expected output
> dynamically. I'd just reword "generated. This is..." to make it
> neutral.
To clarify my earlier comment, I think the SQUASH?? you queued looks great.
Thanks,
Jake
^ permalink raw reply
* Re: [RFC for GIT] pull-request: add praise to people doing QA
From: Jacob Keller @ 2017-01-19 23:42 UTC (permalink / raw)
To: Jeff King
Cc: Wolfram Sang, Junio C Hamano, Git mailing list,
linux-kernel@vger.kernel.org
In-Reply-To: <20170119212039.3gixsrk7qco45wjo@sigill.intra.peff.net>
On Thu, Jan 19, 2017 at 1:20 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote:
>
>> > As to the implementation, I am wondering if we can make this somehow
>> > work well with the "trailers" code we already have, instead of
>> > inventing yet another parser of trailers.
>> >
>> > In its current shape, "interpret-trailers" focuses on "editing" an
>> > existing commit log message to tweak the trailer lines. That mode
>> > of operation would help amending and rebasing, and to do that it
>> > needs to parse the commit log message, identify trailer blocks,
>> > parse out each trailer lines, etc.
>> >
>> > There is no fundamental reason why its output must be an edited
>> > original commit log message---it should be usable as a filter that
>> > picks trailer lines of the selected trailer type, like "Tested-By",
>> > etc.
>>
>> I didn't know about trailers before. As I undestand it, I could use
>> "Tested-by" as the key, and the commit subject as the value. This list
>> then could be parsed and brought into proper output shape. It would
>> simplify the subject parsing, but most things my AWK script currently
>> does would still need to stay or to be reimplemented (extracting names
>> from tags, creating arrays of tags given by $name). Am I correct?
>>
>> All under the assumption that trailers work on a range of commits. I
>> have to admit that adding this to git is beyond my scope.
>
> This sounds a lot like the shortlog-trailers work I did about a year
> ago:
>
> http://public-inbox.org/git/20151229073832.GN8842@sigill.intra.peff.net/
>
> http://public-inbox.org/git/20151229075013.GA9191@sigill.intra.peff.net/
>
> Nobody seemed to really find it useful, so I didn't pursue it.
>
> Some of the preparatory patches in that series bit-rotted in the
> meantime, but you can play with a version based on v2.7.0 by fetching
> the "shortlog-trailers-historical" branch from
> https://github.com/peff/git.git.
>
> And then things like:
>
> git shortlog --ident=tested-by --format='...tested a patch by %an'
>
> work (and you can put whatever commit items you want into the --format,
> including just dumping the hash if you want to do more analysis).
>
> -Peff
This sounds interesting to me! When I have some more time to take a
look at this i might see if I can revive it.
Thanks,
Jake
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox