* Re: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'
From: Jeff King @ 2009-11-09 1:08 UTC (permalink / raw)
To: Jay Soffian; +Cc: Björn Gustavsson, git, Junio C Hamano
In-Reply-To: <76718490911081659u318ea362l29342a9b3d90f03f@mail.gmail.com>
On Sun, Nov 08, 2009 at 07:59:46PM -0500, Jay Soffian wrote:
> 2009/11/8 Björn Gustavsson <bgustavsson@gmail.com>:
> > Add the --multiple option to specify that all arguments are either
> > groups or remotes. The primary reason for adding this option is
> > to allow us to re-implement 'git remote update' using fetch.
>
> Can't this be determined automagically by inspecting the arguments? I
> believe there can be two unambiguous usages:
> [...]
> "The format of a <refspec> parameter is an optional plus +, followed
> by the source ref <src>, followed by a colon :, followed by the
> destination ref <dst>."
Isn't the colon optional, indicating that the ref should be fetched into
FETCH_HEAD? I.e.,
$ git fetch origin pu
From git://git2.kernel.org/pub/scm/git/git
* branch pu -> FETCH_HEAD
?
-Peff
^ permalink raw reply
* Re: gitk : french translation
From: Nicolas Sebrecht @ 2009-11-09 1:24 UTC (permalink / raw)
To: Maximilien Noal
Cc: Nicolas Sebrecht, Emmanuel Trillaud, Thomas Moulard,
Git Mailing List
In-Reply-To: <4AF7502A.9020903@gmail.com>
The 09/11/09, Maximilien Noal wrote:
> Why not put the translation first, then the english word between () ?
> At least for English words above that are not used by French devs "as
> is" (not like "diff") ?
Because it would decrease the readability. The () tip can't be used
everywhere seriously.
> That way, newbies to SCMs' concepts get the idea, and old SCM users
> don't have to translate back.
Newbies learning Git's concepts have more interest to learn the english
words too ; the GUIs should help them to do so. Matthieu Moy explained
why very well in this thread.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: gitk : french translation
From: Nicolas Pitre @ 2009-11-09 1:30 UTC (permalink / raw)
To: Matthieu Moy
Cc: Nicolas Sebrecht, Emmanuel Trillaud, Thomas Moulard,
Git Mailing List
In-Reply-To: <vpqtyx5nql0.fsf@bauges.imag.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1744 bytes --]
On Sun, 8 Nov 2009, Matthieu Moy wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> >> > - make some consistency changes
> >> > * s/diff/différences/
> >> > * s/patch/correctif/ everywhere
> >
> > I disagree here. Words like "diff", "commit", "patch", etc should be
> > kept as is. Translation of those terms make things harder for the users.
>
> Metoo.
>
> One day or another, the user will have to face the words "diff",
> "commit" and "patch" even in a 100% french-speaking context (for
> example when requesting help and someone answering "open a terminal
> and type 'git commit --whatever'" or so).
>
> Matching the command-line concepts and the GUI concepts is made really
> hard by over-translating.
Striking a good balance is the key. Not translating enough might simply
look "cheap" to a new user who was not exposed to the concepts in the
first place.
It is not like if we were facing issues like:
"Made in Turkey" -> "Fait en dinde"
"arm rest and pad assembly" -> "armer le repos et rembourer l'assemblée"
It's like those stu**d people who decided that "email" was too hard to
translate. So they declared that "email" was "imél" in French.
Fortunately some non European people came up with a refreshing idea and
translated "email" into "courriel" instead. And with a step back, you
must admit that "courriel" is so much clearer and more descriptive
semantically.
Therefore I think that it is a good thing to _try_ to translate stuff
appropriately. but this is often much harder than it may seem.
> (and BTW, "correctif" is not a very good translation of "patch", since
> a patch is not necessarilly a correction of something).
In this case I think "retouche" would be a better choice.
Nicolas
^ permalink raw reply
* Re: early days before git's invention
From: Zhi Li @ 2009-11-09 3:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ws21rvrd.fsf@localhost.localdomain>
Thank you all for the information!
Zhi
On Sun, Nov 8, 2009 at 9:29 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> Zhi Li <lizhi1215@gmail.com> writes:
>
> > I have a question maybe not suitable to be put on this list. I'm just
> > curious on git and Linux history. As what was said on wiki, Linux
> > kernel was maintained by BitKeeper, then for some reason, BitKeeper
> > can not be used, so git was invented. My question is what was used
> > before BitKeeper, CVS? I don't think so. Then, just using file to
> > manage?
>
> For why BitKeeper could not be used, see:
> http://en.wikipedia.org/wiki/Git_(software)#Early_history
> http://git.or.cz/gitwiki/GitHistory
> http://kerneltrap.org/node/4982
> http://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git?fp=16&fpid=0
>
> http://better-scm.berlios.de/bk/demise-of-gratis-bitkeeper.html
> http://better-scm.berlios.de/bk/what-bitmover-got-wrong.html
> http://better-scm.berlios.de/bk/the-bitkeeper-ghost.html
>
> Before BitKeeper Linux used tarballs (for releases) plus patches (for
> changes); patches were send by email (on LKML). Some maintainers used
> tools like Quilt (or custom scripts) for patch management.
>
>
> P.S. FreeBSD (IIRC) used / uses CVS for version control, but it has
> quite different development model than Linux.
>
> --
> Jakub Narebski
> Poland
>
^ permalink raw reply
* What's cooking in git.git (Nov 2009, #02; Sun, 08)
From: Junio C Hamano @ 2009-11-09 5:18 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
--------------------------------------------------
[New Topics]
* bw/autoconf-more (2009-11-04) 2 commits
- configure: add settings for gitconfig, editor and pager
- configure: add macro to set arbitrary make variables
* em/commit-claim (2009-11-04) 1 commit
- commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
I just picked better bits from both versions.
* jk/maint-format-patch-p-suppress-stat (2009-11-04) 1 commit.
(merged to 'next' on 2009-11-08 at 0943296)
+ format-patch: make "-p" suppress diffstat
(this branch is used by bg/format-patch-doc-update.)
* bg/format-patch-doc-update (2009-11-07) 3 commits.
- format-patch documentation: Fix formatting
- format-patch documentation: Remove diff options that are not useful
- format-patch: Always generate a patch
(this branch uses jk/maint-format-patch-p-suppress-stat.)
* rj/maint-simplify-cygwin-makefile (2009-10-27) 1 commit.
- Makefile: merge two Cygwin configuration sections into one
(this branch is used by rj/cygwin-msvc.)
This is one of the most obviously correct bit from "Compiling on Cygwin
using MSVC fails" topic.
* rj/cygwin-msvc (2009-11-07) 3 commits.
- Add explicit Cygwin check to guard WIN32 header inclusion
- MSVC: Add support for building with NO_MMAP
- Makefile: keep MSVC and Cygwin configuration separate
(this branch uses rj/maint-simplify-cygwin-makefile.)
* vl/maint-openssl-signature-change (2009-10-31) 1 commit.
(merged to 'next' on 2009-10-31 at 0e1ce6b)
+ imap-send.c: fix compiler warnings for OpenSSL 1.0
Prepare ourselves before newer versions of OpenSSL hits more platforms.
* bg/fetch-multi (2009-11-08) 4 commits.
- Re-implement 'git remote update' using 'git fetch'
- Add the configure variable skipFetchAll
- Teach the --multiple option to 'git fetch'
- Teach the --all option to 'git fetch'
* bs/maint-pre-commit-hook-sample (2009-11-05) 1 commit.
(merged to 'next' on 2009-11-06 at d70f646)
+ pre-commit.sample: Diff against the empty tree when HEAD is invalid
* cc/bisect-doc (2009-11-08) 1 commit
- Documentation: add "Fighting regressions with git bisect" article
* jn/add-h-to-all-commands (2009-11-08) 1 commit.
- Show usage string for 'git grep -h'
* pb/maint-gitweb-blob-lineno (2009-11-06) 1 commit.
(merged to 'next' on 2009-11-06 at 27b86ec)
+ gitweb: Fix blob linenr links in pathinfo mode
* sb/tutorial-test (2009-11-06) 4 commits
- t1200: prepare for merging with Fast-forward bikeshedding
- t1200: further modernize test script style
- t1200: Make documentation and test agree
- t1200: cleanup and modernize test style
* pb/gitweb-no-project-list (2009-11-06) 3 commits.
. gitweb: Polish the content tags support
. gitweb: Support for no project list on gitweb front page
. gitweb: Refactor project list routines
I picked these up but didn't queue as Warthog9's comments made certain
amount of sense to me.
--------------------------------------------------
[Stalled]
* tr/filter-branch (2009-10-28) 2 commits.
- filter-branch: nearest-ancestor rewriting outside subdir filter
- filter-branch: stop special-casing $filter_subdir argument
J6t had some comments on this.
* 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
Seems to be moving again soon.
* 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]
* bg/merge-ff-only (2009-10-29) 1 commit
(merged to 'next' on 2009-10-31 at b6b49aa)
+ Teach 'git merge' and 'git pull' the option --ff-only
* jk/maint-1.6.3-ls-files-i (2009-10-30) 1 commit.
(merged to 'next' on 2009-10-31 at 3a31fcc)
+ ls-files: unbreak "ls-files -i"
* jn/editor-pager (2009-10-30) 8 commits
- Provide a build time default-pager setting
- Provide a build time default-editor setting
- am -i, git-svn: use "git var GIT_PAGER"
- add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
- Teach git var about GIT_PAGER
- Teach git var about GIT_EDITOR
- Do not use VISUAL editor on dumb terminals
- Handle more shell metacharacters in editor names
* js/maint-diff-color-words (2009-10-30) 3 commits.
- diff --color-words: bit of clean-up
- diff --color-words -U0: fix the location of hunk headers
- t4034-diff-words: add a test for word diff without context
Fixes a corner case of running --color-words with -U0.
* sc/difftool-p4merge (2009-10-28) 1 commit
(merged to 'next' on 2009-10-31 at 194b5c5)
+ mergetool--lib: add p4merge as a pre-configured mergetool option
* sc/protocol-doc (2009-10-29) 1 commit
- Update packfile transfer protocol documentation
There is the final draft posted, but I haven't picked it up yet.
* sr/vcs-helper (2009-11-06) 12 commits
- Add Python support library for remote helpers
- Basic build infrastructure for Python scripts
- Allow helpers to request the path to the .git directory
- Allow helpers to report in "list" command that the ref is unchanged
- Allow helper to map private ref names into normal names
- Add support for "import" helper command
- Allow specifying the remote helper in the url
- Add a config option for remotes to specify a foreign vcs
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Allow programs to not depend on remotes having urls
- Fix memory leak in helper method for disconnect
Re-rolled series that contains Daniel's and Johan's.
* tr/describe-advice (2009-10-28) 1 commit
(merged to 'next' on 2009-10-31 at 8084850)
+ describe: when failing, tell the user about options that work
* mr/gitweb-snapshot (2009-11-07) 4 commits.
- gitweb: Smarter snapshot names
- gitweb: Document current snapshot rules via new tests
- t/gitweb-lib.sh: Split gitweb output into headers and body
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
Replaced commits near the tip with recent updates.
* jp/dirty-describe (2009-10-21) 1 commit.
(merged to 'next' on 2009-10-30 at 19c7fc7)
+ Teach "git describe" --dirty option
* jp/fetch-cull-many-refs (2009-10-25) 2 commits
(merged to 'next' on 2009-11-01 at 1f09ce9)
+ 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-11-04) 4 commits.
(merged to 'next' on 2009-11-08 at 6220d55)
+ Revert "format-patch -p is now a no-op" series
(merged to 'next' on 2009-10-30 at e34a3db)
+ format-patch documentation: Fix formatting
+ format-patch documentation: Remove diff options that are not useful
+ format-patch: Make implementation and documentation agree
This is now a no-op; jk/maint-format-patch-p-suppress-stat and
bg/format-patch-doc-update topics will replace this.
* jk/gitignore-anchored (2009-10-26) 1 commit
(merged to 'next' on 2009-10-30 at 9391a93)
+ gitignore: root most patterns at the top-level directory
* jk/maint-add-p-empty (2009-10-27) 1 commit.
(merged to 'next' on 2009-10-30 at 2bd302f)
+ add-interactive: handle deletion of empty files
* jk/maint-push-config (2009-10-25) 1 commit.
(merged to 'next' on 2009-10-30 at 934e3c5)
+ push: always load default config
* lt/revision-bisect (2009-10-27) 1 commit.
(merged to 'next' on 2009-10-30 at 81ee52b)
+ Add '--bisect' revision machinery argument
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
* rs/pretty-wrap (2009-11-08) 2 commits
(merged to 'next' on 2009-11-08 at 8973fd8)
+ log --format: don't ignore %w() at the start of format string
(merged to 'next' on 2009-10-30 at 403bbfe)
+ Implement wrap format %w() as if it is a mode switch
(this branch uses js/log-rewrap.)
* js/log-rewrap (2009-10-18) 3 commits
(merged to 'next' on 2009-10-30 at 403bbfe)
+ 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.)
* 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.
* fc/doc-fast-forward (2009-10-24) 1 commit.
(merged to 'next' on 2009-11-01 at faaad90)
+ Use 'fast-forward' all over the place
* 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-11-04) 30 commits
(merged to 'next' on 2009-11-06 at 666837c)
+ http-backend: Test configuration options
+ http-backend: Use http.getanyfile to disable dumb HTTP serving
+ test smart http fetch and push
+ http tests: use /dumb/ URL prefix
+ set httpd port before sourcing lib-httpd
+ t5540-http-push: remove redundant fetches
+ 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
+ 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 fetch and push over HTTP: server side
+ Add stateless RPC options to upload-pack, receive-pack
+ Git-aware CGI to provide dumb HTTP transport
+ remote-helpers: return successfully if everything up-to-date
+ 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
+ http-push: fix check condition on http.c::finish_http_pack_request()
v5 plus 3 more fix-up patches, started cooking in 'next'.
* ef/msys-imap (2009-10-22) 9 commits.
(merged to 'next' on 2009-10-31 at 8630603)
+ 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
* 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, but the "temporarily" turned out to be very loooong. Sigh...
* 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
(merged to 'next' on 2009-11-01 at 948327a)
+ 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
* 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.
* 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]
* 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. Does not seem to
pass the tests when merged to 'pu', so it has been ejected for now.
* 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
* 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.)
* jc/log-stdin (2009-11-03) 1 commit
. Teach --stdin option to "log" family
* 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.)
^ permalink raw reply
* pulling git -- version confusion
From: Rustom Mody @ 2009-11-09 6:14 UTC (permalink / raw)
To: git
I did a git pull today
When I compile it
git --version gives
git version 1.6.3.3.334.g916e1
Whereas latest stable shown on http://git-scm.com/
is 1.6.5.2.
Note:
git branch shows a star before master
git tag contains v1.6.5.2 as well as v1.6.3.3
When I checkout branch next
git version becomes 1.6.0.rc1.194.g9e4e
Can someone explain whats happening or am I missing something basic?
^ permalink raw reply
* Re: [PATCH 4/4] format-patch: Add "--no-stat" as a synonym for "-p"
From: Björn Gustavsson @ 2009-11-09 6:22 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <1257721866.1734.47.camel@swboyd-laptop>
2009/11/9 Stephen Boyd <bebarino@gmail.com>:
>> - OPT_BOOLEAN('p', NULL, &use_patch_format,
>> + OPT_BOOLEAN('p', "no-stat", &use_patch_format,
>
> I think this needs to have the OPT_NO_NEG flag so users can't say
> --no-no-stat.
Thanks! I didn't know about that.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'
From: Björn Gustavsson @ 2009-11-09 6:25 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git, Junio C Hamano
In-Reply-To: <20091109010824.GA17414@coredump.intra.peff.net>
2009/11/9 Jeff King <peff@peff.net>:
> Isn't the colon optional, indicating that the ref should be fetched into
> FETCH_HEAD?
Yes, that's why I was forced to invent a new option.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: pulling git -- version confusion
From: Sverre Rabbelier @ 2009-11-09 6:37 UTC (permalink / raw)
To: Rustom Mody; +Cc: git
In-Reply-To: <f46c52560911082214x81ae8beya139a8bcb3cbcf2a@mail.gmail.com>
Heya,
On Mon, Nov 9, 2009 at 07:14, Rustom Mody <rustompmody@gmail.com> wrote:
> When I checkout branch next
> git version becomes 1.6.0.rc1.194.g9e4e
Try either:
$ git checkout master
$ git reset --hard origin/master
or:
$ git checkout next
$ git reset --hard origin/next
Followed by:
$ make
$ ./git --version
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Re-implement 'git remote update' using 'git fetch'
From: Björn Gustavsson @ 2009-11-09 6:37 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490911081643w46e34858kd82270be0482f8b9@mail.gmail.com>
2009/11/9 Jay Soffian <jaysoffian@gmail.com>:
> 2009/11/8 Björn Gustavsson <bgustavsson@gmail.com>:
>> In order to not duplicate functionality, re-implement 'git remote
>> update' in terms of 'git fetch'.
>
> Junio, I guess I'll wait for this to hit pu and then rebase my fetch
> --prune changes on top of it?
It has hit pu now.
If you'll rebase and finish your patch series, I can base my final
patch in my series on your changes, because that patch will need a
fetch that supports --prune in order to support 'git remote update --prune'.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [PATCH v3 08/12] Allow helper to map private ref names into normal names
From: Sverre Rabbelier @ 2009-11-09 6:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911061519j6d64ff50v9b0cefe61965fbbc@mail.gmail.com>
Heya,
On Sat, Nov 7, 2009 at 00:19, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Sat, Nov 7, 2009 at 00:12, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> At the very least, it needs documentation and memory leaks fixed (the
>> refspec strings read from the helper, and the refspec structs and array on
>> freeing the helper data).
>
> Please send follow-ups against [0] and I will include them in the next round :).
It's in next now, so please send follow-ups against sr/vcs-helper.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 4/4] Add explicit Cygwin check to guard WIN32 header inclusion
From: Johannes Sixt @ 2009-11-09 7:20 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, Marius Storm-Olsen, GIT Mailing-list
In-Reply-To: <4AF5D6F8.40608@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> Since commit 435bdf8c ("Make usage of windows.h lean and mean",
> 16-9-2009), the amount of code potentially including the WIN32
> API header files has greatly increased. In particular, the Cygwin
> build is at greater risk of inadvertently including WIN32 code
> within preprocessor sections protected by the WIN32 or _WIN32
> macros.
Thanks, this makes the problem pretty clear that you want to solve.
> The previous commit message, along with comments elsewhere, assert
> that the WIN32 macro is not defined on Cygwin. Currently, this is
> true for the cygwin build. However, the cygwin platform can be
> used to develop WIN32 GUI, WIN32 console, and POSIX applications.
> Indeed it is possible to create applications which use a mix of
> the WIN32 API and POSIX code (eg git!).
In this paragraph, you are only saying that cygwin comes with headers and
libraries that can be used to write code using the Windows API in addition
to the POSIX headers and libraries. (I'm just asking, not complaining;
perhaps this could be stated differently.)
> Unlike native WIN32 compilers, gcc on cygwin does not automatically
> define the _WIN32 macro. However, as soon as you include the
> <windows.h> header file, the _WIN32 and WIN32 macros are defined.
>
> In order to reduce the risk of problems in the future, we protect
> the inclusion of the windows header with an explicit check for
> __CYGWIN__. Also, we move the other use of the <windows.h> header
> from compat/win32.h to compat/cygwin.c
But I sense a contradiction here. Above you are arguing that much more
WIN32 code is included, but here you are saying that the explicit check
for __CYGWIN__ is just a safety measure to protect us from failures in
future changes. Indeed, looking at the code it seems that this extra check
is *currently* not necessary:
- Cygwin does not define WIN32, hence, in the original code of this hunk,
> diff --git a/git-compat-util.h b/git-compat-util.h
> index ef60803..c4b9e5a 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -65,10 +65,10 @@
> #define _NETBSD_SOURCE 1
> #define _SGI_SOURCE 1
>
> -#ifdef WIN32 /* Both MinGW and MSVC */
> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> -#include <winsock2.h>
> -#include <windows.h>
> +#if defined(_WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */
> +# define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> +# include <winsock2.h>
> +# include <windows.h>
> #endif
>
> #include <unistd.h>
windows.h is not included in cygwin. (Nor is it in the changed version.)
- The other files that include windows.h are compat/win32.h and nedmalloc.
The latter isn't used on cygwin.
- win32.h is included only from cygwin.c, mingw.c, and msvc.c. Only the
first one is used by cygwin, and since it is a .c file, pulling in
windows.h can only concern code in cygwin.c, but not code.
IOW, I disagree with your analysis that a lot of code suffers from
windows.h pollution. What am I missing?
-- Hannes
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-09 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130911060951q3358ce9ahe28fb0cf902853f2@mail.gmail.com>
Avery Pennarun <apenwarr <at> gmail.com> writes:
> There are three methods I know of to manage this:
>
> 1) Just commit whatever version of a subproject you want as a subtree
> of your current project, and if you want to replace/delete/upgrade it,
> just do that. (You rarely want to track the actual *history* of the
> third party tool, just the history of versions *you* used, which is
> easy to do.)
Ok. Does that mean that new component2 and common component1 should leave on the
new branch (having in mind that old component2 and component1 are still living
on previous branch)? So, how many efforts will I need to get both component1
versions in sync (it is supposed that most of the changes in this component are
common for both)? Is is supposed that having 2 branches for this component is
cheaper (from development cycle POW)?
> 2) Use git-submodule to link repositories together. (Arguably, one
> major reason 'repo' was written is that git-submodule is too
> complicated, though.)
> 3) Try my git-subtree tool, which basically makes it easier to
> split/join repositories (similar to #1) without losing the history
> (similar to #2).
I'll try to learn it.
I suppose, both these tools (repo and git-subtree) are the indication of some
contradiction between the tool and SCM practice (especially, for big projects).
>
> Basically, performance is linear with the number of files in your
> repo. If you can check out just a "slice" of your repo (say 10% of
> the whole), you'll have faster performance (eg. 10x) from any VCS.
Yes, I just wish to see this feature in some VCS. Why not Git? ;-)
> So I can see an argument that Windows users would want arbitrary
> "slices" much more often than Linux+git users, but I think this is
> largely due to performance, not because people really *want* to be
> stuck with a restricted view of the repo.
How offten do you use this info? I mean the whole stuff?
^ permalink raw reply
* Re: pulling git -- version confusion
From: Sverre Rabbelier @ 2009-11-09 7:51 UTC (permalink / raw)
To: Rustom Mody; +Cc: git
In-Reply-To: <f46c52560911082345y71eb12c9w114b799d70720dc6@mail.gmail.com>
Heya,
On Mon, Nov 9, 2009 at 08:45, Rustom Mody <rustompmody@gmail.com> wrote:
> Gives me
> fatal: ambiguous argument 'origin/master': unknown revision or path
> not in the working tree.
> Use '--' to separate paths from revisions
Well, as what remote do you have upstream configured?
What is the output of
$ git config -l
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: pulling git -- version confusion
From: Rustom Mody @ 2009-11-09 7:45 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911082237x462b1203v724b51e309a2d89@mail.gmail.com>
On Mon, Nov 9, 2009 at 12:07 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Mon, Nov 9, 2009 at 07:14, Rustom Mody <rustompmody@gmail.com> wrote:
>> When I checkout branch next
>> git version becomes 1.6.0.rc1.194.g9e4e
>
> Try either:
> $ git checkout master
> $ git reset --hard origin/master
Gives me
fatal: ambiguous argument 'origin/master': unknown revision or path
not in the working tree.
Use '--' to separate paths from revisions
>
> or:
> $ git checkout next
> $ git reset --hard origin/next
Likewise here
>
> Followed by:
> $ make
> $ ./git --version
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-09 7:53 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.00.0911061051540.3216@asgard.lang.hm>
<david <at> lang.hm> writes:
> going back to the initial poster's comments. if the android repo is 1G,
> eliminating the history will probably have significantly less impact than
> you expect it to.
Do you have 2 or more copies of the same repository at the same time?
If yes, can I skip cloning new copy from network?
Or even skip cloning it at all?
Is it possible with Git to chekout into two (few) working trees?
^ permalink raw reply
* Re: Allowing push --dry-run through fetch url
From: Mike Hommey @ 2009-11-09 7:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx8obz2o.fsf@alter.siamese.dyndns.org>
On Sun, Nov 08, 2009 at 11:23:27AM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > Usually, when I run git push --dry-run, it's to check that what follows
> > (usually the refspec part) does what I want it to do, such as not pushing
> > tags I didn't intend to push(*), and stuff like that.
>
> Ahh, that one.
>
> That reminds me of a topic that we discussed but went away without
> reaching the conclusion on adding a "confirmation: are you sure this
> pushes what you want?" to the command. I had a doubt about the patch back
> then which was that it hardcoded a tty interaction and it would be hard to
> retrofit it to help GUI frontends (so my suggestion was to use something
> like hooks mechanism, perhaps --confirm=this-script and allow it to do its
> GUI thing), but thinking about it again, they can always use "expect" to
> drive the interaction with the confirmation prompt, so it may not a big
> deal after all---we might want to resurrect the topic.
How about an option to have the confirmation asked, quite like
cp/mv/rm's -i option ?
> That was an unrelated, independent thought on your comment, but if we did
> so, you might not even have to try to use --dry-run on git:// transport.
Sounds like a good trade-off.
Cheers
Mike
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #02; Sun, 08)
From: Tarmigan @ 2009-11-09 8:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <7vzl6wz36r.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]
On Sun, Nov 8, 2009 at 9:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * sp/smart-http (2009-11-04) 30 commits
> + test smart http fetch and push
I am trying to test smart http, and have had to set
DEFAULT_HTTPD_PATH='/usr/sbin/httpd'
DEFAULT_HTTPD_MODULE_PATH='/usr/lib64/httpd/modules' on Centos.
Perhaps this failing test is just a difference in the default Apache
and curl configurations.
Testing with 7f640b7 ("http-backend: Test configuration options")
gives me errors with the third test in t5551-http-fetch. I don't
really know the point of the sed lines, but I am attaching my "err"
file in case some of the problem is with the CR/LF stuff.
Thanks,
Tarmigan
* expecting success:
GIT_CURL_VERBOSE=1 git clone --quiet $HTTPD_URL/smart/repo.git clone 2>err &&
test_cmp file clone/file &&
tr '\015' Q <err |
sed -e "
s/Q\$//
/^[*] /d
/^[^><]/{
s/^/> /
}
/^> User-Agent: /d
/^> Host: /d
s/^> Content-Length: .*/> Content-Length: xxx/
/^< Server: /d
/^< Expires: /d
/^< Date: /d
/^< Content-Length: /d
/^< Transfer-Encoding: /d
" >act &&
test_cmp exp act
--- exp 2009-11-09 07:33:19.000000000 +0000
+++ act 2009-11-09 07:33:19.000000000 +0000
@@ -6,15 +6,16 @@
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Type: application/x-git-upload-pack-advertisement
-<
> POST /smart/repo.git/git-upload-pack HTTP/1.1
+> Accept: */*
> Accept-Encoding: deflate, gzip
> Content-Type: application/x-git-upload-pack-request
> Accept: application/x-git-upload-pack-response
> Content-Length: xxx
+> 0073want 1937bb05802e1973cc2e437c13e9f1845941b785
multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta
+> 00000009done
< HTTP/1.1 200 OK
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Type: application/x-git-upload-pack-result
-<
* FAIL 3: clone http repository
GIT_CURL_VERBOSE=1 git clone --quiet $HTTPD_URL/smart/repo.git clone 2>err &&
test_cmp file clone/file &&
tr '\015' Q <err |
sed -e "
s/Q\$//
/^[*] /d
/^[^><]/{
s/^/> /
}
/^> User-Agent: /d
/^> Host: /d
s/^> Content-Length: .*/> Content-Length: xxx/
/^< Server: /d
/^< Expires: /d
/^< Date: /d
/^< Content-Length: /d
/^< Transfer-Encoding: /d
" >act &&
test_cmp exp act
[-- Attachment #2: err --]
[-- Type: application/octet-stream, Size: 1601 bytes --]
* Couldn't find host 127.0.0.1 in the .netrc file, using defaults
* About to connect() to 127.0.0.1 port 5551
* Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 5551
> GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.6.5.45.g7f640
Host: 127.0.0.1:5551
Accept: */*
Pragma: no-cache
< HTTP/1.1 200 OK
< Date: Mon, 09 Nov 2009 07:29:09 GMT
< Server: Apache/2.2.3 (CentOS)
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Transfer-Encoding: chunked
< Content-Type: application/x-git-upload-pack-advertisement
* Connection #0 to host 127.0.0.1 left intact
* Couldn't find host 127.0.0.1 in the .netrc file, using defaults
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 5551
> POST /smart/repo.git/git-upload-pack HTTP/1.1
User-Agent: git/1.6.5.45.g7f640
Host: 127.0.0.1:5551
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-response
Content-Length: 128
0073want 016a872ce97795d991a9c5014a0bbc8aa4ecca39 multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta
00000009done
< HTTP/1.1 200 OK
< Date: Mon, 09 Nov 2009 07:29:09 GMT
< Server: Apache/2.2.3 (CentOS)
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Transfer-Encoding: chunked
< Content-Type: application/x-git-upload-pack-result
* Connection #0 to host 127.0.0.1 left intact
^ permalink raw reply
* [OT] Re: gitk : french translation
From: Matthieu Moy @ 2009-11-09 8:39 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Nicolas Sebrecht, Emmanuel Trillaud, Thomas Moulard,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0911082010590.16711@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> It's like those stu**d people who decided that "email" was too hard to
> translate. So they declared that "email" was "imél" in French.
This one is not _as_ stupid as it seems to be. It's not "imél", it's
"mél.", and it's a shortcut for "messagerie électronique", like "tél."
is a shortcut for "téléphone" (the kind of things to put on your visit
card or on the header of a letter).
http://www.culture.gouv.fr/culture/dglf/mel.htm
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Show usage string for 'git http-push -h'
From: Tay Ray Chuan @ 2009-11-09 8:52 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20091108072604.GA21367@progeny.tock>
Hi,
On Sun, Nov 8, 2009 at 3:26 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> @@ -1792,6 +1792,11 @@ int main(int argc, char **argv)
>
> git_extract_argv0_path(argv[0]);
>
> + if (argc == 2 && !strcmp(argv[1], "-h")) {
> + fprintf(stderr, "usage: %s\n", http_push_usage);
> + return 0;
> + }
> +
> setup_git_directory();
>
> repo = xcalloc(sizeof(*repo), 1);
just curious, I'm wondering why isn't the check for "-h" done in the
argv loop later on? I see this being done already in the builtins
diff, log, ls-remote and update-index.
Also, unlike grep, -h <arg> is not an option we're looking out for, so
I'm not sure if we should allow the user to mix -h with a valid set of
arguments (which is what Johnathan's patch would allow).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [OT] Re: gitk : french translation
From: Maximilien Noal @ 2009-11-09 9:24 UTC (permalink / raw)
To: Matthieu Moy
Cc: Nicolas Pitre, Nicolas Sebrecht, Emmanuel Trillaud,
Thomas Moulard, Git Mailing List
In-Reply-To: <vpqocncay8m.fsf_-_@bauges.imag.fr>
Matthieu Moy a écrit :
> Nicolas Pitre <nico@fluxnic.net> writes:
>
>> It's like those stu**d people who decided that "email" was too hard to
>> translate. So they declared that "email" was "imél" in French.
>
> This one is not _as_ stupid as it seems to be. It's not "imél", it's
> "mél.", and it's a shortcut for "messagerie électronique", like "tél."
> is a shortcut for "téléphone" (the kind of things to put on your visit
> card or on the header of a letter).
>
> http://www.culture.gouv.fr/culture/dglf/mel.htm
>
mél is ugly as hell to the ear.
Courriel sounds way better!
^ permalink raw reply
* [PATCH v2] Show usage string for 'git http-push -h'
From: Jonathan Nieder @ 2009-11-09 10:47 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <be6fef0d0911090052s158ac720ha1fac70da748106d@mail.gmail.com>
http-push already knows how to dump usage if it is given no
options, but it interprets '-h' as the URL to a remote
repository:
$ git http-push -h
error: Cannot access URL -h/, return code 6
Dump usage instead. Humans wanting to pass the URL -h/ to curl
for some reason can use 'git http-push -h/' explicitly. Scripts
expecting to access an HTTP repository at URL '-h' will break,
though.
Also delay finding a git directory until after option parsing, so
"http-push -h" can be used outside any git repository.
Cc: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Tay Ray Chuan wrote:
> just curious, I'm wondering why isn't the check for "-h" done in the
> argv loop later on? I see this being done already in the builtins
> diff, log, ls-remote and update-index.
Good question. :)
(I was making sure "git http-push -h" would work without a git
directory by putting the check for -h before setup_git_directory().
But nothing in the argv loop requires a git repository, so it is
better and simpler to move the setup_git_directory() call to after the
loop. Thanks for the catch.)
> Also, unlike grep, -h <arg> is not an option we're looking out for, so
> I'm not sure if we should allow the user to mix -h with a valid set of
> arguments (which is what Johnathan's patch would allow).
Makes sense.
http-push.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/http-push.c b/http-push.c
index 00e83dc..ad1a6c9 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1792,8 +1792,6 @@ int main(int argc, char **argv)
git_extract_argv0_path(argv[0]);
- setup_git_directory();
-
repo = xcalloc(sizeof(*repo), 1);
argv++;
@@ -1827,6 +1825,8 @@ int main(int argc, char **argv)
force_delete = 1;
continue;
}
+ if (!strcmp(arg, "-h"))
+ usage(http_push_usage);
}
if (!repo->url) {
char *path = strstr(arg, "//");
@@ -1854,6 +1854,8 @@ int main(int argc, char **argv)
if (delete_branch && nr_refspec != 1)
die("You must specify only one branch name when deleting a remote branch");
+ setup_git_directory();
+
memset(remote_dir_exists, -1, 256);
/*
--
1.6.5.2
^ permalink raw reply related
* Re: question: connecting to multiple remote svn projects
From: Dave Rodgman @ 2009-11-09 10:59 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130911061151q68ddcc58w209acf28c5eec2f@mail.gmail.com>
>> Given a layout in a single subversion repository like this:
>>
>> module1/branches/1.0/work
>> module2/branches/1.0/work
>>
>> I would like achieve the following layout locally, in git:
>>
>> module1/work
>> module2/work
>>
>> Obviously I can create multiple git repositories in separate
>> directories, but I would like them to be in a single repository. I can
>> also get the same layout as subversion, but this breaks various bits of
>> build infrastructure.
>
> Can you just create the file structure you want using symlinks? That
> would be the easiest way.
It would, and this is what I do on Linux. On Windows, obviously, this
doesn't work.
>> I don't care about tracking the subversion branches in git, or being
>> able to switch between subversion branches.
>
> Don't care about tracking *any* subversion history, or just the history
> of branches other than the 1.0 branch you've listed above? I assume the
> latter, because otherwise the problem is easy (just copy the latest
> revision of the files into a git repo and commit).
Indeed. I want history, but only for a given branch.
> Other options that might work for you: create a "superproject" branch
> and import the two modules using git-submodule, or else import them
> using git-subtree (http://github.com/apenwarr/git-subtree). Or import
> the svn history and then use git-filter-branch to move stuff around.
As far as I can understand, git-submodule pulls in a specific commit,
as does git subtree? I've experimented a little but with not much success.
I want "git svn rebase" (or some equivalent command, or series of
commands) to update the contents of module1/work to the latest commit
into this branch, and similarly "git svn dcommit" should also commit into
module1, module2, etc. Basically, I want my working copy to have the same
functionality as if moduleX/work was the actual layout in subversion. I'm
using git as a client for a svn repository, rather than doing a one-time
import. Is this possible?
thanks for your help
Dave
^ permalink raw reply
* Re: [BUG] unpack-objects abnormal exit when pushing
From: Matthieu Moy @ 2009-11-09 11:56 UTC (permalink / raw)
To: git
In-Reply-To: <vpqeio8eou4.fsf@bauges.imag.fr>
Hi again,
I just found a way to reproduce the problem using plain SSH, and not
Git:
$ ssh localhost cat < random.bin | wc
249 1460 65536
$ cat < random.bin | wc
796 4545 204800
So, sshd is broken on this machine, and I don't think Git is the one
to blame.
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Hi,
>
> I'm hitting a bug when git-push-ing to a Linux PPC machine. In
> general, pushing works well, but pushing some particular commits
> breaks reproducibly with :
>
> fatal: early EOF
> error: unpack failed: unpack-objects abnormal exit
> To ssh://localhost//home/perms/moy/prive/dest
> ! [remote rejected] master -> master (n/a (unpacker error))
>
> I've put the guilty files on my website and wrote a reproduction
> script:
>
> #!/bin/sh
>
> rm -fr source dest
> git init source
> git init --bare dest
> dest=$PWD/dest
> cd source
> echo foo > bar.txt
> git add .
> git commit -m init
> git push ssh://localhost/$dest master
> wget 'http://www-verimag.imag.fr/~moy/tmp/git-bug/Conception Manual.docx'
> wget 'http://www-verimag.imag.fr/~moy/tmp/git-bug/Extreme Programming.doc'
> git add .
> git commit -m "bug"
> git push ssh://localhost/$dest master
>
> The full output is attached (the error message for the last push is
> given above). The machine on which I get this (let's call it "A")
> says :
>
> $ ssh -Version
> OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
> $ uname -a
> Linux A 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:08:13 EDT 2009 ppc64 ppc64 ppc64 GNU/Linux
> $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5.4 (Tikanga)
> (it's a 32-bit distribution although the machine is 64bits)
> $ git --version
> git version 1.6.5.2
> (compiled myself, "make test" passes)
>
> According to my experiments, the problem is on the receiver side. If I
> do the same as above, with source/ and dest/ directories on two
> different machines, then if source/ in on A and dest/ anywhere else,
> it works, and if dest/ is on machine A, I get the same error.
>
> If I push using "file://" instead of "ssh://", then everything works
> well.
>
> If instead of push-ing, I go to dest/ and do a fetch, then it works
> well too.
>
> Does anyone have any idea on what's going on?
>
> If anyone has a machine similar to mine (ppc64), can he/she run my
> reproduction script and tell me if the bug happens?
>
> Thanks a lot,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH RFC] builtin-push: add --delete as syntactic sugar for :foo
From: Jan Krüger @ 2009-11-09 12:09 UTC (permalink / raw)
To: Git ML
Refspecs without a source side have been reported as confusing by many.
As an alternative, this adds support for commands like:
git push origin --delete somebranch
Specifically, --delete will prepend a colon to all colon-less refspecs
given on the command line.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
Since I consider this extension pure syntactic sugar, it doesn't change
the underlying transport code. As such it's a relatively non-invasive
change.
One might imagine a different implementation that supports combining
--delete with --all and/or --tags, but perhaps it's better if people
are forced to do that kind of thing manually.
builtin-push.c | 15 +++++++++++++++
t/t5516-fetch-push.sh | 6 ++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 8631c06..4ae9166 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -15,6 +15,7 @@ static const char * const push_usage[] = {
};
static int thin;
+static int deleterefs;
static const char *receivepack;
static const char **refspec;
@@ -44,6 +45,14 @@ static void set_refspecs(const char **refs, int nr)
strcat(tag, refs[i]);
ref = tag;
}
+ if (deleterefs && !strchr(ref, ':')) {
+ char *delref;
+ int len = strlen(refs[i] + 1);
+ delref = xmalloc(len);
+ strcpy(delref, ":");
+ strcat(delref, refs[i]);
+ ref = delref;
+ }
add_refspec(ref);
}
}
@@ -181,6 +190,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
+ OPT_BOOLEAN( 0, "delete", &deleterefs, "delete refs"),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all or --mirror)"),
OPT_BIT('n' , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT( 0, "porcelain", &flags, "machine-readable output", TRANSPORT_PUSH_PORCELAIN),
@@ -193,6 +203,11 @@ int cmd_push(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
+ if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR))))
+ die("--delete is incompatible with --all, --mirror and --tags");
+ if (deleterefs && argc < 2)
+ die("--delete doesn't make sense without any refs");
+
if (tags)
add_refspec("refs/tags/*");
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6889a53..aa1450a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -546,6 +546,12 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'allow deleting a ref using --delete' '
+ mk_test heads/master &&
+ git push testrepo --delete master &&
+ (cd testrepo && test_must_fail git rev-parse --verify refs/heads/master)
+'
+
test_expect_success 'warn on push to HEAD of non-bare repository' '
mk_test heads/master
(cd testrepo &&
--
1.6.5.2.155.gbb47.dirty
^ 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