* 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: 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
* [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
* [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
* 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
* 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: 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
* 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
* [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: 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
* 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 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: 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: Santiago Torres @ 2017-02-07 0:57 UTC (permalink / raw)
To: Paul Wise; +Cc: git
In-Reply-To: <1486427537.16949.42.camel@bonedaddy.net>
[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]
Hello, pabs.
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).
I'm wondering if standardizing this would be more interesting to those
communities?
I would like to see what becomes of this.
Cheers!
-Santiago.
On Tue, Feb 07, 2017 at 08:32:17AM +0800, Paul Wise 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.
>
> 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.
>
> Contributions from people who don't use or dislike MUAs are possible.
>
> Disadvantages:
>
> Pull request spam, could be mitigated with configuration options.
>
> Extra configuration and complexity on the server side. This is once
> only and means less complexity on the pull requester side.
>
> Will not work with typical setups where the git/http/ssh user does not
> have write access to the repositories. A workaround could be some sort
> of hybrid-repository setup with the new refs and objects in a second
> repository which would be shared by all pull requesters.
>
> --
> bye,
> pabs
>
> http://bonedaddy.net/pabs3/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: git-daemon shallow checkout fail
From: Bob Proulx @ 2017-02-07 0:56 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20170206171225215133282@bob.proulx.com>
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.
> Therefore it looks like it is invoking some other command by a hard
> coded path and avoiding PATH to my development bits. It must be
> invoking some other binary. I will get more agressive about disabling
> the packaged version and hopefully find out which one.
I did and of course it is /usr/bin/git-upload-pack and if I disable
that binary then git-daemon no longer operates.
error: cannot run upload-pack: No such file or directory
But shouldn't it find git-upload-pack from PATH? Since I have
git-upload-pack installed in PATH? Apparently not. At least not when
invoking as /path/to/git-daemon directly.
In any case with the all of your very good help, especially the
version echo print, guiding me to the problem that I was able to make
this work.
cd /run/git && env -i HOME=/run/git PATH=$HOME/src/git-stuff/git:/usr/bin:/bin $HOME/src/git-stuff/git/git --exec-path=$HOME/src/git-stuff/git daemon --export-all --base-path=/srv/git --verbose
That works for the git-daemon. It does not require me to modify
anything else on the system. Good enough. Problem solved.
Thanks!
Bob
^ permalink raw reply
* idea: light-weight pull requests
From: Paul Wise @ 2017-02-07 0:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
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.
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.
Contributions from people who don't use or dislike MUAs are possible.
Disadvantages:
Pull request spam, could be mitigated with configuration options.
Extra configuration and complexity on the server side. This is once
only and means less complexity on the pull requester side.
Will not work with typical setups where the git/http/ssh user does not
have write access to the repositories. A workaround could be some sort
of hybrid-repository setup with the new refs and objects in a second
repository which would be shared by all pull requesters.
--
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: Request re git status
From: Phil Hord @ 2017-02-07 0:45 UTC (permalink / raw)
To: Ron Pero, Git
In-Reply-To: <CANOj2JG5VuDtS30PfOrZ=4q8pTv_frY7=p+0g=UW3yV6ev+1KQ@mail.gmail.com>
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: git-daemon shallow checkout fail
From: Bob Proulx @ 2017-02-07 0:27 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <CACsJy8DED9WRr_T6g43bxHUGQYVnfaTx15hqSGiiajvi0TxtuA@mail.gmail.com>
Duy Nguyen wrote:
> Jeff King wrote:
> > It depends on the git version on the server. The interesting code is in
> > upload-pack.c, which is spawned by git-daemon to serve a fetch or clone
> > request.
> >
> > See commit b790e0f67 (upload-pack: send shallow info over stdin to
> > pack-objects, 2014-03-11), which lays out the history. Since that commit
> > (in git v2.0.0), there should be no tmpfile needed.
>
> It must be it. There's nowhere else that upload-pack can create
> shallow_XXXXXX. (receive-pack and fetch-pack can).
I am sure the file creation is there. Because it isn't being done
anywhere. But the problem is before that time period. By then the
paths are already set.
> >Bob Proulx wrote:
> >> git --version # from today's git clone build
> >> git version 2.11.0.485.g4e59582
> >
> > This shouldn't be happening with git v2.11. Are you sure that the "git
> > daemon" invocation is running that same version? I notice you set up a
> > restricted PATH. Is it possible that /usr/local/bin or /usr/bin has an
> > older version of git?
I have been starting it with PATH set to my directory. But given this
question I start it with a full path.
PATH=~/src/git-stuff/git:$PATH ~/src/git-stuff/git/git-daemon --export-all --base-path=/srv/git --verbose
But then I worry about the package installed binary still getting
invoked with the fork somehow. Therefore I disable it. There should
be no possibility of it invoking the packaged daemon. I moved it out
of the way.
mv /usr/lib/git-core/git-daemon /usr/lib/git-core/git-daemon.disabled
I can't trivially remove the packaged version because other things
depend upon it. I could get more agressive about disabling it in a
non-destructive and reversible way though.
> One easy way to verify is clone or fetch again with GIT_TRACE_PACKET=1
> since we send the server's version as a capability since 1.8.0
And here is the interesting part. If I read this right the client is
reporting 1.9.1 from the server! But how?
$ GIT_TRACE_PACKET=1 git clone --depth 1 git://git0.savannah.gnu.org/test-project.git
Cloning into 'test-project'...
17:20:40.482970 pkt-line.c:46 packet: clone> git-upload-pack /test-project.git\0host=git0.savannah.gnu.org\0
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
17:20:40.662623 pkt-line.c:46 packet: clone< 34e7202270c381f4e5734180dc19426ce69f2e1e refs/heads/master
17:20:40.662653 pkt-line.c:46 packet: clone< 0000
17:20:40.663682 pkt-line.c:46 packet: clone> want 34e7202270c381f4e5734180dc19426ce69f2e1e multi_ack_detailed side-band-64k thin-pack include-tag ofs-delta agent=git/2.1.4
17:20:40.663701 pkt-line.c:46 packet: clone> want 34e7202270c381f4e5734180dc19426ce69f2e1e
17:20:40.663713 pkt-line.c:46 packet: clone> deepen 1
17:20:40.663724 pkt-line.c:46 packet: clone> 0000
17:20:40.739502 pkt-line.c:46 packet: clone< shallow 34e7202270c381f4e5734180dc19426ce69f2e1e
17:20:40.854338 pkt-line.c:46 packet: clone< 0000
17:20:40.854360 pkt-line.c:46 packet: clone> done
17:20:40.929349 pkt-line.c:46 packet: clone< NAK
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
I am assuming that the "agent=git/1.9.1" is the evidence that it isn't
running the code that I am trying to make it run? Of course the
packaged installed git version is 1.9.1 (from Trisquel 7, an Ubuntu
14.04 fork) so that matches. My client is "agent=git/2.1.4" (from
Debian Jessie) so that matches my client end.
Therefore it looks like it is invoking some other command by a hard
coded path and avoiding PATH to my development bits. It must be
invoking some other binary. I will get more agressive about disabling
the packaged version and hopefully find out which one.
Thank you very much for the good hints here. They are very helpful.
Bob
^ permalink raw reply
* Re: git-daemon shallow checkout fail
From: Bob Proulx @ 2017-02-07 0:27 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.20.1701301719590.3469@virtualbox>
Hello Johannes,
Thank you very much for the good hints here. They are very helpful.
Johannes Schindelin wrote:
> Assuming that you can rebuild your Git with debug symbols and without
> optimization (simply remove the -O2 from CFLAGS in the Makefile, I never
> had any luck with single-stepping in gdb when compiled with -O2), you
I always debug with -g and without -O because otherwise it leads to a
lot of confusion. But git-daemon is a forking daemon which makes
debugging it with the debugger somewhere more default and requiring
more setup to debug past the fork points. As you note and hint with
later setting up an attach point for gdb.
> - that error message comes from shallow.c's setup_temporary_shallow()
> function
Yes. I find that too.
> - that function is only called from fetch-pack and receive-pack, neither
> of which should be called by upload-pack, so it is a puzzle
The choice of directionality for upload and download might be
confusing me here too. Since from the client side of things it is a
download. But on the server side it is an upload.
> - adding a test case to t5570-git-daemon.sh that tests specifically your
> described scenario seems *not* to fail:
I have seen some of the patches that seems like should have fixed this
problem. It is perplexing. But see my next mail on this too.
> - I even modified t/lib-git-daemon.sh to start the daemon as `nobody` and
> kill it as `root`, and I won't share that patch because it is as
> ugly, but *even then* the test succeeded.
It succeeds for me on other systems. It is only the one (where I need
it) that it is failing.
> So my suspicion is that the repository you try to serve may already be
> shallow, or something else funky is going on that has not been included in
> your report.
It happens to any repository. I picked a small repository and copied
it verbatim using rsync to my working environment. The identical bits
of a repository copied by rsync work okay on one system but fail on
the other.
> The most direct way to get to the bottom of this may be to do something
> like this:
...
> if (write_shallow_commits(&sb, 0, extra)) {
> +error("About to create shallow_XXXXXX: pid = %d", getpid());
> +while (!debug_me) {
> + sleep(1);
> +}
> fd = xmks_tempfile(&temporary_shallow, git_path("shallow_XXXXXX"));
>
> if (write_in_full(fd, sb.buf, sb.len) != sb.len)
> -- snap --
>
> Then let it run, wait for the error message "About to create
> shallow_XXXXXX" and then attach with a gdb started as nobody via `attach
> <pid>` to see the stack trace.
>
> That should give you an idea where that code path is hit (unexpectedly).
That is a good hint. I will give that a try. However see my next
email for more (confusing) information.
Bob
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)
From: SZEDER Gábor @ 2017-02-07 0:24 UTC (permalink / raw)
To: Junio C Hamano, Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <xmqqzihzymn3.fsf@gitster.mtv.corp.google.com>
> * 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.
> + ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
> + ref-filter: introduce refname_atom_parser()
> + ref-filter: introduce refname_atom_parser_internal()
> + ref-filter: make "%(symref)" atom work with the ':short' modifier
> + ref-filter: add support for %(upstream:track,nobracket)
> + ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
> + ref-filter: introduce format_ref_array_item()
> + ref-filter: move get_head_description() from branch.c
> + ref-filter: modify "%(objectname:short)" to take length
> + ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
> + ref-filter: include reference to 'used_atom' within 'atom_value'
> + ref-filter: implement %(if), %(then), and %(else) atoms
>
> The code to list branches in "git branch" has been consolidated
> with the more generic ref-filter API.
>
> Will cook in 'next'.
^ permalink raw reply
* Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`
From: Eric Wong @ 2017-02-07 0:14 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Josh Triplett, git
In-Reply-To: <20170206220754.5q2oddr5ej7c6qcg@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Mon, Feb 06, 2017 at 08:48:20PM +0000, Eric Wong wrote:
>
> > I haven't hit insurmountable performance problems, even on
> > low-end hardware; especially since I started storing blob ids in
> > Xapian itself, avoiding the expensive tree lookup via git.
>
> The painful thing is traversing the object graph for clones and fetches.
> Bitmaps help, but you still have to generate them.
Yep. "public-inbox-init" defaults to enabling bitmaps in the
config for this reason.
> > The main problem seems to be tree size. Deepening (2/2/36 vs
> > 2/38) might be an option (I think Peff brought that up); but it
> > might be easier to switch to YYYYMM refs (working like
> > logrotate) and rely on Xapian to tie the entire thing together.
>
> Yes, the hashing is definitely one issue. Some numbers here:
>
> http://public-inbox.org/git/20160805092805.w3nwv2l6jkbuwlzf@sigill.intra.peff.net/
>
> If you have C commits on a tree with T entries, you have to do C*T hash
> lookups for a flat tree (for each commit, you have to see "yup, already
> saw that object"). Sharding that across H entries at the top level drops
> the tree cost from T to H + T/H (actually, it's a bit worse because we
> have to read the secondary tree, too). Sharding again (at H') gets you
> H + H' + T/H/H'.
>
> Let's imagine you do one message per commit, so C=T. At 400K messages,
> that's about 160 billion hash lookups flat. At H=256, it's about 700
> million. If you shard again with H'=256, it's 200 million. After that,
> the additive terms start to dominate, and it's not worth going any
> further (and also, we're ignoring the extra-tree cost to each level).
Just to make sure I'm following, here; the entire formulas are:
C * H + H' + (T / H / H') # 2/2/36
C * H + (T / H) # 2/38 (current)
Right?
> At that point you're better off to start having fewer commits. I know
> that the schema you use does put useful information into the commit
> message, but it's also redundant with what's in the messages themselves.
> And it sounds like you push most of that out to Xapian anyway.
Yeah, there's no benefit to Xapian users for having any info in
the commit. However, keeping commit-per-message is still
important to me to for better robustness from hardware and
network failures.
But yes, historical stuff could be squashed into a single commit
(much like how linux.git started with v2.6.12-rc2 without
history). Perhaps some folks will care about NNTP article
numbering being non-chronological...
> Imagine your repo had one commit with 400K historical messages, and then
> grouped the new messages so that on average we got about 10 messages per
> commit (this doesn't seem unrealistic for something that commits every
> few minutes; the messages tend to be bunched in time; I ran some
> numbers against a 10-minute mark in the earlier message).
>
> Then after another 100K messages, we'd have C=10,001 and T=500K. With
> two levels of hashing at 256 each, that's ~5 million hash lookups to
> walk the graph. And those numbers would be reasonable for a hosting site
> like GitHub.
>
> I don't know what C is for the kernel repo, but I suspect with the right
> tuning it could be made into large-but-reasonable.
LKML probably has an upper bound of 30K messages per month;
so it could hit 100K in less than 4 months. Worst case might
be 360K messages a year
360000 * (256 + 256 + ((360000 + old) / 256 / 256))
That's still at least 180 million hash lookups after a year or
so of real-time updates; right? (But probably closer to 240
million if there's 10 million old messages in there.
Instead, I think I will add an option to support logrotate-style
monthly heads (YYYYMM); keeping 2/38 and C == T:
30000 * (256 + (30000 / 256)) => 11 million
30000 * (256 + 256 + (30000 / 256 / 256)) => 15 million
The monthly heads would each be discontiguous history-wise;
so Xapian would become a requirement for users of this option
for Message-ID lookups, but histories would still be readable
with "git log"
One good side-effect of using monthly heads is --single-branch
clones may be used if someone lacks the bandwidth or space to do
a full mirror. I'm not sure if the server-side (pack reuse,
bitmaps) will benefit other aside from bandwidth reductions,
though.
A (far-fetched) option I've considered would be to store entire
messages in the commit and have no trees or blobs at all. But
that would require a significant rework, and would also make
Xapian a hard requirement for even checking if a message is
deleted or not.
^ permalink raw reply
* Re: [PATCH 00/12] completion: speed up refs completion
From: Jacob Keller @ 2017-02-06 23:55 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Git mailing list
In-Reply-To: <CAM0VKjm-HQFtDypcWgOdQrLyjAicOVLUsFby5_wE1hvTE1pTRQ@mail.gmail.com>
On Mon, Feb 6, 2017 at 11:36 AM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
> On Mon, Feb 6, 2017 at 7:31 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> On Fri, Feb 3, 2017 at 7:15 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>> I haven't had a chance to further investigate, but I tried this series
>>> out (from your github) and it appears that this series (or the
>>> previous series for __gitdir work) breaks "git log" ref completion.
>>> I'll have further details when I am able to investigate a it more.
>>>
>>> Thanks,
>>> Jake
>>
>> At first I had the same problem, but I verified by re-installing the
>> completion script and the problem appears to have gone away. I suspect
>> what happened is that the original time, I forgot to actually install
>> the new version of git, and only installed the completion script, so
>> when some of the commands were run with new options they (silently)
>> failed and the result was missing completion values.
>>
>> Once I properly re-installed everything it appears to work as
>> expected. I haven't found any other issues yet.
>
> Thanks, that's good to hear.
>
> Still, I'm a bit puzzled as to what exactly might have caused your
> problem. Considering new options:
>
> - the __gitdir()-related series added the 'git rev-parse
> --absolute-git-dir' option, but only ever used it if you invoked
> completion after 'git -C some/where'.
>
> - The refs completion speedup didn't add any new options but started
> to use two that it previously didn't:
>
> - 'git for-each-ref --sort=<key>' option, but that's with us since
> the earliest ever 'for-each-ref' version from more than a decade
> ago...
>
> - 'git for-each-ref' format modifier 'strip=2', which was
> introduced in v2.7.1~15^2 (tag: do not show ambiguous tag names
> as "tags/foo", 2016-01-25), only about a year ago. Were you
> using a pre-2.7.1 version when seeing the problems?
>
> Gábor
Nope. I was using some version of next at some point recently (less
than a couple months old). I do not know exactly what caused it, and
I'm not really able to find out because I can't reproduce it any more.
(after a fresh make install).
Thanks,
Jake
^ permalink raw reply
* Request re git status
From: Ron Pero @ 2017-02-06 23:35 UTC (permalink / raw)
To: git
Hi
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.
This page explains it well.
http://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream
That page also contains a good suggestion:
Why ... not design it to [optionally] DO a fetch and THEN declare
whether it is up to date? 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"?
Thanks, and best wishes,
Ron
^ permalink raw reply
* Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"
From: Junio C Hamano @ 2017-02-06 23:09 UTC (permalink / raw)
To: Siddharth Kannan; +Cc: git, pranit.bauva, Matthieu.Moy, peff, pclouds, sandals
In-Reply-To: <20170206181026.GA4010@ubuntu-512mb-blr1-01.localdomain>
Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
> Hey Junio, I did some more digging into the codepath:
> ...
> In case you would prefer for me to not work on this anymore
> because I am new to the codebase, I will leave it at this.
The above is nicely analized and summarized.
The earlier mention of "those new to the codebase" by me was "this
is an inappropriate topic as a GSoC microproject for people new to
the codebase" and it wasn't meant to say "this part of the code is
too precious to let unknown folks touch it."
The focus of GSoC being mentoring those who are new to the open
source development, and hopefully retain them in the community after
GSoC is over, we do expect microprojects to be suitable for those
who are new to the codebase.
The focus of microprojects are twofold. It is a way for new people
to learn the way in which they will be interacting with the
community once they become Git developers, sending their patches
(which includes analyzing and explaining the problem they are trying
to solve and their solution to it) and receiving and responding to
review comments. We also want to find out which candidates are
willing to learn and which ones are difficult to work with during
the process. And its primary focus is not about solving the real
issues the project has with its code---something "bite-sized" is
sufficient (and desirable) for microprojects for both GSoC student
candidates and GSoC mentors and reviewers to work with.
> (c) -> Else look for "r1^-"
> ...
> Case (c) is a bit confusing. This could be something like "-^-", and
> something like "^-" could mean "Not commits on previous branch" or it
> could mean "All commits on this branch except for the parent of HEAD"
Do you mean:
"git rev-parse ^-" does not mean "git rev-parse HEAD^-", but we
probably would want to, and if that is what is going to happen,
"^-" should mean "HEAD^-", and cannot be used for "^@{-1}"?
It's friend "^!" does not mean "HEAD^!", and "^@" does not mean
"HEAD^@", either (the latter is somewhat borked, though, and "^@"
translates to "^HEAD" because confusingly "@" stands for "HEAD"
sometimes).
So my gut feeling is that it is probably OK to make "^-" mean
"^@{-1}"; it may be prudent to at least initially keep "^-" an error
like it currently is already, though.
^ permalink raw reply
* Re: [PATCH] Completion: Add support for --submodule=diff
From: Peter Law @ 2017-02-06 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq4m0gtakk.fsf@gitster.mtv.corp.google.com>
Hi,
Junio C Hamano <gitster@pobox.com> wrote:
> Peter Law <peterjclaw@gmail.com> writes:
>
>>> Teach git-completion.bash about the 'diff' option to 'git diff
>>> --submodule=', which was added in Git 2.11.
>>
>> I posted this patch back in December, but I've not heard anything. I'm
>> sure as maintainers you're all quite busy, but I was wondering how
>> long it usually takes to get a response to patches? (also whether I'd
>> gotten some part of the submission process wrong?)
>
> When there is clear "subsystem maintainer(s)" in the area, I try to
> refrain from commenting until they speak up, and completion scripts
> are one of these areas. I usually ping them after a few days but in
> December with holidays and things people are usually slow, and so
> was I X-<.
>
> Will pick it up. Thanks for a reminder; you absolutely did the
> right thing (i.e. sending it out with people who are likely to know
> about the area CC'ed, waiting for a while and then sending a
> reminder).
Awesome, many thanks!
Peter
^ 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