* 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
* 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
* 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
* 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
* 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: 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: [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: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'
From: Jay Soffian @ 2009-11-09 0:59 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git, Junio C Hamano
In-Reply-To: <4AF6E7DE.1020201@gmail.com>
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:
a) git fetch <repository> <refspec>...
b) git fetch <repository>...
If there is more than one argument, either:
a) arguments 2...N must be refpecs (i.e., each must contain a colon)
b) arguments 2...N must NOT be refspecs
"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>."
j.
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Re-implement 'git remote update' using 'git fetch'
From: Jay Soffian @ 2009-11-09 0:43 UTC (permalink / raw)
To: Björn Gustavsson, Junio C Hamano; +Cc: git
In-Reply-To: <4AF6E865.1030900@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?
j.
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Kate Ebneter @ 2009-11-08 23:10 UTC (permalink / raw)
To: Jeff King, Björn Steinbrink; +Cc: git
In-Reply-To: <20091108230300.GB17129@coredump.intra.peff.net>
On 11/8/09 3:03 PM, "Jeff King" <peff@peff.net> wrote:
> On Sun, Nov 08, 2009 at 11:49:55PM +0100, Björn Steinbrink wrote:
>
>>> I ran into a weird situation while working on a script, which is best
>>> described with a little snippet from my gitosis-admin repository:
>>>
>>> $ git branch
>>> * master
>> ^^^
>>
>>> $ branch=$(git branch)
>>> $ echo $branch
>>> gitosis.conf keydir master
>>
>> Your shell expands the *, thus echo sees all the things in the current
>> directory. Use 'echo "$branch"' and you'll see what you expected.
>
> And more to the point, this is just one reason why one should use
> for-each-ref when scripting (the other is that git-branch's output is
> considered porcelain, and is not guaranteed to remain stable). E.g.:
>
> git for-each-ref --format='%(refname:short)' refs/heads/
>
> would produce the output the original poster wanted.
Ah, sweet, I did not know about that. I ended up doing something entirely
different (short form: my original idea about what I wanted to do was wrong)
but that's very helpful for the future.
Thanks,
Kate Ebneter (who is gradually learning more and more about git)
^ permalink raw reply
* Re: gitk : french translation
From: Maximilien Noal @ 2009-11-08 23:15 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Emmanuel Trillaud, Thomas Moulard, Git Mailing List
In-Reply-To: <4AF7502A.9020903@gmail.com>
Maximilien Noal a écrit :
> Nicolas Sebrecht wrote :
>>>> I disagree here. Words like "diff", "commit", "patch", etc should be
>>>> kept as is. Translation of those terms make things harder for the
>>>> users.
>>> I agree with you when those terms refers to _commands_ names, but the
>>> main goal of a
>>> translation is to _translate_ and we have to make the best effort to
>>> use french word if they _exist_
>>
>> I don't think so. Here is _why_: the user-frienliness of a translated
>> software comes from "how hard is it to connect a word with the
>> underlying concept".
>>
>> IOW, we want to have good words to refer to the _concepts_. In the
>> computer science world (and more _specially_ for a SCM), those concepts
>> are much more well-known with the english terms. Keeping english words
>> help users to directly understand what it is about, without making the
>> users have to search for "what the fucking translators are refering to
>> here?".
> 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") ?
>
> That way, newbies to SCMs' concepts get the idea, and old SCM users
> don't have to translate back.
>
> But if it isn't done _everywhere_ (and not used anywhere for words we
> don't want to translate because there's no need or no good translation,
> like "diff" for the first case, and "patch" for the second one), it will
> make the situation worse.
>
> Just my two cents.
I had in mind a man page when I wrote this, not gitk! Oh well.. Instead
of "French Translated Word (<English Word>)" idea, may be the tooltip
text (the text that pops up on a mouse over a control) can be used when
there is no pixel space left in the UI for the extra (<English Word>) text.
^ permalink raw reply
* Re: gitk : french translation
From: Maximilien Noal @ 2009-11-08 23:11 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Emmanuel Trillaud, Thomas Moulard, Git Mailing List
In-Reply-To: <20091108214130.GA12931@vidovic>
Nicolas Sebrecht wrote :
>>> I disagree here. Words like "diff", "commit", "patch", etc should be
>>> kept as is. Translation of those terms make things harder for the users.
>> I agree with you when those terms refers to _commands_ names, but the
>> main goal of a
>> translation is to _translate_ and we have to make the best effort to
>> use french word if they _exist_
>
> I don't think so. Here is _why_: the user-frienliness of a translated
> software comes from "how hard is it to connect a word with the
> underlying concept".
>
> IOW, we want to have good words to refer to the _concepts_. In the
> computer science world (and more _specially_ for a SCM), those concepts
> are much more well-known with the english terms. Keeping english words
> help users to directly understand what it is about, without making the
> users have to search for "what the fucking translators are refering to
> here?".
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") ?
That way, newbies to SCMs' concepts get the idea, and old SCM users
don't have to translate back.
But if it isn't done _everywhere_ (and not used anywhere for words we
don't want to translate because there's no need or no good translation,
like "diff" for the first case, and "patch" for the second one), it will
make the situation worse.
Just my two cents.
^ permalink raw reply
* Re: [PATCH 4/4] format-patch: Add "--no-stat" as a synonym for "-p"
From: Stephen Boyd @ 2009-11-08 23:11 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git, Junio C Hamano
In-Reply-To: <4AF544DF.6070404@gmail.com>
On Sat, 2009-11-07 at 10:58 +0100, Björn Gustavsson wrote:
> diff --git a/builtin-log.c b/builtin-log.c
> index 9df8dac..968a038 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -925,7 +925,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> "show patch format instead of default (patch + stat)"),
> OPT_BOOLEAN(0, "ignore-if-in-upstream", &ignore_if_in_upstream,
> "don't include a patch matching a commit upstream"),
> - OPT_BOOLEAN('p', NULL, &use_patch_format,
> + OPT_BOOLEAN('p', "no-stat", &use_patch_format,
> "show patch format instead of default (patch + stat)"),
> OPT_GROUP("Messaging"),
> { OPTION_CALLBACK, 0, "add-header", NULL, "header",
I think this needs to have the OPT_NO_NEG flag so users can't say
--no-no-stat.
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Jeff King @ 2009-11-08 23:03 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Kate Ebneter, git
In-Reply-To: <20091108224955.GA14095@atjola.homenet>
On Sun, Nov 08, 2009 at 11:49:55PM +0100, Björn Steinbrink wrote:
> > I ran into a weird situation while working on a script, which is best
> > described with a little snippet from my gitosis-admin repository:
> >
> > $ git branch
> > * master
> ^^^
>
> > $ branch=$(git branch)
> > $ echo $branch
> > gitosis.conf keydir master
>
> Your shell expands the *, thus echo sees all the things in the current
> directory. Use 'echo "$branch"' and you'll see what you expected.
And more to the point, this is just one reason why one should use
for-each-ref when scripting (the other is that git-branch's output is
considered porcelain, and is not guaranteed to remain stable). E.g.:
git for-each-ref --format='%(refname:short)' refs/heads/
would produce the output the original poster wanted.
-Peff
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Kate Ebneter @ 2009-11-08 22:50 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911081446o7793eef1kcbad964c9a73edda@mail.gmail.com>
On 11/8/09 2:46 PM, "Sverre Rabbelier" <srabbelier@gmail.com> wrote:
> Heya
>
> On Sun, Nov 8, 2009 at 23:11, Kate Ebneter <kate@ning.com> wrote:
>> That is, if you run 'git branch' inside $() or ``, it lists the directories,
>> too. I can't imagine that this is intended behavior, but perhaps I'm wrong.
>
> Try enclosing it in quotes ;).
>
> That is, compare:
> $ echo "`git branch`"
> with
> $ echo `git branch`
>
> The kicker is that there's a * in the output of git branch, which your
> shell helpfully substitutes with the contents of your current
> directory :).
*head desk*
You know, I spent hours last night trying to figure that out. So simple.
Duh.
Thanks for pointing that out -- I knew it had to be something simple, but
sometimes you just can't see the forest for the trees! :-)
Thanks again,
Kate Ebneter
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Björn Steinbrink @ 2009-11-08 22:49 UTC (permalink / raw)
To: Kate Ebneter; +Cc: git
In-Reply-To: <C71C822C.22429%kate@ning.com>
On 2009.11.08 14:11:56 -0800, Kate Ebneter wrote:
> Hi, folks,
>
> I ran into a weird situation while working on a script, which is best
> described with a little snippet from my gitosis-admin repository:
>
> $ git branch
> * master
^^^
> $ branch=$(git branch)
> $ echo $branch
> gitosis.conf keydir master
Your shell expands the *, thus echo sees all the things in the current
directory. Use 'echo "$branch"' and you'll see what you expected.
Björn
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Sverre Rabbelier @ 2009-11-08 22:46 UTC (permalink / raw)
To: Kate Ebneter; +Cc: git
In-Reply-To: <C71C822C.22429%kate@ning.com>
Heya
On Sun, Nov 8, 2009 at 23:11, Kate Ebneter <kate@ning.com> wrote:
> That is, if you run 'git branch' inside $() or ``, it lists the directories,
> too. I can't imagine that this is intended behavior, but perhaps I'm wrong.
Try enclosing it in quotes ;).
That is, compare:
$ echo "`git branch`"
with
$ echo `git branch`
The kicker is that there's a * in the output of git branch, which your
shell helpfully substitutes with the contents of your current
directory :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Kate Ebneter @ 2009-11-08 22:11 UTC (permalink / raw)
To: git
Hi, folks,
I ran into a weird situation while working on a script, which is best
described with a little snippet from my gitosis-admin repository:
$ git branch
* master
$ branch=$(git branch)
$ echo $branch
gitosis.conf keydir master
That is, if you run 'git branch' inside $() or ``, it lists the directories,
too. I can't imagine that this is intended behavior, but perhaps I'm wrong.
I can reproduce this on CentOS, Ubuntu, Solaris, and Mac OS X using git
1.6.2.3, 1.6.3.2, 1.6.3.3, 1.6.4.2, and 1.6.5.2.
(In the end, I figured out a better way to write my script anyway, but this
is just too weird not to ask about.)
Thanks,
Kate Ebneter
Somewhat befuddled build engineer
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Re-implement 'git remote update' using 'git fetch'
From: Björn Gustavsson @ 2009-11-08 22:23 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git, Junio C Hamano
In-Reply-To: <hd7c4k$aul$3@ger.gmane.org>
On Sun, Nov 8, 2009 at 10:10 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 11/08/2009 04:48 PM, Björn Gustavsson wrote:
>> There is one incompatibility: the skipDefaultUpdate configuration
>> variable will only be honored if remotes.default is not set (i.e.
>> when 'git remote update' will invoke 'git fetch --all', not when
>> it will invoke 'git fetch default').
>
> Rather than introducing this incompatibility, I'd rather see 'git remote
> update' deprecated (so that the code will one day go away for good) and, for
> now, leave duplicated functionality for the incompatible case.
I didn't check my facts properly before writing that commit message.
Looking again at the old code in builtin_remote.c (after a long break), and
actually testing the behavior, I see that there is no incompatibility.
Both the old and the new code use skipDefaultUpdate only if remotes.default
is not set. If remotes.default is set, that list of remotes will be used. Only
if remotes.default is not set, will 'git remote update' go through the list
of all remotes and filter away those that have skipDefaultUpdate set to true.
Sorry for the confusion. I will correct the commit message in my re-roll
of the patch.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* [PATCH] Add intermediate build products to .gitignore
From: Jonathan Nieder @ 2009-11-08 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Chris Johnsen
In-Reply-To: <7vvdhkdect.fsf@alter.siamese.dyndns.org>
Temporaries such as configure.ac+ and Documentation/*.xml+
sometimes remain after an interrupted build. Tell git not to
track them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Some of these files appeared in the "git status" output after an
>> interrupted build. I hope I caught them all.
>
> Thanks; I think "*+" would suffice, though.
That’s much better. Here’s an updated patch.
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 51a37b1..f0d2e96 100644
--- a/.gitignore
+++ b/.gitignore
@@ -168,6 +168,7 @@ git.spec
*.exe
*.[aos]
*.py[co]
+*+
config.mak
autom4te.cache
config.cache
--
1.6.5.2
^ permalink raw reply related
* Re: gitk : french translation
From: Nicolas Sebrecht @ 2009-11-08 21:41 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: Nicolas Sebrecht, Thomas Moulard, Git Mailing List
In-Reply-To: <9f50533b0911080955l606ea87aw4edd7b0bc926a25f@mail.gmail.com>
The 08/11/09, Emmanuel Trillaud wrote:
> 2009/11/7 Nicolas Sebrecht <nicolas.s.dev@gmx.fr>:
> > [
> > Please, conform to Documentation/SubmittingPatches of the git.git
> > project and send your patches inline to make the work for reviewers
> > easier.
> >
> > Both of your patches lack the Signed-off-by but maybe you don't want
> > them to be merged?
> > ]
> I am aware of this recommendation but this translation is almost 22kb and
> I tought that put it inline wouldn't make the review easier. I will
> submit a patch
> gathering my workand those of the reviewers soon.
Thanks, it will really help. If the patch is very long, you could split
it into more patches for the review purpose, maybe relying on the
semantic fields. Regardless you split it or not, inline patches are the
good way to contribute here.
Side note : you _must_ have the signed-off-by from Thomas if you want to
use his work.
Oh, and please, submit the new version in this thread.
> > I disagree here. Words like "diff", "commit", "patch", etc should be
> > kept as is. Translation of those terms make things harder for the users.
>
> I agree with you when those terms refers to _commands_ names, but the
> main goal of a
> translation is to _translate_ and we have to make the best effort to
> use french word if they _exist_
I don't think so. Here is _why_: the user-frienliness of a translated
software comes from "how hard is it to connect a word with the
underlying concept".
IOW, we want to have good words to refer to the _concepts_. In the
computer science world (and more _specially_ for a SCM), those concepts
are much more well-known with the english terms. Keeping english words
help users to directly understand what it is about, without making the
users have to search for "what the fucking translators are refering to
here?".
> and _are_ appropriate (that's why I'm not sure about translate
> "cherry-pick" by "ceullir").
I don't have strong opinion for this one because :
- the translation is good enough to be directly understood ;
- where "cueillir" (or so) is used, we have the fallback to the english
term between round brackets.
> I prefer to translate "Diff this -> selected" by "Différence entre ça
> et selection"
> because it is what the user do when he make a diff.
Looks ok to me, except that "Diff" is better than "Différence" for the
reason I give above. A "diff" is clearly about a _patch_ where
"différence" may be used to much more concepts. French people don't use
the word "différence" to talk about a diff, they use "diff" as is.
> because it is what the user do when he make a diff. I am also ok to
> translate "merge" by "fusion"
> because it's what "merge" is in french and I don't this we mislead the
> user by using the term
> "fusion".
I don't have a strong opinion on this because both english and french
words are known. That said, I tend to think that the english word is
better here too.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [BUG] unpack-objects abnormal exit when pushing
From: Matthieu Moy @ 2009-11-08 21:28 UTC (permalink / raw)
To: git
In-Reply-To: <vpqeio8eou4.fsf@bauges.imag.fr>
Hi,
Sorry, I forgot to set the subject before sending. The bug report
still holds:
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
* Re: [gitweb feature request] Release snapshots with vX.X.X tags
From: J.H. @ 2009-11-08 21:27 UTC (permalink / raw)
To: Bram Neijt; +Cc: Git mailing list
In-Reply-To: <1257714522.14087.133.camel@owl>
Bram,
This is true, but gitweb, in it's current incarnation, is *SLOW* using
it as a primary distribution means is ludicrous. Regenerating a tarball
on each request will destroy a server, plain and simple. Git/Gitweb
should *NOT* be used in place of doing properly release engineering.
If Debian requires their tarballs to be done up in a certain way, this
is either the problem of the packager, or if you want to be kind create
a makefile target that will generate this and release both when you do a
release:
I.E.
# make release
Generating Normal Tarball: <project>-<version>.tar.gz
Generating Debian Tarball: <project>-<version>.deb.tar.gz
# ls
Makefile <project>-<version>.tar.gz <project>-<version>.deb.tar.gz src/
#
Then take your releases and put them on your release server.
- John 'Warthog9' Hawley
Bram Neijt wrote:
> I was going to comment inline but I think the general question can be
> read as "why would you want this?". For me it's just an extra bit of
> automation. It would keep me from having to make release tarballs. I
> would just refer all the users to a gitweb snapshot link of the "v..."
> tag. Having a release tarball with "projectname-version" with a single
> directory called "projectname-version/" in it is just good practice if
> you ask me.
>
> Therefore it would benefit any developer like me :D : a spare time
> hobbyist who likes to automate as much of the administrative tasks, that
> go into running an open source project, as possible.
>
> Greets,
> Bram
>
> PS I've found that cgit: http://hjemli.net/git/cgit/
> has this feature, so I'm probably going to give that a try and get back
> to you if I find any problems with it (the feature that is).
>
> On Sun, 2009-11-08 at 10:53 -0800, Junio C Hamano wrote:
>> Bram Neijt <bneijt@gmail.com> writes:
>>
>>> I would like to create release snapshots with a git tag like "v0.0.1".
>>> For proper Debian packaging, a release snapshot of tag "v0.0.1" would
>>> have to be named "project-0.0.1.tar.gz" and contain a single directory
>>> with "project-0.0.1/" in the archive.
>> What the intended audience of this feature? IOW,
>>
>> - who are going to "click" such a link on gitweb to obtain
>> project-0.0.1.tar.gz with project-0.0.1/?
>>
>> - how are they going to use that tarball?
>>
>> I somehow suspect that they won't be the official Debian distro packagers.
>>
>> Most likely they actually have a clone of the upstream project (how else
>> they can stay up to date? In addition they would want to track their own
>> changes), so it would be more efficient for them to generate such a
>> tarball from a tag, and more importantly, doing it locally means that they
>> can they can verify the tag (and the whole history leading to it) before
>> doing so, instead of relying on somebody else's gitweb.
>>
>> You could be a mere Debian user who produces a *.deb for his own use out
>> of such tarball, and in such a case you are a lot less likely be tracking
>> the project (meaning, reading the history and keeping track of fixed bugs,
>> new regressions and such) than just getting a snapshot that happens to be
>> there and building it blindly, and I can understand it would be nicer if
>> you did not have to unpack, rename and regenerate an archive.
>>
>> Also, whose gitweb installations are you envisioning to enable this new
>> feature? Are you going to convince all the gitweb administrators of
>> projects packaged by Debian (and derivatives) that have gitweb, and what
>> are the incentive for these upstream projects to do so? I would guess
>> that most of the upstream projects do not consider Debian as their sole
>> target distribution, and it would be a tough sell if changing the snapshot
>> name to suit Debian breaks some other distro's (or human users) needs.
>>
>> Jakub is polishing Mark's patch to change the snapshot name and contents
>> hierarchy, but I think it won't satisfy Debian's naming guideline (it will
>> have v0.0.1, not 0.0.1 in the name). Changing the series's default to
>> drop 'v' from the beginning of the tagname when the rest of it consists of
>> all digits and dots would not be a correct solution, as Debian is not the
>> only system in the world and other people may want different naming rules.
>>
>> In order to make his series useful for your objective, it probably would
>> require a bit more customizability, but because I cannot tell whom such a
>> feature is really trying to help, and what the deployment plans are, I
>> cannot judge if extra complexity to add such a customizability is worth
>> it. Also because there will be conflicts in the desired archive format
>> ("Distro X people want this kind of archive, distro Y people want this
>> different kind"), the choice somehow how to come from whoever is clicking
>> the link, not from the gitweb administrator, and it probably would mean
>> the codepath involved would need a lot more careful audit than just a
>> server only "this gitweb installation would use this format"
>> configuration.
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Re-implement 'git remote update' using 'git fetch'
From: Paolo Bonzini @ 2009-11-08 21:10 UTC (permalink / raw)
To: git
In-Reply-To: <4AF6E865.1030900@gmail.com>
On 11/08/2009 04:48 PM, Björn Gustavsson wrote:
> In order to not duplicate functionality, re-implement 'git remote
> update' in terms of 'git fetch'.
>
> There is one incompatibility: the skipDefaultUpdate configuration
> variable will only be honored if remotes.default is not set (i.e.
> when 'git remote update' will invoke 'git fetch --all', not when
> it will invoke 'git fetch default').
Rather than introducing this incompatibility, I'd rather see 'git remote
update' deprecated (so that the code will one day go away for good) and,
for now, leave duplicated functionality for the incompatible case.
It would be great if the deprecation message for "git remote update"
spewed out commands to convert the old configuration to what is needed
for "git fetch --all" to work in the same way.
Paolo
^ permalink raw reply
* Re: [gitweb feature request] Release snapshots with vX.X.X tags
From: Bram Neijt @ 2009-11-08 21:08 UTC (permalink / raw)
To: Git mailing list
In-Reply-To: <7vbpjcetlp.fsf@alter.siamese.dyndns.org>
I was going to comment inline but I think the general question can be
read as "why would you want this?". For me it's just an extra bit of
automation. It would keep me from having to make release tarballs. I
would just refer all the users to a gitweb snapshot link of the "v..."
tag. Having a release tarball with "projectname-version" with a single
directory called "projectname-version/" in it is just good practice if
you ask me.
Therefore it would benefit any developer like me :D : a spare time
hobbyist who likes to automate as much of the administrative tasks, that
go into running an open source project, as possible.
Greets,
Bram
PS I've found that cgit: http://hjemli.net/git/cgit/
has this feature, so I'm probably going to give that a try and get back
to you if I find any problems with it (the feature that is).
On Sun, 2009-11-08 at 10:53 -0800, Junio C Hamano wrote:
> Bram Neijt <bneijt@gmail.com> writes:
>
> > I would like to create release snapshots with a git tag like "v0.0.1".
> > For proper Debian packaging, a release snapshot of tag "v0.0.1" would
> > have to be named "project-0.0.1.tar.gz" and contain a single directory
> > with "project-0.0.1/" in the archive.
>
> What the intended audience of this feature? IOW,
>
> - who are going to "click" such a link on gitweb to obtain
> project-0.0.1.tar.gz with project-0.0.1/?
>
> - how are they going to use that tarball?
>
> I somehow suspect that they won't be the official Debian distro packagers.
>
> Most likely they actually have a clone of the upstream project (how else
> they can stay up to date? In addition they would want to track their own
> changes), so it would be more efficient for them to generate such a
> tarball from a tag, and more importantly, doing it locally means that they
> can they can verify the tag (and the whole history leading to it) before
> doing so, instead of relying on somebody else's gitweb.
>
> You could be a mere Debian user who produces a *.deb for his own use out
> of such tarball, and in such a case you are a lot less likely be tracking
> the project (meaning, reading the history and keeping track of fixed bugs,
> new regressions and such) than just getting a snapshot that happens to be
> there and building it blindly, and I can understand it would be nicer if
> you did not have to unpack, rename and regenerate an archive.
>
> Also, whose gitweb installations are you envisioning to enable this new
> feature? Are you going to convince all the gitweb administrators of
> projects packaged by Debian (and derivatives) that have gitweb, and what
> are the incentive for these upstream projects to do so? I would guess
> that most of the upstream projects do not consider Debian as their sole
> target distribution, and it would be a tough sell if changing the snapshot
> name to suit Debian breaks some other distro's (or human users) needs.
>
> Jakub is polishing Mark's patch to change the snapshot name and contents
> hierarchy, but I think it won't satisfy Debian's naming guideline (it will
> have v0.0.1, not 0.0.1 in the name). Changing the series's default to
> drop 'v' from the beginning of the tagname when the rest of it consists of
> all digits and dots would not be a correct solution, as Debian is not the
> only system in the world and other people may want different naming rules.
>
> In order to make his series useful for your objective, it probably would
> require a bit more customizability, but because I cannot tell whom such a
> feature is really trying to help, and what the deployment plans are, I
> cannot judge if extra complexity to add such a customizability is worth
> it. Also because there will be conflicts in the desired archive format
> ("Distro X people want this kind of archive, distro Y people want this
> different kind"), the choice somehow how to come from whoever is clicking
> the link, not from the gitweb administrator, and it probably would mean
> the codepath involved would need a lot more careful audit than just a
> server only "this gitweb installation would use this format"
> configuration.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox