* Re: Is it possible to use git as a remote file storage without making any local repos?
From: Avery Pennarun @ 2009-10-28 18:33 UTC (permalink / raw)
To: matvejchikov; +Cc: git
In-Reply-To: <8496f91a0910280509p49447d6egd7c07b382657c375@mail.gmail.com>
On Wed, Oct 28, 2009 at 8:09 AM, Matvejchikov Ilya
<matvejchikov@gmail.com> wrote:
> I have a remote storage server with a git-daemon running and I want to
> be able to put some data in that repo
> in a way like 'git hash-object -w <object>'. The general problem for
> me is that I don't want to create any local
> git repositories that is needed by 'pit push ...' etc.
>
> So, is it possible to use git for remote storage purposes without
> making local repository?
This functionality isn't built into git (and it might be considered a
security hole, strictly speaking, if a repository let you download any
object by default). However, it would be pretty easy to create your
own server that does this.
For example, you could make one CGI script that dumps its POST data
into a pipe to "git hash-object --stdin -w"
I've written a service similar to this at work. It's relatively
simple to do a basic version. Of course, as you get into more
complicated situations (what about multiple users updating the same
filename? merges? authentication?) it gets more complicated. But I
think everybody would want this for a different reason, so it's
unlikely that there'll ever be a single "standard" solution.
Have fun,
Avery
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: Dirk Süsserott @ 2009-10-28 19:24 UTC (permalink / raw)
To: Allan Caffee; +Cc: Dirk Süsserott, eschvoca, kusmabite, git
In-Reply-To: <b2e43f8f0910261347m38ccb608nb5858ff1dc432b33@mail.gmail.com>
Am 26.10.2009 21:47 schrieb Allan Caffee:
> 2009/10/26 Dirk Süsserott <newsletter@dirk.my1.cc>:
>> Am 26.10.2009 19:08 schrieb eschvoca:
>> Hi,
>>
>> probably my approach could help you in the future: When I create a new repo
>> (git init) I firstly create an initial commit with nothing else than an
>> initial commit, i.e.:
>>
>> $ git init
>> $ echo "initial" > initial.commit
>> $ git add initial.commit
>> $ git commit -m "Initial commit"
>
> I don't think this is actually necessary. You should just be able to do:
> $ git init
> $ git commit --allow-empty -m "Initial commit (empty)"
>
Allan,
that works great and is not as cumbersome as my solution.
Thank you!
Dirk
^ permalink raw reply
* Re: [PATCH] help -a: do not unnecessarily look for a repository
From: Junio C Hamano @ 2009-10-28 20:26 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20091028093022.30253.qmail@d8110c1e8cdcdf.315fe32.mid.smarden.org>
Thanks.
^ permalink raw reply
* What's cooking in git.git (Oct 2009, #05; Wed, 28)
From: Junio C Hamano @ 2009-10-28 21:11 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
--------------------------------------------------
[Graduated to "master"]
* jc/fsck-default-full (2009-10-20) 1 commit
+ fsck: default to "git fsck --full"
* jc/maint-fix-unpack-zlib-check (2009-10-21) 1 commit.
+ Fix incorrect error check while reading deflated pack data
* jc/receive-pack-auto (2009-10-20) 2 commits.
+ receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
+ gc --auto --quiet: make the notice a bit less verboase
* bg/clone-doc (2009-10-20) 1 commit.
+ git-clone.txt: Fix grammar and formatting
* iv/tar-lzma-xz (2009-10-20) 1 commit.
+ import-tars: Add support for tarballs compressed with lzma, xz
* jk/maint-cvsimport-pathname (2009-10-19) 1 commit.
+ cvsimport: fix relative argument filenames
* sb/gitweb-link-author (2009-10-15) 1 commit
+ gitweb: linkify author/committer names with search
--------------------------------------------------
[New Topics]
* jp/dirty-describe (2009-10-21) 1 commit.
- Teach "git describe" --dirty option
Soon in 'next'.
* jp/fetch-cull-many-refs (2009-10-25) 2 commits
- fetch: Speed up fetch of large numbers of refs
- remote: Make ref_remove_duplicates faster for large numbers of refs
* bg/format-patch-p-noop (2009-10-25) 3 commits.
- format-patch documentation: Fix formatting
- format-patch documentation: Remove diff options that are not useful
- format-patch: Make implementation and documentation agree
* jk/gitignore-anchored (2009-10-26) 1 commit
- gitignore: root most patterns at the top-level directory
* jk/maint-add-p-empty (2009-10-27) 1 commit.
- add-interactive: handle deletion of empty files
Soon in 'next'.
* jk/maint-push-config (2009-10-25) 1 commit.
- push: always load default config
Soon in 'next'.
* lt/revision-bisect (2009-10-27) 1 commit.
- Add '--bisect' revision machinery argument
* mh/maint-diff-color-words (2009-10-28) 3 commits
- diff: fix the location of hunk headers for "git diff --color-words -U0"
- diff: move the handling of the hunk header after the changed lines
- t4034-diff-words: add a test for word diff without context
--------------------------------------------------
[Stalled]
* tr/filter-branch (2009-10-21) 2 commits.
- filter-branch: nearest-ancestor rewriting outside subdir filter
- filter-branch: stop special-casing $filter_subdir argument
J6t already has some comments on this.
* mr/gitweb-snapshot (2009-09-26) 2 commits.
- gitweb: append short hash ids to snapshot files
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
Jakub says the tip one needs updates.
* ne/rev-cache (2009-10-19) 7 commits.
- support for commit grafts, slight change to general mechanism
- support for path name caching in rev-cache
- full integration of rev-cache into git, completed test suite
- administrative functions for rev-cache, start of integration into git
- support for non-commit object caching in rev-cache
- basic revision cache system, no integration or features
- man page and technical discussion for rev-cache
The author indicated that there is another round coming.
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
???
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
--------------------------------------------------
[Cooking]
* db/vcs-helper-rest (2009-10-27) 7 commits.
- Fix memory leak in helper method for disconnect
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
Queued a fix-up.
* jh/cvs-helper (2009-08-18) 8 commits.
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
This depends on the above.
* cb/doc-fetch-pull-merge (2009-10-21) 1 commit.
(merged to 'next' on 2009-10-21 at 1d9190d)
+ modernize fetch/merge/pull examples
Soon in 'master'.
* ja/fetch-doc (2009-10-22) 3 commits.
(merged to 'next' on 2009-10-22 at 8868407)
+ Documentation/merge-options.txt: order options in alphabetical groups
+ Documentation/git-pull.txt: Add subtitles above included option files
(merged to 'next' on 2009-10-21 at bf09f62)
+ Documentation/fetch-options.txt: order options alphabetically
Soon in 'master'.
* tr/maint-roff-quote (2009-10-22) 1 commit.
(merged to 'next' on 2009-10-22 at 14c5631)
+ Quote ' as \(aq in manpages
Soon in 'master'.
* rs/pretty-wrap (2009-10-17) 1 commit
- Implement wrap format %w() as if it is a mode switch
(this branch uses js/log-rewrap.)
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
* js/log-rewrap (2009-10-18) 3 commits
- Teach --wrap to only indent without wrapping
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
(this branch is used by rs/pretty-wrap.)
Before discarding jc/strbuf-nested-expand, I cherry-picked the tip of it
to this series.
* sr/blame-incomplete (2009-10-19) 1 commit.
(merged to 'next' on 2009-10-22 at 133e0ce)
+ blame: make sure that the last line ends in an LF
I think this is _good enough_ as-is; although it would be better if we
added some hint to the output for Porcelain implementations, that can be
done as a follow-up fix.
* ak/bisect-reset-to-switch (2009-10-13) 1 commit.
(merged to 'next' on 2009-10-22 at 592fff3)
+ bisect reset: Allow resetting to any commit, not just a branch
Soon in 'master'.
* fc/doc-fast-forward (2009-10-24) 1 commit.
- Use 'fast-forward' all over the place
* jc/maint-1.6.3-graft-trailing-space (2009-10-14) 1 commit.
(merged to 'next' on 2009-10-22 at 90ccac6)
+ info/grafts: allow trailing whitespaces at the end of line
Soon in 'master'.
* jn/show-normalized-refs (2009-10-12) 3 commits.
(merged to 'next' on 2009-10-23 at 332aad3)
+ check-ref-format: simplify --print implementation
+ git check-ref-format --print
+ Add tests for git check-ref-format
Soon in 'master'.
* jc/checkout-auto-track (2009-10-18) 3 commits
(merged to 'next' on 2009-10-23 at ff7e8f3)
+ git checkout --no-guess
+ DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
+ check_filename(): make verify_filename() callable without dying
The final shape of this series ended up to be more or less exactly what
Dscho hinted he wanted to have in one of the discussion.
Soon in 'master'.
* tr/stash-format (2009-10-19) 5 commits
(merged to 'next' on 2009-10-23 at 6c551c3)
+ stash list: drop the default limit of 10 stashes
+ stash list: use new %g formats instead of sed
+ Introduce new pretty formats %g[sdD] for reflog information
+ reflog-walk: refactor the branch@{num} formatting
+ Refactor pretty_print_commit arguments into a struct
Soon in 'master'.
* ks/precompute-completion (2009-10-26) 3 commits.
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
* sp/smart-http (2009-10-25) 24 commits
- remote-helpers: return successfully if everything up-to-date
- update http tests according to remote-curl capabilities
- http-backend: more explict LocationMatch
- http-backend: add example for gitweb on same URL
- http-backend: use mod_alias instead of mod_rewrite
- http-backend: reword some documentation
- http-backend: add GIT_PROJECT_ROOT environment var
- Smart HTTP fetch: gzip requests
- Smart fetch over HTTP: client side
- Smart push over HTTP: client side
- Discover refs via smart HTTP server when available
- Smart fetch and push over HTTP: server side
- Add stateless RPC options to upload-pack, receive-pack
- Git-aware CGI to provide dumb HTTP transport
- Move WebDAV HTTP push under remote-curl
- remote-helpers: Support custom transport options
- remote-helpers: Fetch more than one ref in a batch
- fetch: Allow transport -v -v -v to set verbosity to 3
- remote-curl: Refactor walker initialization
- Add multi_ack_detailed capability to fetch-pack/upload-pack
- Move "get_ack()" back to fetch-pack
- fetch-pack: Use a strbuf to compose the want list
- pkt-line: Make packet_read_line easier to debug
- pkt-line: Add strbuf based functions
Shawn plans another round of re-roll.
* ef/msys-imap (2009-10-22) 9 commits.
- Windows: use BLK_SHA1 again
- MSVC: Enable OpenSSL, and translate -lcrypto
- mingw: enable OpenSSL
- mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
- imap-send: build imap-send on Windows
- imap-send: fix compilation-error on Windows
- imap-send: use run-command API for tunneling
- imap-send: use separate read and write fds
- imap-send: remove useless uid code
This is pulled from J6t; I'll merge it to 'next' if Dscho is Ok with it.
* js/diff-verbose-submodule (2009-10-23) 2 commits.
(merged to 'next' on 2009-10-23 at e479773)
+ add tests for git diff --submodule
+ Add the --submodule option to the diff option family
Soon in 'master'.
* jc/fix-tree-walk (2009-10-22) 11 commits.
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
+ unpack_callback(): use unpack_failed() consistently
+ unpack-trees: typofix
+ diff-lib.c: fix misleading comments on oneway_diff()
This has some stupid bugs and temporarily reverted from 'next' until I can
fix it.
* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Add selftests verifying concatenation of multiple notes for the same commit
- Refactor notes code to concatenate multiple notes annotating the same object
- Add selftests verifying that we can parse notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- Teach notes code to free its internal data structures on request
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
I think Johan indicated that early parts of it is ready for 'next', so I
may do so up to "Add selftests" one.
* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame. Probably the first three should go to 'master' by now?
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jc/1.7.0-no-commit-no-ff-2 (2009-10-22) 1 commit.
- git-merge: forbid fast-forward and up-to-date when --no-commit is given
This makes "git merge --no-commit" fail when it results in fast-forward or
up-to-date. I haven't described this at the beginning of this message
yet, as it is not clear if this change is even necessary. Opinions?
* jk/1.7.0-status (2009-09-05) 5 commits.
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
The tip one is not in 'next' as I have been hoping that somebody may want
to change the code to make it unnecessary, but it does not seem to be
happening, so probably it should also go to 'next'.
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* jg/log-format-body-indent (2009-09-19) 1 commit.
. git-log --format: Add %B tag with %B(x) option
^ permalink raw reply
* Fwd: [ANN] gitsharp 0.2 released
From: Meinrad Recheis @ 2009-10-28 21:33 UTC (permalink / raw)
To: git
In-Reply-To: <658c7e11-85ad-4ae6-a2a3-dec5aff121d1@b2g2000yqi.googlegroups.com>
Dear fellow git enthusiasts,
We are proud to announce version 0.2 which marks significant
improvements in the new Git api we are building around GitSharp.Core.
The core is a line-by-line port of jgit. We found it quite hard to use
without good knowledge of git's internals and technical concepts.
The api which is documented by examples at
http://www.eqqon.com/index.php/GitSharp/Examples
encapsulates and abstracts this knowledge so that everyone with a
little git experience can easily make use of the library.
The improvements mentioned above allow to add files to the index and
commit them. It is as easy as this:
var repo = Repository.Init("path/to/new/repo");
Now suppose you have created some files in the new repository and want
to stage them for committing:
repo.Index.Add("README", "License.txt");
var commit=repo.Commit("My first commit with gitsharp", new Author
("henon", "meinrad.recheis@gmail.com"));
Easy, isn't it? Now let's have a look at the changes of this commit:
foreach(var change in commit.Changes) Console.WriteLine
(change.Name + " " + change.ChangeType);
Of course there is still much work to do until this new API will
completely reflect the full range of git interactions a standard
application is probably going to need. We hope to quickly build up the
most important parts until the end of the year. If you check it out,
please give us feedback which will be greatly appreciated.
Download Gitsharp 0.2 binaries from
http://www.eqqon.com/index.php?title=GitSharp/v0.2.0
Have a nice day,
--Henon 21:22, 28 October 2009 (CET)
^ permalink raw reply
* [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Scott Chacon @ 2009-10-28 21:39 UTC (permalink / raw)
To: git list; +Cc: Junio C Hamano, Charles Bailey, David Aguilar
In-Reply-To: <d411cc4a0910280837h52596089je9ab4d03383d43cc@mail.gmail.com>
p4merge is now a built-in diff/merge tool.
This adds p4merge to git-completion and updates
the documentation to mention p4merge.
Signed-Off-By: Scott Chacon <schacon@gmail.com>
---
This is the same patch, but I tested it on Linux as well as Mac and it
works fine as long as the [difftool|mergetool].p4merge.path configs
are set or it's in your path.
Documentation/git-difftool.txt | 2 +-
Documentation/git-mergetool.txt | 2 +-
Documentation/merge-config.txt | 2 +-
contrib/completion/git-completion.bash | 2 +-
git-mergetool--lib.sh | 17 +++++++++++++++--
5 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 96a6c51..8e9aed6 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -31,7 +31,7 @@ OPTIONS
Use the diff tool specified by <tool>.
Valid merge tools are:
kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff,
- ecmerge, diffuse, opendiff and araxis.
+ ecmerge, diffuse, opendiff, p4merge and araxis.
+
If a diff tool is not specified, 'git-difftool'
will use the configuration variable `diff.tool`. If the
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 68ed6c0..4a6f7f3 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -27,7 +27,7 @@ OPTIONS
Use the merge resolution program specified by <tool>.
Valid merge tools are:
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge,
- diffuse, tortoisemerge, opendiff and araxis.
+ diffuse, tortoisemerge, opendiff, p4merge and araxis.
+
If a merge resolution program is not specified, 'git-mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index c0f96e7..a403155 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -23,7 +23,7 @@ merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: "kdiff3",
"tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff",
- "diffuse", "ecmerge", "tortoisemerge", "araxis", and
+ "diffuse", "ecmerge", "tortoisemerge", "p4merge", "araxis" and
"opendiff". Any other value is treated is custom merge tool
and there must be a corresponding mergetool.<tool>.cmd option.
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d3fec32..5fb6017 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -953,7 +953,7 @@ _git_diff ()
}
__git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff
- tkdiff vimdiff gvimdiff xxdiff araxis
+ tkdiff vimdiff gvimdiff xxdiff araxis p4merge
"
_git_difftool ()
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index bfb01f7..f7c571e 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -46,7 +46,7 @@ check_unchanged () {
valid_tool () {
case "$1" in
kdiff3 | tkdiff | xxdiff | meld | opendiff | \
- emerge | vimdiff | gvimdiff | ecmerge | diffuse | araxis)
+ emerge | vimdiff | gvimdiff | ecmerge | diffuse | araxis | p4merge)
;; # happy
tortoisemerge)
if ! merge_mode; then
@@ -130,6 +130,19 @@ run_merge_tool () {
"$merge_tool_path" "$LOCAL" "$REMOTE"
fi
;;
+ p4merge)
+ if merge_mode; then
+ touch "$BACKUP"
+ if $base_present; then
+ "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
+ else
+ "$merge_tool_path" "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
+ fi
+ check_unchanged
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ fi
+ ;;
meld)
if merge_mode; then
touch "$BACKUP"
@@ -323,7 +336,7 @@ guess_merge_tool () {
else
tools="opendiff kdiff3 tkdiff xxdiff meld $tools"
fi
- tools="$tools gvimdiff diffuse ecmerge araxis"
+ tools="$tools gvimdiff diffuse ecmerge p4merge araxis"
fi
if echo "${VISUAL:-$EDITOR}" | grep emacs > /dev/null 2>&1; then
# $EDITOR is emacs so add emerge as a candidate
--
1.6.5.2.75.gad2f8
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Sverre Rabbelier @ 2009-10-28 22:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git, vcs-fast-import-devs
In-Reply-To: <fabb9a1e0910081058m59527600o392a6b438b18512e@mail.gmail.com>
Heya,
On Thu, Oct 8, 2009 at 10:58, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> I think it makes to ignore options that are not for our vcs, as long
> as options that change import behavior (such as marks, date-format)
> are combined with, say, 'feature tool=git'. This way we can be sure
> that when outputting out a vcs specific stream, it is only parsed by
> that vcs.
>
> Note: yes, I know that marks and date-format are features now, but
> there's really no other suitable example that I could think of).
>
> vcs fast import devs please ack this idea (and perhaps suggest
> something other than "feature tool=git" if preferable) so that I can
> reroll my gfi-options series :).
Shawn, what do you want to do with this, it seems the vcs devs are not
very interested in this feature, should I implement it as described
above? That is:
* If you use any option that is stream-changing you should include
"feature tool=git" in your stream
* import-marks and export-marks are made into features
* "option vcs" is ignored if vcs is a different vcs
* "option vcs" must be recognised if vcs is this vcs
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #05; Wed, 28)
From: Sverre Rabbelier @ 2009-10-28 22:09 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce; +Cc: git
In-Reply-To: <7vfx93jkb1.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Oct 28, 2009 at 14:11, Junio C Hamano <gitster@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits.
> - fast-import: test the new option command
> - fast-import: add option command
> - fast-import: test the new feature command
> - fast-import: add feature command
> - fast-import: put marks reading in it's own function
> - fast-import: put option parsing code in separate functions
>
> ???
Repinged Shawn and the vcs list to decide what to do, I really want to
get this done with...
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH v2] describe: when failing, tell the user about options that work
From: Thomas Rast @ 2009-10-28 22:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eugene Sajine
In-Reply-To: <7vmy3iaqfr.fsf@alter.siamese.dyndns.org>
Users seem to call git-describe without reading the manpage, and then
wonder why it doesn't work with unannotated tags by default.
Make a minimal effort towards seeing if there would have been
unannotated tags, and tell the user. Specifically, we say that --tags
could work if we found any unannotated tags. If not, we say that
--always would have given results.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
> > However, it could be written e.g.
> >
> > No annotated tags can describe '%s'. However, there were
> > unannotated tags: try --tags.
>
> Sounds better.
Then let's make it so. Sorry for taking so long.
builtin-describe.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index 2dcfd3d..4ea6f88 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -96,8 +96,6 @@ static int get_name(const char *path, const unsigned char *sha1, int flag, void
if (!all) {
if (!prio)
return 0;
- if (!tags && prio < 2)
- return 0;
}
add_to_known_names(all ? path + 5 : path + 10, commit, prio, sha1);
return 0;
@@ -184,6 +182,7 @@ static void describe(const char *arg, int last_one)
struct possible_tag all_matches[MAX_TAGS];
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
unsigned long seen_commits = 0;
+ unsigned int unannotated_cnt = 0;
if (get_sha1(arg, sha1))
die("Not a valid object name %s", arg);
@@ -217,7 +216,9 @@ static void describe(const char *arg, int last_one)
seen_commits++;
n = c->util;
if (n) {
- if (match_cnt < max_candidates) {
+ if (!tags && !all && n->prio < 2) {
+ unannotated_cnt++;
+ } else if (match_cnt < max_candidates) {
struct possible_tag *t = &all_matches[match_cnt++];
t->name = n;
t->depth = seen_commits - 1;
@@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
printf("%s\n", find_unique_abbrev(sha1, abbrev));
return;
}
- die("cannot describe '%s'", sha1_to_hex(sha1));
+ if (unannotated_cnt)
+ die("No annotated tags can describe '%s'.\n"
+ "However, there were unannotated tags: try --tags.",
+ sha1_to_hex(sha1));
+ else
+ die("No tags can describe '%s'.\n"
+ "Try --always, or create some tags.",
+ sha1_to_hex(sha1));
}
qsort(all_matches, match_cnt, sizeof(all_matches[0]), compare_pt);
--
1.6.5.1.161.g3b9c0
^ permalink raw reply related
* [PATCH] Teach 'git merge' and 'git pull' the option --ff-only
From: Björn Gustavsson @ 2009-10-28 22:15 UTC (permalink / raw)
To: git; +Cc: gitster
For convenience in scripts and aliases, add the option
--ff-only to only allow fast-forwards.
Acknowledgements: I did look at Yuval Kogman's earlier
patch (107768 in gmane), mainly as shortcut to find my
way in the code, but I did not copy anything directly.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
When I started to use git earlier this year, I was suprised
that there was a --no-ff option but no --ff-only option.
I saw in the mailing list archive at gmane that there has
been two previous attempts to implement --ff-only. The first
patch was made to the git-merge.sh script (before
builtin-merge.c was created). As far as I understand it,
the author of the patch said he would send some corrections
of the patch, but he never did, and nothing more happened.
So here is my patch, the third attempt.
Documentation/merge-options.txt | 4 ++++
builtin-merge.c | 16 ++++++++++++++--
git-pull.sh | 7 +++++--
t/t7600-merge.sh | 29 +++++++++++++++++++++++++++++
4 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index adadf8e..fbf8976 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -60,6 +60,10 @@
a fast-forward, only update the branch pointer. This is
the default behavior of git-merge.
+--ff-only::
+ Refuse to merge unless the merge can be resolved as a
+ fast-forward.
+
-s <strategy>::
--strategy=<strategy>::
Use the given merge strategy; can be supplied more than
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..298adfb 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -43,6 +43,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, option_log, squash;
static int option_commit = 1, allow_fast_forward = 1;
+static int fast_forward_only;
static int allow_trivial = 1, have_message;
static struct strbuf merge_msg;
static struct commit_list *remoteheads;
@@ -167,6 +168,8 @@ static struct option builtin_merge_options[] = {
"perform a commit if the merge succeeds (default)"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
"allow fast forward (default)"),
+ OPT_BOOLEAN(0, "ff-only", &fast_forward_only,
+ "abort if fast forward is not possible"),
OPT_CALLBACK('s', "strategy", &use_strategies, "strategy",
"merge strategy to use", option_parse_strategy),
OPT_CALLBACK('m', "message", &merge_msg, "message",
@@ -874,6 +877,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
option_commit = 0;
}
+ if (!allow_fast_forward && fast_forward_only)
+ die("You cannot combine --no-ff with --ff-only.");
+
if (!argc)
usage_with_options(builtin_merge_usage,
builtin_merge_options);
@@ -969,8 +975,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
for (i = 0; i < use_strategies_nr; i++) {
- if (use_strategies[i]->attr & NO_FAST_FORWARD)
+ if (use_strategies[i]->attr & NO_FAST_FORWARD) {
allow_fast_forward = 0;
+ if (fast_forward_only)
+ die("You cannot combine --ff-only with the merge strategy '%s'.", use_strategies[i]->name);
+ }
if (use_strategies[i]->attr & NO_TRIVIAL)
allow_trivial = 0;
}
@@ -1040,7 +1049,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* only one common.
*/
refresh_cache(REFRESH_QUIET);
- if (allow_trivial) {
+ if (allow_trivial && !fast_forward_only) {
/* See if it is really trivial. */
git_committer_info(IDENT_ERROR_ON_NO_NAME);
printf("Trying really trivial in-index merge...\n");
@@ -1079,6 +1088,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
+ if (fast_forward_only)
+ die("Not possible to fast forward, aborting.");
+
/* We are going to make a new commit. */
git_committer_info(IDENT_ERROR_ON_NO_NAME);
diff --git a/git-pull.sh b/git-pull.sh
index fc78592..37f3d93 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,7 +16,8 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= diffstat= no_commit= squash= no_ff= log_arg= verbosity=
+strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
+log_arg= verbosity=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
@@ -45,6 +46,8 @@ do
no_ff=--ff ;;
--no-ff)
no_ff=--no-ff ;;
+ --ff-only)
+ ff_only=--ff-only ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -215,5 +218,5 @@ merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
test true = "$rebase" &&
exec git-rebase $diffstat $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git-merge $diffstat $no_commit $squash $no_ff $log_arg $strategy_args \
+exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
"$merge_name" HEAD $merge_head $verbosity
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index e5b210b..d696ea9 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -243,6 +243,16 @@ test_expect_success 'merge c0 with c1' '
test_debug 'gitk --all'
+test_expect_success 'merge c0 with c1 with --ff-only' '
+ git reset --hard c0 &&
+ git merge --ff-only c1 &&
+ git merge --ff-only HEAD c0 c1 &&
+ verify_merge file result.1 &&
+ verify_head "$c1"
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2' '
git reset --hard c1 &&
test_tick &&
@@ -263,6 +273,14 @@ test_expect_success 'merge c1 with c2 and c3' '
test_debug 'gitk --all'
+test_expect_success 'failing merges with --ff-only' '
+ git reset --hard c1 &&
+ test_tick &&
+ test_must_fail git merge --ff-only c2 &&
+ test_must_fail git merge --ff-only c3 &&
+ test_must_fail git merge --ff-only c2 c3
+'
+
test_expect_success 'merge c0 with c1 (no-commit)' '
git reset --hard c0 &&
git merge --no-commit c1 &&
@@ -432,6 +450,17 @@ test_expect_success 'combining --squash and --no-ff is refused' '
test_must_fail git merge --no-ff --squash c1
'
+test_expect_success 'combining --ff-only and --no-ff is refused' '
+ test_must_fail git merge --ff-only --no-ff c1 &&
+ test_must_fail git merge --no-ff --ff-only c1
+'
+
+test_expect_success 'combining --ff-only with certain merge strategies is refused' '
+ git reset --hard c0 &&
+ test_must_fail git merge --ff-only --strategy=ours c1 &&
+ test_must_fail git merge --ff-only --strategy=subtree c1
+'
+
test_expect_success 'merge c0 with c1 (ff overrides no-ff)' '
git reset --hard c0 &&
git config branch.master.mergeoptions "--no-ff" &&
--
1.6.5.1.69.g36942
^ permalink raw reply related
* Re: [PATCH 0/3] fix "git diff --color-words -U0"
From: Markus Heidelberg @ 2009-10-28 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v7hufo07i.fsf@alter.siamese.dyndns.org>
Junio C Hamano, 28.10.2009:
> Is this a serious enough breakage that deserves to be fixed in the
> maintenance track (1.6.5.X)?
This problem exists since the introduction of this feature over three
years ago and apparently nobody complained so far. So I don't think it's
overly serious.
OTOH, depending on the change the produced diff can be totally wrong.
Found a good example: c5022f576aa583429c245054d8600564b788ff33
Compare "--color-words -U0" with "--color-words -U1".
^ permalink raw reply
* Re: Getting Ensimag students to work on Git for a few weeks
From: Jakub Narebski @ 2009-10-28 22:41 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Matthieu Moy, git
In-Reply-To: <20091027144405.GA12464@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Tue, Oct 27, 2009 at 11:12:52AM +0100, Matthieu Moy wrote:
>
> > The students work full-time for about 3 weeks (May 20th to June 16th),
> > and are grouped by teams of 2 to 4 students. Given my bandwidth, I
> > plan to propose only one group of 4 students this year, but we may
> > scale up later, who knows.
>
> That's not much time to get familiar with a complex project like git. So you
> will have to do something extremely simple, which probably means that it
> won't be anything exciting. If it were, someone else would have done it
> already.
Let's take a look at some projects from SoC2009Ideas and Wishlist:
* "smart" HTTP transport is being actively worked on
* narrow / sparse checkout is being worked on
* directory renames development stalled, I think last was in
http://thread.gmane.org/gmane.comp.version-control.git/99529
* git-svnserver has supposedly partial Python implementation
* restartable clone, which should be fairly easy to add to "dumb"
protocols, and quite challenging to add to "smart" protocols;
even without a code, having fresh ideas would be nice
* (optional) support for empty directories, needs index extension,
there were some patches, but the area might be muddy
It all depends on what you want to achieve in this short time. Would
it be to get to know OSS development workflow (submitting patches,
answering reviews, etc.), or would it be solving interesting real-life
problem, or perhaps solving some problem from beginning to the end
(the code being accepted).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Teach 'git merge' and 'git pull' the option --ff-only
From: Junio C Hamano @ 2009-10-28 22:45 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <4AE8C281.50104@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> For convenience in scripts and aliases, add the option
> --ff-only to only allow fast-forwards.
>
> Acknowledgements: I did look at Yuval Kogman's earlier
> patch (107768 in gmane), mainly as shortcut to find my
> way in the code, but I did not copy anything directly.
>
> Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Thanks. I think you covered the points in the old discussion thread.
> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
> index adadf8e..fbf8976 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -60,6 +60,10 @@
> a fast-forward, only update the branch pointer. This is
> the default behavior of git-merge.
>
> +--ff-only::
> + Refuse to merge unless the merge can be resolved as a
> + fast-forward.
Do you or do you not allow "already up to date"? I think it makes sense
to allow it, but it is unclear from these two lines.
> @@ -874,6 +877,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> option_commit = 0;
> }
>
> + if (!allow_fast_forward && fast_forward_only)
> + die("You cannot combine --no-ff with --ff-only.");
Are these the only nonsensical combinations? How should this interact
with other options, e.g. --squash or --message?
> @@ -969,8 +975,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> }
>
> for (i = 0; i < use_strategies_nr; i++) {
> - if (use_strategies[i]->attr & NO_FAST_FORWARD)
> + if (use_strategies[i]->attr & NO_FAST_FORWARD) {
> allow_fast_forward = 0;
> + if (fast_forward_only)
> + die("You cannot combine --ff-only with the merge strategy '%s'.", use_strategies[i]->name);
> + }
I am not convinced this tests the right condition nor it is placed at the
right place in the codepath---even if a specified strategy happens to
allow fast-forward, wouldn't it be nonsense to say
$ git merge --ff-only -s resolve that-one
in the first place? Note that I am not saying "I am convinced this is
wrong."
> @@ -1040,7 +1049,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> * only one common.
> */
> refresh_cache(REFRESH_QUIET);
> - if (allow_trivial) {
> + if (allow_trivial && !fast_forward_only) {
Good.
> @@ -1079,6 +1088,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> }
> }
>
> + if (fast_forward_only)
> + die("Not possible to fast forward, aborting.");
Good.
^ permalink raw reply
* [PATCH v3 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Thomas Rast @ 2009-10-28 22:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <4AE0187C.4040608@viscovery.net>
Handling $filter_subdir in the usual way requires a separate case at
every use, because the variable is empty when unused.
Furthermore, the case for --subdirectory-filter supplies its own --,
so the user cannot provide one himself, so the following was
impossible:
git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
To keep the argument handling sane, we filter $@ to contain only the
non-revision arguments, and store all revisions in $ref_args. The
$ref_args are easy to handle since only the SHA1s are needed; the
actual branch names have already been stored in $tempdir/heads at this
point.
An extra separating -- is only required if the user did not provide
any non-revision arguments, as the latter disambiguate the
$filter_subdir following after them (or fail earlier because they are
ambiguous themselves).
Thanks to Johannes Sixt for suggesting this solution.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Johannes Sixt wrote:
> When the shell expands $variable (outside quotes), it does not apply
> quotes anymore, but only word-splits using $IFS. In your code, the words
> would contain literal single-quotes, and paths with spaces would still be
> split into words.
If there's a good reason for these weird rules, I'm still missing
it...
But your suggestion works very nicely.
git-filter-branch.sh | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a480d6f..da23b99 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -257,15 +257,23 @@ git read-tree || die "Could not seed the index"
# map old->new commit ids for rewriting parents
mkdir ../map || die "Could not create map/ directory"
+dashdash=
+test -z "$(git rev-parse --no-revs "$@")" && dashdash=--
+ref_args=$(git rev-parse --revs-only "$@")
+
case "$filter_subdir" in
"")
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@"
+ eval set -- "$(git rev-parse --sq --no-revs "$@")"
;;
*)
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@" -- "$filter_subdir"
-esac > ../revs || die "Could not get the commits"
+ eval set -- "$(git rev-parse --sq --no-revs "$@")" \
+ $dashdash "$filter_subdir"
+ ;;
+esac
+
+git rev-list --reverse --topo-order --default HEAD \
+ --parents --simplify-merges $ref_args "$@" \
+ > ../revs || die "Could not get the commits"
commits=$(wc -l <../revs | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
@@ -356,8 +364,7 @@ then
do
sha1=$(git rev-parse "$ref"^0)
test -f "$workdir"/../map/$sha1 && continue
- ancestor=$(git rev-list --simplify-merges -1 \
- $ref -- "$filter_subdir")
+ ancestor=$(git rev-list --simplify-merges -1 "$ref" "$@")
test "$ancestor" && echo $(map $ancestor) >> "$workdir"/../map/$sha1
done < "$tempdir"/heads
fi
--
1.6.5.1.161.g3b9c0
^ permalink raw reply related
* [PATCH v3 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Thomas Rast @ 2009-10-28 22:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <6e01558f719f4bfcd12f3c6dc5657790e86c874d.1256770377.git.trast@student.ethz.ch>
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch -- <refs> -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Same as v2.
Documentation/git-filter-branch.txt | 13 ++++++++++++-
git-filter-branch.sh | 9 ++++++++-
t/t7003-filter-branch.sh | 18 ++++++++++++++++++
3 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2b40bab..394a77a 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -159,7 +159,18 @@ to other tags will be rewritten to point to the underlying commit.
--subdirectory-filter <directory>::
Only look at the history which touches the given subdirectory.
The result will contain that directory (and only that) as its
- project root.
+ project root. Implies --remap-to-ancestor.
+
+--remap-to-ancestor::
+ Rewrite refs to the nearest rewritten ancestor instead of
+ ignoring them.
++
+Normally, positive refs on the command line are only changed if the
+commit they point to was rewritten. However, you can limit the extent
+of this rewriting by using linkgit:rev-list[1] arguments, e.g., path
+limiters. Refs pointing to such excluded commits would then normally
+be ignored. With this option, they are instead rewritten to point at
+the nearest ancestor that was not excluded.
--prune-empty::
Some kind of filters will generate empty commits, that left the tree
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index da23b99..ad2bc6f 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -125,6 +125,7 @@ filter_subdir=
orig_namespace=refs/original/
force=
prune_empty=
+remap_to_ancestor=
while :
do
case "$1" in
@@ -137,6 +138,11 @@ do
force=t
continue
;;
+ --remap-to-ancestor)
+ shift
+ remap_to_ancestor=t
+ continue
+ ;;
--prune-empty)
shift
prune_empty=t
@@ -182,6 +188,7 @@ do
;;
--subdirectory-filter)
filter_subdir="$OPTARG"
+ remap_to_ancestor=t
;;
--original)
orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
@@ -358,7 +365,7 @@ done <../revs
# revision walker. Fix it by mapping these heads to the unique nearest
# ancestor that survived the pruning.
-if test "$filter_subdir"
+if test "$remap_to_ancestor" = t
then
while read ref
do
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 329c851..9503875 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -288,4 +288,22 @@ test_expect_success 'Prune empty commits' '
test_cmp expect actual
'
+test_expect_success '--remap-to-ancestor with filename filters' '
+ git checkout master &&
+ git reset --hard A &&
+ test_commit add-foo foo 1 &&
+ git branch moved-foo &&
+ test_commit add-bar bar a &&
+ git branch invariant &&
+ orig_invariant=$(git rev-parse invariant) &&
+ git branch moved-bar &&
+ test_commit change-foo foo 2 &&
+ git filter-branch -f --remap-to-ancestor \
+ moved-foo moved-bar A..master \
+ -- -- foo &&
+ test $(git rev-parse moved-foo) = $(git rev-parse moved-bar) &&
+ test $(git rev-parse moved-foo) = $(git rev-parse master^) &&
+ test $orig_invariant = $(git rev-parse invariant)
+'
+
test_done
--
1.6.5.1.161.g3b9c0
^ permalink raw reply related
* Re: Add '--bisect' revision machinery argument
From: Junio C Hamano @ 2009-10-28 23:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Christian Couder
In-Reply-To: <alpine.LFD.2.01.0910271124110.31845@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> So this adds "--bisect" as a revision parsing argument, and as a result it
> just works with all the normal logging tools. So now I can just do
>
> gitk --bisect --simplify-by-decoration filename-here
This shows a very nice direction to evolve, but your patch as-is breaks
"rev-list --bisect", I think. Call to your setup_revisions() eats the
command line "--bisect" option but cmd_rev_list() wants to see it to go
into the "bisection" mode of traversal.
Also, the helper of "git bisect" can and probably should be taught to just
ask this new behaviour from the revision machinery, instead of collecting
good and bad refs itself using bisect.c::read_bisect_refs().
Here is a short-term fix that can be squashed in, in order to allow t6022
to pass again.
builtin-rev-list.c | 2 ++
revision.c | 1 +
revision.h | 1 +
3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 4ba1c12..32bf033 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -319,6 +319,8 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
memset(&info, 0, sizeof(info));
info.revs = &revs;
+ if (revs.bisect)
+ bisect_list = 1;
quiet = DIFF_OPT_TST(&revs.diffopt, QUIET);
for (i = 1 ; i < argc; i++) {
diff --git a/revision.c b/revision.c
index 80a0528..a36c0d9 100644
--- a/revision.c
+++ b/revision.c
@@ -1273,6 +1273,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (!strcmp(arg, "--bisect")) {
handle_refs(revs, flags, for_each_bad_bisect_ref);
handle_refs(revs, flags ^ UNINTERESTING, for_each_good_bisect_ref);
+ revs->bisect = 1;
continue;
}
if (!strcmp(arg, "--tags")) {
diff --git a/revision.h b/revision.h
index b6421a6..921656a 100644
--- a/revision.h
+++ b/revision.h
@@ -63,6 +63,7 @@ struct rev_info {
reverse:1,
reverse_output_stage:1,
cherry_pick:1,
+ bisect:1,
first_parent_only:1;
/* Diff flags */
^ permalink raw reply related
* Re: Add '--bisect' revision machinery argument
From: Linus Torvalds @ 2009-10-28 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Christian Couder
In-Reply-To: <7viqdzgls9.fsf@alter.siamese.dyndns.org>
On Wed, 28 Oct 2009, Junio C Hamano wrote:
>
> This shows a very nice direction to evolve, but your patch as-is breaks
> "rev-list --bisect", I think.
I think you're right. I tested git rev-parse, and the 'git log' machinery,
but I didn't think about the fact that we already had a meaning
for '--bisect' in rev-list.
> Also, the helper of "git bisect" can and probably should be taught to just
> ask this new behaviour from the revision machinery, instead of collecting
> good and bad refs itself using bisect.c::read_bisect_refs().
Yeah. And git-bisect.sh can be simplified too.
Linus
^ permalink raw reply
* Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)
From: Ian Clatworthy @ 2009-10-28 23:19 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Shawn O. Pearce, vcs-fast-import-devs, git, Johannes Schindelin
In-Reply-To: <fabb9a1e0910281508m3e9bb8a6g7b39abc29fceae78@mail.gmail.com>
Sverre Rabbelier wrote:
> Shawn, what do you want to do with this, it seems the vcs devs are not
> very interested in this feature, should I implement it as described
> above?
Sverre,
I'll try to take a look today. Sorry for the lack of response so far -
other stuff has been swamping my time and this hasn't reached the top of
my TODO list unfortunately.
Ian C.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Junio C Hamano @ 2009-10-28 23:37 UTC (permalink / raw)
To: Scott Chacon
Cc: Jay Soffian, git list, Junio C Hamano, Charles Bailey,
David Aguilar
In-Reply-To: <d411cc4a0910281439v3388c243v42b3700f73744623@mail.gmail.com>
Thanks. Is Jay happy with this version?
^ permalink raw reply
* [RFC PATCH v4 00/26] Return of smart HTTP
From: Shawn O. Pearce @ 2009-10-29 0:00 UTC (permalink / raw)
To: git
I think this is the final spin of the smart HTTP series. I've
collected patches from a few others (thanks folks!) and added
tests specific to the smart variant of the HTTP transport.
At this point, I think it is "next ready"... but would appreciate
any additional feedback if folks identify something we should
address before hitting next.
Clemens Buchacher (1):
remote-helpers: return successfully if everything up-to-date
Mark Lodato (5):
http-backend: add GIT_PROJECT_ROOT environment var
http-backend: reword some documentation
http-backend: use mod_alias instead of mod_rewrite
http-backend: add example for gitweb on same URL
http-backend: more explict LocationMatch
Shawn O. Pearce (18):
pkt-line: Add strbuf based functions
pkt-line: Make packet_read_line easier to debug
fetch-pack: Use a strbuf to compose the want list
Move "get_ack()" back to fetch-pack
Add multi_ack_detailed capability to fetch-pack/upload-pack
remote-curl: Refactor walker initialization
fetch: Allow transport -v -v -v to set verbosity to 3
remote-helpers: Fetch more than one ref in a batch
remote-helpers: Support custom transport options
Move WebDAV HTTP push under remote-curl
Git-aware CGI to provide dumb HTTP transport
Add stateless RPC options to upload-pack, receive-pack
Smart fetch and push over HTTP: server side
Discover refs via smart HTTP server when available
Smart push over HTTP: client side
Smart fetch over HTTP: client side
Smart HTTP fetch: gzip requests
test smart http fetch and push
Tay Ray Chuan (2):
http-push: fix check condition on http.c::finish_http_pack_request()
t5540-http-push: remove redundant fetches
.gitignore | 1 +
Documentation/config.txt | 8 +
Documentation/git-http-backend.txt | 170 ++++++++
Documentation/git-remote-helpers.txt | 85 ++++-
Makefile | 1 +
builtin-fetch-pack.c | 210 ++++++++--
builtin-fetch.c | 2 +-
builtin-receive-pack.c | 26 +-
builtin-send-pack.c | 116 +++++-
cache.h | 1 -
commit.c | 10 +-
commit.h | 2 +-
connect.c | 21 -
fetch-pack.h | 3 +-
http-backend.c | 627 ++++++++++++++++++++++++++++
http-push.c | 31 ++-
http.c | 13 +-
http.h | 2 +
pkt-line.c | 86 ++++-
pkt-line.h | 4 +
remote-curl.c | 759 ++++++++++++++++++++++++++++++++--
send-pack.h | 3 +-
sideband.c | 11 +-
t/lib-httpd/apache.conf | 20 +
t/t5540-http-push.sh | 18 +-
t/t5541-http-push.sh | 103 +++++
t/t5550-http-fetch.sh | 8 +-
t/t5551-http-fetch.sh | 87 ++++
transport-helper.c | 264 +++++++++++-
transport.c | 32 +--
transport.h | 2 +-
upload-pack.c | 71 +++-
32 files changed, 2574 insertions(+), 223 deletions(-)
create mode 100644 Documentation/git-http-backend.txt
create mode 100644 http-backend.c
create mode 100755 t/t5541-http-push.sh
create mode 100755 t/t5551-http-fetch.sh
^ permalink raw reply
* [RFC PATCH v4 05/26] Move "get_ack()" back to fetch-pack
From: Shawn O. Pearce @ 2009-10-29 0:00 UTC (permalink / raw)
To: git
In-Reply-To: <1256774448-7625-1-git-send-email-spearce@spearce.org>
In 41cb7488 Linus moved this function to connect.c for reuse inside
of the git-clone-pack command. That was 2005, but in 2006 Junio
retired git-clone-pack in commit efc7fa53. Since then the only
caller has been fetch-pack. Since this ACK/NAK exchange is only
used by the fetch-pack/upload-pack protocol we should keep move
it back to a private detail of fetch-pack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-fetch-pack.c | 21 +++++++++++++++++++++
cache.h | 1 -
connect.c | 21 ---------------------
3 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 783c2b0..7c09d46 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -157,6 +157,27 @@ static const unsigned char *get_rev(void)
return commit->object.sha1;
}
+static int get_ack(int fd, unsigned char *result_sha1)
+{
+ static char line[1000];
+ int len = packet_read_line(fd, line, sizeof(line));
+
+ if (!len)
+ die("git fetch-pack: expected ACK/NAK, got EOF");
+ if (line[len-1] == '\n')
+ line[--len] = 0;
+ if (!strcmp(line, "NAK"))
+ return 0;
+ if (!prefixcmp(line, "ACK ")) {
+ if (!get_sha1_hex(line+4, result_sha1)) {
+ if (strstr(line+45, "continue"))
+ return 2;
+ return 1;
+ }
+ }
+ die("git fetch_pack: expected ACK/NAK, got '%s'", line);
+}
+
static int find_common(int fd[2], unsigned char *result_sha1,
struct ref *refs)
{
diff --git a/cache.h b/cache.h
index a5eeead..4e283be 100644
--- a/cache.h
+++ b/cache.h
@@ -856,7 +856,6 @@ extern struct ref *find_ref_by_name(const struct ref *list, const char *name);
extern struct child_process *git_connect(int fd[2], const char *url, const char *prog, int flags);
extern int finish_connect(struct child_process *conn);
extern int path_match(const char *path, int nr, char **match);
-extern int get_ack(int fd, unsigned char *result_sha1);
struct extra_have_objects {
int nr, alloc;
unsigned char (*array)[20];
diff --git a/connect.c b/connect.c
index 7945e38..839a103 100644
--- a/connect.c
+++ b/connect.c
@@ -107,27 +107,6 @@ int server_supports(const char *feature)
strstr(server_capabilities, feature) != NULL;
}
-int get_ack(int fd, unsigned char *result_sha1)
-{
- static char line[1000];
- int len = packet_read_line(fd, line, sizeof(line));
-
- if (!len)
- die("git fetch-pack: expected ACK/NAK, got EOF");
- if (line[len-1] == '\n')
- line[--len] = 0;
- if (!strcmp(line, "NAK"))
- return 0;
- if (!prefixcmp(line, "ACK ")) {
- if (!get_sha1_hex(line+4, result_sha1)) {
- if (strstr(line+45, "continue"))
- return 2;
- return 1;
- }
- }
- die("git fetch_pack: expected ACK/NAK, got '%s'", line);
-}
-
int path_match(const char *path, int nr, char **match)
{
int i;
--
1.6.5.2.181.gd6f41
^ permalink raw reply related
* [RFC PATCH v4 03/26] pkt-line: Make packet_read_line easier to debug
From: Shawn O. Pearce @ 2009-10-29 0:00 UTC (permalink / raw)
To: git
In-Reply-To: <1256774448-7625-1-git-send-email-spearce@spearce.org>
When there is an error parsing the 4 byte length component we now
NUL terminate the string and display it as part of the die message,
this may hint as to what data was misunderstood by the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
pkt-line.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/pkt-line.c b/pkt-line.c
index bd603f8..893dd3c 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -124,12 +124,14 @@ static int packet_length(const char *linelen)
int packet_read_line(int fd, char *buffer, unsigned size)
{
int len;
- char linelen[4];
+ char linelen[5];
safe_read(fd, linelen, 4);
len = packet_length(linelen);
- if (len < 0)
- die("protocol error: bad line length character");
+ if (len < 0) {
+ linelen[4] = '\0';
+ die("protocol error: bad line length character: %s", linelen);
+ }
if (!len)
return 0;
len -= 4;
--
1.6.5.2.181.gd6f41
^ permalink raw reply related
* [RFC PATCH v4 06/26] Add multi_ack_detailed capability to fetch-pack/upload-pack
From: Shawn O. Pearce @ 2009-10-29 0:00 UTC (permalink / raw)
To: git
In-Reply-To: <1256774448-7625-1-git-send-email-spearce@spearce.org>
When multi_ack_detailed is enabled the ACK continue messages returned
by the remote upload-pack are broken out to describe the different
states within the peer. This permits the client to better understand
the server's in-memory state.
The fetch-pack/upload-pack protocol now looks like:
NAK
---------------------------------
Always sent in response to "done" if there was no common base
selected from the "have" lines (or no have lines were sent).
* no multi_ack or multi_ack_detailed:
Sent when the client has sent a pkt-line flush ("0000") and
the server has not yet found a common base object.
* either multi_ack or multi_ack_detailed:
Always sent in response to a pkt-line flush.
ACK %s
-----------------------------------
* no multi_ack or multi_ack_detailed:
Sent in response to "have" when the object exists on the remote
side and is therefore an object in common between the peers.
The argument is the SHA-1 of the common object.
* either multi_ack or multi_ack_detailed:
Sent in response to "done" if there are common objects.
The argument is the last SHA-1 determined to be common.
ACK %s continue
-----------------------------------
* multi_ack only:
Sent in response to "have".
The remote side wants the client to consider this object as
common, and immediately stop transmitting additional "have"
lines for objects that are reachable from it. The reason
the client should stop is not given, but is one of the two
cases below available under multi_ack_detailed.
ACK %s common
-----------------------------------
* multi_ack_detailed only:
Sent in response to "have". Both sides have this object.
Like with "ACK %s continue" above the client should stop
sending have lines reachable for objects from the argument.
ACK %s ready
-----------------------------------
* multi_ack_detailed only:
Sent in response to "have".
The client should stop transmitting objects which are reachable
from the argument, and send "done" soon to get the objects.
If the remote side has the specified object, it should
first send an "ACK %s common" message prior to sending
"ACK %s ready".
Clients may still submit additional "have" lines if there are
more side branches for the client to explore that might be added
to the common set and reduce the number of objects to transfer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-fetch-pack.c | 41 ++++++++++++++++++++++++++++++++---------
upload-pack.c | 31 ++++++++++++++++++-------------
2 files changed, 50 insertions(+), 22 deletions(-)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 7c09d46..615f549 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -157,7 +157,15 @@ static const unsigned char *get_rev(void)
return commit->object.sha1;
}
-static int get_ack(int fd, unsigned char *result_sha1)
+enum ack_type {
+ NAK = 0,
+ ACK,
+ ACK_continue,
+ ACK_common,
+ ACK_ready
+};
+
+static enum ack_type get_ack(int fd, unsigned char *result_sha1)
{
static char line[1000];
int len = packet_read_line(fd, line, sizeof(line));
@@ -167,12 +175,16 @@ static int get_ack(int fd, unsigned char *result_sha1)
if (line[len-1] == '\n')
line[--len] = 0;
if (!strcmp(line, "NAK"))
- return 0;
+ return NAK;
if (!prefixcmp(line, "ACK ")) {
if (!get_sha1_hex(line+4, result_sha1)) {
if (strstr(line+45, "continue"))
- return 2;
- return 1;
+ return ACK_continue;
+ if (strstr(line+45, "common"))
+ return ACK_common;
+ if (strstr(line+45, "ready"))
+ return ACK_ready;
+ return ACK;
}
}
die("git fetch_pack: expected ACK/NAK, got '%s'", line);
@@ -218,7 +230,8 @@ static int find_common(int fd[2], unsigned char *result_sha1,
remote_hex = sha1_to_hex(remote);
if (!fetching) {
struct strbuf c = STRBUF_INIT;
- if (multi_ack) strbuf_addstr(&c, " multi_ack");
+ if (multi_ack == 2) strbuf_addstr(&c, " multi_ack_detailed");
+ if (multi_ack == 1) strbuf_addstr(&c, " multi_ack");
if (use_sideband == 2) strbuf_addstr(&c, " side-band-64k");
if (use_sideband == 1) strbuf_addstr(&c, " side-band");
if (args.use_thin_pack) strbuf_addstr(&c, " thin-pack");
@@ -298,18 +311,23 @@ static int find_common(int fd[2], unsigned char *result_sha1,
if (args.verbose && ack)
fprintf(stderr, "got ack %d %s\n", ack,
sha1_to_hex(result_sha1));
- if (ack == 1) {
+ switch (ack) {
+ case ACK:
flushes = 0;
multi_ack = 0;
retval = 0;
goto done;
- } else if (ack == 2) {
+ case ACK_common:
+ case ACK_ready:
+ case ACK_continue: {
struct commit *commit =
lookup_commit(result_sha1);
mark_common(commit, 0, 1);
retval = 0;
in_vain = 0;
got_continue = 1;
+ break;
+ }
}
} while (ack);
flushes--;
@@ -336,7 +354,7 @@ done:
if (args.verbose)
fprintf(stderr, "got ack (%d) %s\n", ack,
sha1_to_hex(result_sha1));
- if (ack == 1)
+ if (ack == ACK)
return 0;
multi_ack = 1;
continue;
@@ -618,7 +636,12 @@ static struct ref *do_fetch_pack(int fd[2],
if (is_repository_shallow() && !server_supports("shallow"))
die("Server does not support shallow clients");
- if (server_supports("multi_ack")) {
+ if (server_supports("multi_ack_detailed")) {
+ if (args.verbose)
+ fprintf(stderr, "Server supports multi_ack_detailed\n");
+ multi_ack = 2;
+ }
+ else if (server_supports("multi_ack")) {
if (args.verbose)
fprintf(stderr, "Server supports multi_ack\n");
multi_ack = 1;
diff --git a/upload-pack.c b/upload-pack.c
index 38ddac2..f1dc3a3 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -498,7 +498,7 @@ static int get_common_commits(void)
{
static char line[1000];
unsigned char sha1[20];
- char hex[41], last_hex[41];
+ char last_hex[41];
save_commit_buffer = 0;
@@ -515,19 +515,22 @@ static int get_common_commits(void)
if (!prefixcmp(line, "have ")) {
switch (got_sha1(line+5, sha1)) {
case -1: /* they have what we do not */
- if (multi_ack && ok_to_give_up())
- packet_write(1, "ACK %s continue\n",
- sha1_to_hex(sha1));
+ if (multi_ack && ok_to_give_up()) {
+ const char *hex = sha1_to_hex(sha1);
+ if (multi_ack == 2)
+ packet_write(1, "ACK %s ready\n", hex);
+ else
+ packet_write(1, "ACK %s continue\n", hex);
+ }
break;
default:
- memcpy(hex, sha1_to_hex(sha1), 41);
- if (multi_ack) {
- const char *msg = "ACK %s continue\n";
- packet_write(1, msg, hex);
- memcpy(last_hex, hex, 41);
- }
+ memcpy(last_hex, sha1_to_hex(sha1), 41);
+ if (multi_ack == 2)
+ packet_write(1, "ACK %s common\n", last_hex);
+ else if (multi_ack)
+ packet_write(1, "ACK %s continue\n", last_hex);
else if (have_obj.nr == 1)
- packet_write(1, "ACK %s\n", hex);
+ packet_write(1, "ACK %s\n", last_hex);
break;
}
continue;
@@ -587,7 +590,9 @@ static void receive_needs(void)
get_sha1_hex(line+5, sha1_buf))
die("git upload-pack: protocol error, "
"expected to get sha, not '%s'", line);
- if (strstr(line+45, "multi_ack"))
+ if (strstr(line+45, "multi_ack_detailed"))
+ multi_ack = 2;
+ else if (strstr(line+45, "multi_ack"))
multi_ack = 1;
if (strstr(line+45, "thin-pack"))
use_thin_pack = 1;
@@ -681,7 +686,7 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
- " include-tag";
+ " include-tag multi_ack_detailed";
struct object *o = parse_object(sha1);
if (!o)
--
1.6.5.2.181.gd6f41
^ permalink raw reply related
* [RFC PATCH v4 14/26] Add stateless RPC options to upload-pack, receive-pack
From: Shawn O. Pearce @ 2009-10-29 0:00 UTC (permalink / raw)
To: git
In-Reply-To: <1256774448-7625-1-git-send-email-spearce@spearce.org>
When --stateless-rpc is passed as a command line parameter to
upload-pack or receive-pack the programs now assume they may
perform only a single read-write cycle with stdin and stdout.
This fits with the HTTP POST request processing model where a
program may read the request, write a response, and must exit.
When --advertise-refs is passed as a command line parameter only
the initial ref advertisement is output, and the program exits
immediately. This fits with the HTTP GET request model, where
no request content is received but a response must be produced.
HTTP headers and/or environment are not processed here, but
instead are assumed to be handled by the program invoking
either service backend.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-receive-pack.c | 26 ++++++++++++++++++++------
upload-pack.c | 40 ++++++++++++++++++++++++++++++++++++----
2 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index b771fe9..70ff8c5 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -615,6 +615,8 @@ static void add_alternate_refs(void)
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
+ int advertise_refs = 0;
+ int stateless_rpc = 0;
int i;
char *dir = NULL;
@@ -623,7 +625,15 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
const char *arg = *argv++;
if (*arg == '-') {
- /* Do flag handling here */
+ if (!strcmp(arg, "--advertise-refs")) {
+ advertise_refs = 1;
+ continue;
+ }
+ if (!strcmp(arg, "--stateless-rpc")) {
+ stateless_rpc = 1;
+ continue;
+ }
+
usage(receive_pack_usage);
}
if (dir)
@@ -652,12 +662,16 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
" report-status delete-refs ofs-delta " :
" report-status delete-refs ";
- add_alternate_refs();
- write_head_info();
- clear_extra_refs();
+ if (advertise_refs || !stateless_rpc) {
+ add_alternate_refs();
+ write_head_info();
+ clear_extra_refs();
- /* EOF */
- packet_flush(1);
+ /* EOF */
+ packet_flush(1);
+ }
+ if (advertise_refs)
+ return 0;
read_head_info();
if (commands) {
diff --git a/upload-pack.c b/upload-pack.c
index f1dc3a3..70badcf 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -39,6 +39,8 @@ static unsigned int timeout;
*/
static int use_sideband;
static int debug_fd;
+static int advertise_refs;
+static int stateless_rpc;
static void reset_timeout(void)
{
@@ -509,6 +511,8 @@ static int get_common_commits(void)
if (!len) {
if (have_obj.nr == 0 || multi_ack)
packet_write(1, "NAK\n");
+ if (stateless_rpc)
+ exit(0);
continue;
}
strip(line, len);
@@ -710,12 +714,32 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct object *o = parse_object(sha1);
+ if (!o)
+ die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+ if (!(o->flags & OUR_REF)) {
+ o->flags |= OUR_REF;
+ nr_our_refs++;
+ }
+ return 0;
+}
+
static void upload_pack(void)
{
- reset_timeout();
- head_ref(send_ref, NULL);
- for_each_ref(send_ref, NULL);
- packet_flush(1);
+ if (advertise_refs || !stateless_rpc) {
+ reset_timeout();
+ head_ref(send_ref, NULL);
+ for_each_ref(send_ref, NULL);
+ packet_flush(1);
+ } else {
+ head_ref(mark_our_ref, NULL);
+ for_each_ref(mark_our_ref, NULL);
+ }
+ if (advertise_refs)
+ return;
+
receive_needs();
if (want_obj.nr) {
get_common_commits();
@@ -737,6 +761,14 @@ int main(int argc, char **argv)
if (arg[0] != '-')
break;
+ if (!strcmp(arg, "--advertise-refs")) {
+ advertise_refs = 1;
+ continue;
+ }
+ if (!strcmp(arg, "--stateless-rpc")) {
+ stateless_rpc = 1;
+ continue;
+ }
if (!strcmp(arg, "--strict")) {
strict = 1;
continue;
--
1.6.5.2.181.gd6f41
^ permalink raw reply related
* [RFC PATCH v4 12/26] remote-helpers: return successfully if everything up-to-date
From: Shawn O. Pearce @ 2009-10-29 0:00 UTC (permalink / raw)
To: git; +Cc: Clemens Buchacher
In-Reply-To: <1256774448-7625-1-git-send-email-spearce@spearce.org>
From: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t5540-http-push.sh | 2 +-
transport-helper.c | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index 09edd23..2ece661 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -58,7 +58,7 @@ test_expect_success 'push to remote repository with packed refs' '
test $HEAD = $(git rev-parse --verify HEAD))
'
-test_expect_failure 'push already up-to-date' '
+test_expect_success 'push already up-to-date' '
git push
'
diff --git a/transport-helper.c b/transport-helper.c
index 16c6641..5078c71 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -263,6 +263,8 @@ static int push_refs(struct transport *transport,
strbuf_addstr(&buf, ref->name);
strbuf_addch(&buf, '\n');
}
+ if (buf.len == 0)
+ return 0;
transport->verbose = flags & TRANSPORT_PUSH_VERBOSE ? 1 : 0;
standard_options(transport);
--
1.6.5.2.181.gd6f41
^ permalink raw reply related
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