* Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)
From: Jacob Keller @ 2017-02-07 1:17 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Karthik Nayak, Git mailing list
In-Reply-To: <CAM0VKjmhO9NQLz9TDv5M3OhxSBt-JdjaouVT0pTA-a6mGaF4_A@mail.gmail.com>
On Mon, Feb 6, 2017 at 4:24 PM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
>> * sg/completion-refs-speedup (2017-02-06) 13 commits
>> - squash! completion: fill COMPREPLY directly when completing refs
>> - completion: fill COMPREPLY directly when completing refs
>> - completion: list only matching symbolic and pseudorefs when completing refs
>> - completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
>> - completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery
>> - completion: let 'for-each-ref' strip the remote name from remote branches
>> - completion: let 'for-each-ref' and 'ls-remote' filter matching refs
>> - completion: don't disambiguate short refs
>> - completion: don't disambiguate tags and branches
>> - completion: support excluding full refs
>> - completion: support completing full refs after '--option=refs/<TAB>'
>> - completion: wrap __git_refs() for better option parsing
>> - completion: remove redundant __gitcomp_nl() options from _git_commit()
>> (this branch uses sg/completion.)
>>
>> Will hold.
>> This seems to break 9902 when merged to 'pu'.
>
> All failing tests fail with the same error:
>
> fatal: unrecognized %(refname:strip=2) argument: strip=2
>
> That's because of this topic:
>
>> * kn/ref-filter-branch-list (2017-01-31) 20 commits
>> (merged to 'next' on 2017-01-31 at e7592a5461)
>> + branch: implement '--format' option
>> + branch: use ref-filter printing APIs
>> + branch, tag: use porcelain output
>> + ref-filter: allow porcelain to translate messages in the output
>> + ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
>> + ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
>> + ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
>> + ref-filter: rename the 'strip' option to 'lstrip'
>
> And in particular this commit, which, well, does what it's subject
> says it's doing, thus breaking backwards compatibility.
>
What about making strip a deprecated variant of lstrip?
Thanks,
Jake
^ permalink raw reply
* Re: idea: light-weight pull requests
From: Paul Wise @ 2017-02-07 1:22 UTC (permalink / raw)
To: Santiago Torres; +Cc: git
In-Reply-To: <20170207005751.cgrpwuvtljfgnntb@LykOS.localdomain>
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
On Mon, 2017-02-06 at 19:57 -0500, Santiago Torres wrote:
> IMHO, the notion of a PR/MR is more specific to Git repository
> management tools (e.g., GitHub, GitLab). They all have specific
> concepts/ways to manage the way how their hosted repositories behave ---
> and I believe this flexibility is one of the beauties in Git . I could
> see how this could be implemented by tools like this rather easily
> (e.g., using symlinks + inotify or something less hacky).
Right, but I would like to see this everywhere (including kernel.org),
so support in git-daemon and the http/ssh equivalents is needed too.
git already has support for anonymous push but this idea is more complex.
> I'm wondering if standardizing this would be more interesting to those
> communities?
I've pitched this to github.com/contact but couldn't find any feature
request address for GitLab.
> I would like to see what becomes of this.
Likewise :)
--
bye,
pabs
http://bonedaddy.net/pabs3/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: idea: light-weight pull requests
From: Eric Wong @ 2017-02-07 3:11 UTC (permalink / raw)
To: Paul Wise; +Cc: git
In-Reply-To: <1486427537.16949.42.camel@bonedaddy.net>
Paul Wise <pabs3@bonedaddy.net> wrote:
> Hi all,
>
> I had an idea that might be interesting to git folks:
>
> light-weight pull requests:
>
> Anonymous and ssh/http-identified users should be able to push just
> using git, within the refs/pull/ namespace, to any non-existent branch
> name or to a branch they created when previously identified, without
> forking off a new repository.
I considered something similar to this a few years ago,
but decided it wasn't worth the effort (see below).
> Advantages:
>
> Removes the need to look up who to send the pull request notification
> to since configuring that is up to the project itself.
>
> Removes the annoying scenario of having lots of remotes that have been
> removed after the corresponding pull request was closed.
>
> Moves popular git hosting services from primarily a model of forests of
> forks to one of contributions to well maintained ongoing projects.
>
> Allows users to use their preferred git clients to issue pull requests
> instead of using web interfaces of popular git hosting services.
>
> Creates a new standard for contributing to repositories on all git
> repository hosting services.
>
> Contributions from people without an account on those services are
> possible.
>
> Contributions from people without any git repository hosting of their
> own are possible.
All of these are great goals which I'd love to see realized, but...
> Contributions from people who don't use or dislike MUAs are possible.
How would discussion and review happen? People seem to use
either mail, or centralized messaging (and the latter often
involves non-Free systems like GitHub or Slack).
> Disadvantages:
>
> Pull request spam, could be mitigated with configuration options.
This is a big one. Maybe CRM114 or another generic/trainable
option can be made usable; but I think there'll always be cases
where hardcoded rules need to be written (for SpamAssassin,
at least) and real-time blacklists need to be checked.
At some point, you might end up having to recreate everything we
have in place to combat email spam. Or, use blockchain or
something similarly expensive for reputation, which isn't good
for poor folks with slow computers.
Anyways, I ultimately decided it would be better to continue
supporting and improving email (which is at least entrenched in
a few communities, like this one), rather than trying to get
people to adopt something new.
^ permalink raw reply
* Re: idea: light-weight pull requests
From: Paul Wise @ 2017-02-07 3:28 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20170207031127.GA29468@dcvr>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Tue, 2017-02-07 at 03:11 +0000, Eric Wong wrote:
> How would discussion and review happen? People seem to use
> either mail, or centralized messaging (and the latter often
> involves non-Free systems like GitHub or Slack).
It would depend on the setup for the particular repo. Information about
where that happens could be part of the output of the git push.
> This is a big one. Maybe CRM114 or another generic/trainable
> option can be made usable; but I think there'll always be cases
> where hardcoded rules need to be written (for SpamAssassin,
> at least) and real-time blacklists need to be checked.
TBH, I doubt spam would become a problem at all.
> Anyways, I ultimately decided it would be better to continue
> supporting and improving email (which is at least entrenched in
> a few communities, like this one), rather than trying to get
> people to adopt something new.
Email is great for people used to the old ways but it is gradually
being replaced by APIs and web interfaces :(
--
bye,
pabs
http://bonedaddy.net/pabs3/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2] Document the --no-gui option in difftool
From: Denton Liu @ 2017-02-07 6:32 UTC (permalink / raw)
To: gitster; +Cc: git, davvid
Prior to this, the `--no-gui` option was not documented in the manpage.
This commit introduces this into the manpage
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
Documentation/git-difftool.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 224fb3090..96c26e6aa 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -86,10 +86,11 @@ instead. `--no-symlinks` is the default on Windows.
Additionally, `$BASE` is set in the environment.
-g::
---gui::
+--[no-]gui::
When 'git-difftool' is invoked with the `-g` or `--gui` option
the default diff tool will be read from the configured
- `diff.guitool` variable instead of `diff.tool`.
+ `diff.guitool` variable instead of `diff.tool`. The `--no-gui`
+ option can be used to override this setting.
--[no-]trust-exit-code::
'git-difftool' invokes a diff tool individually on each file.
--
2.11.1
^ permalink raw reply related
* Re: Request re git status
From: Ron Pero @ 2017-02-07 6:46 UTC (permalink / raw)
To: Phil Hord; +Cc: Ron Pero, Git
In-Reply-To: <CABURp0qbKMfngfsC5pQeO+qyRPxa21vi090hMWDtLd+BBH_3Jg@mail.gmail.com>
Hi Phil
Thanks very much for your reply.
I do understand why git status should not automatically fetch from the
server. The solution is that I become aware of that nuance (yes, I am
fairly new to git) and conduct myself that way.
Still, one way or another, it was easy to feel tripped up by that and
some kind of verbal cue could help.
I wonder if this kind of message would help: Latest fetch: {timestamp}
BTW, you might consider posting your answer on
http://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream
Why? Because someone suggested emailing this suggestion to git@vger.kernel.org.
From the stackoverflow page:
"It would certainly be possible to add that extra text (behind a
config option so that redundant noise isn't shown if you how Git
works) but asking for it here isn't going to change it, try emailing
git@vger.kernel.org"
In answer to a couple of your points, I was not using force. And I do
understand that if I pushed to origin master it would have stopped the
merge, alerting me to the conflict. Thanks for that.
Thanks again,
Ron
On Mon, Feb 6, 2017 at 4:45 PM, Phil Hord <phil.hord@gmail.com> wrote:
> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@magnadev.com> wrote:
>> I almost got bit by git: I knew there were changes on the remote
>> server, but git status said I was uptodate with the remote.
>>
>
> Do you mean you almost pushed some changed history with "--force"
> which would have lost others' changes? Use of this option is
> discouraged on shared branches for this very reason. But if you do
> use it, the remote will tell you the hash of the old branch so you can
> undo the damage.
>
> But if you did not use --force, then you were not in danger of being
> bit. Git would have prevented the push in that case.
>
>
>> Why ... not design it to [optionally] DO a fetch and THEN declare
>> whether it is up to date?
>
> It's because `git status` does not talk to the remote server, by
> design. The only Git commands that do talk to the remote are push,
> pull and fetch. All the rest work off-line and they do so
> consistently.
>
> Imagine `git status` did what you requested; that is, it first did a
> fetch and then reported the status. Suppose someone pushed a commit
> to the remote immediately after your fetch completed. Now git will
> still report "up to date" but it will be wrong as soon as the remote
> finishes adding the new push. Yet the "up to date" message will
> remain on your console, lying to you. If you leave and come back in
> two days, the message will remain there even if it is no longer
> correct.
>
> So you should accept that `git status` tells you the status with
> respect to your most recent fetch, and that you are responsible for
> the timing of the most recent fetch. To have git try to do otherwise
> would be misleading.
>
>> Or change the message to tell what it really
>> did, e.g. "Your branch was up-to-date with 'origin/master' when last
>> checked at {timestamp}"? Or even just say, "Do a fetch to find out
>> whether your branch is up to date"?
>
> These are reasonable suggestions, but i don't think the extra wording
> adds anything for most users. Adding a timestamp seems generally
> useful, but it could get us into other trouble since we have to depend
> on outside sources for timestamps. :-\
^ permalink raw reply
* Re: Request re git status
From: Konstantin Khomoutov @ 2017-02-07 7:30 UTC (permalink / raw)
To: Ron Pero; +Cc: Phil Hord, Git
In-Reply-To: <CANOj2JGAaLLEHMs6KBf2PmCipqu-eYSGADzGGBzNVKwP0DTCtg@mail.gmail.com>
On Mon, 6 Feb 2017 22:46:53 -0800
Ron Pero <rpero@magnadev.com> wrote:
[...]
> Still, one way or another, it was easy to feel tripped up by that and
> some kind of verbal cue could help.
> I wonder if this kind of message would help: Latest fetch: {timestamp}
[...]
Timestamps have little to no sense with regard to histories.
What you should make use of is the concept of "tracking branches".
The basic idea is outlined below.
When you fetch from a named remote, like with
git fetch origin
Git creates/updates the so-called "remote" branches for that named
remote in your local repository. They live in a special hierarchy of
branches distinct from your "normal" branches, and you typically refer
to them using short (incomplete in fact) names which include the name
of the remote they came from.
For instance, if the repo known as "origin" to your local one
contains the branches "master", "foo" and "devel" at the time the
command above was run, Git would create remote branches "origin/master",
"origin/foo" and "origin/devel".
The whole "remote branches" thing serves to provide you with sort of
bookmarks to the state of a remote repository it was last seen.
You can't commit your own work on remote branches, and can't push them
either (I'm oversimplifying things now but let's not digress).
That's because they are, well, bookmarks, and they are not "yours" --
as opposed to normal local branches.
Now another thing Git offers is the possibility to "link" any local
branch to any remote branch. This mechanism is called "tracking".
The remote branch linked to a local branch is then called "an upstream"
for that local branch, and that local branch is said to be tracking
that upstream branch.
Say, if you've just fetched from a remote repository and want to work
on a branch "foo" someone created there, you can do
git checkout -b foo --track origin/foo
if you have existing local branch which doesn't track any remote branch,
you can call
git branch --set-upstream-to origin/whatever
when it's checked out to make it track the origin/whatever remote
branch.
Tracking makes many Git commands be extra chatty about the state of the
tracking local branch compared to the state of its upstream branch.
Say, `git status` will tell you how many different commits your local
and its upstream branch have compared to each other -- a clear sign
that you should consider merging or rebasing your local work if you're
about to push it to the upstream branch.
While tracking helps in this case, you must understand that Git is a
DVCS, and "D" in it means "distributed" which, in turn, implies
"disconnected". You should very well understand, that pushing to a
remote repository is inherently racy in this model. That is, by the
time your `git fetch origin` completed, the state of the branches it
just fetched might have already changed by someone else's push.
So unless your organization / team employs some policy on pushing (that
is, each push to certain "shared" branches must be discussed first and
receive a go-ahead from everyone) you have to be prepared for your
push being rejected because someone else will have managed to push
faster than you.
What I'm leading you to, is that showing you any sort of "last fetch
time" won't really help anyway. You just should know the drill:
* Make use of the tracking feature.
* Never use --force with `git push` unless you absolutely positively
understand what happens and you have discussed this with everyone
else in the team or whoever is in charge for the project.
* If pushing fails, run `git fetch` and reconcile your local changes
with whatever changes crept in there into the "upstream" branch,
re-attempt pushing. Rinse, repeat, if needed.
You're advised to read at least [1], or -- better -- the whole chapter
on branching (even better just read the whole book).
1. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches
^ permalink raw reply
* subtree merging fails
From: Stavros Liaskos @ 2017-02-07 8:16 UTC (permalink / raw)
To: git
Following the instructions here:
https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
will lead to an error.
In particular, if the subtree is merged and then updated, this command
that is supposed to update the local subtree fails with a fatal:
refusing to merge unrelated histories error.
$ git merge --squash -s subtree --no-commit rack_branch
A workaround could be using the --allow-unrelated-histories option
$ git merge --squash --allow-unrelated-histories -s subtree
--no-commit rack_branch
But this completely destroys my project by pushing the subtree
contents into a completely irrelevant directory in my project (no in
the subtree).
Any ideas??
https://github.com/git/git-scm.com/issues/896#issuecomment-277587626
^ permalink raw reply
* Re: [PATCH v2 0/7] completion bash: add more options and commands
From: Johannes Sixt @ 2017-02-07 9:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: cornelius.weig, git, szeder.dev
In-Reply-To: <xmqqd1ev100b.fsf@gitster.mtv.corp.google.com>
Am 06.02.2017 um 22:29 schrieb Junio C Hamano:
> cornelius.weig@tngtech.com writes:
>
>> From: Cornelius Weig <cornelius.weig@tngtech.com>
>>
>> This is the re-roll of patch series <20170122225724.19360-1-cornelius.weig@tngtech.com>.
>>
>> This patch series adds all long-options that are mentioned in the synopsis of
>> the man-page for the respective git-command. There are only a few exceptions,
>> as discussed in the above thread. For example, no unsafe options should be
>> completed.
>> Furthermore, the patches add subommand option completion for git-submodule and
>> git-remote.
>
> Reviewers, do these look good now?
My concerns have been addressed. The patches look good from a cursory read.
-- Hannes
^ permalink raw reply
* [PATCH 1/2] t7800: simplify basic usage test
From: David Aguilar @ 2017-02-07 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git ML, Johannes Schindelin
Use "test_line_count" instead of "wc -l", use "git -C" instead of a
subshell, and use test_expect_code when calling difftool. Ease
debugging by capturing output into temporary files.
Suggested-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This patch applies on top of js/difftool-builtin in next
"difftool: fix bug when printing usage"
t/t7800-difftool.sh | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 21e2ac4ad6..97bae54d83 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -24,16 +24,15 @@ prompt_given ()
}
test_expect_success 'basic usage requires no repo' '
- lines=$(git difftool -h | grep ^usage: | wc -l) &&
- test "$lines" -eq 1 &&
+ test_expect_code 129 git difftool -h >output &&
+ grep ^usage: output &&
# create a ceiling directory to prevent Git from finding a repo
mkdir -p not/repo &&
- ceiling="$PWD/not" &&
- lines=$(cd not/repo &&
- GIT_CEILING_DIRECTORIES="$ceiling" git difftool -h |
- grep ^usage: | wc -l) &&
- test "$lines" -eq 1 &&
- rmdir -p not/repo
+ test_when_finished rm -r not &&
+ test_expect_code 129 \
+ env GIT_CEILING_DIRECTORIES="$(pwd)/not" \
+ git -C not/repo difftool -h >output &&
+ grep ^usage: output
'
# Create a file on master and change it on branch
--
2.12.0.rc0.228.g6c028b8e94
^ permalink raw reply related
* [PATCH 2/2] t7800: replace "wc -l" with test_line_count
From: David Aguilar @ 2017-02-07 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git ML, Johannes Schindelin
In-Reply-To: <20170207091700.20156-1-davvid@gmail.com>
Make t7800 easier to debug by capturing output into temporary files and
using test_line_count to make assertions on those files.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
t/t7800-difftool.sh | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 97bae54d83..25241f4096 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -290,8 +290,8 @@ test_expect_success 'difftool + mergetool config variables' '
test_expect_success 'difftool.<tool>.path' '
test_config difftool.tkdiff.path echo &&
git difftool --tool=tkdiff --no-prompt branch >output &&
- lines=$(grep file output | wc -l) &&
- test "$lines" -eq 1
+ grep file output >grep-output &&
+ test_line_count = 1 grep-output
'
test_expect_success 'difftool --extcmd=cat' '
@@ -428,9 +428,12 @@ run_dir_diff_test 'difftool --dir-diff branch from subdirectory' '
git difftool --dir-diff $symlinks --extcmd ls branch >output &&
# "sub" must only exist in "right"
# "file" and "file2" must be listed in both "left" and "right"
- test "1" = $(grep sub output | wc -l) &&
- test "2" = $(grep file"$" output | wc -l) &&
- test "2" = $(grep file2 output | wc -l)
+ grep sub output > sub-output &&
+ test_line_count = 1 sub-output &&
+ grep file"$" output >file-output &&
+ test_line_count = 2 file-output &&
+ grep file2 output >file2-output &&
+ test_line_count = 2 file2-output
)
'
@@ -440,9 +443,11 @@ run_dir_diff_test 'difftool --dir-diff v1 from subdirectory' '
git difftool --dir-diff $symlinks --extcmd ls v1 >output &&
# "sub" and "file" exist in both v1 and HEAD.
# "file2" is unchanged.
- test "2" = $(grep sub output | wc -l) &&
- test "2" = $(grep file output | wc -l) &&
- test "0" = $(grep file2 output | wc -l)
+ grep sub output >sub-output &&
+ test_line_count = 2 sub-output &&
+ grep file output >file-output &&
+ test_line_count = 2 file-output &&
+ ! grep file2 output
)
'
@@ -452,8 +457,9 @@ run_dir_diff_test 'difftool --dir-diff branch from subdirectory w/ pathspec' '
git difftool --dir-diff $symlinks --extcmd ls branch -- .>output &&
# "sub" only exists in "right"
# "file" and "file2" must not be listed
- test "1" = $(grep sub output | wc -l) &&
- test "0" = $(grep file output | wc -l)
+ grep sub output >sub-output &&
+ test_line_count = 1 sub-output &&
+ ! grep file output
)
'
@@ -463,8 +469,9 @@ run_dir_diff_test 'difftool --dir-diff v1 from subdirectory w/ pathspec' '
git difftool --dir-diff $symlinks --extcmd ls v1 -- .>output &&
# "sub" exists in v1 and HEAD
# "file" is filtered out by the pathspec
- test "2" = $(grep sub output | wc -l) &&
- test "0" = $(grep file output | wc -l)
+ grep sub output >sub-output &&
+ test_line_count = 2 sub-output &&
+ ! grep file output
)
'
--
2.12.0.rc0.228.g6c028b8e94
^ permalink raw reply related
* Re: git-daemon shallow checkout fail
From: Duy Nguyen @ 2017-02-07 11:07 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20170206174000357620972@bob.proulx.com>
On Tue, Feb 7, 2017 at 7:56 AM, Bob Proulx <bob@proulx.com> wrote:
> Bob Proulx wrote:
>> 17:20:40.590177 pkt-line.c:46 packet: clone< 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/1.9.1
>
> The evidence of it running the wrong version being the 1.9.1 which is
> not the bits I built.
I wonder if we should make this "git/1.9.1" information more visible. We could
1) Always print it when cloning
2) Print it when cloning with -v (printing all capabilities with -v
might not be a bad idea)
3) Include it in error messages when clone/fetch fails
--
Duy
^ permalink raw reply
* Re: [PATCH] worktree: fix option descriptions for `prune`
From: Duy Nguyen @ 2017-02-07 11:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Patrick Steinhardt, Git Mailing List, Patrick Steinhardt
In-Reply-To: <xmqq60kn2lia.fsf@gitster.mtv.corp.google.com>
On Tue, Feb 7, 2017 at 1:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Patrick Steinhardt <patrick.steinhardt@elego.de> writes:
>
>> struct option options[] = {
>> OPT__DRY_RUN(&show_only, N_("do not remove, show only")),
>> - OPT__VERBOSE(&verbose, N_("report pruned objects")),
>> + OPT__VERBOSE(&verbose, N_("report pruned working trees")),
>> OPT_EXPIRY_DATE(0, "expire", &expire,
>> - N_("expire objects older than <time>")),
>> + N_("expire working trees older than <time>")),
>
> Thanks for sharp eyes.
Yep.
This message never made it to git@vger right, because I didn't see it?
Oh no, gmail classified the original mail as spam again...
--
Duy
^ permalink raw reply
* Re: [PATCH] difftool: fix bug when printing usage
From: Johannes Schindelin @ 2017-02-07 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, Git ML, Denton Liu
In-Reply-To: <xmqqinon2nnt.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Mon, 6 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > [... and he quoted someone ...]
> >
> >> + # create a ceiling directory to prevent Git from finding a repo
> >> + mkdir -p not/repo &&
> >> + ceiling="$PWD/not" &&
> >> + lines=$(cd not/repo &&
> >> + GIT_CEILING_DIRECTORIES="$ceiling" git difftool -h |
> >> + grep ^usage: | wc -l) &&
> >> + test "$lines" -eq 1 &&
> >
> > Likewise, this would become
> >
> > GIT_CEILING_DIRECTORIES="$PWD/not" \
> > test_expect_code 129 git -C not/repo difftool -h >output &&
> > grep ^usage: output
>
> I agree with the intent, but the execution here is "Not quite".
> test_expect_code being a shell function, it does not take the
> "one-shot environment assignment for this single invocation," like
> external commands do.
So now that we know what is wrong, can you please enlighten me about what
is right?
Thanks,
Johannes
^ permalink raw reply
* Non-zero exit code without error
From: Serdar Sahin @ 2017-02-07 11:27 UTC (permalink / raw)
To: git
Hi,
When we execute the following lines, the exit code is 1, but it is
unclear what is the reason of this exit code. Do you have any idea?
git clone --mirror --depth 50 --no-single-branch
git@github.hede.com:Casual/hodo-server.git
Cloning into bare repository 'hodo-server.git'...
remote: Counting objects: 3371, done.
remote: Compressing objects: 100% (1219/1219), done.
remote: Total 3371 (delta 2344), reused 2971 (delta 2098), pack-reused 0
Receiving objects: 100% (3371/3371), 56.77 MiB | 2.18 MiB/s, done.
Resolving deltas: 100% (2344/2344), done.
echo $?
0
cd hodo-server.git/
GIT_CURL_VERBOSE=1 GIT_TRACE=1 git fetch --depth 50 origin
cc086c96cdffe5c1ac78e6139a7a4b79e7c821ee
14:12:35.215889 git.c:350 trace: built-in: git 'fetch'
'--depth' '50' 'origin' 'cc086c96cdffe5c1ac78e6139a7a4b79e7c821ee'
14:12:35.217273 run-command.c:336 trace: run_command: 'ssh'
'git@github.hede.com' 'git-upload-pack '\''Casual/hodo-server.git'\'''
14:12:37.301122 run-command.c:336 trace: run_command: 'gc' '--auto'
14:12:37.301866 exec_cmd.c:189 trace: exec: 'git' 'gc' '--auto'
14:12:37.304473 git.c:350 trace: built-in: git 'gc' '--auto'
echo $?
1
^ permalink raw reply
* Re: Google Doc about the Contributors' Summit
From: Johannes Schindelin @ 2017-02-07 11:51 UTC (permalink / raw)
To: git; +Cc: Tim Pettersen
In-Reply-To: <alpine.DEB.2.20.1702021007460.3496@virtualbox>
Hi team,
On Thu, 2 Feb 2017, Johannes Schindelin wrote:
> I just started typing stuff up in a Google Doc, and made it editable to
> everyone, feel free to help and add things:
>
> https://docs.google.com/document/d/1KDoSn4btbK5VJCVld32he29U0pUeFGhpFxyx9ZJDDB0/edit?usp=sharing
I am terribly sorry... yesterday I simply tried to restrict editing so
that nobody would just spam the document, but in my haste I even disabled
viewing.
The link is functional again, sorry for that.
Thanks, Tim, for reporting the problem!
Ciao,
Dscho
^ permalink raw reply
* [RFC] mailmap.blob overrides default .mailmap
From: Cornelius Weig @ 2017-02-07 11:56 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I was reading into the mailmap handling today and I'm a bit puzzled by the overriding behavior.
This is what the documentation says about precedence (emphasis mine):
-------------
mailmap.file
The location of an augmenting mailmap file. The default mailmap, located
in the root of the repository, is loaded first, then the mailmap file
pointed to by this variable. The location of the mailmap file may be in a
repository subdirectory, or somewhere outside of the repository itself.
See git-shortlog(1) and git-blame(1).
mailmap.blob
Like mailmap.file, but consider the value as a reference to a blob in the
repository. If both mailmap.file and mailmap.blob are given, both are
!!! parsed, with _entries from mailmap.file taking precedence_. In a bare
repository, this defaults to HEAD:.mailmap. In a non-bare repository, it
defaults to empty.
------------
So from the doc I would have expected that files always get precedence over the blob. IOW entries from .mailmap override entries from mailmap.blob. However, this is not the case.
The code shows why (mailmap.c):
err |= read_mailmap_file(map, ".mailmap", repo_abbrev);
if (startup_info->have_repository)
err |= read_mailmap_blob(map, git_mailmap_blob, repo_abbrev);
err |= read_mailmap_file(map, git_mailmap_file, repo_abbrev);
Apparently this is not an oversight, because there is an explicit test for this overriding behavior (t4203 'mailmap.blob overrides .mailmap').
So I wonder: what is the rationale behind this? I find this mixed overriding behavior hard to explain and difficult to understand.
^ permalink raw reply
* Re: [PATCH 2/2] t7800: replace "wc -l" with test_line_count
From: Johannes Schindelin @ 2017-02-07 12:02 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Git ML
In-Reply-To: <20170207091700.20156-2-davvid@gmail.com>
Hi David,
On Tue, 7 Feb 2017, David Aguilar wrote:
> Make t7800 easier to debug by capturing output into temporary files and
> using test_line_count to make assertions on those files.
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
Both patches look like an obvious improvement with no obvious bugs to me.
In this case, I allowed myself to forego the more thorough code review in
favor of merely glancing over the diffs, seeing as the changes do not
really need a lot of context.
Thank you,
Johannes
^ permalink raw reply
* Re: Git clonebundles
From: Johannes Schindelin @ 2017-02-07 12:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Shawn Pearce, Stefan Saasen, Git Mailing List
In-Reply-To: <xmqq4m070xua.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Mon, 6 Feb 2017, Junio C Hamano wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
> > There is also Junio's work on Bundle v3 that was unfortunately
> > recently discarded. Look for "jc/bundle" in:
> >
> > http://public-inbox.org/git/xmqq4m0cry60.fsf@gitster.mtv.corp.google.com/
> >
> > and previous "What's cooking in git.git" emails.
>
> If people think it might be useful to have it around to experiment, I
> can resurrect and keep that in 'pu' (or rather 'jch'), as long as it
> does not overlap and conflict with other topics in flight. Let me try
> that in today's integration cycle.
I would like to remind you of my suggestion to make this more publicly
visible and substantially easier to play with, by adding it as an
experimental feature (possibly guarded via an explicit opt-in config
setting).
Ciao,
Johannes
^ permalink raw reply
* [PATCH] rev-list-options.txt: update --all about detached HEAD
From: Nguyễn Thái Ngọc Duy @ 2017-02-07 13:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
This is the document patch for f0298cf1c6 (revision walker: include a
detached HEAD in --all - 2009-01-16)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/rev-list-options.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 5da7cf5a8d..72212ac6ec 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -133,8 +133,8 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit).
for all following revision specifiers, up to the next `--not`.
--all::
- Pretend as if all the refs in `refs/` are listed on the
- command line as '<commit>'.
+ Pretend as if all the refs in `refs/` (and HEAD if detached)
+ are listed on the command line as '<commit>'.
--branches[=<pattern>]::
Pretend as if all the refs in `refs/heads` are listed
--
2.11.0.157.gd943d85
^ permalink raw reply related
* ``git clean -xdf'' and ``make clean''
From: Hongyi Zhao @ 2017-02-07 14:17 UTC (permalink / raw)
To: git
Hi all,
In order to delete all of the last build stuff, does the following two
methods equivalent or not?
``git clean -xdf'' and ``make clean''
Regards
--
Hongsheng Zhao <hongyi.zhao@gmail.com>
Institute of Semiconductors, Chinese Academy of Sciences
GnuPG DSA: 0xD108493
^ permalink raw reply
* Re: Request re git status
From: Samuel Lijin @ 2017-02-07 14:54 UTC (permalink / raw)
To: Phil Hord; +Cc: Ron Pero, Git
In-Reply-To: <CABURp0qbKMfngfsC5pQeO+qyRPxa21vi090hMWDtLd+BBH_3Jg@mail.gmail.com>
On Mon, Feb 6, 2017 at 6:45 PM, Phil Hord <phil.hord@gmail.com> wrote:
> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero <rpero@magnadev.com> wrote:
>> I almost got bit by git: I knew there were changes on the remote
>> server, but git status said I was uptodate with the remote.
>>
>
> Do you mean you almost pushed some changed history with "--force"
> which would have lost others' changes? Use of this option is
> discouraged on shared branches for this very reason. But if you do
> use it, the remote will tell you the hash of the old branch so you can
> undo the damage.
>
> But if you did not use --force, then you were not in danger of being
> bit. Git would have prevented the push in that case.
>
>
>> Why ... not design it to [optionally] DO a fetch and THEN declare
>> whether it is up to date?
>
> It's because `git status` does not talk to the remote server, by
> design. The only Git commands that do talk to the remote are push,
> pull and fetch. All the rest work off-line and they do so
> consistently.
>
> Imagine `git status` did what you requested; that is, it first did a
> fetch and then reported the status. Suppose someone pushed a commit
> to the remote immediately after your fetch completed. Now git will
> still report "up to date" but it will be wrong as soon as the remote
> finishes adding the new push. Yet the "up to date" message will
> remain on your console, lying to you. If you leave and come back in
> two days, the message will remain there even if it is no longer
> correct.
>
> So you should accept that `git status` tells you the status with
> respect to your most recent fetch, and that you are responsible for
> the timing of the most recent fetch. To have git try to do otherwise
> would be misleading.
This argument doesn't work for me. Race conditions in *any*
asynchronous work flow are inevitable; in commits, particularly to a
shared branch, I also can't imagine them being common. It's like
saying because there's lag between the remote's response and the
output on the local, `git fetch` shouldn't bother saying that the
local remote has been updated.
It wouldn't be hard, though, to define an alias that fetches the
remote-tracking branch and then reports the status.
Nevertheless, this is one of those cases where I think Git suffers
from a poor UI/UX - it's letting the underlying model define the
behavior, rather than using the underlying model to drive the
behavior.
>> Or change the message to tell what it really
>> did, e.g. "Your branch was up-to-date with 'origin/master' when last
>> checked at {timestamp}"? Or even just say, "Do a fetch to find out
>> whether your branch is up to date"?
>
> These are reasonable suggestions, but i don't think the extra wording
> adds anything for most users. Adding a timestamp seems generally
> useful, but it could get us into other trouble since we have to depend
> on outside sources for timestamps. :-\
^ permalink raw reply
* Re: subtree merging fails
From: Samuel Lijin @ 2017-02-07 14:59 UTC (permalink / raw)
To: Stavros Liaskos; +Cc: git@vger.kernel.org
In-Reply-To: <CAEXhnECi3LvSA92dSjL5PZ1Lx9p1PWELS04nmfJW=8K9o4T-0Q@mail.gmail.com>
Have you tried using (without -s subtree) -X subtree=path/to/add/subtree/at?
From the man page:
subtree[=<path>]
This option is a more advanced form of subtree
strategy, where the strategy
makes a guess on how two trees must be shifted to match
with each other when
merging. Instead, the specified path is prefixed (or
stripped from the
beginning) to make the shape of two trees to match.
On Tue, Feb 7, 2017 at 2:16 AM, Stavros Liaskos <st.liaskos@gmail.com> wrote:
> Following the instructions here:
> https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
> will lead to an error.
>
> In particular, if the subtree is merged and then updated, this command
> that is supposed to update the local subtree fails with a fatal:
> refusing to merge unrelated histories error.
>
> $ git merge --squash -s subtree --no-commit rack_branch
>
> A workaround could be using the --allow-unrelated-histories option
>
> $ git merge --squash --allow-unrelated-histories -s subtree
> --no-commit rack_branch
>
> But this completely destroys my project by pushing the subtree
> contents into a completely irrelevant directory in my project (no in
> the subtree).
>
> Any ideas??
>
> https://github.com/git/git-scm.com/issues/896#issuecomment-277587626
^ permalink raw reply
* Re: [PATCH v2 2/2] grep: use '/' delimiter for paths
From: Stefan Hajnoczi @ 2017-02-07 15:04 UTC (permalink / raw)
To: Brandon Williams; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <20170120235133.GA146274@google.com>
[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]
On Fri, Jan 20, 2017 at 03:51:33PM -0800, Brandon Williams wrote:
> On 01/20, 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'
> > >
> > > 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)
> > >
> > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > ---
> > > builtin/grep.c | 4 +++-
> > > t/t7810-grep.sh | 5 +++++
> > > 2 files changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/builtin/grep.c b/builtin/grep.c
> > > index 90a4f3d..7a7aab9 100644
> > > --- a/builtin/grep.c
> > > +++ b/builtin/grep.c
> > > @@ -494,7 +494,9 @@ 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/ */
> > > + char delim = obj->type == OBJ_COMMIT ? ':' : '/';
> >
> > Why check the equality with commit, rather than un-equality with
> > tree? Wouldn't you want to treat $commit:path and $tag:path the
> > same way?
>
> I assume Stefan just grabbed my naive suggestion hence why it checks
> equality with a commit. So that's my fault :) Either of these may
> not be enough though, since if you do 'git grep malloc v2.9.3^{tree}'
> with this change the output prefix is 'v2.9.3^{tree}/' instead of the
> correct prefix 'v2.9.3^{tree}:'
I revisited this series again today and am coming to the conclusion that
forming output based on the user's rev is really hard to get right in
all cases. I don't have a good solution to the v2.9.3^{tree} problem.
Perhaps it's better to leave this than to merge code that doesn't work
correctly 100% of the time.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: ``git clean -xdf'' and ``make clean''
From: Cornelius Weig @ 2017-02-07 15:07 UTC (permalink / raw)
To: Hongyi Zhao, git
In-Reply-To: <CAGP6PO+qD6eRkKbWAxOfiqUQw8o+dOfgwgvt_8OxHQ5ocAopEQ@mail.gmail.com>
On 02/07/2017 03:17 PM, Hongyi Zhao wrote:
> Hi all,
>
> In order to delete all of the last build stuff, does the following two
> methods equivalent or not?
>
> ``git clean -xdf'' and ``make clean''
No, it is not equivalent.
* `make clean` removes any build-related files (assuming that the
`clean` target is properly written). To see exactly what it would do,
run `make clean -n`. Judging from your question, I think this is what
you want to do.
* `git clean -xdf` would remove any files that git does not track. This
also includes build-related files, but also any other files that happen
to be in your working directory. For example, any output from `git
format-patch` would be removed by this, but not `make clean`.
^ 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