* [ANNOUNCE] Git 1.6.6.rc2
From: Junio C Hamano @ 2009-12-10 1:44 UTC (permalink / raw)
To: git
A release candidate Git 1.6.6.rc2 is available at the usual places
for testing:
http://www.kernel.org/pub/software/scm/git/
git-1.6.6.rc2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.6.rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.6.rc2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.6.6.rc2-1.fc11.$arch.rpm (RPM)
The changes since rc1 are mostly updates to the subsystems.
The regression to "git pull" that made the command give annoying warning
message when there is no local commit has been fixed; it appeared in rc1.
----------------------------------------------------------------
Changes since v1.6.6-rc1 are as follows:
Alex Vandiver (3):
git-svn: sort svk merge tickets to account for minimal parents
git-svn: Set svn.authorsfile to an absolute path when cloning
git-svn: set svn.authorsfile earlier when cloning
Alexander Gavrilov (1):
git-gui: Increase blame viewer usability on MacOS.
Bernt Hansen (1):
gitk: Skip translation of "wrong Tcl version" message
Brandon Casey (2):
t4201: use ISO8859-1 rather than ISO-8859-1
t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
Clemens Buchacher (1):
git-gui: search 4 directories to improve statistic of gc hint
Eric Wong (1):
git svn: log removals of empty directories
Greg Price (1):
git svn: Don't create empty directories whose parents were deleted
Guillermo S. Romero (1):
gitk: Add configuration for UI colour scheme
Heiko Voigt (1):
git gui: make current branch default in "remote delete branch" merge check
Jakub Narebski (1):
gitweb: Describe (possible) gitweb.js minification in gitweb/README
Jan Krüger (1):
pull: clarify advice for the unconfigured error case
Jeff King (3):
rerere: don't segfault on failure to open rr-cache
reset: improve worktree safety valves
add-interactive: fix deletion of non-empty files
Jens Lehmann (2):
gitk: Fix diffing committed -> staged (typo in diffcmd)
gitk: Use the --submodule option for displaying diffs when available
Jindrich Makovicka (1):
git-gui: suppress RenderBadPicture X error caused by Tk bug
Johan Herland (1):
Fix crasher on encountering SHA1-like non-note in notes tree
Junio C Hamano (9):
Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make
Unconditionally set man.base.url.for.relative.links
Git 1.6.5.4
Documentation: xmlto 0.0.18 does not know --stringparam
Prepare for 1.6.5.5
Git 1.6.5.5
Revert recent "git merge <msg> HEAD <commit>..." deprecation
Update draft release notes to 1.6.6 before -rc2
Git 1.6.6-rc2
Linus Torvalds (1):
Fix diff -B/--dirstat miscounting of newly added contents
Markus Heidelberg (1):
gitk: Fix "git gui blame" invocation when called from top-level directory
Mizar (2):
gitk: Add Japanese translation
gitk: Update Japanese translation
Pat Thoyts (4):
gitk: Use themed tk widgets
gitk: Fix errors in the theme patch
gitk: Default to the system colours on Windows
gitk: Fix selection of tags
Paul Mackerras (5):
gitk: Restore scrolling position of diff pane on back/forward in history
gitk: Add a user preference to enable/disable use of themed widgets
gitk: Show diff of commits at end of compare-commits output
gitk: Don't compare fake children when comparing commits
gitk: Improve appearance of radiobuttons and checkbuttons
René Scharfe (1):
archive: clarify description of path parameter
SZEDER Gábor (1):
bash: update 'git commit' completion
Sitaram Chamarty (1):
gitk: Disable checkout of remote branches
Todd Zullinger (1):
Documentation: Avoid use of xmlto --stringparam
^ permalink raw reply
* subtree merge tries to merge into wrong directory
From: Nils Adermann @ 2009-12-10 3:41 UTC (permalink / raw)
To: git
Following
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
I have subtree merged a 3rd party library (ezc-reflection) into my
repository (pflow). The prefix I used was lib/ezc/trunk/Reflection. Now
there have been changes to ezc-reflection but merging them into my
repository fails. The merge is attempted in example/ rather than
lib/ezc/trunk/Reflection.
I originally set this up with:
git remote add -f ezc-reflection /path/to/ezc-reflection
git merge -s ours --no-commit ezc-reflection/master
git read-tree --prefix=lib/ezc/trunk/Reflection -u ezc-reflection/master
Reproduce my problem by executing the following:
git clone git://github.com/naderman/pflow.git
cd pflow
git reset --hard f3e001e3
git fetch git://github.com/naderman/ezc-reflection.git master
git merge -s subtree FETCH_HEAD
As you see this results in:
CONFLICT (delete/modify): example/src/doc_comment_parser.php deleted in
HEAD and modified in FETCH_HEAD. Version FETCH_HEAD of
example/src/doc_comment_parser.php left in tree.
Automatic merge failed; fix conflicts and then commit the result.
As long as I don't make any changes to lib/ezc/trunk/Reflection that I
want to merge I can work around this by simply repeating my original
process like this:
git clone git://github.com/naderman/pflow.git
cd pflow
git reset --hard f3e001e3
git fetch git://github.com/naderman/ezc-reflection.git master
git merge -s ours --no-commit FETCH_HEAD
git rm -r lib/ezc/trunk/Reflection/
git read-tree --prefix=lib/ezc/trunk/Reflection/ -u FETCH_HEAD
Why does this problem occur and how can I get the merge to work properly?
Cheers,
Nils Adermann
^ permalink raw reply
* Re: subtree merge tries to merge into wrong directory
From: David Aguilar @ 2009-12-10 4:20 UTC (permalink / raw)
To: Nils Adermann; +Cc: git
In-Reply-To: <4B206DCF.90202@naderman.de>
On Thu, Dec 10, 2009 at 04:41:03AM +0100, Nils Adermann wrote:
> Following
> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
> I have subtree merged a 3rd party library (ezc-reflection) into my
> repository (pflow). The prefix I used was lib/ezc/trunk/Reflection. Now
> there have been changes to ezc-reflection but merging them into my
> repository fails. The merge is attempted in example/ rather than
> lib/ezc/trunk/Reflection.
>
> I originally set this up with:
>
> git remote add -f ezc-reflection /path/to/ezc-reflection
> git merge -s ours --no-commit ezc-reflection/master
> git read-tree --prefix=lib/ezc/trunk/Reflection -u ezc-reflection/master
>
> Reproduce my problem by executing the following:
>
> git clone git://github.com/naderman/pflow.git
> cd pflow
> git reset --hard f3e001e3
> git fetch git://github.com/naderman/ezc-reflection.git master
> git merge -s subtree FETCH_HEAD
>
> As you see this results in:
>
> CONFLICT (delete/modify): example/src/doc_comment_parser.php deleted in
> HEAD and modified in FETCH_HEAD. Version FETCH_HEAD of
> example/src/doc_comment_parser.php left in tree.
> Automatic merge failed; fix conflicts and then commit the result.
>
> As long as I don't make any changes to lib/ezc/trunk/Reflection that I
> want to merge I can work around this by simply repeating my original
> process like this:
>
> git clone git://github.com/naderman/pflow.git
> cd pflow
> git reset --hard f3e001e3
> git fetch git://github.com/naderman/ezc-reflection.git master
> git merge -s ours --no-commit FETCH_HEAD
> git rm -r lib/ezc/trunk/Reflection/
> git read-tree --prefix=lib/ezc/trunk/Reflection/ -u FETCH_HEAD
>
> Why does this problem occur and how can I get the merge to work properly?
I'm not sure, but maybe you can try git-subtree?
It makes this stuff easier for mere mortals.
http://github.com/apenwarr/git-subtree/
You might need to start redo your repo, but several people have
had good success with git-subtree.
--
David
^ permalink raw reply
* Re: subtree merge tries to merge into wrong directory
From: Nils Adermann @ 2009-12-10 4:26 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <20091210042008.GA3398@gmail.com>
David Aguilar schrieb:
> On Thu, Dec 10, 2009 at 04:41:03AM +0100, Nils Adermann wrote:
>
>> Following
>> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
>> I have subtree merged a 3rd party library (ezc-reflection) into my
>> repository (pflow). The prefix I used was lib/ezc/trunk/Reflection. Now
>> there have been changes to ezc-reflection but merging them into my
>> repository fails. The merge is attempted in example/ rather than
>> lib/ezc/trunk/Reflection.
>>
>> I originally set this up with:
>>
>> git remote add -f ezc-reflection /path/to/ezc-reflection
>> git merge -s ours --no-commit ezc-reflection/master
>> git read-tree --prefix=lib/ezc/trunk/Reflection -u ezc-reflection/master
>>
>> Reproduce my problem by executing the following:
>>
>> git clone git://github.com/naderman/pflow.git
>> cd pflow
>> git reset --hard f3e001e3
>> git fetch git://github.com/naderman/ezc-reflection.git master
>> git merge -s subtree FETCH_HEAD
>>
>> As you see this results in:
>>
>> CONFLICT (delete/modify): example/src/doc_comment_parser.php deleted in
>> HEAD and modified in FETCH_HEAD. Version FETCH_HEAD of
>> example/src/doc_comment_parser.php left in tree.
>> Automatic merge failed; fix conflicts and then commit the result.
>>
>> As long as I don't make any changes to lib/ezc/trunk/Reflection that I
>> want to merge I can work around this by simply repeating my original
>> process like this:
>>
>> git clone git://github.com/naderman/pflow.git
>> cd pflow
>> git reset --hard f3e001e3
>> git fetch git://github.com/naderman/ezc-reflection.git master
>> git merge -s ours --no-commit FETCH_HEAD
>> git rm -r lib/ezc/trunk/Reflection/
>> git read-tree --prefix=lib/ezc/trunk/Reflection/ -u FETCH_HEAD
>>
>> Why does this problem occur and how can I get the merge to work properly?
>>
>
> I'm not sure, but maybe you can try git-subtree?
> It makes this stuff easier for mere mortals.
>
> http://github.com/apenwarr/git-subtree/
>
> You might need to start redo your repo, but several people have
> had good success with git-subtree.
>
I actually tried that and I get the exact same problem. From what I
understand git-subtree really doesn't do anything different than what I
do anyway.
^ permalink raw reply
* What's cooking in git.git (Dec 2009, #04; Wed, 09)
From: Junio C Hamano @ 2009-12-10 7:11 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
As we are supposed to be in pre-release feature freeze, there is nothing
to see here ;-)
--------------------------------------------------
[Graduated to "master"]
* jk/maint-add-p-delete-fix (2009-12-08) 1 commit.
(merged to 'next' on 2009-12-08 at 3c2c08a)
+ add-interactive: fix deletion of non-empty files
Fixes a regression in 1.6.5.3.
* jn/maint-pull-rebase-error-message (2009-11-27) 1 commit.
(merged to 'next' on 2009-12-03 at 2ced03c)
+ pull: clarify advice for the unconfigured error case
Replaces old 'jn/rfc-pull-rebase-error-message' topic.
--------------------------------------------------
[New Topics]
* cc/reset-more (2009-12-08) 6 commits
- Documentation: reset: add some tables to describe the different options
- Documentation: reset: describe new "--keep-local-changes" option
- reset: add test cases for "--keep-local-changes" option
- reset: add option "--keep-local-changes" to "git reset"
- reset: use "unpack_trees()" directly instead of "git read-tree"
- reset: add a few tests for "git reset --merge"
The documentation is much clearer than the previous round in describing
what it does, but I find it a bit unclear in describing what it is _good_
for (iow, scenarios and use cases).
Breaks 'pu' and does not pass test on its own yet.
* tr/http-push-ref-status (2009-12-08) 3 commits
- transport-helper.c::push_refs(): emit "no refs" error message
- transport.c::transport_push(): make ref status affect return value
- refactor ref status logic for pushing
--------------------------------------------------
[Stalled]
* 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"?)
* jc/checkout-merge-base (2009-11-20) 2 commits
- "rebase --onto A...B" replays history on the merge base between A and B
- "checkout A...B" switches to the merge base between A and B
I've been using the first one for a while myself but do not see many users
want this (yet); the new feature is not urgent anyway.
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
(merged to 'next' on 2009-11-21 at fadaf7b)
+ rebase: refuse to rebase with -s ours
I do not think we reached a concensus for solving conflicts between "give
them rope" and "protect users from clearly meaningless combinations". The
author obviously is for the latter (and I am inclined to agree); Dscho
seems to think otherwise.
* jc/fix-tree-walk (2009-10-22) 8 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
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong. Sigh. We won't have a
proper fix in 1.6.6.
--------------------------------------------------
[Cooking]
* bg/maint-add-all-doc (2009-12-07) 4 commits.
- squash! rm documentation--also mention add-u where we mention commit-a
- git-rm doc: Describe how to sync index & work tree
- git-add/rm doc: Consistently back-quote
- Documentation: 'git add -A' can remove files
I didn't like the existing documentation for "add -u" myself (especially
because I wrote the initial version) and this neatly fix it as well.
* il/vcs-helper (2009-12-09) 8 commits
- Remove special casing of http, https and ftp
- Support remote archive from all smart transports
- Support remote helpers implementing smart transports
- Support taking over transports
- Refactor git transport options parsing
- Pass unknown protocols to external protocol handlers
- Support mandatory capabilities
- Add remote helper debug mode
(this branch uses early parts of sr/vcs-helper.)
Yet another round.
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
* mm/diag-path-in-treeish (2009-12-07) 1 commit
- Detailed diagnosis when parsing an object name fails.
* ns/rebase-auto-squash (2009-12-08) 2 commits
- fixup! rebase -i --autosquash
- rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
* jh/notes (2009-12-07) 11 commits
- 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
- Minor style fixes to notes.c
- Add more testcases to test fast-import of notes
- Rename t9301 to t9350, to make room for more fast-import tests
- fast-import: Proper notes tree manipulation
Rerolled and under discussion.
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- General --quiet improvements
* mv/commit-date (2009-12-03) 2 commits
- Document date formats accepted by parse_date()
- builtin-commit: add --date option
* mh/rebase-fixup (2009-12-07) 2 commits
- Add a command "fixup" to rebase --interactive
- t3404: Use test_commit to set up test repository
(this branch is used by ns/rebase-auto-squash.)
Initial round of "fixup" action that is similar to "squash" action in
"rebase -i" that excludes the commit log message from follow-up commits
when composing the log message for the updated one. Expected is a further
improvement to skip opening the editor if a pick is followed only by
"fixup" and no "squash".
* sr/gfi-options (2009-12-04) 7 commits
- fast-import: add (non-)relative-marks feature
- fast-import: allow for multiple --import-marks= arguments
- fast-import: test the new option command
- fast-import: add option command
- fast-import: add feature command
- fast-import: put marks reading in its own function
- fast-import: put option parsing code in separate functions
Rerolled.
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* mo/bin-wrappers (2009-12-02) 3 commits
- INSTALL: document a simpler way to run uninstalled builds
- run test suite without dashed git-commands in PATH
- build dashless "bin-wrappers" directory similar to installed bindir
Rerolled.
* tr/http-updates (2009-12-01) 3 commits
(merged to 'next' on 2009-12-07 at f08d447)
+ Allow curl to rewind the RPC read buffer
+ Add an option for using any HTTP authentication scheme, not only basic
+ http: maintain curl sessions
* jc/diff-whitespace-prepare (2009-11-28) 2 commits
- diff: flip the default diff.bwoutputonly to true
- diff: optionally allow traditional "-b/-w affects only output" semantics
(this branch uses gb/1.7.0-diff-whitespace-only-output and jc/1.7.0-diff-whitespace-only-status; is used by jc/1.7.0-diff-whitespace-prepare.)
This was to redo the two -b/-w semantic changes to prepare the migration of
existing users before 1.7.0 happens, but I think we should drop it.
Comments?
* sr/vcs-helper (2009-12-07) 14 commits
(merged to 'next' on 2009-12-07 at 8f041bc)
+ tests: handle NO_PYTHON setting
(merged to 'next' on 2009-12-03 at e45b562)
+ builtin-push: don't access freed transport->url
(merged to 'next' on 2009-11-27 at 83268ab)
+ Add Python support library for remote helpers
+ Basic build infrastructure for Python scripts
+ Allow helpers to report in "list" command that the ref is unchanged
+ Fix various memory leaks in transport-helper.c
+ 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
(this branch shares commits with il/vcs-helper.)
Should be among the first to graduate after 1.6.6 final.
* tr/reset-checkout-patch (2009-11-19) 1 commit.
(merged to 'next' on 2009-11-22 at b224950)
+ {checkout,reset} -p: make patch direction configurable
I do not particularly like a configuration like this that changes the
behaviour of a command in a drastic way---it will make helping others
much harder.
Comments?
* nd/sparse (2009-11-25) 20 commits.
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ 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
There were some test glitches reported and at least one test seems to
be broken in the sense that it is not testing what it is trying to.
Fix-up expected.
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-12-08) 13 commits.
(merged to 'next' on 2009-12-08 at 9b57d84)
+ t7508-status: test all modes with color
+ t7508-status: status --porcelain ignores relative paths setting
(merged to 'next' on 2009-12-07 at 7723acf)
+ status: reduce duplicated setup code
+ status: disable color for porcelain format
(merged to 'next' on 2009-12-05 at 44dcefd)
+ status -s: obey color.status
+ builtin-commit: refactor short-status code into wt-status.c
(merged to 'next' on 2009-11-27 at 91691ec)
+ t7508-status.sh: Add tests for status -s
+ status -s: respect the status.relativePaths option
(merged to 'next' on 2009-11-21 at 884bb56)
+ 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".
Immediately after 1.6.6 while rebuilding 'next', we may want to reorder a
few commits at the tip, as "docs: affects only long format" describes a
limitation that has disappeared.
* 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
As the title says.
* 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
* 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 branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change,
and jc/diff-whitespace-prepare topic is meant to ease the transition.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
Likewise but for the output of "diff --git" headers.
* jc/1.7.0-diff-whitespace-prepare (2009-11-28) 2 commits
- diff: disable diff.bwoutputonly warning
- diff: flip the diff.bwoutputonly default to false
(this branch uses gb/1.7.0-diff-whitespace-only-output, jc/1.7.0-diff-whitespace-only-status and jc/diff-whitespace-prepare.)
And this is to actually flip the default and eventually remove the warning.
As I am contemplating of dropping jc/diff-whitespace-prepare, this should
also be dropped as well.
* ns/1.7.0-send-email-no-chain-reply-to (2009-08-22) 1 commit
- send-email: make --no-chain-reply-to the default
And this is to actually flip the default in 1.7.0.
--------------------------------------------------
[Reverted from 'next']
* jc/botched-maint-cygwin-count-objects (2009-11-24) 2 commits.
(merged to 'next' on 2009-11-25 at 8aa62a0)
+ Revert "ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)"
(merged to 'next' on 2009-11-22 at 4ba5880)
+ ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)
This is a revert of the tip one I merged prematurely to 'next'. The real
fix from Ramsay is already in 'master'.
* ks/precompute-completion (2009-11-15) 4 commits.
(merged to 'next' on 2009-11-15 at 23cdb96)
+ Revert ks/precompute-completion series
(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
Reverted out of 'next', to be replaced with jn/faster-completion-startup
topic.
--------------------------------------------------
[Haven't been purged from 'pu' yet]
* jc/grep-full-tree (2009-11-24) 1 commit.
- grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-10 7:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael S. Tsirkin, Andreas Schwab, Peter Krefting,
Git Mailing List
In-Reply-To: <7v1vj4orra.fsf@alter.siamese.dyndns.org>
On 2009.12.09 11:46:01 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > "merge --squash" is one of the things I really dislike, because it turns
> > off the "history" part of the merge. You can say "Merging in git is about
> > histories, merging in svn is about changes only" to describe the major
> > difference for the merge commands in the two systems... "But then
> > there's --squash which turns git into svn".
>
> I agree with this to some degree, but I do not offhand think of a better
> alternative.
>
> At the first sight, it looks as if what "merge --squash" does was
> implemented as a new option "--squash" to the "merge" command merely
> because the way _how_ it internally needs to compute the result was
> already available in the implementation of "merge" command, and not
> necessarily because _what_ it does was conceptually consistent with the
> way "merge" works.
>
> But at the conceptual level, "merge --squash" is a short-hand for this
> command sequence:
>
> git rebase -i HEAD that-branch
> ... make everything except the first one into "squash"
> git checkout - ;# come back to the original branch
> git merge that-branch ;# fast forward to it
>
> So after all, it is "merge it after squashing them".
To me, that approach looks backwards, just like the "rebase --revisions"
proposal. "rebase" just happens to already provide the necessary
operations, but if cherry-pick would accepts ranges, this looks a lot
more logical to me:
git cherry-pick HEAD..that_branch
git reset --soft this_branch@{1} # [1]
git commit
[1] I assume that like "rebase", such a cherry-pick command would
already add a single reflog entry for the current branch
I cherry-pick all changes, and then use reset + commit to squash them
together to a single commit. To me, it's "I want to get all the changes
and squash them into a single commit", not "I want to squash the other
side's history in the background, without actually affecting the other
side and then merge that squashed version of the history".
So "cherry-pick --squash ..that_branch" seems more logical at the
conceptual level. Internally, it could of course just do a three-way
merge, instead of being stupid and repeating the "apply, commit --amend"
sequence over and over again.
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Peter Krefting @ 2009-12-10 8:43 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
In-Reply-To: <20091209134133.GA30596@atjola.homenet>
Björn Steinbrink:
> "git merge" is about merging histories. --squash and the A..B you suggest
> make it degenerate into merging changes (and you can't record that using
> the commit DAG). So that messes things up conceptually.
I know, this is the one "feature" of CVS that I sometimes miss in Git, that
I cannot "merge" just parts of a history, and have that recorded in the
history tree. I know it's wrong, I know I could do it better, but sometimes
it's the shortcut that would make life easier for me. :-)
But the reason I mentioned it was because of the discussion on whether the
"reverse rebase" should be an option to "cherry-pick" or not, and I
mentioned that it could just as well be "merge" since it can be used to
throw away history as well.
> Anyway, "git merge" with a range simply makes no sense at all given how
> git's merge works (opposed to svn's idea of merging, which is about
> changes, not about histories). If you want a squash flag, tell cherry-pick
> to handle ranges and teach such a flag to it.
And tell "merge" to tell me that if I try, so that if I try
$ git merge A..B
I would get a message saying something like
Cannot merge a range of commits. Try "git cherry-pick A..B" or
"git rebase --reverse A..B".
And perhaps we could also in the same way retire --squash?
$ git merge --squash B
The "--squash" option is obsolete. Please use "git cherry-pick
--squash B".
(with a transition period where it would just call the other). Or whatever
the options to simulate the old behaviour would be. This would make it
clearer that "merge" preserves history while "cherry-pick" and "rebase" do
not.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation
From: Johan Herland @ 2009-12-10 9:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <200912080345.37429.johan@herland.net>
On Tuesday 08 December 2009, Johan Herland wrote:
> On Tuesday 08 December 2009, Shawn O. Pearce wrote:
> > Johan Herland <johan@herland.net> wrote:
> > > > If we're here, isn't it likely that *all* notes are in the wrong
> > > > path in the tree, and we need to move them all to a new location?
> > > > If that's true then should we instead just build an entirely new
> > > > tree and swap the root when we are done?
> > >
> > > Hmm. Not always. In your earlier scenario where we add 2,000,000
> > > notes in a single commit, the current code would need to rewrite 255
> > > of them from fanout 0 to fanout 2, and 65,535 of them from fanout 1
> > > to fanout 2. But the vast majority (1,934,465) would not require
> > > rewriting (having been added at the correct fanout initially).
> > > However, if we build a new tree (by which I assume you mean
> > > tree_content_remove() from the old tree and
> > > tree_content_set() to the new tree for every single note (and
> > > non-note)), we end up processing all 2,000,000 entries.
> >
> > Well, by processing here you mean we wind up looking at them, only
> > to determine they are in the correct place already and skipping past.
>
> No, (as far as I (mis?)understood your idea) by processing here I'm
> talking about moving all 2,000,000 entries from the old tree to the new
> tree.
>
> Here's my understanding of your idea:
> - Create a new, empty tree
> - For each entry in the old/existing tree:
> - If not a note, move[*] verbatim to new tree
> - If a correctly placed note, move[*] verbatim to new tree
> - Else, move[*] note to the _correct_ place in the new tree
>
> [*]: By "move" I assume you mean tree_content_remove() from the old tree,
> followed by tree_content_set() into the new tree.
>
> From this understanding, I cannot see how your idea improves on the
> adding-2M-notes scenario.
>
> > I guess I see your point though. We're fairly bounded on how many
> > we might need to move, probably only 65,535, and the rest will be
> > at the right position so we're mostly just iterating through to
> > confirm they don't have to be moved.
>
> Yep.
Do you have more comments/suggestions on this patch? Or is it ok to include
in fast-import as-is?
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* FEATURE REQUEST: display <commit SHA> in message: git tag -d
From: Jari Aalto @ 2009-12-10 10:06 UTC (permalink / raw)
To: git
It would be helpful if the delete command would displayed the SHA:
$ git tag -d foo/20060213-1
Deleted tag 'foo/20060213-1'
... oops, I didn't want to do that
... Whatwas the commit ID again that I can restore the tag?
Instead:
$ git tag -d foo/20060213-1
Deleted tag 'foo/20060213-1' 4b397f6
... oops, I didn't want to do that
$ git tag 'foo/20060213-1' 4b397f6
... retagged, phew.
Notice that the message is in the format of copy/paste for immediate
retagging.
Jari
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-10 11:08 UTC (permalink / raw)
To: Peter Krefting; +Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0912100937580.22606@ds9.cixit.se>
On 2009.12.10 09:43:51 +0100, Peter Krefting wrote:
> Björn Steinbrink:
> >"git merge" is about merging histories. --squash and the A..B you
> >suggest make it degenerate into merging changes (and you can't
> >record that using the commit DAG). So that messes things up
> >conceptually.
>
> I know, this is the one "feature" of CVS that I sometimes miss in
> Git, that I cannot "merge" just parts of a history, and have that
> recorded in the history tree. I know it's wrong, I know I could do
> it better, but sometimes it's the shortcut that would make life
> easier for me. :-)
Hm, does CVS really record the fact that things were merged? I've never
seriously used CVS, so I have no idea... And if it does, is it just the
same thing as the svn "merge"-tracking?
> But the reason I mentioned it was because of the discussion on
> whether the "reverse rebase" should be an option to "cherry-pick" or
> not, and I mentioned that it could just as well be "merge" since it
> can be used to throw away history as well.
OK, and I disagreed because I think that "merge --squash" is already
wrong. And given your comment below about retiring "merge --squash", I
guess we're in agreement now, right?
> >Anyway, "git merge" with a range simply makes no sense at all
> >given how git's merge works (opposed to svn's idea of merging,
> >which is about changes, not about histories). If you want a squash
> >flag, tell cherry-pick to handle ranges and teach such a flag to
> >it.
>
> And tell "merge" to tell me that if I try, so that if I try
>
> $ git merge A..B
>
> I would get a message saying something like
>
> Cannot merge a range of commits. Try "git cherry-pick A..B" or
> "git rebase --reverse A..B".
Hm, for an error message that "range of commits" is probably on the edge
of being confusing. After all "git merge B" will create a new commit M
that "says" that M^1..M^2 was merged to M^1. But I can't come up with a
better error message either.
> And perhaps we could also in the same way retire --squash?
>
> $ git merge --squash B
> The "--squash" option is obsolete. Please use "git cherry-pick
> --squash B".
git cherry-pick --squash ..B # Not just B itself, but the whole range
> (with a transition period where it would just call the other). Or
> whatever the options to simulate the old behaviour would be. This
> would make it clearer that "merge" preserves history while
> "cherry-pick" and "rebase" do not.
I'd certainly like that.
Bjoern
^ permalink raw reply
* [BUG] 'git stash save' cannot create stash
From: SungHyun Nam @ 2009-12-10 12:17 UTC (permalink / raw)
To: git
Hello,
'git stash save' generates error:
/usr/local/libexec/git-core/git-stash: 436: cannot create
/home/namsh/work/project/.git/logs/refs/stash: Directory
nonexistent
Is it caused by my 'core.logAllRefUpdates' setting?
$ git config core.logAllRefUpdates
false
Anyway, 'git stash save' works fine after I do 'mkdir -p
.git/logs/refs'.
Thanks,
namsh
^ permalink raw reply
* [PATCH] tag -d: print sha1 of deleted tag
From: Michael J Gruber @ 2009-12-10 12:23 UTC (permalink / raw)
To: git; +Cc: Jari Aalto, Junio C Hamano
In-Reply-To: <87ljhb87nj.fsf@jondo.cante.net>
Print the sha1 of the deleted tag (in addition to the tag name) so that
one can easily recreate a mistakenly deleted tag:
git tag -d tagname
Deleted tag 'tagname' DEADBEEF
git tag 'tagname' DEADBEEF # for lightweight tags
git update-ref refs/tags/'tagname' DEADBEEF # for annotated tags
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Suggested-by: Jari Aalto <jari.aalto@cante.net>
---
builtin-tag.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index c479018..39d0ce2 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -140,7 +140,7 @@ static int delete_tag(const char *name, const char *ref,
{
if (delete_ref(ref, sha1, 0))
return 1;
- printf("Deleted tag '%s'\n", name);
+ printf("Deleted tag '%s' %s\n", name, sha1_to_hex(sha1));
return 0;
}
--
1.6.6.rc1.292.gd8fe
^ permalink raw reply related
* [RFC/PATCH] tag: display original sha1 of deleted/overwritten tag
From: Zoltán Füzesi @ 2009-12-10 12:34 UTC (permalink / raw)
To: git; +Cc: jari.aalto, Zoltán Füzesi
It makes possible to undo accidental tag deletion and overwriting.
Signed-off-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
---
This patch was created in response to this feature request:
http://article.gmane.org/gmane.comp.version-control.git/135016
I named it "RFC" because of the overwriting part.
builtin-tag.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index c479018..8dca364 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -140,7 +140,7 @@ static int delete_tag(const char *name, const char *ref,
{
if (delete_ref(ref, sha1, 0))
return 1;
- printf("Deleted tag '%s'\n", name);
+ printf("Deleted tag '%s' %s\n", name, sha1_to_hex(sha1));
return 0;
}
@@ -479,6 +479,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
die("%s: cannot lock the ref", ref);
if (write_ref_sha1(lock, object, NULL) < 0)
die("%s: cannot update the ref", ref);
+ else if (force && hashcmp(object, prev))
+ printf("Overwritten tag '%s' (%s)\n", ref, sha1_to_hex(prev));
strbuf_release(&buf);
return 0;
--
1.6.6.rc2
^ permalink raw reply related
* Re: [PATCH] tag -d: print sha1 of deleted tag
From: Björn Steinbrink @ 2009-12-10 12:47 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jari Aalto, Junio C Hamano
In-Reply-To: <3b0a7bfa75126e4c13ec15a4357645b2bfd14b5b.1260447713.git.git@drmicha.warpmail.net>
On 2009.12.10 13:23:43 +0100, Michael J Gruber wrote:
> Print the sha1 of the deleted tag (in addition to the tag name) so that
> one can easily recreate a mistakenly deleted tag:
>
> git tag -d tagname
> Deleted tag 'tagname' DEADBEEF
> git tag 'tagname' DEADBEEF # for lightweight tags
> git update-ref refs/tags/'tagname' DEADBEEF # for annotated tags
Using "git tag 'tagname' DEADBEEF" should actually work in both cases.
As that does nothing but creating the ref in the refs/tags/ namespace.
Bjoern
^ permalink raw reply
* Re: [PATCH] tag -d: print sha1 of deleted tag
From: Jeff King @ 2009-12-10 12:49 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jari Aalto, Junio C Hamano
In-Reply-To: <3b0a7bfa75126e4c13ec15a4357645b2bfd14b5b.1260447713.git.git@drmicha.warpmail.net>
On Thu, Dec 10, 2009 at 01:23:43PM +0100, Michael J Gruber wrote:
> Print the sha1 of the deleted tag (in addition to the tag name) so that
> one can easily recreate a mistakenly deleted tag:
>
> git tag -d tagname
> Deleted tag 'tagname' DEADBEEF
> git tag 'tagname' DEADBEEF # for lightweight tags
> git update-ref refs/tags/'tagname' DEADBEEF # for annotated tags
I think this is a good idea, and we already do the same for branch
deletion.
I'm not sure your example is right. If "tag -d" always prints out the
sha1 in the tag ref, can't you just use "git tag 'tagname' DEADBEEF" to
recreate both lightweight and annotated tags? That is, making a
lightweight tag of an annotated tag's sha1 should just recreate the
original annotated tag.
That being said, I am not a fan of the cut-and-paste format. This is not
something that happens so frequently that I think we need to go out of
our way to save some typing. And for a user seeing this message for the
first time:
1. It is not immediately obvious to a user seeing this message
for this first time exactly what the trailing sha1 means. We
already had this discussion with "git branch -d" and decided
that "(was DEADBEEF)" was more readable.
2. Even if they know what it means, it is not immediately obvious that
the error line is meant to be cut-and-pasted. If you are going to
give something to cut-and-paste, I think you are better off making
it obvious, like:
Deleted tag 'foo'; you can recreate it with
git tag 'foo' DEADBEEF
Of course that is painfully long for a message that is meant to be
a "just in case" notification of a successful command (I can see it
more for an actual error, where git is telling you "I couldn't do
what you wanted, but you might try running this command first").
-Peff
^ permalink raw reply
* Re: [PATCH] tag -d: print sha1 of deleted tag
From: Jari Aalto @ 2009-12-10 13:16 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, git, Junio C Hamano
In-Reply-To: <20091210124929.GA444@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Dec 10, 2009 at 01:23:43PM +0100, Michael J Gruber wrote:
>
>> Print the sha1 of the deleted tag (in addition to the tag name) so that
>> one can easily recreate a mistakenly deleted tag:
>>
>> git tag -d tagname
>> Deleted tag 'tagname' DEADBEEF
>> git tag 'tagname' DEADBEEF # for lightweight tags
>> git update-ref refs/tags/'tagname' DEADBEEF # for annotated tags
> That being said, I am not a fan of the cut-and-paste format. This is not
> something that happens so frequently
It dpends on user. For me it it does.
> 1. It is not immediately obvious to a user seeing this message
> for this first time exactly what the trailing sha1 means.
>
> 2. Even if they know what it means, it is not immediately obvious that
> the error line is meant to be cut-and-pasted.
"not meant" specifically, but it's very convenient to have it in format
that happens to be "cut-n-paste ready". The SHA itself is easily
understood in the context.
Thanks for all that have so quickly implemented this,
Jari
^ permalink raw reply
* Re: [PATCH] tag -d: print sha1 of deleted tag
From: Michael J Gruber @ 2009-12-10 13:21 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Jari Aalto, Junio C Hamano
In-Reply-To: <20091210124701.GA12521@atjola.homenet>
Björn Steinbrink venit, vidit, dixit 10.12.2009 13:47:
> On 2009.12.10 13:23:43 +0100, Michael J Gruber wrote:
>> Print the sha1 of the deleted tag (in addition to the tag name) so that
>> one can easily recreate a mistakenly deleted tag:
>>
>> git tag -d tagname
>> Deleted tag 'tagname' DEADBEEF
>> git tag 'tagname' DEADBEEF # for lightweight tags
>> git update-ref refs/tags/'tagname' DEADBEEF # for annotated tags
>
> Using "git tag 'tagname' DEADBEEF" should actually work in both cases.
> As that does nothing but creating the ref in the refs/tags/ namespace.
>
> Bjoern
Cool, even better! So, an annotated tag is practically a lightweight tag
pointing to a tag object. Once you think of it it's natural!
Michael
^ permalink raw reply
* [RFC/PATCH v2] tag: display original sha1 of deleted/overwritten tag
From: Zoltán Füzesi @ 2009-12-10 13:26 UTC (permalink / raw)
To: git; +Cc: jari.aalto, Zoltán Füzesi
In-Reply-To: <1260448496-527-1-git-send-email-zfuzesi@eaglet.hu>
It makes possible to undo accidental tag deletion and overwriting.
Signed-off-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
---
This patch was created in response to this feature request:
http://article.gmane.org/gmane.comp.version-control.git/135016
I named it "RFC" because of the overwriting part.
v2: works when tag object is created.
builtin-tag.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index c479018..1265b84 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -140,7 +140,7 @@ static int delete_tag(const char *name, const char *ref,
{
if (delete_ref(ref, sha1, 0))
return 1;
- printf("Deleted tag '%s'\n", name);
+ printf("Deleted tag '%s' %s\n", name, sha1_to_hex(sha1));
return 0;
}
@@ -363,7 +363,7 @@ static int parse_msg_arg(const struct option *opt, const char *arg, int unset)
int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
- unsigned char object[20], prev[20];
+ unsigned char object[20], prev[20], tag_object[20];
char ref[PATH_MAX];
const char *object_ref, *tag;
struct ref_lock *lock;
@@ -472,13 +472,15 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (annotate)
create_tag(object, tag, &buf, msg.given || msgfile,
- sign, prev, object);
+ sign, prev, tag_object);
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
die("%s: cannot lock the ref", ref);
if (write_ref_sha1(lock, object, NULL) < 0)
die("%s: cannot update the ref", ref);
+ else if (force && hashcmp(object, prev))
+ printf("Overwritten tag '%s' (%s)\n", ref, sha1_to_hex(prev));
strbuf_release(&buf);
return 0;
--
1.6.6.rc2
^ permalink raw reply related
* Re: [PATCH] tag -d: print sha1 of deleted tag
From: Michael J Gruber @ 2009-12-10 13:27 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jari Aalto, Junio C Hamano
In-Reply-To: <20091210124929.GA444@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 10.12.2009 13:49:
> On Thu, Dec 10, 2009 at 01:23:43PM +0100, Michael J Gruber wrote:
>
>> Print the sha1 of the deleted tag (in addition to the tag name) so that
>> one can easily recreate a mistakenly deleted tag:
>>
>> git tag -d tagname
>> Deleted tag 'tagname' DEADBEEF
>> git tag 'tagname' DEADBEEF # for lightweight tags
>> git update-ref refs/tags/'tagname' DEADBEEF # for annotated tags
>
> I think this is a good idea, and we already do the same for branch
> deletion.
>
> I'm not sure your example is right. If "tag -d" always prints out the
> sha1 in the tag ref, can't you just use "git tag 'tagname' DEADBEEF" to
> recreate both lightweight and annotated tags? That is, making a
> lightweight tag of an annotated tag's sha1 should just recreate the
> original annotated tag.
While my example is right it is unnecessarily complex. I learned that
through Björns and your remark.
> That being said, I am not a fan of the cut-and-paste format. This is not
> something that happens so frequently that I think we need to go out of
> our way to save some typing. And for a user seeing this message for the
> first time:
>
> 1. It is not immediately obvious to a user seeing this message
> for this first time exactly what the trailing sha1 means. We
> already had this discussion with "git branch -d" and decided
> that "(was DEADBEEF)" was more readable.
So, should we simply go with that then?
Meanwhile, RFCs/PATCHes crossed paths. I take it that Zoltan suggests
giving the same output for force-overwritten existing tags. I beat him
by 11 minutes, though ;)
Michael
^ permalink raw reply
* Re: [PATCH] tag -d: print sha1 of deleted tag
From: Jeff King @ 2009-12-10 13:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jari Aalto, Junio C Hamano
In-Reply-To: <4B20F733.6010401@drmicha.warpmail.net>
On Thu, Dec 10, 2009 at 02:27:15PM +0100, Michael J Gruber wrote:
> > 1. It is not immediately obvious to a user seeing this message
> > for this first time exactly what the trailing sha1 means. We
> > already had this discussion with "git branch -d" and decided
> > that "(was DEADBEEF)" was more readable.
>
> So, should we simply go with that then?
I think so. Jari obviously disagrees, but I don't have much more to say
in favor of it except that I find the other ugly and unintuitive. So it
is up to you what you want to submit and Junio what he wants to apply.
:)
> Meanwhile, RFCs/PATCHes crossed paths. I take it that Zoltan suggests
> giving the same output for force-overwritten existing tags. I beat him
> by 11 minutes, though ;)
Yes, I think if you are going to protect "tag -d", you might as well
protect overwriting, as well. Which made me think at first that we need
something similar for "branch -f", but I don't think we do; the last
branch value will be left in the reflog (but with tags, there is no
reflog).
-Peff
^ permalink raw reply
* [RFC/PATCH v3] tag: display original sha1 of deleted/overwritten tag
From: Zoltán Füzesi @ 2009-12-10 13:58 UTC (permalink / raw)
To: git; +Cc: jari.aalto, Zoltán Füzesi
In-Reply-To: <1260451579-4400-1-git-send-email-zfuzesi@eaglet.hu>
It makes possible to undo accidental tag deletion and overwriting.
Signed-off-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
---
This patch was created in response to this feature request:
http://article.gmane.org/gmane.comp.version-control.git/135016
I named it "RFC" because of the overwriting part.
v3: works when tag object is created (I should slow down...)
builtin-tag.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index c479018..1404a0e 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -140,7 +140,7 @@ static int delete_tag(const char *name, const char *ref,
{
if (delete_ref(ref, sha1, 0))
return 1;
- printf("Deleted tag '%s'\n", name);
+ printf("Deleted tag '%s' %s\n", name, sha1_to_hex(sha1));
return 0;
}
@@ -363,7 +363,7 @@ static int parse_msg_arg(const struct option *opt, const char *arg, int unset)
int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
- unsigned char object[20], prev[20];
+ unsigned char object[20], prev[20], tag_object[20];
char ref[PATH_MAX];
const char *object_ref, *tag;
struct ref_lock *lock;
@@ -472,13 +472,15 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (annotate)
create_tag(object, tag, &buf, msg.given || msgfile,
- sign, prev, object);
+ sign, prev, tag_object);
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
die("%s: cannot lock the ref", ref);
- if (write_ref_sha1(lock, object, NULL) < 0)
+ if (write_ref_sha1(lock, annotate ? tag_object : object, NULL) < 0)
die("%s: cannot update the ref", ref);
+ else if (force && hashcmp(object, prev))
+ printf("Overwritten tag '%s' (%s)\n", ref, sha1_to_hex(prev));
strbuf_release(&buf);
return 0;
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH v2] tag -d: print sha1 of deleted tag
From: Michael J Gruber @ 2009-12-10 14:01 UTC (permalink / raw)
To: git
Cc: Jari Aalto, Björn Steinbrink, Jeff King,
Zoltán Füzesi, Junio C Hamano
In-Reply-To: <20091210133645.GA2149@coredump.intra.peff.net>
Print the sha1 of the deleted tag (in addition to the tag name) so that
one can easily recreate a mistakenly deleted tag:
git tag -d tagname
Deleted tag 'tagname' (was DEADBEEF)
git tag 'tagname' DEADBEEF
We output the previous ref also in the case of forcefully overwriting
tags.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Helped-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
---
v2 changes the wording to match with branch -d and uses the same
for forcefully overwriting tags.
Zoltán, I don't think we should make this into a race. Posting in
the relevant thread (and actually following it) would help this.
Also, I think we should really compare the sha1 the tag points to,
i.e. like below and like in your v1 (not v2). Different tag object
is different tag (message may differ, e.g.).
builtin-tag.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index c479018..4ef1c4f 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -140,7 +140,7 @@ static int delete_tag(const char *name, const char *ref,
{
if (delete_ref(ref, sha1, 0))
return 1;
- printf("Deleted tag '%s'\n", name);
+ printf("Deleted tag '%s' (was %s)\n", name, find_unique_abbrev(sha1, DEFAULT_ABBREV));
return 0;
}
@@ -479,6 +479,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
die("%s: cannot lock the ref", ref);
if (write_ref_sha1(lock, object, NULL) < 0)
die("%s: cannot update the ref", ref);
+ if (force && hashcmp(prev, object))
+ printf("Updated tag '%s' (was %s)\n", tag, find_unique_abbrev(prev, DEFAULT_ABBREV));
strbuf_release(&buf);
return 0;
--
1.6.6.rc1.292.gd8fe
^ permalink raw reply related
* Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation
From: Shawn O. Pearce @ 2009-12-10 14:03 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster
In-Reply-To: <200912101039.44526.johan@herland.net>
Johan Herland <johan@herland.net> wrote:
> Do you have more comments/suggestions on this patch? Or is it ok to include
> in fast-import as-is?
Oops, sorry.
No, no additional comments. I am happy with this patch.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH v3] tag: display original sha1 of deleted/overwritten tag
From: Zoltán Füzesi @ 2009-12-10 14:09 UTC (permalink / raw)
To: git
In-Reply-To: <1260453537-6156-1-git-send-email-zfuzesi@eaglet.hu>
Forget v2 and v3, v1 is the good one. Sorry.
2009/12/10 Zoltán Füzesi <zfuzesi@eaglet.hu>:
> It makes possible to undo accidental tag deletion and overwriting.
>
> Signed-off-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
> ---
> This patch was created in response to this feature request:
> http://article.gmane.org/gmane.comp.version-control.git/135016
> I named it "RFC" because of the overwriting part.
>
> v3: works when tag object is created (I should slow down...)
>
> builtin-tag.c | 10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/builtin-tag.c b/builtin-tag.c
> index c479018..1404a0e 100644
> --- a/builtin-tag.c
> +++ b/builtin-tag.c
> @@ -140,7 +140,7 @@ static int delete_tag(const char *name, const char *ref,
> {
> if (delete_ref(ref, sha1, 0))
> return 1;
> - printf("Deleted tag '%s'\n", name);
> + printf("Deleted tag '%s' %s\n", name, sha1_to_hex(sha1));
> return 0;
> }
>
> @@ -363,7 +363,7 @@ static int parse_msg_arg(const struct option *opt, const char *arg, int unset)
> int cmd_tag(int argc, const char **argv, const char *prefix)
> {
> struct strbuf buf = STRBUF_INIT;
> - unsigned char object[20], prev[20];
> + unsigned char object[20], prev[20], tag_object[20];
> char ref[PATH_MAX];
> const char *object_ref, *tag;
> struct ref_lock *lock;
> @@ -472,13 +472,15 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
>
> if (annotate)
> create_tag(object, tag, &buf, msg.given || msgfile,
> - sign, prev, object);
> + sign, prev, tag_object);
>
> lock = lock_any_ref_for_update(ref, prev, 0);
> if (!lock)
> die("%s: cannot lock the ref", ref);
> - if (write_ref_sha1(lock, object, NULL) < 0)
> + if (write_ref_sha1(lock, annotate ? tag_object : object, NULL) < 0)
> die("%s: cannot update the ref", ref);
> + else if (force && hashcmp(object, prev))
> + printf("Overwritten tag '%s' (%s)\n", ref, sha1_to_hex(prev));
>
> strbuf_release(&buf);
> return 0;
> --
> 1.6.6.rc2
>
>
^ permalink raw reply
* Re: [PATCH v2] tag -d: print sha1 of deleted tag
From: Zoltán Füzesi @ 2009-12-10 14:16 UTC (permalink / raw)
To: Michael J Gruber
Cc: git, Jari Aalto, Björn Steinbrink, Jeff King, Junio C Hamano
In-Reply-To: <39e5cb38658919ed989f954a0917dfaa292f6350.1260453234.git.git@drmicha.warpmail.net>
2009/12/10 Michael J Gruber <git@drmicha.warpmail.net>:
> Zoltán, I don't think we should make this into a race. Posting in
> the relevant thread (and actually following it) would help this.
You are right. I've deleted the feature request mail, and then few
minutes laster decided to create the patch. So I've lost the message
ID (though I could retrieve it from the web...).
After posting the patch, noticed that you also posted one.
> Also, I think we should really compare the sha1 the tag points to,
> i.e. like below and like in your v1 (not v2). Different tag object
> is different tag (message may differ, e.g.).
I agree.
^ 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