* Re: [PATCH 2/2] Add a remote helper to interact with mediawiki (fetch & push)
From: Jonathan Nieder @ 2011-08-30 3:56 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Matthieu Moy, git, Jeremie Nikaes, Arnaud Lacurie,
Claire Fousse, David Amouyal, Matthieu Moy, Sylvain Boulmé,
Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <CAGdFq_jwLGZ+tLKramRrLJmwyY_uDtj7JXUwYBO9pSqOmZ20xQ@mail.gmail.com>
Sverre Rabbelier wrote:
> On Mon, Aug 29, 2011 at 08:05, Junio C Hamano <gitster@pobox.com> wrote:
>> Does this exchange suggest that at least we would need an update to
>> documentation around "done", as Matthieu's "why is 'done' needed even
>> though I am not calling with --done?" sounds like a very fair question.
>
> No I think the documentation for fast-import is correct.
However, the documentation for git-remote-helpers is hopelessly outdated.
Here's an old attempt to make the documentation a little easier to read,
and hopefully also to add to. The text from "Capabilities for Pushing"
on needs help to avoid seeming redundant in light of the list of
capabilities before, but I'm sending it now to get comments and
hopefully help from other interested people.
It does _not_ document recent changes; patches for that would
presumably come on top. Last time I sent this to list[1], it brought
to life some inconsistencies in how the various "list" commands are
used. Another response was to flesh out what a capability for
fetching a single tree ("git archive --remote") would look like[2],
for which I was very grateful (and I'd happy to see it come to life).
[1] http://thread.gmane.org/gmane.comp.version-control.git/169341
[2] http://colabti.org/irclogger/irclogger_log/git-devel?date=2011-03-19#l434
-- >8 --
Subject: Documentation/remote-helpers: explain capabilities first
The current remote helper documentation is from the perspective of
git, so to speak: it presents a full menu of commands for a person
invoking a remote helper to choose from. In practice, that's less
useful than it could be, since the daunted novice remote-helper author
probably just wanted a list of commands needs to implement to get
started. So preface the command list with an overview of each
capability, its purpose, and what commands it requires.
As a side effect, this makes it a little clearer that git doesn't
choose arbitrary commands to run, even if the remote helper advertises
all capabilities --- instead, there are well defined command sequences
for various tasks.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-remote-helpers.txt | 159 +++++++++++++++++++++++++++-------
1 files changed, 129 insertions(+), 30 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 58f6ad49..f3fd63a4 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -23,22 +23,141 @@ output. Because a remote helper runs as an independent process from
git, there is no need to re-link git to add a new helper, nor any
need to link the helper with the implementation of git.
-Every helper must support the "capabilities" command, which git will
-use to determine what other commands the helper will accept. Other
-commands generally concern facilities like discovering and updating
-remote refs, transporting objects between the object database and
-the remote repository, and updating the local object store.
-
-Helpers supporting the 'fetch' capability can discover refs from the
-remote repository and transfer objects reachable from those refs to
-the local object store. Helpers supporting the 'push' capability can
-transfer local objects to the remote repository and update remote refs.
+Every helper must support the "capabilities" command, which git
+uses to determine what other commands the helper will accept. Those
+other commands can be used to discover and update remote refs,
+transport objects between the object database and the remote repository,
+and update the local object store.
Git comes with a "curl" family of remote helpers, that handle various
transport protocols, such as 'git-remote-http', 'git-remote-https',
'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
'fetch', 'option', and 'push'.
+INPUT FORMAT
+------------
+
+Git sends the remote helper a list of commands on standard input, one
+per line. The first command is always the 'capabilities' command, in
+response to which the remote helper must print a list of the
+capabilities it supports (see below) followed by a blank line. The
+response to the capabilities command determines what commands Git uses
+in the remainder of the command stream.
+
+The command stream is terminated by a blank line. In some cases
+(indicated in the documentation of the relevant commands), this blank
+line is followed by a payload in some other protocol (e.g., the pack
+protocol), while in others it indicates the end of input.
+
+Capabilities
+~~~~~~~~~~~~
+
+Each remote helper is expected to support only a subset of commands.
+The operations a helper supports are declared to git in the response
+to the `capabilities` command (see COMMANDS, below).
+
+'option'::
+ For specifying settings like `verbosity` (how much output to
+ write to stderr) and `depth` (how much history is wanted in the
+ case of a shallow clone) that affect how other commands are
+ carried out.
+
+'connect'::
+ For fetching and pushing using git's native packfile protocol
+ that requires a bidirectional, full-duplex connection.
+
+'push'::
+ For listing remote refs and pushing specified objects from the
+ local object store to remote refs.
+
+'fetch'::
+ For listing remote refs and fetching the associated history to
+ the local object store.
+
+'import'::
+ For listing remote refs and fetching the associated history as
+ a fast-import stream.
+
+'refspec' <refspec>::
+ This modifies the 'import' capability, allowing the produced
+ fast-import stream to modify refs in a private namespace
+ instead of writing to refs/heads or refs/remotes directly.
+ It is recommended that all importers providing the 'import'
+ capability use this.
++
+A helper advertising the capability
+`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}`
+is saying that, when it is asked to `import refs/heads/topic`, the
+stream it outputs will update the `refs/svn/origin/branches/topic`
+ref.
++
+This capability can be advertised multiple times. The first
+applicable refspec takes precedence. The left-hand of refspecs
+advertised with this capability must cover all refs reported by
+the list command. If no 'refspec' capability is advertised,
+there is an implied `refspec {asterisk}:{asterisk}`.
+
+Capabilities for Pushing
+~~~~~~~~~~~~~~~~~~~~~~~~
+'connect'::
+ Can attempt to connect to 'git receive-pack' (for pushing),
+ 'git upload-pack', etc for communication using the
+ packfile protocol.
++
+Supported commands: 'connect'.
+
+'push'::
+ Can discover remote refs and push local commits and the
+ history leading up to them to new or existing remote refs.
++
+Supported commands: 'list for-push', 'push'.
+
+If a helper advertises both 'connect' and 'push', git will use
+'connect' if possible and fall back to 'push' if the helper requests
+so when connecting (see the 'connect' command under COMMANDS).
+
+Capabilities for Fetching
+~~~~~~~~~~~~~~~~~~~~~~~~~
+'connect'::
+ Can try to connect to 'git upload-pack' (for fetching),
+ 'git receive-pack', etc for communication using the
+ packfile protocol.
++
+Supported commands: 'connect'.
+
+'fetch'::
+ Can discover remote refs and transfer objects reachable from
+ them to the local object store.
++
+Supported commands: 'list', 'fetch'.
+
+'import'::
+ Can discover remote refs and output objects reachable from
+ them as a stream in fast-import format.
++
+Supported commands: 'list', 'import'.
+
+If a helper advertises 'connect', git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'fetch' and 'import', git prefers 'fetch'.
+Other frontends may have some other order of preference.
+
+'refspec' <refspec>::
+ This modifies the 'import' capability.
++
+A helper advertising
+`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}`
+in its capabilities is saying that, when it handles
+`import refs/heads/topic`, the stream it outputs will update the
+`refs/svn/origin/branches/topic` ref.
++
+This capability can be advertised multiple times. The first
+applicable refspec takes precedence. The left-hand of refspecs
+advertised with this capability must cover all refs reported by
+the list command. If no 'refspec' capability is advertised,
+there is an implied `refspec {asterisk}:{asterisk}`.
+
INVOCATION
----------
@@ -167,26 +286,6 @@ completing a valid response for the current command.
Additional commands may be supported, as may be determined from
capabilities reported by the helper.
-CAPABILITIES
-------------
-
-'fetch'::
-'option'::
-'push'::
-'import'::
-'connect'::
- This helper supports the corresponding command with the same name.
-
-'refspec' 'spec'::
- When using the import command, expect the source ref to have
- been written to the destination ref. The earliest applicable
- refspec takes precedence. For example
- "refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}" means
- that, after an "import refs/heads/name", the script has written to
- refs/svn/origin/branches/name. If this capability is used at
- all, it must cover all refs reported by the list command; if
- it is not used, it is effectively "{asterisk}:{asterisk}"
-
REF LIST ATTRIBUTES
-------------------
--
1.7.6
^ permalink raw reply related
* Re: Overriding ~/.gitconfig using GIT_CONFIG
From: David Aguilar @ 2011-08-30 3:10 UTC (permalink / raw)
To: Richard Purdie
Cc: Junio C Hamano, Daniel Barkalow,
Nguy?? n Thái Ngọc Duy, GIT Mailing-list
In-Reply-To: <1314620166.5939.282.camel@rex>
On Mon, Aug 29, 2011 at 01:16:06PM +0100, Richard Purdie wrote:
> On Sun, 2011-08-28 at 06:05 -0700, David Aguilar wrote:
> > On Fri, Aug 12, 2011 at 09:44:13PM +0100, Richard Purdie wrote:
> > > My problem isn't that I want to specify a specific .gitconfig file, I
> > > just need it to ignore the one in $HOME. I'm happy for the .git/config
> > > file to be used, in fact I need it to be.
> >
> > If you're writing a tool then it should restrict itself to
> > git's plumbing commands. You should be able to do just about
> > anything without needing to worry about differences in
> > configuraiton. Git commands almost always provide a way to
> > override configuration through the use of flags.
> >
> > The plumbing commands are listed in the main git manpage.
> > See "Low-level commands (plumbing)" here:
> > http://www.kernel.org/pub/software/scm/git/docs/
> >
> > What is the specific problem solved by overriding the
> > configuration? It may be possible to solve it without needing
> > to get too complicated.
>
> I'm not sure writing my own porcelain makes sense in this case.
True... luckily we don't have to go that far.
> The tool in question is a build system which is primarily interested in
> building software. Sometimes the software we want to build is "bleeding
> edge" and hence rather than download tarballs, we want to interact
> directly with SCMs like git to obtain it.
>
> The commands I'm using are the likes of "git clone" and "git fetch"
> although we do use commands listed under the plumbing section too such
> as ls-remote and read-tree. We do "cache" checkouts and support
> automatically noticing changes and updating/building.
>
> What I do want to be able to say is "ignore whatever the user might have
> put in their ~/.gitconfig file" since I've open bug reports about people
> putting things in there that break builds.
>
> The fetch/clone commands do what I need, apart from being influenced by
> userconfig so reimplementing them myself doesn't seem like a good
> approach.
This is what we're interested in.
Do you have the specifics of exactly what in the user
~/.gitconfig file broke the build?
What I'm suggesting is that there's probably a way to avoid
the user-dependent behavior by being explicit on
the command-line.
Specifically regarding fetch -- if you're doing "git fetch"
and relying on the configuration then we can probably come
up with a more explicit fetch command that has an explicit
and predictable behavior independent of the user's
configuraiton.
Using the explicit form of the command can make the build system
more robust.
Let us know what you're cooking, it sounds interesting.
cheers,
--
David
^ permalink raw reply
* Not yet 1.7.7-rc1 but...
From: Junio C Hamano @ 2011-08-30 2:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vobzbbw0b.fsf@alter.siamese.dyndns.org>
... here is an updated preview of the "New Topics" section of the next
issue of "What's cooking". People sent in fixes to bugs several topics
that are new in 1.7.7-rc0 have introduced, and while they are still on
the "pu" (proposed updates) branch for tonight, they should and will be
fast tracked to 1.7.7-rc1.
Thanks.
-- >8 --
[New Topics]
* mg/maint-notes-C-doc (2011-08-25) 1 commit
- git-notes.txt: clarify -C vs. copy and -F
Will merge to "master".
* jc/clean-exclude-doc (2011-08-28) 1 commit
- Documentation: clarify "git clean -e <pattern>"
Will merge to "master".
* mh/check-ref-format-print-normalize (2011-08-27) 2 commits
- Forbid DEL characters in reference names
- check-ref-format --print: Normalize refnames that start with slashes
Will merge to "master".
* bk/ancestry-path (2011-08-25) 3 commits
- revision: do not include sibling history in --ancestry-path output
- revision: keep track of the end-user input from the command line
- rev-list: Demonstrate breakage with --ancestry-path --all
The topic came up a bit too late in the cycle.
Will cook for a while.
* mg/branch-list (2011-08-28) 5 commits
- branch: allow pattern arguments
- branch: introduce --list option
- git-branch: introduce missing long forms for the options
- git-tag: introduce long forms for the options
- t6040: test branch -vv
The topic came up a bit too late in the cycle.
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
- rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
- rebase -i: clean error message for --continue after failed exec
The topic came up a bit too late in the cycle.
* jk/default-attr (2011-08-26) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
I fixed up the test breakage just for fun, but this is not urgent.
* hv/submodule-merge-search (2011-08-26) 4 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(this branch uses fg/submodule-ff-check-before-push.)
The topic came up a bit too late in the cycle.
The bottom one needs to be replaced with a properly written commit log message.
* mm/mediawiki-as-a-remote (2011-08-26) 1 commit
- Add a remote helper to interact with mediawiki (fetch & push)
Fun.
* nd/maint-autofix-tag-in-head (2011-08-26) 3 commits
- Accept tags in HEAD or MERGE_HEAD
- merge: remove global variable head[]
- merge: keep stash[] a local variable
Probably needs a re-roll to aim a bit higher.
* bc/unstash-clean-crufts (2011-08-27) 4 commits
- git-stash: remove untracked/ignored directories when stashed
- t/t3905: add missing '&&' linkage
- git-stash.sh: fix typo in error message
- t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
* bg/t5540-osx-grep (2011-08-28) 1 commit
- t5540-http-test: shorten grep pattern
Will merge to "master".
* cb/maint-ls-files-error-report (2011-08-28) 1 commit
- t3005: do not assume a particular order of stdout and stderr of git-ls-files
Will merge to "master".
* da/make-auto-header-dependencies (2011-08-27) 1 commit
- Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
* ms/daemon-timeout-is-in-seconds (2011-08-28) 1 commit
- git-daemon.txt: specify --timeout in seconds
Will merge to "master".
* bc/bisect-test-use-shell-path (2011-08-29) 1 commit
- t6030: use $SHELL_PATH to invoke user's preferred shell instead of bare sh
Will merge to "master".
* gb/am-hg-patch (2011-08-29) 1 commit
- am: preliminary support for hg patches
* gb/maint-am-patch-format-error-message (2011-08-29) 1 commit
- am: format is in $patch_format, not parse_patch
Will merge to "master".
* gb/maint-am-stgit-author-to-from-fix (2011-08-29) 1 commit
- am: fix stgit patch mangling
Will merge to "master".
* jc/diff-index-unpack (2011-08-29) 3 commits
- diff-index: pass pathspec down to unpack-trees machinery
- unpack-trees: allow pruning with pathspec
- traverse_trees(): allow pruning with pathspec
Will cook for a while.
* tr/maint-format-patch-empty-output (2011-08-29) 4 commits
- Document negated forms of format-patch --to --cc --add-headers
- t4014: "no-add-headers" is actually called "no-add-header"
- t4014: invoke format-patch with --stdout where intended
- t4014: check for empty files from git format-patch --stdout
Will merge to "master".
* tr/maint-ident-to-git-memmove (2011-08-29) 1 commit
- Use memmove in ident_to_git
Will merge to "master".
* tr/maint-strbuf-grow-nul-termination (2011-08-29) 1 commit
- strbuf_grow(): maintain nul-termination even for new buffer
Will merge to "master".
* tr/maint-t3903-misquoted-command (2011-08-29) 1 commit
- t3903: fix misquoted rev-parse invocation
Will merge to "master".
* va/p4-branch-import-test-update (2011-08-29) 1 commit
- git-p4: simple branch tests edits
Will merge to "master".
^ permalink raw reply
* git tab completion shows ansi escape sequences
From: Mike Gant @ 2011-08-30 2:17 UTC (permalink / raw)
To: git
Tab completion results in this output:
$ git <TAB><TAB>
^[[31m^[[K c^[[m^[[Kount-objects g^[[m^[[Ket-tar-commit-id replace
a^[[m^[[Kdd c^[[m^[[Kvsexportcommit g^[[m^[[Krep request-pull
a^[[m^[[Km c^[[m^[[Kvsimport g^[[m^[[Kui reset
a^[[m^[[Knnotate c^[[m^[[Kvsserver help revert
a^[[m^[[Kpply ci imap-send rl
a^[[m^[[Krchive co init rm
b^[[m^[[Kisect d^[[m^[[Kaemon instaweb send-email
b^[[m^[[Klame d^[[m^[[Kescribe log shortlog
b^[[m^[[Kranch d^[[m^[[Kiff logk show
b^[[m^[[Kundle d^[[m^[[Kiff-files lol show-branch
br d^[[m^[[Kiff-index lola st
c^[[m^[[Kat-file d^[[m^[[Kiff-tree ls sta
c^[[m^[[Kheck-attr d^[[m^[[Kifftool merge stage
c^[[m^[[Kheck-ref-format f^[[m^[[Kast-export mergetool stash
c^[[m^[[Kheckout f^[[m^[[Kast-import mv status
c^[[m^[[Kheckout-index f^[[m^[[Ketch name-rev sts
c^[[m^[[Kherry f^[[m^[[Ketch-pack notes submodule
c^[[m^[[Kherry-pick f^[[m^[[Kilter-branch pull svn
c^[[m^[[Kitool f^[[m^[[Kmt-merge-msg push tag
c^[[m^[[Klean f^[[m^[[Kor-each-ref rebase tlog
c^[[m^[[Klone f^[[m^[[Kormat-patch reflog unstage
c^[[m^[[Kommit f^[[m^[[Ksck relink whatchanged
c^[[m^[[Kommit-tree f^[[m^[[Ksck-objects remote
c^[[m^[[Konfig g^[[m^[[Kc repack
This is on Linux Mint 11 but it also happens on openSuse 11.4.
$ echo $SHELL
bash
$ echo $BASH_VERSION
4.2.8(1)-release
$ echo $TERM
xterm-256color
The same result when TERM is set to xterm, rxvt, rxvt-256color, rxvt-unicode.
Does anyone know why I'm getting this output?
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH] t3903: fix misquoted rev-parse invocation
From: Jon Seymour @ 2011-08-30 1:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <fa41d38f9297ca14b61e05033c9d1b5f5a778263.1314662636.git.trast@student.ethz.ch>
On Tue, Aug 30, 2011 at 10:06 AM, Thomas Rast <trast@student.ethz.ch> wrote:
>
> !"git ..." hopefully always succeeds because "git ..." is not the name
> of any executable. However, that's not what was intended. Unquote
> it, and while we're at it, also replace ! with test_must_fail since it
> is a call to git.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
Oops.
Acked-by: Jon Seymour <jon.seymour@gmail.com>
| Apologies for resend, didn't realise my gmail was sending in rich text.
jon.
^ permalink raw reply
* Re: [PATCH] do not require filters to consume stdin
From: Joey Hess @ 2011-08-30 1:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vobz74yoe.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
Junio C Hamano wrote:
> Isn't this filter already broken if clean request is for a blob contents
> that is different from what is on the filesystem? The name %f is passed
> to give the filter a _hint_ on what the path is about (so that the filter
> can choose to work differently depending on the extension, for example),
> but the data may or may not come from the filesystem, depending on what is
> calling the filter, no?
>
> Most notably, renormalize_buffer() would call convert_to_git() on a buffer
> that is internal, possibly quite different from what is in the working
> tree.
So during a merge.
gitattributes(5) is not very clear about this, it would probably be good
to add a caveat there about what %f is not.
This seems to make it impractical to build the sort of thing described here:
http://lists-archives.org/git/737857-fwd-git-and-large-binaries-a-proposed-solution.html
Arguably that thread already reached the same conclusion about using
smudge/clean for handling large files, for other reasons. Since I
already have something that works without smudge/clean, perhaps I should
give up on them.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* 'p4 sync' like command in git
From: Parag Kalra @ 2011-08-30 0:52 UTC (permalink / raw)
To: git
I was wondering if there is any 'p4 sync' like command in git.
I did some google and found this -
git pull git@example.com:pk/foobar.git
And it seem to work for me but want to just confirm.
Thanks,
Parag
^ permalink raw reply
* Re: [PATCH] Symlink mergetools scriptlets into valgrind wrappers
From: Thomas Rast @ 2011-08-30 0:50 UTC (permalink / raw)
To: git
In-Reply-To: <e11fd4c98faf1fc4f970bd1570fe931e078f436e.1314665234.git.trast@student.ethz.ch>
That's it, master is back to valgrind-clean on my box. Thanks for
reading.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Symlink mergetools scriptlets into valgrind wrappers
From: Thomas Rast @ 2011-08-30 0:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, David Aguilar
Since bc7a96a (mergetool--lib: Refactor tools into separate files,
2011-08-18) the mergetools and difftools related tests fail under
--valgrind because the mergetools/* scriptlets are not in the exec
path.
For now, symlink the mergetools subdir into the t/valgrind/bin
directory as a whole, since it does not contain anything of interest
to the valgrind wrappers.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/test-lib.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index d7dfc8b..bdd9513 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -950,6 +950,8 @@ then
do
make_valgrind_symlink $file
done
+ # special-case the mergetools loadables
+ make_symlink "$GIT_BUILD_DIR"/mergetools "$GIT_VALGRIND/bin/mergetools"
OLDIFS=$IFS
IFS=:
for path in $PATH
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* [PATCH] t3903: fix misquoted rev-parse invocation
From: Thomas Rast @ 2011-08-30 0:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jon Seymour
!"git ..." hopefully always succeeds because "git ..." is not the name
of any executable. However, that's not what was intended. Unquote
it, and while we're at it, also replace ! with test_must_fail since it
is a call to git.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I kind of wonder how many bogus tests we have...
t/t3903-stash.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 7197aae..fcdb182 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -542,7 +542,7 @@ test_expect_success 'ref with non-existent reflog' '
echo bar6 > file2 &&
git add file2 &&
git stash &&
- ! "git rev-parse --quiet --verify does-not-exist" &&
+ test_must_fail git rev-parse --quiet --verify does-not-exist &&
test_must_fail git stash drop does-not-exist &&
test_must_fail git stash drop does-not-exist@{0} &&
test_must_fail git stash pop does-not-exist &&
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* Re: [PATCH] Documentation: point to "History Simplification" from -- <path>
From: Junio C Hamano @ 2011-08-29 23:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <307fe311ad448ecd3d0643040008954a217d7ddb.1314659821.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 'git log -- <path>' does not "show commits that affect the specified
> paths" in a literal sense unless --full-history is given (for example,
> a file that only existed on a side branch will turn up no commits at
> all!).
>
> Point the user to the "History Simplification" section to avoid
> surprises.
Hmm, or perhaps replace it with a brief explanation instead of redirecting
the readers to a separate section without telling them anything here?
Show only commits that are enough to explain how the files that match
the specified paths came to be.
(this is my attempt to paraphrase $gmane/90659)
> [\--] <path>...::
> + Show only commits that affect any of the specified paths.
> + See "History Simplification" below for a precise definition of
> + the filtering applied.
^ permalink raw reply
* Re: [PATCH 0/3] Un-pessimize "diff-index $commit -- $pathspec"
From: Junio C Hamano @ 2011-08-29 23:42 UTC (permalink / raw)
To: Marat Radchenko; +Cc: Linus Torvalds, git, Nguyen Thai Ngoc Duy
In-Reply-To: <CA+55aFz9givAWhP5_SfnneY6x_0ekcN2U9HrKr+NTgY=Ot=6TQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Aug 29, 2011 at 3:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> The topic started by Marat Radchenko in
>
> Ugh, that's ugly. Is it verified to solve Marat's nasty case too?
Not yet, though Marat is on the CC list of the original "this is still
rough" draft (the code is identical but it is not split up into
three-patch series) message.
Marat, if/when you have a chance could you try a patched git on your
original use case and see if it produces correct output with shorter
amount of time?
> But yeah, ack on the series.
>
> Linus
Thanks.
^ permalink raw reply
* [PATCH] Documentation: point to "History Simplification" from -- <path>
From: Thomas Rast @ 2011-08-29 23:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
'git log -- <path>' does not "show commits that affect the specified
paths" in a literal sense unless --full-history is given (for example,
a file that only existed on a side branch will turn up no commits at
all!).
Point the user to the "History Simplification" section to avoid
surprises.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Sparked by an IRC discussion minutes ago, where I got the paragraph
quoted back to me verbatim to "prove" it shows *all* commits affecting
a file.
Documentation/git-log.txt | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 6c93466..437f06e 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -69,10 +69,12 @@ produced by --stat etc.
its size is not included.
[\--] <path>...::
- Show only commits that affect any of the specified paths. To
- prevent confusion with options and branch names, paths may need
- to be prefixed with "\-- " to separate them from options or
- refnames.
+ Show only commits that affect any of the specified paths.
+ See "History Simplification" below for a precise definition of
+ the filtering applied.
++
+To prevent confusion with options and branch names, paths may need to
+be prefixed with "\-- " to separate them from options or refnames.
include::rev-list-options.txt[]
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* Re: [PATCH] strbuf_grow(): maintain nul-termination even for new buffer
From: Brandon Casey @ 2011-08-29 23:15 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, Pierre Habouzit
In-Reply-To: <c8d8686c1813885a36d8f4cada218686989df236.1314651926.git.trast@student.ethz.ch>
On 08/29/2011 04:16 PM, Thomas Rast wrote:
> In the case where sb is initialized to the slopbuf (through
> strbuf_init(sb,0) or STRBUF_INIT), strbuf_grow() loses the terminating
> nul: it grows the buffer, but gives ALLOC_GROW a NULL source to avoid
> it being freed. So ALLOC_GROW does not copy anything to the new
> memory area.
>
> This subtly broke the call to strbuf_getline in read_next_command()
> [fast-import.c:1855], which goes
>
> strbuf_detach(&command_buf, NULL); # command_buf is now = STRBUF_INIT
> stdin_eof = strbuf_getline(&command_buf, stdin, '\n');
> if (stdin_eof)
> return EOF;
>
> In strbuf_getwholeline, this did
>
> strbuf_grow(sb, 0); # loses nul-termination
I'm thinking this call to strbuf_grow() predates the decision to
require that the buf component of a strbuf should always be valid
nul-terminated string. It was likely made here solely to force
allocation of buf which may have been NULL.
I think this line can safely be removed from strbuf_getwholeline().
> if (feof(fp))
> return EOF;
> strbuf_reset(sb); # this would have nul-terminated!
>
> Valgrind found this because fast-import subsequently uses prefixcmp()
> on command_buf.buf, which after the EOF exit contains only
> uninitialized memory.
>
> Arguably strbuf_getwholeline is also broken, in that it touches the
> buffer before deciding whether to do any work. However, it seems more
> futureproof to not let the strbuf API lose the nul-termination by its
> own fault.
>
> So make sure that strbuf_grow() puts in a nul even if it has nowhere
> to copy it from. This makes strbuf_grow(sb, 0) a semantic no-op as
> far as readers of the buffer are concerned.
>
> Also remove the nul-termination added by strbuf_init, which is made
> redudant.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Patch looks good.
-Brandon
^ permalink raw reply
* Re: [PATCH] strbuf_grow(): maintain nul-termination even for new buffer
From: Junio C Hamano @ 2011-08-29 23:09 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Pierre Habouzit
In-Reply-To: <c8d8686c1813885a36d8f4cada218686989df236.1314651926.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> So make sure that strbuf_grow() puts in a nul even if it has nowhere
> to copy it from. This makes strbuf_grow(sb, 0) a semantic no-op as
> far as readers of the buffer are concerned.
Makes sense, thanks.
> Also remove the nul-termination added by strbuf_init, which is made
> redudant.
Ok.
This is a tangent but if we do not have hint, we point at strbuf_slopbuf[]
which is:
/*
* Used as the default ->buf value, so that people can always assume
* buf is non NULL and ->buf is NUL terminated even for a freshly
* initialized strbuf.
*/
char strbuf_slopbuf[1];
While nobody should be writing into it, we do not really enforce the
constness of this buffer.
I wonder if it would be worth making this into "const char []" and have
the complier/linker move it to read-only section to catch potential bugs.
^ permalink raw reply
* Re: [PATCH] do not require filters to consume stdin
From: Junio C Hamano @ 2011-08-29 22:53 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20110829203107.GA4946@gnu.kitenet.net>
Joey Hess <joey@kitenet.net> writes:
> There has been discussion before about using clean and smudge filters
> with %f to handle big files in git, with the file content stored outside
> git somewhere. A simplistic clean filter for large files could look
> like this:
>
> #!/bin/sh
> file="$1"
> ln -f $file ~/.big/$file
> echo $file
Isn't this filter already broken if clean request is for a blob contents
that is different from what is on the filesystem? The name %f is passed
to give the filter a _hint_ on what the path is about (so that the filter
can choose to work differently depending on the extension, for example),
but the data may or may not come from the filesystem, depending on what is
calling the filter, no?
Most notably, renormalize_buffer() would call convert_to_git() on a buffer
that is internal, possibly quite different from what is in the working
tree.
^ permalink raw reply
* Re: [PATCH] .gitattributes: Enable cpp diff parsing for .[ch] files
From: Boaz Harrosh @ 2011-08-29 22:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Peter Zijlstra, Andrew Morton, Git Mailing List, linux-kernel,
Junio C Hamano
In-Reply-To: <CA+55aFxB7mBByT9W4c0D6kELcZMZDD_j0_S2869nS4LV0mNTbA@mail.gmail.com>
On 08/29/2011 03:02 PM, Linus Torvalds wrote:
>
> I'd hate to start populating the project with more stuff.
>
> Linus
OK Thanks for the answer. That I can understand
Boaz
^ permalink raw reply
* Re: [PATCH] strbuf_grow(): maintain nul-termination even for new buffer
From: Erik Faye-Lund @ 2011-08-29 22:41 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, Pierre Habouzit
In-Reply-To: <c8d8686c1813885a36d8f4cada218686989df236.1314651926.git.trast@student.ethz.ch>
On Mon, Aug 29, 2011 at 11:16 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> In the case where sb is initialized to the slopbuf (through
> strbuf_init(sb,0) or STRBUF_INIT), strbuf_grow() loses the terminating
> nul: it grows the buffer, but gives ALLOC_GROW a NULL source to avoid
> it being freed. So ALLOC_GROW does not copy anything to the new
> memory area.
>
> This subtly broke the call to strbuf_getline in read_next_command()
> [fast-import.c:1855], which goes
>
> strbuf_detach(&command_buf, NULL); # command_buf is now = STRBUF_INIT
> stdin_eof = strbuf_getline(&command_buf, stdin, '\n');
> if (stdin_eof)
> return EOF;
>
> In strbuf_getwholeline, this did
>
> strbuf_grow(sb, 0); # loses nul-termination
> if (feof(fp))
> return EOF;
> strbuf_reset(sb); # this would have nul-terminated!
>
> Valgrind found this because fast-import subsequently uses prefixcmp()
> on command_buf.buf, which after the EOF exit contains only
> uninitialized memory.
>
> Arguably strbuf_getwholeline is also broken, in that it touches the
> buffer before deciding whether to do any work. However, it seems more
> futureproof to not let the strbuf API lose the nul-termination by its
> own fault.
>
> So make sure that strbuf_grow() puts in a nul even if it has nowhere
> to copy it from. This makes strbuf_grow(sb, 0) a semantic no-op as
> far as readers of the buffer are concerned.
>
> Also remove the nul-termination added by strbuf_init, which is made
> redudant.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> Only found this now because the bug is only triggered by the tests
> added in 4cedb78 (fast-import: add input format tests, 2011-08-11).
>
>
> strbuf.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/strbuf.c b/strbuf.c
> index 1a7df12..4556f96 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -30,10 +30,8 @@ void strbuf_init(struct strbuf *sb, size_t hint)
> {
> sb->alloc = sb->len = 0;
> sb->buf = strbuf_slopbuf;
> - if (hint) {
> + if (hint)
> strbuf_grow(sb, hint);
> - sb->buf[0] = '\0';
> - }
> }
>
> void strbuf_release(struct strbuf *sb)
This gave me a bit of deja-vu, and indeed:
5e7a5d9 strbuf: make sure buffer is zero-terminated
> @@ -65,12 +63,15 @@ void strbuf_attach(struct strbuf *sb, void *buf, size_t len, size_t alloc)
>
> void strbuf_grow(struct strbuf *sb, size_t extra)
> {
> + int new_buf = !sb->alloc;
> if (unsigned_add_overflows(extra, 1) ||
> unsigned_add_overflows(sb->len, extra + 1))
> die("you want to use way too much memory");
> - if (!sb->alloc)
> + if (new_buf)
> sb->buf = NULL;
> ALLOC_GROW(sb->buf, sb->len + extra + 1, sb->alloc);
> + if (new_buf)
> + sb->buf[0] = '\0';
> }
>
> void strbuf_trim(struct strbuf *sb)
Looks sensible to me.
^ permalink raw reply
* Re: [PATCH 1/4] t4014: check for empty files from git format-patch --stdout
From: Junio C Hamano @ 2011-08-29 22:30 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Stephen Boyd
In-Reply-To: <bbfb7190ca0125798417f57f4d33b5443257e478.1314648438.git.trast@student.ethz.ch>
Thanks.
^ permalink raw reply
* Re: What would be a normal tool chain for supporting git
From: Philip Oakley @ 2011-08-29 22:25 UTC (permalink / raw)
To: Git List
In-Reply-To: <3EA7FAC7B6F4447792312CA1B87EB3E2@PhilipOakley>
From: "Philip Oakley" <philipoakley@iee.org>
> I'm using git in a windows engineering environment [visual studio, matlab,
> etc]. My main familiarity has been with windows tools :-( I know). My unix
> knowledge is dated.
>
> What would be a typical toolset I would need to set up for contributing to
> git?
>
> Philip
See http://article.gmane.org/gmane.comp.version-control.msysgit/13284 for
the preferred method.
^ permalink raw reply
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Junio C Hamano @ 2011-08-29 22:22 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, git, cmn
In-Reply-To: <20110829185011.GC756@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... I always assumed that you did one of:
>
> 1. Comment on the patch via email, just as any other reviewer, so it
> can go into the re-roll.
>
> 2. Fix-up the patch or commit message during "am", with the assumption
> that it is ready to be merged at least to "next", at which point
> re-rolls are no longer OK, anyway.
Not really.
I usually amend patches queued to 'pu' (or queue fixup! separately) when I
am reasonably confident that my suggestion had enough merits. Also I roll
in suggestions that are obviously (to me) good from the list, which may or
may not be the same to the list concensus. Maybe I should try to be less
aggressive.
> I mentioned "it takes effort" above. I don't mean "submitters shouldn't
> be expected to put in extra effort". But we should make sure the effort
> is well-spent, which means:
>
> 1. Giving them some indication that you tweaked things during
> application. It doesn't have to be an inclusive list. Even saying
> "Thanks, applied with some spelling fixes" instead of your usual
> "Thanks" is enough (actually, I think you frequently do so
> already).
Just started consciously doing so yesterday, after starthing this offtopic
therad ;-)
^ permalink raw reply
* Re: [PATCH 0/3] Un-pessimize "diff-index $commit -- $pathspec"
From: Linus Torvalds @ 2011-08-29 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyen Thai Ngoc Duy
In-Reply-To: <7v1uw36fgb.fsf@alter.siamese.dyndns.org>
On Mon, Aug 29, 2011 at 3:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> The topic started by Marat Radchenko in
Ugh, that's ugly. Is it verified to solve Marat's nasty case too?
But yeah, ack on the series.
Linus
^ permalink raw reply
* Re: [PATCH 0/3] Un-pessimize "diff-index $commit -- $pathspec"
From: Junio C Hamano @ 2011-08-29 22:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Nguyen Thai Ngoc Duy
In-Reply-To: <CA+55aFzk+hn9wMAp3H92SHAGO8CQVBpTsmR41FgCy32T7muUzA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Aug 29, 2011 at 2:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Before and after applying this series, looking for changes in the kernel
>> repository with a fairly narrow pathspec gets a moderate speeds up.
>
> "moderate speeds up"?
>
> Looks like a big win to me. Admittedly it's already a pretty fast
> operation, but script it and repeat it a million times, and that will
> matter a lot more.
>
> I guess the "--raw" diff part means that you are hiding the time to
> make a real diff, which would otherwise swamp everything else. Even
> so, this looks like a good improvement.
The topic started by Marat Radchenko in
http://thread.gmane.org/gmane.comp.version-control.git/179926
who was trying to pick a single path (we do not know how deep it is), and
was comparing between these two:
$ time git show branch:file | diff -u - file > /dev/null
real 0m0.003s
user 0m0.000s
sys 0m0.000s
$ time git diff branch -- file > /dev/null
real 0m31.442s
user 0m31.040s
sys 0m0.380s
Replacing "diff -u" with "git diff --no-index" in the former didn't make
much of a difference. It turned out that Marat had 603k paths in the index
and the most of the time was spent in the unpack machinery.
^ permalink raw reply
* Re: [PATCH] .gitattributes: Enable cpp diff parsing for .[ch] files
From: Linus Torvalds @ 2011-08-29 22:02 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Peter Zijlstra, Andrew Morton, Git Mailing List, linux-kernel,
Junio C Hamano
In-Reply-To: <4E5BFD36.2090000@panasas.com>
On Mon, Aug 29, 2011 at 1:57 PM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>
> What are you guys afraid of? what possibly could be bad about this patch?
I just detest filling the kernel tree with git stuff.
Right now, the only git-specific file we have in the kernel tree is
the ".gitignore" files, afaik. And if you were to use some other SCM,
the "ignore" model at least translates directly to just about anything
else (with the problem that the .gitignore model tends to be more
powerful than most other SCM's have, but whatever).
I'd hate to start populating the project with more stuff.
Linus
^ permalink raw reply
* Re: [PATCH 0/3] Un-pessimize "diff-index $commit -- $pathspec"
From: Linus Torvalds @ 2011-08-29 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyen Thai Ngoc Duy
In-Reply-To: <1314653603-7533-1-git-send-email-gitster@pobox.com>
On Mon, Aug 29, 2011 at 2:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Before and after applying this series, looking for changes in the kernel
> repository with a fairly narrow pathspec gets a moderate speeds up.
"moderate speeds up"?
Looks like a big win to me. Admittedly it's already a pretty fast
operation, but script it and repeat it a million times, and that will
matter a lot more.
I guess the "--raw" diff part means that you are hiding the time to
make a real diff, which would otherwise swamp everything else. Even
so, this looks like a good improvement.
Linus
^ 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