* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Marius Storm-Olsen @ 2009-12-09 20:56 UTC (permalink / raw)
To: Yann Dirson; +Cc: kusmabite, Ferry Huberts, GIT ml
In-Reply-To: <20091208143700.GC5425@linagora.com>
Yann Dirson said the following on 08.12.2009 15:37:
> On Tue, Dec 08, 2009 at 03:23:55PM +0100, Erik Faye-Lund wrote:
>> You can follow the discussion here:
>> http://code.google.com/p/msysgit/issues/detail?id=288
>>
>> I believe the reason is something like "because someone suggested
>> it, and no one disagreed". Do you have a good argument why it
>> shouldn't be the default (other than "it's a change", because
>> changing it back now would also be a change)?
>
> Depending on the opinion of the Eclipse guys on this issue about
> "writing to hidden files only says 'could not write'", which
> arguably could be seen as a bug on their side, we can see changing
> this behaviour back to the default on the msysgit side as either a
> (possibly temporary) workaround for a known eclipse bug, or as
> getting again interoperable with egit.
Dot-files on unix are considered hidden. It's the only way files are
hidden there. Not so on Windows. Dot-files are just like any normal
file, and you need to mark a file hidden.
So, the logic of egit, that *actually* hidden files should not be
written to, but dot-files should, seems to me to be a bug in egit.
There should be no reason why egit shouldn't be able to write to any
file, pending permissions. I'd say file a bug report with egit.
--
.marius
^ permalink raw reply
* Re: [REROLL PATCH 5/8] Support taking over transports
From: Junio C Hamano @ 2009-12-09 21:08 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Junio C Hamano, git
In-Reply-To: <20091209151718.GE15673@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>> Who guarantees that reading from the (FILE *)data->out by strbuf_getline()
>> that eventually calls into fgetc() does not cause more data be read in the
>> buffer assiciated with the (FILE *) than we will consume? The other FILE*
>> you will make out of helper->out won't be able to read what data->out has
>> already slurped in to its stdio buffer.
>
> Causality impiles this can happen only if buffered version gets its buffer
> filled after sending connect command. And looking at stdio operations that
> can occur after sending the command:
>
> - fprintfs on stderr (debug mode only).
> - fgetc()s on unbuffered version.
I was worried about the "capabilities" loop in get_helper() if it reads
too much from data->out (causing helper->out to lose the beginning of what
it should read), but as you said, by "Causality" it cannot happen. The
protocol during that phase works with the other end in lock-step, and the
other end wouldn't have written to the pipe what we shouldn't read in that
loop (e.g. remote-curl.c responds with "capabilities" with lines and ends
with fflush(), and after that it waits for us to talk to it --- it would
never start talking by itself without first being asked to talk).
Is data->out only used inside get_helper() to read the capabilities
response? I was confused by it being keft open until disconnect time.
^ permalink raw reply
* Re: [REROLL PATCH 5/8] Support taking over transports
From: Ilari Liusvaara @ 2009-12-09 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vein3onxf.fsf@alter.siamese.dyndns.org>
On Wed, Dec 09, 2009 at 01:08:44PM -0800, Junio C Hamano wrote:
>
> Is data->out only used inside get_helper() to read the capabilities
> response? I was confused by it being keft open until disconnect time.
Its used for all incoming communications from remote helper until connect
request (and even after it if falling back to dumb transport).
- In smart transport case, that includes possible servpath option.
- In non-smart case, it includes a lot more.
In fact, recvline uses exactly helper->out as stream to read.
-Ilari
^ permalink raw reply
* Re: Delete particular file contents from complete history
From: Miklos Vajna @ 2009-12-09 21:50 UTC (permalink / raw)
To: Patrick Grimard; +Cc: git
In-Reply-To: <9cdb17250912091001u362ce64fybe3d554304cbc445@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
On Wed, Dec 09, 2009 at 01:01:17PM -0500, Patrick Grimard <pgrimard@gmail.com> wrote:
> Is there some way to remove from the entire history a particular
> file's content?
Did you read man git-filter-branch? Looks like the first example does
what you need.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Ready for 1.6.6-rc2?
From: Junio C Hamano @ 2009-12-09 21:54 UTC (permalink / raw)
To: git
I see many people have been actively adding commits to 'pu', but we are in
pre-release freeze and I'll be tagging 1.6.6-rc2 hopefully later today.
Depending on how fast the earth rotates, perhaps I'll do so tomorrow, as I
am expecting one order-to-pull from the other side of the globe.
If anybody, including those who are working on new topics, notices a bug
that didn't exist in 1.6.5 in the post-1.6.5 code, please give it a higher
priority than anything else. Bugs and glitches that we had in 1.6.5 are
what users have lived with, and unless fixes to them are really trivial,
they can stay in the upcoming release a bit longer.
But new bugs introduced after 1.6.5, iow, regressions, are something we
would really want to avoid.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Junio C Hamano @ 2009-12-09 21:59 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, git
In-Reply-To: <4B1F6B77.80108@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Regarding the larger part of your change: Is there a specific reason for
> ...
> ">output" rather than "> output" or just a style issue?
Yeah, I shouldn't have included these style fixes in there.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Charles Bailey @ 2009-12-09 22:34 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, David Aguilar, Junio C Hamano
In-Reply-To: <1260302477-49412-1-git-send-email-jaysoffian@gmail.com>
On Tue, Dec 08, 2009 at 12:01:17PM -0800, Jay Soffian wrote:
> Add SourceGear DiffMerge to the set of built-in diff/merge tools, and update
> bash completion and documentation.
> ---
> Documentation/git-difftool.txt | 2 +-
> Documentation/git-mergetool.txt | 2 +-
> Documentation/merge-config.txt | 4 ++--
> contrib/completion/git-completion.bash | 2 +-
> git-mergetool--lib.sh | 22 ++++++++++++++++++++--
> 5 files changed, 25 insertions(+), 7 deletions(-)
I'm not a diffmerge user but the patch looks fine to me.
Is diffmerge free but not Free?
Any reason for holding back on sign-off?
Charles.
^ permalink raw reply
* Re: Generic filters for git archive?
From: René Scharfe @ 2009-12-09 22:48 UTC (permalink / raw)
To: Russ Dill; +Cc: git
In-Reply-To: <f9d2a5e10912071706m10ed7112ob7db47cdfac510d6@mail.gmail.com>
Am 08.12.2009 02:06, schrieb Russ Dill:
> I'm trying to add copyright headers to my source files as they are
> exported via git archive. eg:
>
> * $Copyright$
>
> to
>
> * Copyright (c) 2003-2009 by Foo Bar
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the
> * Free Software Foundation; either version 2 of the License, or (at your
> * option) any later version.
> *
> * This program is distributed in the hope that it will be useful, but
> * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> * for more details.
> *
> * You should have received a copy of the GNU General Public License
> * along with this program; if not, write to the Free Software Foundation,
> * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>
> And properly handling things like '# $Copyright$', '// $Copyright$',
> etc. I have a sed script that does this, but no way to apply it to the
> output of git archive. I tried setting up a smudge filter that would
> only smudge output on archive exports, but it doesn't appear that the
> smudge filters get run on git archive.
>
> I am currently running 1.6.3.3
Is the filter attribute contained in a .gitattribute file that's part of
the tree you are trying to export? If it's only in the worktree copy,
then you need to use the option --worktree-attributes to make git
archive use it.
René
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Jay Soffian @ 2009-12-09 23:14 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, David Aguilar, Junio C Hamano
In-Reply-To: <20091209223409.GA32744@hashpling.org>
On Wed, Dec 9, 2009 at 2:34 PM, Charles Bailey <charles@hashpling.org> wrote:
> Is diffmerge free but not Free?
Correct, it's free as in beer, not as in speech. It is multi-platform
though (Linux, Windows, OS X). I've tested only on MacOS X. If someone
else wants to give it a test on Linux, that would be good. Looks like
there's both a deb and an rpm:
http://www.sourcegear.com/diffmerge/downloads.html
> Any reason for holding back on sign-off?
Oversight:
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
j.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Junio C Hamano @ 2009-12-10 0:08 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, David Aguilar
In-Reply-To: <1260302477-49412-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index 5b62785..5b29fef 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -46,7 +46,8 @@ check_unchanged () {
> valid_tool () {
> case "$1" in
> kdiff3 | tkdiff | xxdiff | meld | opendiff | \
> - emerge | vimdiff | gvimdiff | ecmerge | diffuse | araxis | p4merge)
> + emerge | vimdiff | gvimdiff | ecmerge | diffuse | araxis | p4merge | \
> + diffmerge)
> ;; # happy
> tortoisemerge)
> if ! merge_mode; then
As we are in pre-release feature freeze, it doesn't matter very much if I
take this patch now, so I'll let it sit in the list archive for now.
But I have to wonder about the maintainability of this file, if we have to
add every time somebody finds yet another diff/merge backends that could
be used, even a closed-source one.
There are only a handful of entry points that mergetool--lib defines, and
by overriding what should happen when these entry points are called, an end
user should be able to tell mergetool/difftool to use a new backend.
Perhaps it is a better approach to first eject bulk of code for the
backends we currently support under these case statements into separate
files, one per backend, move them to mergetool/ subdirectory in the source
tree, install them as "$(share)/git-core/mergetool/$toolname", and at
runtime source them? That way, a patch to add a new backend can be as
simple as adding a new file in mergetool/ and doing nothing else. Also an
end user can privately add support to a new backend much more easily.
Anybody want to try that approach?
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Jay Soffian @ 2009-12-10 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar
In-Reply-To: <7vaaxrn10o.fsf@alter.siamese.dyndns.org>
On Wed, Dec 9, 2009 at 4:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Perhaps it is a better approach to first eject bulk of code for the
> backends we currently support under these case statements into separate
> files, one per backend, move them to mergetool/ subdirectory in the source
> tree, install them as "$(share)/git-core/mergetool/$toolname", and at
> runtime source them? That way, a patch to add a new backend can be as
> simple as adding a new file in mergetool/ and doing nothing else. Also an
> end user can privately add support to a new backend much more easily.
>
> Anybody want to try that approach?
Sure. There may also be value in emulating the mercurial approach:
http://mercurial.selenic.com/wiki/MergeToolConfiguration
I'll give both a shot.
j.
^ permalink raw reply
* [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
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