Re: What's cooking in git.git (Dec 2012, #04; Sun, 16)
Matt Kraai wrote: Junio C Hamano wrote: It could turn out that we may be able to get rid of sys/param.h altogether, but one step at a time. Inputs from people on minority platforms are very much appreciated---does your platform build fine when the inclusion of the file is removed from git-compat-util.h? QNX builds fine when sys/param.h is not included. HP-NonStop build fine too without it. Bye, Jojo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tiffany jewellery launched a new series of luxury jewelry
Caused the posh jewelry from excavations in nature to fight, really coming in contact with story of Tiffany colored treasures. inch Tiffany executive vice us president Jon King said, This year, the 175th loved-one's birthday of the birth of a time when [url=http://www.tiffanyandcobracelets.co.uk/]tiffany jewellery uk[/url] , exactly the perfect time to honor the great heritage of the brandeach part of jewelry is unique, gorgeous treasures inlaid on perfect Tiffany light great rich design tradition. http://www.tiffanyandcobracelets.co.uk -- View this message in context: http://git.661346.n2.nabble.com/tiffany-jewellery-launched-a-new-series-of-luxury-jewelry-tp7573265.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2012, #04; Sun, 16)
Junio C Hamano wrote: It could turn out that we may be able to get rid of sys/param.h altogether, but one step at a time. Inputs from people on minority platforms are very much appreciated---does your platform build fine when the inclusion of the file is removed from git-compat-util.h? MinGW works fine with sys/param.h removed from git-compat-util.h. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On 12/18/2012 10:55 AM, Toralf Förster wrote: failed test(s): t3600 t7508 fixed 0 success 8342 failed 8 broken 56 total 8528 ick forgot these : n22 /usr/portage/dev-vcs/git # grep -i ^not ok /tmp/git.log | grep -v TODO not ok - 15 Test that git rm -f fails if its rm fails not ok - 16 When the rm in git rm -f fails, it should not remove the file from the index not ok - 20 Re-add foo and baz not ok - 21 Modify foo -- rm should refuse not ok - 22 Modified foo -- rm -f should work not ok - 23 Re-add foo and baz for HEAD tests not ok - 24 foo is different in index from HEAD -- rm should refuse not ok - 55 status succeeds in a read-only repository -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On 12/18/2012 02:56 AM, Andrew Ardill wrote: On 18 December 2012 03:01, Toralf Förster toralf.foers...@gmx.de wrote: On 12/17/2012 12:38 PM, Andrew Ardill wrote: On 17 December 2012 21:23, Toralf Förster toralf.foers...@gmx.de wrote: Hello, I'm faced with this situation : http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html and even a git stash doesn't help. Hi Toralf, That list is private and not visible without an account. Can you transcribe the relevant parts? Regards, Andrew Ardill Oh of course : On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote: So if you have further issues with boinc feel free to look in our debian git and feel free to download appropriate patches :-) Gianfranco thx Currently I'm struggling with a git problem of the boinc repository itself and b/c I'm using git for the linux kernel tree w/o any problems since eons /me wonders whether this is a BOINC-repository specific problem : After doing the following sequence with git 1.8.0.2 : $ git clone git://boinc.berkeley.edu/boinc.git $ cd boinc $ git checkout client_release_7.0.39 $ git checkout master (sometimes I've to repeat this : $ git checkout client_release_7.0.39 $ git checkout master ) I'm faced with this situation : $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: clientgui/AsyncRPC.cpp # modified: clientgui/sg_BoincSimpleFrame.cpp # no changes added to commit (use git add and/or git commit -a) (sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned) Now these commands $ git checkout -- clientgui/AsyncRPC.cpp $ git checkout -- clientgui/sg_BoincSimpleFrame.cpp doesn't help - the status is still the same (and ofc now I'm no longer allowed to make a git checkout - due to un-commited changes). Now I'm wondering where to start to investigate this issue ... Hi Toralf, That does look like a weird issue. What operating system are you on? I'm running a stable Gentoo Linux x86, 32bit with gcc 4.6.3 and current stable kernel 3.6.1x and 3.7.1, file system is ext4 at an external USB 2.0 drive. FWIW from the boinc maintainer I know that all tags till 7.0.3X are imported from svn. I upgraded to git 1.8.0.2 from 1.7.8.6 - situation is the same. The emerge gave : failed test(s): t3600 t7508 fixed 0 success 8342 failed 8 broken 56 total 8528 Ok, now answering your other questions: $ git stash warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp. The file will have its original line endings in your working directory. Saved working directory and index state WIP on master: 4a296dc - client simulator: fix build errors HEAD is now at 4a296dc - client simulator: fix build errors After that the situation is unchanged. What happens if you do a hard reset to the branch? $ git reset --hard HEAD~1 not better. What is the ouptut of git diff --cached ? The output is empty but git status shows still modified files. FWIW there's a related issue I'm wondering about which might help: $ git clone git://boinc.berkeley.edu/boinc.git $ tar -cpf boinc.tar boinc/ $ rm -rf boinc/ $ tar -xpf boinc.tar $ cd boinc/ $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: client/win/boinc_log.h # modified: client/win/boinc_log.rc # modified: clientctrl/boincsvcctrl.cpp # modified: clientctrl/boincsvcctrl.h # modified: clientctrl/boincsvcctrl.rc # modified: clientgui/AsyncRPC.cpp # modified: clientgui/DlgEventLog.cpp # modified: clientgui/DlgEventLog.h # modified: clientgui/DlgEventLogListCtrl.cpp # modified: clientgui/DlgEventLogListCtrl.h # modified: clientgui/DlgExitMessage.h # modified: clientgui/DlgItemProperties.h # modified: clientgui/TermsOfUsePage.cpp # modified: clientgui/TermsOfUsePage.h # modified: clientgui/ViewNotices.cpp # modified: clientgui/ViewNotices.h # modified: clientgui/sg_BoincSimpleFrame.cpp # modified: clientscr/boinc_ss_opengl.h # modified: clientscr/boinc_ss_opengl.rc # modified: clientscr/screensaver.cpp # modified: clienttray/boinc_tray.h # modified:
Re: [BUG] Cannot push some grafted branches
On Mon, 17 Dec 2012 13:14:56 -0800
Junio C Hamano gits...@pobox.com wrote:
Andreas Schwab sch...@linux-m68k.org writes:
Christian Couder christian.cou...@gmail.com writes:
Yeah, at one point I wanted to have a command that created to craft a
new commit based on an existing one.
This isn't hard to do, you only have to resort to plumbing:
$ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed
s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
| git hash-object -t commit --stdin -w
bb45cc6356eac6c7fa432965090045306dab7026
Good. I do not think an extra special-purpose command is welcome
here.
Well, I'm not sure this is intuitive enough to be useful to the average user :)
Adding git-rev-parse calls for convenience, and calling git-replace, would make
it
a more complete recipe, and we could suggest that as an alias in the collection
that's
in the wiki (which is not even linked any more from git-scm.com btw), but imho
that
would be hiding valuable information in a dark corner.
Anyway, in this form it will only replace a parent with another, whereas a full
graft replacement should allow to write a different number of new parents
instead.
That is, instead of this simple sed, something like:
(NEWPARENTS='parent xxx\nparent yyy\nparent zzz\n; git cat-file commit master |
perl -ne 'BEGIN { $state=0 }; if ($state eq 0) { if (/^parent/) { $state=1 }
else { print } } elsif ($state eq 1) { if (/^author/) { print
'$NEWPARENTS'; print; $state=2 } } else { print }')
Well, a short bash script should be more readable and possibly faster, but
that's the
idea. Such a script could be a candidate for contrib ?
--
Yann Dirson - Bertin Technologies
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
Am 12/18/2012 12:00, schrieb Yann Dirson: On Mon, 17 Dec 2012 13:14:56 -0800 Junio C Hamano gits...@pobox.com wrote: Andreas Schwab sch...@linux-m68k.org writes: Christian Couder christian.cou...@gmail.com writes: Yeah, at one point I wanted to have a command that created to craft a new commit based on an existing one. This isn't hard to do, you only have to resort to plumbing: $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/ | git hash-object -t commit --stdin -w bb45cc6356eac6c7fa432965090045306dab7026 Good. I do not think an extra special-purpose command is welcome here. Well, I'm not sure this is intuitive enough to be useful to the average user :) When I played with git-replace in the past, I imagined that it could be git replace object --commit ...commit options... that would do the trick. We could implement it with a git-replace--commit helper script that generates the replacement commit using the ...commit options... (to be defined what this should be), and git-replace would just pick its output (the SHA1 of the generated commit) as a substitute for the replacement argument that would have to be given without the --commit option. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On 18.12.12 10:55, Toralf Förster wrote: On 12/18/2012 02:56 AM, Andrew Ardill wrote: On 18 December 2012 03:01, Toralf Förster toralf.foers...@gmx.de wrote: On 12/17/2012 12:38 PM, Andrew Ardill wrote: On 17 December 2012 21:23, Toralf Förster toralf.foers...@gmx.de wrote: Hello, I'm faced with this situation : http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html and even a git stash doesn't help. Hi Toralf, That list is private and not visible without an account. Can you transcribe the relevant parts? Regards, Andrew Ardill Oh of course : On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote: So if you have further issues with boinc feel free to look in our debian git and feel free to download appropriate patches :-) Gianfranco thx Currently I'm struggling with a git problem of the boinc repository itself and b/c I'm using git for the linux kernel tree w/o any problems since eons /me wonders whether this is a BOINC-repository specific problem : After doing the following sequence with git 1.8.0.2 : $ git clone git://boinc.berkeley.edu/boinc.git $ cd boinc $ git checkout client_release_7.0.39 $ git checkout master (sometimes I've to repeat this : $ git checkout client_release_7.0.39 $ git checkout master ) I'm faced with this situation : $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: clientgui/AsyncRPC.cpp # modified: clientgui/sg_BoincSimpleFrame.cpp # no changes added to commit (use git add and/or git commit -a) (sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned) Now these commands $ git checkout -- clientgui/AsyncRPC.cpp $ git checkout -- clientgui/sg_BoincSimpleFrame.cpp doesn't help - the status is still the same (and ofc now I'm no longer allowed to make a git checkout - due to un-commited changes). Now I'm wondering where to start to investigate this issue ... Hi Toralf, That does look like a weird issue. What operating system are you on? I'm running a stable Gentoo Linux x86, 32bit with gcc 4.6.3 and current stable kernel 3.6.1x and 3.7.1, file system is ext4 at an external USB 2.0 drive. FWIW from the boinc maintainer I know that all tags till 7.0.3X are imported from svn. I upgraded to git 1.8.0.2 from 1.7.8.6 - situation is the same. The emerge gave : failed test(s): t3600 t7508 fixed 0 success 8342 failed 8 broken 56 total 8528 Ok, now answering your other questions: $ git stash warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in clientgui/AsyncRPC.cpp. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in clientgui/sg_BoincSimpleFrame.cpp. The file will have its original line endings in your working directory. Saved working directory and index state WIP on master: 4a296dc - client simulator: fix build errors HEAD is now at 4a296dc - client simulator: fix build errors After that the situation is unchanged. What happens if you do a hard reset to the branch? $ git reset --hard HEAD~1 not better. What is the ouptut of git diff --cached ? The output is empty but git status shows still modified files. FWIW there's a related issue I'm wondering about which might help: $ git clone git://boinc.berkeley.edu/boinc.git $ tar -cpf boinc.tar boinc/ $ rm -rf boinc/ $ tar -xpf boinc.tar $ cd boinc/ $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: client/win/boinc_log.h # modified: client/win/boinc_log.rc # modified: clientctrl/boincsvcctrl.cpp # modified: clientctrl/boincsvcctrl.h # modified: clientctrl/boincsvcctrl.rc # modified: clientgui/AsyncRPC.cpp # modified: clientgui/DlgEventLog.cpp # modified: clientgui/DlgEventLog.h # modified: clientgui/DlgEventLogListCtrl.cpp # modified: clientgui/DlgEventLogListCtrl.h # modified: clientgui/DlgExitMessage.h # modified: clientgui/DlgItemProperties.h # modified: clientgui/TermsOfUsePage.cpp # modified: clientgui/TermsOfUsePage.h # modified: clientgui/ViewNotices.cpp # modified: clientgui/ViewNotices.h # modified: clientgui/sg_BoincSimpleFrame.cpp # modified: clientscr/boinc_ss_opengl.h # modified:
Re: [BUG] Cannot push some grafted branches
Johannes Sixt j.s...@viscovery.net writes:
Am 12/18/2012 12:00, schrieb Yann Dirson:
On Mon, 17 Dec 2012 13:14:56 -0800
Junio C Hamano gits...@pobox.com wrote:
Andreas Schwab sch...@linux-m68k.org writes:
Christian Couder christian.cou...@gmail.com writes:
Yeah, at one point I wanted to have a command that created to craft a
new commit based on an existing one.
This isn't hard to do, you only have to resort to plumbing:
$ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 |
sed
s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/
| git hash-object -t commit --stdin -w
bb45cc6356eac6c7fa432965090045306dab7026
Good. I do not think an extra special-purpose command is welcome
here.
Well, I'm not sure this is intuitive enough to be useful to the average user
:)
When I played with git-replace in the past, I imagined that it could be
git replace object --commit ...commit options...
that would do the trick.
We could implement it with a git-replace--commit helper script that
generates the replacement commit using the ...commit options... (to be
defined what this should be), and git-replace would just pick its output
(the SHA1 of the generated commit) as a substitute for the replacement
argument that would have to be given without the --commit option.
I wouldn't even want a script -- we'd end up inventing a complicated
command-line editor for what can simply be done by judicious use of an
actual text editor. How about something like the following?
Documentation/git-replace.txt | 21 +
1 file changed, 21 insertions(+)
diff --git i/Documentation/git-replace.txt w/Documentation/git-replace.txt
index 51131d0..2502118 100644
--- i/Documentation/git-replace.txt
+++ w/Documentation/git-replace.txt
@@ -61,6 +61,27 @@ OPTIONS
Typing git replace without arguments, also lists all replace
refs.
+
+EXAMPLE
+---
+
+Replacements (and before them, grafts) are often used to replace the
+parent list of a commit. Since commits are stored in a human-readable
+format, you can in fact change any property using the following
+recipe:
+
+
+$ git cat-file commit original_commit tmp
+$ vi tmp
+
+In the editor, adjust the commit as needed. For example, you can edit
+the parent lists by adding/removing lines starting with parent.
+When done, replace the original commit with the edited one:
+
+$ git replace original_commit $(git hash-object -w tmp)
+
+
+
BUGS
Comparing blobs or trees that have been replaced with those that
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
Yann Dirson dir...@bertin.fr writes:
+EXAMPLE
+---
+
+Replacements (and before them, grafts) are often used to replace the
+parent list of a commit. Since commits are stored in a human-readable
+format, you can in fact change any property using the following
+recipe:
+
+
+$ git cat-file commit original_commit tmp
+$ vi tmp
+
+In the editor, adjust the commit as needed. For example, you can edit
+the parent lists by adding/removing lines starting with parent.
+When done, replace the original commit with the edited one:
+
+$ git replace original_commit $(git hash-object -w tmp)
You probably meant -t commit - a sign that it's not so trivial to forge ?
Mostly a sign that despite my testing efforts, I still fail at
cutpaste...
But yes, it absolutely needs -t commit. Otherwise the commit would be
replaced by a blob, and confusion ensues.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Opera release Git-splitter, a sub-modularizing tool for Git
Hello all, Today Opera Software released the Git-splitter, a small tool for sub-modularizing code in a git repo, with complete commit history, under the Apache 2.0 license. It's functionality is similar to git-subtree, but also include a command for reversing the process. The code is hosted on GitHub: https://github.com/operasoftware/git-splitter We have announced the release as part of another announcement of released code at the Opera Security Group home page: http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license -- Sincerely, Yngve N. Pettersen Senior Developer Email: yn...@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax:+47 23 69 24 01 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Makefile: track TCLTK_PATH as it used to be tracked
A long time ago, gitk used to live at the root of the git.git repository. In 62ba514 (Move gitk to its own subdirectory, 2007-11-17) it was moved to a subdirectory, but some code used to track TCLTK_PATH was left in the main Makefile instead of being moved to the new Makefile that was created in gitk-git/. The code left in the main Makefile in git.git should now have been removed because it was found useless. And this patch puts some code back to track TCLTK_PATH properly where it should be. Note that there is already some code to do that in git-gui. At the same time this patch creates a .gitignore and also marks some targets in the Makefile as PHONY. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Hi Paul, In this thread: http://thread.gmane.org/gmane.comp.version-control.git/211641 Junio asked me to send you this patch. So here it is, for you to apply to your tree. Thanks, Christian. .gitignore | 2 ++ Makefile | 16 ++-- 2 files changed, 16 insertions(+), 2 deletions(-) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..d7ebcaf --- /dev/null +++ b/.gitignore @@ -0,0 +1,2 @@ +/GIT-TCLTK-VARS +/gitk-wish diff --git a/Makefile b/Makefile index e1b6045..5acdc90 100644 --- a/Makefile +++ b/Makefile @@ -17,6 +17,16 @@ DESTDIR_SQ = $(subst ','\'',$(DESTDIR)) bindir_SQ = $(subst ','\'',$(bindir)) TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH)) +### Detect Tck/Tk interpreter path changes +TRACK_TCLTK = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') + +GIT-TCLTK-VARS: FORCE + @VARS='$(TRACK_TCLTK)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Tcl/Tk interpreter location; \ + echo $$VARS $@; \ + fi + ## po-file creation rules XGETTEXT ?= xgettext ifdef NO_MSGFMT @@ -49,9 +59,9 @@ uninstall:: $(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk clean:: - $(RM) gitk-wish po/*.msg + $(RM) gitk-wish po/*.msg GIT-TCLTK-VARS -gitk-wish: gitk +gitk-wish: gitk GIT-TCLTK-VARS $(QUIET_GEN)$(RM) $@ $@+ \ sed -e '1,3s|^exec .* $$0|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) $$0|' gitk $@+ \ chmod +x $@+ \ @@ -65,3 +75,5 @@ $(ALL_MSGFILES): %.msg : %.po @echo Generating catalog $@ $(MSGFMT) --statistics --tcl $ -l $(basename $(notdir $)) -d $(dir $@) +.PHONY: all install uninstall clean update-po +.PHONY: FORCE -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] gitk-git/Makefile: track TCLTK_PATH as it used to be tracked
From: Junio C Hamano gits...@pobox.com .gitignore | 1 - gitk-git/.gitignore | 2 ++ gitk-git/Makefile | 16 ++-- I'll apply the .gitignore part to my tree, but could you split the rest out and have Paul apply to his tree at git://ozlabs.org/~paulus/gitk.git Ok, I just sent the rest to Paul and I am going to send you an updated series for you. Regards, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
Martin von Zweigbergk martinv...@gmail.com writes: On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset originally wanted to. I do use commit --amend a lot, but I still appreciate having reset --soft. For example, to squash the last few commits: git reset --soft HEAD^^^ git commit --amend Yeah, I do that sometimes myself, but the key word is sometimes. These days, I think most users (not just mortals but experienced ones) use rebase -i to squash them altogether, either with fixup, with which you lose the messages from the follow-up fixes, just like the soft reset to an old one with an amen,) or with squash, with which you can pick pieces of messages from the follow-up fixes while updating the message from the original one. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] Makefile: remove tracking of TCLTK_PATH
It looks like we are tracking the value of TCLTK_PATH in the main Makefile for no good reason. This patch removes the useless code used to do this tracking. Maybe this code should have been moved to gitk-git/Makefile by 62ba514 (Move gitk to its own subdirectory, 2007-11-17). A patch to do that has just been sent to Paul Mackerras, the gitk maintainer. While at it, this patch removes /gitk-git/gitk-wish from .gitignore as it should be in /gitk-git/.gitignore and the patch sent to Paul put it there. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Hi Junio, I removed from the commit message everything that talked about git-gui. And this patch removes /gitk-git/gitk-wish from .gitignore. Regards, Christian. .gitignore | 2 -- Makefile | 14 +- 2 files changed, 1 insertion(+), 15 deletions(-) diff --git a/.gitignore b/.gitignore index f702415..64a454b 100644 --- a/.gitignore +++ b/.gitignore @@ -1,7 +1,6 @@ /GIT-BUILD-OPTIONS /GIT-CFLAGS /GIT-LDFLAGS -/GIT-GUI-VARS /GIT-PREFIX /GIT-SCRIPT-DEFINES /GIT-USER-AGENT @@ -171,7 +170,6 @@ /git-whatchanged /git-write-tree /git-core-*/?* -/gitk-git/gitk-wish /gitweb/GITWEB-BUILD-OPTIONS /gitweb/gitweb.cgi /gitweb/static/gitweb.js diff --git a/Makefile b/Makefile index 4ad6fbd..585b2eb 100644 --- a/Makefile +++ b/Makefile @@ -2624,18 +2624,6 @@ ifdef GIT_PERF_MAKE_OPTS @echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@ endif -### Detect Tck/Tk interpreter path changes -ifndef NO_TCLTK -TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') - -GIT-GUI-VARS: FORCE - @VARS='$(TRACK_VARS)'; \ - if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new Tcl/Tk interpreter location; \ - echo $$VARS $@; \ -fi -endif - test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) @@ -2910,7 +2898,7 @@ ifndef NO_TCLTK $(MAKE) -C gitk-git clean $(MAKE) -C git-gui clean endif - $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS + $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES .PHONY: all install profile-clean clean strip -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] Makefile: detect when PYTHON_PATH changes
When make is run, the python scripts are created from *.py files that are changed to use the python given by PYTHON_PATH. And PYTHON_PATH is set by default to /usr/bin/python on Linux. This is nice except when you run make another time setting a different PYTHON_PATH, because, as the python scripts have already been created, make finds nothing to do. The goal of this patch is to detect when the PYTHON_PATH changes and to create the python scripts again when this happens. To do that we use the same trick that is done to track other variables like prefix, flags, tcl/tk path and shell path. We update a GIT-PYTHON-VARS file with the PYTHON_PATH and check if it changed. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 1 + Makefile | 16 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 64a454b..56a4b2b 100644 --- a/.gitignore +++ b/.gitignore @@ -2,6 +2,7 @@ /GIT-CFLAGS /GIT-LDFLAGS /GIT-PREFIX +/GIT-PYTHON-VARS /GIT-SCRIPT-DEFINES /GIT-USER-AGENT /GIT-VERSION-FILE diff --git a/Makefile b/Makefile index 585b2eb..7db8445 100644 --- a/Makefile +++ b/Makefile @@ -2245,7 +2245,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh endif # NO_PERL ifndef NO_PYTHON -$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX +$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py $(QUIET_GEN)$(RM) $@ $@+ \ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \ @@ -2624,6 +2624,18 @@ ifdef GIT_PERF_MAKE_OPTS @echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@ endif +### Detect Python interpreter path changes +ifndef NO_PYTHON +TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') + +GIT-PYTHON-VARS: FORCE + @VARS='$(TRACK_PYTHON)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Python interpreter location; \ + echo $$VARS $@; \ +fi +endif + test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) @@ -2899,7 +2911,7 @@ ifndef NO_TCLTK $(MAKE) -C git-gui clean endif $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS - $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES + $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES GIT-PYTHON-VARS .PHONY: all install profile-clean clean strip .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] Makefile: replace echo 1... with echo ...
This is clearer to many people this way. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Makefile | 10 +- git-gui/Makefile | 6 +++--- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 7db8445..e055c9a 100644 --- a/Makefile +++ b/Makefile @@ -2183,7 +2183,7 @@ endef GIT-SCRIPT-DEFINES: FORCE @FLAGS='$(SCRIPT_DEFINES)'; \ if test x$$FLAGS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new script parameters; \ + echo 2 * new script parameters; \ echo $$FLAGS $@; \ fi @@ -2564,7 +2564,7 @@ TRACK_PREFIX = $(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):\ GIT-PREFIX: FORCE @FLAGS='$(TRACK_PREFIX)'; \ if test x$$FLAGS != x`cat GIT-PREFIX 2/dev/null` ; then \ - echo 12 * new prefix flags; \ + echo 2 * new prefix flags; \ echo $$FLAGS GIT-PREFIX; \ fi @@ -2573,7 +2573,7 @@ TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):$(USE_GETTEXT_SCHEME) GIT-CFLAGS: FORCE @FLAGS='$(TRACK_CFLAGS)'; \ if test x$$FLAGS != x`cat GIT-CFLAGS 2/dev/null` ; then \ - echo 12 * new build flags; \ + echo 2 * new build flags; \ echo $$FLAGS GIT-CFLAGS; \ fi @@ -2582,7 +2582,7 @@ TRACK_LDFLAGS = $(subst ','\'',$(ALL_LDFLAGS)) GIT-LDFLAGS: FORCE @FLAGS='$(TRACK_LDFLAGS)'; \ if test x$$FLAGS != x`cat GIT-LDFLAGS 2/dev/null` ; then \ - echo 12 * new link flags; \ + echo 2 * new link flags; \ echo $$FLAGS GIT-LDFLAGS; \ fi @@ -2631,7 +2631,7 @@ TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') GIT-PYTHON-VARS: FORCE @VARS='$(TRACK_PYTHON)'; \ if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new Python interpreter location; \ + echo 2 * new Python interpreter location; \ echo $$VARS $@; \ fi endif diff --git a/git-gui/Makefile b/git-gui/Makefile index e22ba5c..e9c2bc3 100644 --- a/git-gui/Makefile +++ b/git-gui/Makefile @@ -254,7 +254,7 @@ lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS auto_mkindex lib '*.tcl' \ | $(TCL_PATH) $(QUIET_2DEVNULL); then : ok; \ else \ -echo 12 * $(TCL_PATH) failed; using unoptimized loading; \ +echo 2 * $(TCL_PATH) failed; using unoptimized loading; \ rm -f $@ ; \ echo '# Autogenerated by git-gui Makefile' $@ \ echo $@ \ @@ -274,8 +274,8 @@ TRACK_VARS = \ GIT-GUI-VARS: FORCE @VARS='$(TRACK_VARS)'; \ if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new locations or Tcl/Tk interpreter; \ - echo 1$@ $$VARS; \ + echo 2 * new locations or Tcl/Tk interpreter; \ + echo $@ $$VARS; \ fi ifdef GITGUI_MACOSXAPP -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Tue, Dec 18, 2012 at 02:41:57PM +0100, Yann Dirson wrote:
I wouldn't even want a script -- we'd end up inventing a complicated
command-line editor for what can simply be done by judicious use of an
actual text editor. How about something like the following?
Well, while it does the job, it is still hardly as straightforward as the
old vi .git/info/grafts, or as a single easily-remembered commandline.
I wouldn't discount coming up with something based around git commit
that might be easier to use for specific instances, but it does seem
like an obvious feature to git replace to encapsulate Thomas's edit
script, which is the most general form.
I am not really interested in pushing this forward myself, but I worked
up this toy that somebody might find interesting (you can git replace
HEAD~20 to get dumped in an editor). It should probably handle trees,
and it would probably make sense to do per-object-type sanity checks
(e.g., call verify_tag on tags).
diff --git a/builtin/replace.c b/builtin/replace.c
index 398ccd5..90979b6 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -81,6 +81,57 @@ static int delete_replace_ref(const char *name, const char
*ref,
return 0;
}
+static void edit_buffer(struct strbuf *out, const char *buf, unsigned long len)
+{
+ char tmpfile[PATH_MAX];
+ int fd;
+
+ fd = git_mkstemp(tmpfile, sizeof(tmpfile), replace.XX);
+ if (fd 0)
+ die_errno(unable to create tempfile);
+ if (write_in_full(fd, buf, len) 0)
+ die_errno(unable to write to tempfile);
+ if (launch_editor(tmpfile, out, NULL) 0)
+ die_errno(unable to run editor);
+
+ close(fd);
+ unlink_or_warn(tmpfile);
+}
+
+static void edit_object(unsigned char old[20], unsigned char new[20])
+{
+ enum object_type type;
+ unsigned long size;
+ char *old_buf;
+ struct strbuf new_buf = STRBUF_INIT;
+
+ old_buf = read_sha1_file_extended(old, type, size, 0);
+ if (!old_buf)
+ die(unable to read object '%s', sha1_to_hex(old));
+
+ switch (type) {
+ case OBJ_COMMIT:
+ case OBJ_TAG:
+ case OBJ_BLOB:
+ /* These are OK to edit literally. */
+ edit_buffer(new_buf, old_buf, size);
+ break;
+ case OBJ_TREE:
+ /*
+* XXX we'd probably want to massage this into ls-tree format,
+* and then read the result back via mktree.
+*/
+ die(editing tree objects is not yet supported);
+ default:
+ die(unknown object type for %s, sha1_to_hex(old));
+ }
+
+ if (write_sha1_file(new_buf.buf, new_buf.len, typename(type), new) 0)
+ die(unable to write replacement object);
+ free(old_buf);
+ strbuf_release(new_buf);
+}
+
static int replace_object(const char *object_ref, const char *replace_ref,
int force)
{
@@ -90,7 +141,7 @@ static int replace_object(const char *object_ref, const char
*replace_ref,
if (get_sha1(object_ref, object))
die(Failed to resolve '%s' as a valid ref., object_ref);
- if (get_sha1(replace_ref, repl))
+ if (replace_ref get_sha1(replace_ref, repl))
die(Failed to resolve '%s' as a valid ref., replace_ref);
if (snprintf(ref, sizeof(ref),
@@ -105,6 +156,9 @@ static int replace_object(const char *object_ref, const
char *replace_ref,
else if (!force)
die(replace ref '%s' already exists, ref);
+ if (!replace_ref)
+ edit_object(object, repl);
+
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
die(%s: cannot lock the ref, ref);
@@ -144,7 +198,7 @@ int cmd_replace(int argc, const char **argv, const char
*prefix)
/* Replace object */
if (!list argc) {
- if (argc != 2)
+ if (argc 1 || argc 2)
usage_msg_opt(bad number of arguments,
git_replace_usage, options);
return replace_object(argv[0], argv[1], force);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Mon, Dec 17, 2012 at 10:34:07PM -0800, Martin von Zweigbergk wrote: On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset originally wanted to. I do use commit --amend a lot, but I still appreciate having reset --soft. For example, to squash the last few commits: git reset --soft HEAD^^^ git commit --amend Me too. Another one I use is: $ hack hack hack $ git commit -m wip $ git checkout something-else ... time passes ... $ git checkout orig-branch $ git reset --soft HEAD^ $ hack hack hack $ git diff $ git add -p $ git commit which ends up with the same history as commit --amend, but in between the reset and the commit, the bogus WIP commit is thrown away entirely. And things like diff and add -p do what you want, instead of showing your progress on top of the WIP. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-completion.bash: add support for path completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 17/12/2012 20:42, Junio C Hamano ha scritto: [...] I am not sure how you would handle the last parameter to git mv, though. That is by definition a path that does not exist, i.e. cannot be completed. Right, the code should be changed. No completion should be done for the second parameter. I deliberately wrote the last not the second, as you can do $ mkdir X $ git mv COPYING README X/. The patch is ready, however I decided to leave git mv completion simple. Pressing TAB will always try to autocomplete using all cached files. I have added a note to remember it needs more work. P.S.: git-completion.bash has a lot of other things that may be improved: * adding missing commands (as an example, there is strangely no custom support fot git status) * completion support for commands like git checkout is not complete. git checkout TAB will correctly try to complete the tree-ish, however git checkout HEAD -- TAB will try to complete the path using *all* files in the working directory. This is easy to fix, using the new functions I have added * not all long options are supported. The script documentation says that only common long options are supported, so I'm not sure it is ok to add support for all available long options. Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDQmQgACgkQscQJ24LbaUSw9QCfT1lCH/yjA4Lgmb2nMspNWM3l hMMAn26UxWesuoOxMbuwhqaypPjkmN84 =Wh4c -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with BOINC repository and CR/LF
On Tue, Dec 18, 2012 at 01:15:30PM +0100, Torsten Bögershausen wrote: I could re-produce the problem here: git version 1.8.0.197.g5a90748 Mac OS X (that what I had at hands fastest) I could reproduce it, too, on Linux. The reason it does not always happen is that git will not re-examine the file content unless the timestamp on the file is older than what's in the index. So it is a race condition for git to see whether the file is stat-dirty. But you can make sure all files are stat-dirty by just resetting the index: $ git clone git://boinc.berkeley.edu/boinc.git $ rm .git/index $ git reset which shows the complete list of files with LF/CRLF normalization issues. So my conclusion is: The file has CRLF in the repo, but should have LF. This is not a good thing, and the files need to be normalized. Yes, exactly. The project has told git via .gitattributes that certain files should have particular line endings in the repository, but that is not the case with the current versions. Doing: $ git commit -a -m 'normalize line endings according to gitattributes' on top of the commands above would fix it (for that commit and onwards, anyway). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
sys/param.h
Johannes Sixt j.s...@viscovery.net writes: Junio C Hamano wrote: It could turn out that we may be able to get rid of sys/param.h altogether, but one step at a time. Inputs from people on minority platforms are very much appreciated---does your platform build fine when the inclusion of the file is removed from git-compat-util.h? MinGW works fine with sys/param.h removed from git-compat-util.h. It seems that OpenBSD 5.2 does not mind it getting removed, either. Debian 5 and Debian 6 seem OK; so do Ubuntu 10.04 and 12.04. I have a hunch that Fedora or anything based on glibc would be fine, too. What other platforms do we care deeply about? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Makefile: track TCLTK_PATH as it used to be tracked
Christian Couder chrisc...@tuxfamily.org writes: A long time ago, gitk used to live at the root of the git.git repository. In 62ba514 (Move gitk to its own subdirectory, 2007-11-17) it was moved to a subdirectory, but some code used to track TCLTK_PATH was left in the main Makefile instead of being moved to the new Makefile that was created in gitk-git/. The code left in the main Makefile in git.git should now have been removed because it was found useless. And this patch puts some code back to track TCLTK_PATH properly where it should be. It is more like should have been moved to gitk's Makefile back then, but didn't. Make it so.. Note that there is already some code to do that in git-gui. At the same time this patch creates a .gitignore and also marks some targets in the Makefile as PHONY. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Hi Paul, In this thread: http://thread.gmane.org/gmane.comp.version-control.git/211641 Junio asked me to send you this patch. So here it is, for you to apply to your tree. Paul, just to clarify, I didn't review the contents of the patch; I merely redirected the patch in the right direction, so this still needs to be vetted by you ;-) ... +GIT-TCLTK-VARS: FORCE + @VARS='$(TRACK_TCLTK)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Tcl/Tk interpreter location; \ I think in a related patch to the top-level Makefile changes it to lose 1 to read it as echo 2 here. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] git-completion.bash: add support for path completion
The git-completion.bash script did not implemented full, git aware,
support for completion, for git commands that operate on files within
the current working directory or the index.
For these commands, only long options completion was available.
As an example:
git add TAB
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths within the current
working directory or the index, as the follow:
* the path completion for the git mv, git rm and git ls-tree
commands will suggest all cached files.
* the path completion for the git add command will suggest all
untracked and modified files. Ignored files are excluded.
* the path completion for the git clean command will suggest all
untracked files. Ignored files are excluded.
* the path completion for the git commit command will suggest all
files that have been modified from the HEAD.
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
contrib/completion/git-completion.bash | 112 -
1 file changed, 97 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..923ef37 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
#*) .git/remotes file names
#*) git 'subcommands'
#*) tree paths within 'ref:path/to/file' expressions
+#*) file paths within current working directory and index
#*) common --long-options
#
# To use these routines:
@@ -233,6 +234,59 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
}
+# Perl filter used to process path list returned by ls-files and
+# diff-index --name-only commands, in order to list file names
+# relative to a specified directory, and append a slash to directory
+# names.
+# The script expects the prefix path in the pfx environ variable.
+# The output must be processed with the uniq filter, to remove
+# duplicate directories.
+# XXX remove duplicates in the Perl script ?
+__git_index_file_list_filter='$pfx = $ENV{pfx};
+ $idx = index($_, $pfx);
+ if ($idx == 0) {
+ $_ = substr $_, length($pfx);
+ @segments = split(/, $_);
+ if ($segments[1]) {
+ print $segments[0], /\n
+ } else {
+ print $segments[0], \n
+ }
+ }'
+
+# __git_files accepts 1 or 2 arguments:
+# 1: A string for file index status mode (c, m, d, o), as
+#supported by git ls-files command. This is required.
+# 2: An optional directory path. If provided, only files within the
+#specified directory are listed. Sub directories are never recursed.
+#Path must have a trailing slash.
+__git_files ()
+{
+ local dir=$(__gitdir) flags=-${1}
+
+ if [ -d $dir ]; then
+ git --git-dir=$dir ls-files --exclude-standard ${flags}
${pfx} \
+ | pfx=$2 perl -ne ${__git_index_file_list_filter} \
+ | uniq
+ return
+ fi
+}
+
+# __git_commit_files accepts 1 optional argument: a directory path.
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed. Path must have a trailing slash.
+__git_commit_files ()
+{
+ local dir=$(__gitdir)
+
+ if [ -d $dir ]; then
+ git --git-dir=$dir diff-index --name-only HEAD \
+ | pfx=$1 perl -ne ${__git_index_file_list_filter} \
+ | uniq
+ return
+ fi
+}
+
__git_heads ()
{
local dir=$(__gitdir)
@@ -430,6 +484,25 @@ __git_complete_revlist_file ()
}
+# __git_complete_index_file requires 1 argument, the file index
+# status mode
+_git_complete_index_file ()
+{
+ local pfx cur_=$cur flags=${1}
+ case $cur_ in
+ ?*/*)
+ pfx=${cur_%/*}
+ cur_=${cur_##*/}
+ pfx=${pfx}/
+
+ __gitcomp_nl $(__git_files ${flags} ${pfx}) $pfx
$cur_
+ ;;
+ *)
+ __gitcomp_nl $(__git_files ${flags}) $cur_
+ ;;
+ esac
+}
+
__git_complete_file ()
{
__git_complete_revlist_file
@@ -770,8 +843,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash return
-
case $cur in
--*)
[RFH/PATCH] git-compat-util.h: do not #include sys/param.h by default
Earlier we allowed platforms that lack sys/param.h not to include the header file from git-compat-util.h; we have included this header file since the early days back when we used MAXPATHLEN (which we no longer use) and also depended on it slurping ULONG_MAX (which we get by including stdint.h or inttypes.h these days). It turns out that we can compile our modern codebase just file without including it on many platforms (so far, Debian, Ubuntu, MinGW, HP-Nonstop, QNX and z/OS are reported to be OK). Let's stop including it by default, and on platforms that need it to be included, leave make NEEDS_SYS_PARAM_H=YesPlease as an escape hatch and ask them to report to us, so that we can find out about the real dependency and fix it in a more platform agnostic way. Signed-off-by: Junio C Hamano gits...@pobox.com --- * I'd propose queuing this on top of dm/port topic, cook it in 'next' for a while and then unleash it to the public. Makefile | 8 +--- configure.ac | 6 -- git-compat-util.h | 2 +- 3 files changed, 6 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index 5cd1de0..2c1f04f 100644 --- a/Makefile +++ b/Makefile @@ -167,7 +167,9 @@ all:: # Define NO_POLL if you do not have or don't want to use poll(). # This also implies NO_SYS_POLL_H. # -# Define NO_SYS_PARAM_H if you don't have sys/param.h. +# Define NEEDS_SYS_PARAM_H if you need to include sys/param.h to compile, +# *PLEASE* REPORT to git@vger.kernel.org if your platform needs this; +# we want to know more about the issue. # # Define NO_PTHREADS if you do not have or do not want to use Pthreads. # @@ -1747,8 +1749,8 @@ endif ifdef NO_SYS_POLL_H BASIC_CFLAGS += -DNO_SYS_POLL_H endif -ifdef NO_SYS_PARAM_H - BASIC_CFLAGS += -DNO_SYS_PARAM_H +ifdef NEEDS_SYS_PARAM_H + BASIC_CFLAGS += -DNEEDS_SYS_PARAM_H endif ifdef NO_INTTYPES_H BASIC_CFLAGS += -DNO_INTTYPES_H diff --git a/configure.ac b/configure.ac index e3ab6fe..8fbb533 100644 --- a/configure.ac +++ b/configure.ac @@ -699,12 +699,6 @@ AC_CHECK_HEADER([sys/poll.h], [NO_SYS_POLL_H=UnfortunatelyYes]) GIT_CONF_SUBST([NO_SYS_POLL_H]) # -# Define NO_SYS_PARAM_H if you don't have sys/param.h -AC_CHECK_HEADER([sys/param.h], -[NO_SYS_PARAM_H=], -[NO_SYS_PARAM_H=UnfortunatelyYes]) -GIT_CONF_SUBST([NO_SYS_PARAM_H]) -# # Define NO_INTTYPES_H if you don't have inttypes.h AC_CHECK_HEADER([inttypes.h], [NO_INTTYPES_H=], diff --git a/git-compat-util.h b/git-compat-util.h index d7359ef..a88147b 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -104,7 +104,7 @@ #endif #include errno.h #include limits.h -#ifndef NO_SYS_PARAM_H +#ifdef NEEDS_SYS_PARAM_H #include sys/param.h #endif #include sys/types.h -- 1.8.1.rc2.136.gb42b73a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Incorrect man page for git-diff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. Documentation seems to suggest this is supported, but it is not true: $ git diff HEAD:git.c HEAD~100:git.c -- git.c usage: git diff [options] [commit [commit]] [--] [path...] unless I'm missing something. Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDQqncACgkQscQJ24LbaUT9XwCfV40P7lGulSWw+dzVo17EhcDQ YFoAnRb46025qYsKWp9mg6ZTRyuuaG3x =0gO1 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] git-completion.bash: add support for path completion
[jch: cc'ed git-completion experts to review implementation details]
Manlio Perillo manlio.peri...@gmail.com writes:
The git-completion.bash script did not implemented full, git aware,
support for completion, for git commands that operate on files within
the current working directory or the index.
For these commands, only long options completion was available.
I find the long options completion is a misleading phrase. It
sounds as if you changed the current completion that does not
complete git commit -TAB but does git commit --TAB to
complete the short options (e.g. git commit -c), but I do not
think that is the topic of this patch.
As an example:
git add TAB
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Full support for completion is now implemented, for git commands where
s/Full.*implemented/Support more comprehensive completion/; or
something, talking in the imperative mood (i.e. as if you are giving
the order to the codebase to do something).
the non-option arguments always refer to paths within the current
working directory or the index, as the follow:
* the path completion for the git mv, git rm and git ls-tree
commands will suggest all cached files.
I thought you dropped git mv in this round.
* the path completion for the git add command will suggest all
untracked and modified files. Ignored files are excluded.
* the path completion for the git clean command will suggest all
untracked files. Ignored files are excluded.
* the path completion for the git commit command will suggest all
files that have been modified from the HEAD.
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
I read always stop at directory boundary to mean that
git cmd tTAB
will give us t/ tag.c (assuming there is a new or modified file in
t/ and tag.c is the only modified file at the root level that begins
with t) and then
git cmd t/TAB
will likewise show the files and top-level subdirectories within t/
directory. That would be great.
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
contrib/completion/git-completion.bash | 112
-
1 file changed, 97 insertions(+), 15 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..923ef37 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
#*) .git/remotes file names
#*) git 'subcommands'
#*) tree paths within 'ref:path/to/file' expressions
+#*) file paths within current working directory and index
#*) common --long-options
#
# To use these routines:
@@ -233,6 +234,59 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
}
+# Perl filter used to process path list returned by ls-files and
+# diff-index --name-only commands, in order to list file names
+# relative to a specified directory, and append a slash to directory
+# names.
+# The script expects the prefix path in the pfx environ variable.
+# The output must be processed with the uniq filter, to remove
+# duplicate directories.
+# XXX remove duplicates in the Perl script ?
Surely, that will remove one fork/exec with pipeline. I am not sure
what the performance implication of using Perl here, but because we
do not have to stick to POSIX shell in this file, the completion
experts would be able to help rewriting this logic as a pure bash
script.
+__git_index_file_list_filter='$pfx = $ENV{pfx};
+ $idx = index($_, $pfx);
+ if ($idx == 0) {
+ $_ = substr $_, length($pfx);
+ @segments = split(/, $_);
+ if ($segments[1]) {
+ print $segments[0], /\n
+ } else {
+ print $segments[0], \n
+ }
+ }'
+
+# __git_files accepts 1 or 2 arguments:
+# 1: A string for file index status mode (c, m, d, o), as
+#supported by git ls-files command. This is required.
+# 2: An optional directory path. If provided, only files within the
+#specified directory are listed. Sub directories are never recursed.
+#Path must have a trailing slash.
+__git_files ()
+{
+ local dir=$(__gitdir) flags=-${1}
+
+ if [ -d $dir ]; then
+ git --git-dir=$dir ls-files --exclude-standard ${flags}
${pfx} \
+ | pfx=$2 perl -ne ${__git_index_file_list_filter} \
+ | uniq
This is purely a style thing (note that style suggestions are not
optional), but
the data source
Re: Re: [PATCH] completion: add option --recurse-submodules to git push
Hi, sorry for the late reply. On Fri, Dec 07, 2012 at 09:21:33AM -0800, Junio C Hamano wrote: Steffen Jaeckel steffen.jaec...@stzedn.de writes: Signed-off-by: Steffen Jaeckel steffen.jaec...@stzedn.de --- contrib/completion/git-completion.bash | 9 + 1 file changed, 9 insertions(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 0b77eb1..5b4d2e1 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1434,6 +1434,10 @@ _git_pull () __git_complete_remote_or_refspec } +__git_push_recurse_submodules_options= + check on-demand + Most of the existing completion functions do not seem to define separate variables like this; instead, they literally embed their choices at the point of use. Is it expected that the same set of choices will appear in the completion of many other subcommand options? [jc: Cc'ed Heiko so that we can sanity check the answer to this question]. If so, the variable may be justified; otherwise, not. No I think not. At least not exactly the same. check will be limited to push since it only makes sense there. on-demand on the other hand is already used for fetch and pull. Currently no more possible uses come to my mind. checkout and others will learn to traverse submodules but that will most likely be a boolean (to switch it on and off). CC'ed Jens so he can also take a look. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Incorrect man page for git-diff
Manlio Perillo manlio.peri...@gmail.com writes: Documentation seems to suggest this is supported, but it is not true: $ git diff HEAD:git.c HEAD~100:git.c -- git.c usage: git diff [options] [commit [commit]] [--] [path...] unless I'm missing something. Neither HEAD:git.c nor HEAD~100:git.c are commits. You are comparing two blob objects in their raw forms without textconv nor filter. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Makefile: replace echo 1... with echo ...
This is clearer to many people this way. A similar patch has been sent to the git mailing list for git.git. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Hi Pat, Here is a patch to apply to your git-gui tree following this discussion: http://thread.gmane.org/gmane.comp.version-control.git/211532/ Thanks, Christian. Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index e22ba5c..e9c2bc3 100644 --- a/Makefile +++ b/Makefile @@ -254,7 +254,7 @@ lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS auto_mkindex lib '*.tcl' \ | $(TCL_PATH) $(QUIET_2DEVNULL); then : ok; \ else \ -echo 12 * $(TCL_PATH) failed; using unoptimized loading; \ +echo 2 * $(TCL_PATH) failed; using unoptimized loading; \ rm -f $@ ; \ echo '# Autogenerated by git-gui Makefile' $@ \ echo $@ \ @@ -274,8 +274,8 @@ TRACK_VARS = \ GIT-GUI-VARS: FORCE @VARS='$(TRACK_VARS)'; \ if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new locations or Tcl/Tk interpreter; \ - echo 1$@ $$VARS; \ + echo 2 * new locations or Tcl/Tk interpreter; \ + echo $@ $$VARS; \ fi ifdef GITGUI_MACOSXAPP -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] git-completion.bash: add support for path completion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 18/12/2012 18:53, Junio C Hamano ha scritto:
[jch: cc'ed git-completion experts to review implementation details]
Manlio Perillo manlio.peri...@gmail.com writes:
The git-completion.bash script did not implemented full, git aware,
support for completion, for git commands that operate on files within
the current working directory or the index.
For these commands, only long options completion was available.
I find the long options completion is a misleading phrase. It
sounds as if you changed the current completion that does not
complete git commit -TAB but does git commit --TAB to
complete the short options (e.g. git commit -c), but I do not
think that is the topic of this patch.
It does not sound misleading to me.
I'm saying that the git-completion.bash script only implemented
completion for long options, but not for file names in the current
working directory.
Do you think I should rewrite the subject and the log message introduction?
As an example, something like this in the subject:
git-completion.bash: improve some git commands completion
and in the message:
The git-completion.bash script did not implemented full, git aware,
support for completion, for git commands that operate on files within
the current working directory or the index.
As an example:
...
I'm still not fully satisfied with it, however.
It still requires reading the full message to understand the changes
implemented.
As an example:
git add TAB
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Full support for completion is now implemented, for git commands where
s/Full.*implemented/Support more comprehensive completion/; or
something, talking in the imperative mood (i.e. as if you are giving
the order to the codebase to do something).
Ok.
the non-option arguments always refer to paths within the current
working directory or the index, as the follow:
* the path completion for the git mv, git rm and git ls-tree
commands will suggest all cached files.
I thought you dropped git mv in this round.
Well, no.
But the current implementation should not cause problems.
Also note that I added support for ls-files, too.
There are some XXX marks in the code, but I think that the changes
always improve the old behaviour.
[...]
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
I read always stop at directory boundary to mean that
git cmd tTAB
will give us t/ tag.c (assuming there is a new or modified file in
t/ and tag.c is the only modified file at the root level that begins
with t) and then
git cmd t/TAB
will likewise show the files and top-level subdirectories within t/
directory. That would be great.
Yes, this is how it works, bugs excluded (I'm not a bash/perl expert).
[...]
+# Perl filter used to process path list returned by ls-files and
+# diff-index --name-only commands, in order to list file names
+# relative to a specified directory, and append a slash to directory
+# names.
+# The script expects the prefix path in the pfx environ variable.
+# The output must be processed with the uniq filter, to remove
+# duplicate directories.
+# XXX remove duplicates in the Perl script ?
Surely, that will remove one fork/exec with pipeline. I am not sure
what the performance implication of using Perl here, but because we
do not have to stick to POSIX shell in this file, the completion
experts would be able to help rewriting this logic as a pure bash
script.
Ok. I'll wait for a review from git-completion experts.
Note that the performance is the reason why I suggested, in a previous
email, that git should have some more options to format data in custom ways.
As an example, there is no way to tell ls-files to not recurse
directories, and there is no way to also get the file type.
A --no-recurse option, and a change in the code to make, as an example
git ls-files --stage --modified
to honor the --modified option, will probably make it possible to use a
simple sed filter (there is still the problem that, unlike ls-tree,
ls-files shows the complete file path).
[...]
+__git_files ()
+{
+local dir=$(__gitdir) flags=-${1}
+
+if [ -d $dir ]; then
+git --git-dir=$dir ls-files --exclude-standard ${flags}
${pfx} \
+| pfx=$2 perl -ne ${__git_index_file_list_filter} \
+| uniq
This is purely a style thing (note that style suggestions are not
optional), but
the data source command |
a filter command |
another filter command
is easier to read and can be spelled without the backslash. The
same comment applies to git-commit-files as well.
I agree.
But I was copying the
[PATCH v5 1/3] Makefile: remove tracking of TCLTK_PATH
It looks like we are tracking the value of TCLTK_PATH in the main Makefile for no good reason. This patch removes the useless code used to do this tracking. Maybe this code should have been moved to gitk-git/Makefile by 62ba514 (Move gitk to its own subdirectory, 2007-11-17). A patch to do that has just been sent to Paul Mackerras, the gitk maintainer. While at it, this patch removes /gitk-git/gitk-wish from .gitignore as it should be in /gitk-git/.gitignore and the patch sent to Paul put it there. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 2 -- Makefile | 14 +- 2 files changed, 1 insertion(+), 15 deletions(-) diff --git a/.gitignore b/.gitignore index f702415..64a454b 100644 --- a/.gitignore +++ b/.gitignore @@ -1,7 +1,6 @@ /GIT-BUILD-OPTIONS /GIT-CFLAGS /GIT-LDFLAGS -/GIT-GUI-VARS /GIT-PREFIX /GIT-SCRIPT-DEFINES /GIT-USER-AGENT @@ -171,7 +170,6 @@ /git-whatchanged /git-write-tree /git-core-*/?* -/gitk-git/gitk-wish /gitweb/GITWEB-BUILD-OPTIONS /gitweb/gitweb.cgi /gitweb/static/gitweb.js diff --git a/Makefile b/Makefile index 4ad6fbd..585b2eb 100644 --- a/Makefile +++ b/Makefile @@ -2624,18 +2624,6 @@ ifdef GIT_PERF_MAKE_OPTS @echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@ endif -### Detect Tck/Tk interpreter path changes -ifndef NO_TCLTK -TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') - -GIT-GUI-VARS: FORCE - @VARS='$(TRACK_VARS)'; \ - if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new Tcl/Tk interpreter location; \ - echo $$VARS $@; \ -fi -endif - test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) @@ -2910,7 +2898,7 @@ ifndef NO_TCLTK $(MAKE) -C gitk-git clean $(MAKE) -C git-gui clean endif - $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS + $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES .PHONY: all install profile-clean clean strip -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/3] Makefile: replace echo 1... with echo ...
This is clearer to many people this way. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Makefile | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 7db8445..e055c9a 100644 --- a/Makefile +++ b/Makefile @@ -2183,7 +2183,7 @@ endef GIT-SCRIPT-DEFINES: FORCE @FLAGS='$(SCRIPT_DEFINES)'; \ if test x$$FLAGS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new script parameters; \ + echo 2 * new script parameters; \ echo $$FLAGS $@; \ fi @@ -2564,7 +2564,7 @@ TRACK_PREFIX = $(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):\ GIT-PREFIX: FORCE @FLAGS='$(TRACK_PREFIX)'; \ if test x$$FLAGS != x`cat GIT-PREFIX 2/dev/null` ; then \ - echo 12 * new prefix flags; \ + echo 2 * new prefix flags; \ echo $$FLAGS GIT-PREFIX; \ fi @@ -2573,7 +2573,7 @@ TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):$(USE_GETTEXT_SCHEME) GIT-CFLAGS: FORCE @FLAGS='$(TRACK_CFLAGS)'; \ if test x$$FLAGS != x`cat GIT-CFLAGS 2/dev/null` ; then \ - echo 12 * new build flags; \ + echo 2 * new build flags; \ echo $$FLAGS GIT-CFLAGS; \ fi @@ -2582,7 +2582,7 @@ TRACK_LDFLAGS = $(subst ','\'',$(ALL_LDFLAGS)) GIT-LDFLAGS: FORCE @FLAGS='$(TRACK_LDFLAGS)'; \ if test x$$FLAGS != x`cat GIT-LDFLAGS 2/dev/null` ; then \ - echo 12 * new link flags; \ + echo 2 * new link flags; \ echo $$FLAGS GIT-LDFLAGS; \ fi @@ -2631,7 +2631,7 @@ TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') GIT-PYTHON-VARS: FORCE @VARS='$(TRACK_PYTHON)'; \ if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new Python interpreter location; \ + echo 2 * new Python interpreter location; \ echo $$VARS $@; \ fi endif -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/3] Makefile: detect when PYTHON_PATH changes
When make is run, the python scripts are created from *.py files that are changed to use the python given by PYTHON_PATH. And PYTHON_PATH is set by default to /usr/bin/python on Linux. This is nice except when you run make another time setting a different PYTHON_PATH, because, as the python scripts have already been created, make finds nothing to do. The goal of this patch is to detect when the PYTHON_PATH changes and to create the python scripts again when this happens. To do that we use the same trick that is done to track other variables like prefix, flags, tcl/tk path and shell path. We update a GIT-PYTHON-VARS file with the PYTHON_PATH and check if it changed. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 1 + Makefile | 16 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 64a454b..56a4b2b 100644 --- a/.gitignore +++ b/.gitignore @@ -2,6 +2,7 @@ /GIT-CFLAGS /GIT-LDFLAGS /GIT-PREFIX +/GIT-PYTHON-VARS /GIT-SCRIPT-DEFINES /GIT-USER-AGENT /GIT-VERSION-FILE diff --git a/Makefile b/Makefile index 585b2eb..7db8445 100644 --- a/Makefile +++ b/Makefile @@ -2245,7 +2245,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh endif # NO_PERL ifndef NO_PYTHON -$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX +$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py $(QUIET_GEN)$(RM) $@ $@+ \ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \ @@ -2624,6 +2624,18 @@ ifdef GIT_PERF_MAKE_OPTS @echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@ endif +### Detect Python interpreter path changes +ifndef NO_PYTHON +TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') + +GIT-PYTHON-VARS: FORCE + @VARS='$(TRACK_PYTHON)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Python interpreter location; \ + echo $$VARS $@; \ +fi +endif + test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) @@ -2899,7 +2911,7 @@ ifndef NO_TCLTK $(MAKE) -C git-gui clean endif $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS - $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES + $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES GIT-PYTHON-VARS .PHONY: all install profile-clean clean strip .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Incorrect man page for git-diff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 18/12/2012 19:11, Junio C Hamano ha scritto: Manlio Perillo manlio.peri...@gmail.com writes: Documentation seems to suggest this is supported, but it is not true: $ git diff HEAD:git.c HEAD~100:git.c -- git.c usage: git diff [options] [commit [commit]] [--] [path...] unless I'm missing something. Neither HEAD:git.c nor HEAD~100:git.c are commits. Well, the documentation calls these parameter commit, later saying For a more complete list of ways to spell commit, see SPECIFYING REVISIONS. You are comparing two blob objects in their raw forms without textconv nor filter. Note that I was not missing the fact that git diff does not apply texconv and filters. I'm not sure the man page is wrong and should be changed: -- usage: git diff [options] [commit [commit]] [--] [path...] ++ usage: git diff [options] [commit [commit]] Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDQv40ACgkQscQJ24LbaUT+vwCgj0rjaZbc+/x0+jvAGZydbVKB 244An2pWLj7t4nG3lZzx+LGyH3mjTujS =TmVI -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] git-completion.bash: add support for path completion
Manlio Perillo manlio.peri...@gmail.com writes: Il 18/12/2012 18:53, Junio C Hamano ha scritto: [jch: cc'ed git-completion experts to review implementation details] Manlio Perillo manlio.peri...@gmail.com writes: The git-completion.bash script did not implemented full, git aware, support for completion, for git commands that operate on files within the current working directory or the index. For these commands, only long options completion was available. I find the long options completion is a misleading phrase. It sounds as if you changed the current completion that does not complete git commit -TAB but does git commit --TAB to complete the short options (e.g. git commit -c), but I do not think that is the topic of this patch. It does not sound misleading to me. I'm saying that the git-completion.bash script only implemented completion for long options, but not for file names in the current working directory. Do you think I should rewrite the subject and the log message introduction? The subject sounds fine; it is just It only does long options sounded as if it were viewing the lack of short options support as an issue. In other words, my knee-jerk answer to long options, as opposed to what??? question was short options, not files. If the phrase were It only does options, the question would become options as opposed to what???, which may have given me a chance to guess files as the answer to that question. As an example, something like this in the subject: git-completion.bash: improve some git commands completion I think the original is better; you do not touch any options, either long or short. You are improving paths, and the original is much clearer on that point. and in the message: The git-completion.bash script did not implemented full, git aware, support for completion, for git commands that operate on files within With s/for completion/to complete paths/, it would be perfect. You do not touch options, and this new log message does not talk about it. Much nicer than the one that was posted. Note that the performance is the reason why I suggested, in a previous email, that git should have some more options to format data in custom ways. As an example, there is no way to tell ls-files to not recurse directories, and there is no way to also get the file type. To ls-files, no-recurse is an idiotic thing to ask. The index is a flat structure that is read as a whole. There is no recursion involved. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
t7004: do not create unneeded gpghome/gpg.conf when GPG is not used
These tests themselves are properly protected by the GPG prerequisite, but one of the set-up steps outside the test_expect_success block unconditionally assumed that there is a gpghome/ directory, which is not true if GPG is not being used. It may be a good idea to move the whole set-up steps in the test but that is a follow-up topic. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t7004-tag.sh | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git i/t/t7004-tag.sh w/t/t7004-tag.sh index 5189446..f5a79b1 100755 --- i/t/t7004-tag.sh +++ w/t/t7004-tag.sh @@ -1066,12 +1066,12 @@ test_expect_success GPG \ ' # usage with rfc1991 signatures -echo rfc1991 gpghome/gpg.conf get_tag_header rfc1991-signed-tag $commit commit $time expect echo RFC1991 signed tag expect echo '-BEGIN PGP MESSAGE-' expect test_expect_success GPG \ 'creating a signed tag with rfc1991' ' + echo rfc1991 gpghome/gpg.conf git tag -s -m RFC1991 signed tag rfc1991-signed-tag $commit get_tag_msg rfc1991-signed-tag actual test_cmp expect actual @@ -1085,6 +1085,7 @@ chmod +x fakeeditor test_expect_success GPG \ 'reediting a signed tag body omits signature' ' + echo rfc1991 gpghome/gpg.conf echo RFC1991 signed tag expect GIT_EDITOR=./fakeeditor git tag -f -s rfc1991-signed-tag $commit test_cmp expect actual @@ -1092,11 +1093,13 @@ test_expect_success GPG \ test_expect_success GPG \ 'verifying rfc1991 signature' ' + echo rfc1991 gpghome/gpg.conf git tag -v rfc1991-signed-tag ' test_expect_success GPG \ 'list tag with rfc1991 signature' ' + echo rfc1991 gpghome/gpg.conf echo rfc1991-signed-tag RFC1991 signed tag expect git tag -l -n1 rfc1991-signed-tag actual test_cmp expect actual -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Incorrect man page for git-diff
Manlio Perillo manlio.peri...@gmail.com writes:
I'm not sure the man page is wrong and should be changed:
-- usage: git diff [options] [commit [commit]] [--] [path...]
++ usage: git diff [options] [commit [commit]]
Comparison of two blob objects works entirely in different way (it
is not even recursively comparing two tree-shaped things).
I do not think this mode is common enough to deserve to be in the
short help text, but it should be in the documentation, perhaps like
this patch, I think.
Documentation/git-diff.txt | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git c/Documentation/git-diff.txt w/Documentation/git-diff.txt
index f8d0819..f8c0601 100644
--- c/Documentation/git-diff.txt
+++ w/Documentation/git-diff.txt
@@ -12,6 +12,7 @@ SYNOPSIS
'git diff' [options] [commit] [--] [path...]
'git diff' [options] --cached [commit] [--] [path...]
'git diff' [options] commit commit [--] [path...]
+'git diff' [options] blob blob
'git diff' [options] [--no-index] [--] path path
DESCRIPTION
@@ -55,6 +56,11 @@ directories. This behavior can be forced by --no-index.
This is to view the changes between two arbitrary
commit.
+'git diff' [options] blob blob::
+
+ This form is to view the differences between the raw
+ contents of two blob objects.
+
'git diff' [--options] commit..commit [--] [path...]::
This is synonymous to the previous form. If commit on
@@ -72,8 +78,7 @@ directories. This behavior can be forced by --no-index.
Just in case if you are doing something exotic, it should be
noted that all of the commit in the above description, except
in the last two forms that use .. notations, can be any
-tree. The third form ('git diff commit commit') can also
-be used to compare two blob objects.
+tree.
For a more complete list of ways to spell commit, see
SPECIFYING REVISIONS section in linkgit:gitrevisions[7].
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sys/param.h
On 18.12.12 18:01, Junio C Hamano wrote: Johannes Sixt j.s...@viscovery.net writes: Junio C Hamano wrote: It could turn out that we may be able to get rid of sys/param.h altogether, but one step at a time. Inputs from people on minority platforms are very much appreciated---does your platform build fine when the inclusion of the file is removed from git-compat-util.h? MinGW works fine with sys/param.h removed from git-compat-util.h. It seems that OpenBSD 5.2 does not mind it getting removed, either. Debian 5 and Debian 6 seem OK; so do Ubuntu 10.04 and 12.04. I have a hunch that Fedora or anything based on glibc would be fine, too. What other platforms do we care deeply about? Mac OS X 10.6.8: OK -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Q: do people compile with NO_FNMATCH on OpenBSD 5.2?
I seem to get a failure from git ls-files a* in t/t-basic.sh if I link with platform's fnmatch(). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] git-completion.bash: add support for path completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 18/12/2012 20:22, Junio C Hamano ha scritto: [...] Note that the performance is the reason why I suggested, in a previous email, that git should have some more options to format data in custom ways. As an example, there is no way to tell ls-files to not recurse directories, and there is no way to also get the file type. To ls-files, no-recurse is an idiotic thing to ask. The index is a flat structure that is read as a whole. There is no recursion involved. What about an option like --as-tree, so that ls-files will list the files as they were in a tree, instead of a flat structure ? Thanks Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDQ0j4ACgkQscQJ24LbaURXoACffQ4iz6MsoeffEZEBib1b1KF8 NZsAoIUXa7OonWyFxfJ35mukBK/sddGr =0nO7 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Q: do people compile with NO_FNMATCH on OpenBSD 5.2?
Junio C Hamano gits...@pobox.com writes: I seem to get a failure from git ls-files a* in t/t-basic.sh if I link with platform's fnmatch(). Not what you asked, but on NetBSD 5.1, libc fnmatch is used, and with git 1.8.0.1 that test passes. This prompted me to look at the rest of the tests. All tests pass (except for expected failures) until: *** t0070-fundamental.sh *** ok 1 - character classes (isspace, isalpha etc.) not ok - 2 mktemp to nonexistent directory prints filename # # test_must_fail test-mktemp doesnotexist/testXX 2err # grep doesnotexist/test err # ok 3 - mktemp to unwritable directory prints filename ok 4 - check for a bug in the regex routines # failed 1 among 4 test(s) 1..4 Running this by hand, I get: gdt 51 /usr/pkgsrc/devel/scmgit-base/work/git-1.8.0.1/t ../test-mktemp foo/barXX MKTEMP.stdout 2 MKTEMP.stderr; ls -l MKTEMP* -rw-r--r-- 1 gdt wheel 121 Dec 18 15:14 MKTEMP.stderr -rw-r--r-- 1 gdt wheel0 Dec 18 15:14 MKTEMP.stdout gdt 52 /usr/pkgsrc/devel/scmgit-base/work/git-1.8.0.1/t cat MKTEMP.stderr fatal: Unable to create temporary file '/usr/pkgsrc/devel/scmgit-base/work/git-1.8.0.1/t/foo': No such file or directory It seems ENOENT is correct for the directory not existing. I think the test is complaining that the failed call to mkstemp modified the argument. Looking at: http://pubs.opengroup.org/onlinepubs/9699919799/functions/mkstemp.html I can't see that it requires anything in particular for the in/out paramater when there is an error. pgpnwLq2iMf0J.pgp Description: PGP signature
Re: Q: do people compile with NO_FNMATCH on OpenBSD 5.2?
Greg Troxel g...@ir.bbn.com writes: *** t0070-fundamental.sh *** ok 1 - character classes (isspace, isalpha etc.) not ok - 2 mktemp to nonexistent directory prints filename # # test_must_fail test-mktemp doesnotexist/testXX 2err # grep doesnotexist/test err # ok 3 - mktemp to unwritable directory prints filename ok 4 - check for a bug in the regex routines # failed 1 among 4 test(s) 1..4 Running this by hand, I get: gdt 51 /usr/pkgsrc/devel/scmgit-base/work/git-1.8.0.1/t ../test-mktemp foo/barXX MKTEMP.stdout 2 MKTEMP.stderr; ls -l MKTEMP* -rw-r--r-- 1 gdt wheel 121 Dec 18 15:14 MKTEMP.stderr -rw-r--r-- 1 gdt wheel0 Dec 18 15:14 MKTEMP.stdout gdt 52 /usr/pkgsrc/devel/scmgit-base/work/git-1.8.0.1/t cat MKTEMP.stderr fatal: Unable to create temporary file '/usr/pkgsrc/devel/scmgit-base/work/git-1.8.0.1/t/foo': No such file or directory It seems ENOENT is correct for the directory not existing. I think the test is complaining that the failed call to mkstemp modified the argument. Looking at: http://pubs.opengroup.org/onlinepubs/9699919799/functions/mkstemp.html I can't see that it requires anything in particular for the in/out paramater when there is an error. True. Perhaps something like this. -- 8 -- Subject: xmkstemp(): avoid showing truncated template more carefully Some implementations of xmkstemp() leaves the given in/out buffer truncated when they return with failure. 6cf6bb3 (Improve error messages when temporary file creation fails, 2010-12-18) attempted to show the real filename we tried to create (but failed), and if that is not available due to such truncation, to show the original template that was given by the caller. But it failed to take into account that the given template could have directory/ in front, in which case the truncation point may not be template[0] but somewhere else. Signed-off-by: Junio C Hamano gits...@pobox.com --- wrapper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git c/wrapper.c w/wrapper.c index 68739aa..a066e2e 100644 --- c/wrapper.c +++ w/wrapper.c @@ -229,7 +229,7 @@ int xmkstemp(char *template) int saved_errno = errno; const char *nonrelative_template; - if (!template[0]) + if (strlen(template) != strlen(origtemplate)) template = origtemplate; nonrelative_template = absolute_path(template); -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Feature suggestion: new 'git add -i' command to discard working copy changes
It's not infrequent that I want to discard changes I've made locally to
files ('git checkout file.txt') and find myself wishing that this was an
action available from the 'git add --interactive' UI; it feels like it
would fit in.
Does this sound like it would be useful? I might even be able to try my
hand at adding it if it seems like something that might be accepted
upstream and someone can point me at the places in the code to look.
Evan
signature.asc
Description: OpenPGP digital signature
Re: Feature suggestion: new 'git add -i' command to discard working copy changes
Evan Driscoll drisc...@cs.wisc.edu writes:
It's not infrequent that I want to discard changes I've made locally to
files ('git checkout file.txt') and find myself wishing that this was an
action available from the 'git add --interactive' UI; it feels like it
would fit in.
Hrm, not really. git add is about manipulating the index and its
promise is that it won't touch working tree files. And people rely
on that promise.
I can see how it would be useful to have a UI that is more
interactive than CLI that shows you a list of paths and lets you
pick from the list to run git checkout on, but I think git add
is a bad match to it.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature suggestion: new 'git add -i' command to discard working copy changes
On Tue, Dec 18, 2012 at 01:34:38PM -0800, Junio C Hamano wrote:
Evan Driscoll drisc...@cs.wisc.edu writes:
It's not infrequent that I want to discard changes I've made locally to
files ('git checkout file.txt') and find myself wishing that this was an
action available from the 'git add --interactive' UI; it feels like it
would fit in.
Hrm, not really. git add is about manipulating the index and its
promise is that it won't touch working tree files. And people rely
on that promise.
I can see how it would be useful to have a UI that is more
interactive than CLI that shows you a list of paths and lets you
pick from the list to run git checkout on, but I think git add
is a bad match to it.
Yeah. We already generalized git add -p to git checkout -p (and
reset -p, etc) to do hunk selection. Nobody bothered to generalize
the rest of git add --interactive, but logically having git checkout
--interactive (and git reset --interactive) would make sense.
I always assumed nobody really used the full add -i, but maybe it is
because I am such a command-line snob. Evan, are you after hunk
selection (like choosing patch from the interactive UI), or full path
selection?
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Port to QNX
This series ports Git to QNX. It differs from the previous version in that: * it's rebased on dm/port, so it narrows the scope of the lock variable in builtin/fetch-pack.c instead of fetch-pack.c and uses HAVE_STRINGS_H; and * it disables use of Pthreads, since fork(2) doesn't work once Pthreads are used. The first test suite failure occurs because getcwd(3) can return paths containing symbolic links. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] Make lock local to fetch_pack
From: Matt Kraai matt.kr...@amo.abbott.com
lock is only used by fetch_pack, so move it into that function.
Signed-off-by: Matt Kraai matt.kr...@amo.abbott.com
---
builtin/fetch-pack.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index e644398..9bc10b3 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -875,8 +875,6 @@ static int fetch_pack_config(const char *var, const char
*value, void *cb)
return git_default_config(var, value, cb);
}
-static struct lock_file lock;
-
static void fetch_pack_setup(void)
{
static int did_setup;
@@ -1069,6 +1067,7 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
ref_cpy = do_fetch_pack(fd, ref, sought, pack_lockfile);
if (args.depth 0) {
+ static struct lock_file lock;
struct cache_time mtime;
struct strbuf sb = STRBUF_INIT;
char *shallow = git_path(shallow);
--
1.8.0.2.8.gc42826d.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] Port to QNX
From: Matt Kraai matt.kr...@amo.abbott.com Signed-off-by: Matt Kraai matt.kr...@amo.abbott.com --- Makefile | 21 + git-compat-util.h | 6 +- 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 2c1f04f..a39dc83 100644 --- a/Makefile +++ b/Makefile @@ -80,6 +80,8 @@ all:: # # Define NO_MEMMEM if you don't have memmem. # +# Define NO_GETPAGESIZE if you don't have getpagesize. +# # Define NO_STRLCPY if you don't have strlcpy. # # Define NO_STRTOUMAX if you don't have both strtoimax and strtoumax in the @@ -1446,6 +1448,22 @@ else NO_CURL = YesPlease endif endif +ifeq ($(uname_S),QNX) + COMPAT_CFLAGS += -DSA_RESTART=0 + HAVE_STRINGS_H = YesPlease + NEEDS_SOCKET = YesPlease + NO_FNMATCH_CASEFOLD = YesPlease + NO_GETPAGESIZE = YesPlease + NO_ICONV = YesPlease + NO_MEMMEM = YesPlease + NO_MKDTEMP = YesPlease + NO_MKSTEMPS = YesPlease + NO_NSEC = YesPlease + NO_PTHREADS = YesPlease + NO_R_TO_GCC_LINKER = YesPlease + NO_STRCASESTR = YesPlease + NO_STRLCPY = YesPlease +endif -include config.mak.autogen -include config.mak @@ -1863,6 +1881,9 @@ ifdef NO_MEMMEM COMPAT_CFLAGS += -DNO_MEMMEM COMPAT_OBJS += compat/memmem.o endif +ifdef NO_GETPAGESIZE + COMPAT_CFLAGS += -DNO_GETPAGESIZE +endif ifdef INTERNAL_QSORT COMPAT_CFLAGS += -DINTERNAL_QSORT COMPAT_OBJS += compat/qsort.o diff --git a/git-compat-util.h b/git-compat-util.h index a88147b..610e6b7 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -75,7 +75,7 @@ # endif #elif !defined(__APPLE__) !defined(__FreeBSD__) !defined(__USLC__) \ !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__) \ - !defined(__TANDEM) + !defined(__TANDEM) !defined(__QNX__) #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */ #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */ #endif @@ -413,6 +413,10 @@ void *gitmemmem(const void *haystack, size_t haystacklen, const void *needle, size_t needlelen); #endif +#ifdef NO_GETPAGESIZE +#define getpagesize() sysconf(_SC_PAGESIZE) +#endif + #ifdef FREAD_READS_DIRECTORIES #ifdef fopen #undef fopen -- 1.8.0.2.8.gc42826d.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature suggestion: new 'git add -i' command to discard working copy changes
On 12/18/2012 03:59 PM, Jeff King wrote: I always assumed nobody really used the full add -i, but maybe it is because I am such a command-line snob. Evan, are you after hunk selection (like choosing patch from the interactive UI), or full path selection? Mostly the latter. I have two use cases of 'add -i'. The more common one is if I kind of want -p but don't want to do it for every file. (I guess in part this is my way of substituting for not knowing all the actions during -p as well.) But I sometimes use it if I want to stage several but not all files, as it's often faster for me to just choose the files I want from the interactive add's list than it is for me to type each of the files that I want (even with tab completion) -- I'm often working in a project with unfortunately-deep paths. What I want for my 'discard' action is more like the latter: I'd like a fast way to choose a file(s) to discard without having to type the path(s). Maybe I should just investigate tig or another front end; that might satisfy my desire. Evan signature.asc Description: OpenPGP digital signature
Re: Feature suggestion: new 'git add -i' command to discard working copy changes
On Tue, Dec 18, 2012 at 04:10:34PM -0600, Evan Driscoll wrote: I have two use cases of 'add -i'. The more common one is if I kind of want -p but don't want to do it for every file. (I guess in part this is my way of substituting for not knowing all the actions during -p as well.) But I sometimes use it if I want to stage several but not all files, as it's often faster for me to just choose the files I want from the interactive add's list than it is for me to type each of the files that I want (even with tab completion) -- I'm often working in a project with unfortunately-deep paths. What I want for my 'discard' action is more like the latter: I'd like a fast way to choose a file(s) to discard without having to type the path(s). That makes sense. Maybe I should just investigate tig or another front end; that might satisfy my desire. Yes, tig status will do this (use ! to revert changes to the path). Another trick is to stage what you want and throw away the rest, like: $ hack hack hack $ git add -i ;# now everything unstaged is garbage $ git checkout . $ test test test $ git commit Of course that implies that you can separate the wheat from the chaff at that exact moment. Sometimes you are just discarding known junk to make further work or add -i easier. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Prebuilt man pages on Google code
John Keeping j...@keeping.me.uk writes: While investigating Asciidoc's quoting in this thread [1], I noticed that my system man pages don't display Asciidoc double quoted text correctly. ... I can't see any configuration option that could cause this difference, so I assume it must be caused by some particular tool version on the machine used to generate these man pages. Yeah, Debian ships with a tad older one, and I've been using asciidoc 8.5.2 on my primary box. I'm experimenting a newer one from the latest tarball (asciidoc 8.6.8) and the result looks promising. If everything goes smoothly, I'll probably do another -rc before the final 1.8.1 release goes out with the new asciidoc, but no promises (yet). Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] Makefile: detect when PYTHON_PATH changes
chrisc...@tuxfamily.org wrote on Tue, 18 Dec 2012 20:00 +0100: When make is run, the python scripts are created from *.py files that are changed to use the python given by PYTHON_PATH. And PYTHON_PATH is set by default to /usr/bin/python on Linux. This is nice except when you run make another time setting a different PYTHON_PATH, because, as the python scripts have already been created, make finds nothing to do. The goal of this patch is to detect when the PYTHON_PATH changes and to create the python scripts again when this happens. To do that we use the same trick that is done to track other variables like prefix, flags, tcl/tk path and shell path. We update a GIT-PYTHON-VARS file with the PYTHON_PATH and check if it changed. Signed-off-by: Christian Couder chrisc...@tuxfamily.org I played around with this a bit in the context of git-p4; and it seems to work fine. It's interesting that the code in git_remote_helpers/Makefile does not work with python3, but that's not a problem to solve here. If you get interested in looking, that approach to installing always struck me as a bit odd. If it is the right way, though, maybe we should try to unify the approach to git-p4 and potential future .py scripts in git. Acked-by: Pete Wyckoff p...@padd.com Thanks for fixing this bug. -- Pete -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] Makefile: detect when PYTHON_PATH changes
Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] git-clean: Display more accurate delete messages
Thanks for the feedback.
My reading of the above is that lst after sorting is expected to
have something like:
a/
a/b/
a/b/to-be-removed
a/to-be-removed
and we first show a/, remember that prefix in dir, not show
a/b/ because it matches prefix, but still update the prefix to
a/b/, not show a/b/to-be-removed, and because a/to-be-removed
does not match the latest prefix, it is now shown. Am I confused???
No, it's a bug. The correct output should be just a/. Thanks for
pointing it out, I'm going to fix that.
@@ -150,43 +170,45 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
if (S_ISDIR(st.st_mode)) {
strbuf_addstr(directory, ent-name);
qname = quote_path_relative(directory.buf,
directory.len, buf, prefix);
- if (show_only (remove_directories ||
- (matches == MATCHED_EXACTLY))) {
- printf(_(Would remove %s\n), qname);
- } else if (remove_directories ||
-(matches == MATCHED_EXACTLY)) {
- if (!quiet)
- printf(_(Removing %s\n), qname);
- if (remove_dir_recursively(directory,
-rm_flags) != 0) {
- warning(_(failed to remove %s),
qname);
- errors++;
- }
- } else if (show_only) {
- printf(_(Would not remove %s\n), qname);
- } else {
- printf(_(Not removing %s\n), qname);
+ if (remove_directories || (matches ==
MATCHED_EXACTLY)) {
+ remove_dir_recursively_with_dryrun(directory,
rm_flags, dry_run,
+ dels, skips, errs, prefix);
}
Moving the above logic to a single helper function makes sense, but
can we name it a bit more concisely? Also this helper feels very
specific to clean---does it need to go to dir.[ch], I have to
wonder.
Would you have a better name in mind for the
remove_dir_recursively_with_dryrun() function? I'm kinda stuck.
My thinking was that since the private function remove_dir_recurse()
in dir.c already handles the recursive removing of files and
directories and checks for nested git directories, it would be better
to modify that function rather than implement something similar but
with dels, skips and errs lists in clean.c.
I am not very much pleased by the change to dir.[ch] in this patch,
though.
+static void append_dir_name(struct string_list *dels, struct string_list
*skips,
+ struct string_list *errs, char *name, const char * prefix, int
failed, int isdir)
+{
+ struct strbuf quoted = STRBUF_INIT;
+
+ quote_path_relative(name, strlen(name), quoted, prefix);
+ if (isdir quoted.buf[strlen(quoted.buf) -1] != '/')
+ strbuf_addch(quoted, '/');
+
+ if (skips)
+ string_list_append(skips, quoted.buf);
+ else if (!failed dels)
+ string_list_append(dels, quoted.buf);
+ else if (errs)
+ string_list_append(errs, quoted.buf);
+}
The three lists dels/skips/errs are mostly mutually exclusive (the
caller knows which one to throw the element in) except that failed
controls which one between dels or errs is used.
That's an ugly interface, I have to say. I think the quote-path
part should become a separate helper function to be used by the
callers of this function, and the callers should stuff the path to
the list they want to put the element in. That will eliminate the
need for this ugliness.
Will get rid of append_dir_name() and reimplement things the way you
suggested above.
Cheers,
Zoltan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On Wed, Dec 12, 2012 at 7:43 AM, Eric S. Raymond e...@thyrsus.com wrote: Patrick Donnelly batr...@batbytes.com: How would another language (e.g. Python) mitigate this? The way you mitigate this sort of problem is to have a good set of high-level bindings for standard services (like socket I/O) built in your extension language and using its abstractions, so you don't get a proliferation of low-level semi-custom APIs for doing the same stuff. I have elsewhere referred to this as the harsh lesson of Perl, which I do not love but which was the first scripting language to get this right. There is a reason Tcl and a couple of earlier designs like csh that we would now call scripting languages were displaced by Python and Perl; this is it. Okay, I understand what you were trying to say earlier. I'm not going to say Lua is a silver bullet for all embedded language needs. If you seriously need an exotic suite of libraries built into the language, then Lua is not really going to work well for you. In reality though, many projects that require an extension language do not need all the system programming facilities thrown in. In fact, many don't want them due to bloat or security considerations. So, you take on a hyperopic viewpoint by ruling out Lua simply because it lacks a suite of system libraries. With Jeff's response: As for interacting with the outside world, I was specifically thinking of stuff like git-send-email (currently in perl) and git-imap-send (written in C). They need to open network sockets and speak standard protocols. I suspect Lua would need a module or custom bindings to do the former at all, and certainly the code would be much simpler if we re-used standard modules for speaking SMTP and IMAP (which of course increases our dependencies again...). I would think this can perhaps be exported into another script Lua could exec as needed. Or luasocket may be sufficient. These dependencies would need to be examined in detail. I wouldn't recommend selecting a language because of one odd network protocol dependency satisfied by an obscure built-in library (I realize Jeff's example was exactly that, an example). On Wed, Dec 12, 2012 at 7:43 AM, Eric S. Raymond e...@thyrsus.com wrote: I don't see how these languages are more appropriate based on your concerns. Your previous exchange with Jeff King indicates that you don't understand glue scripting very well. Your puzzlement here just confirms that. Trust both of us on this, it's important. And reread my previous three paragraphs. What I didn't understand coming into this thread was Git's ecosystem. I understand embedded scripting languages very well and have been working with Lua for years. What does puzzle me is your dismissal of Lua because it doesn't have the library suite Python does. Lua is not a system programming language and I could argue Python is not really an embedded language. I came here to try to stimulate discussion about what Git actually needs/wants from a higher level language. If a small embedded language would fit well, the Lua should be a candidate for consideration. -- - Patrick Donnelly -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] git-clean: Display more accurate delete messages
Zoltan Klinger zoltan.klin...@gmail.com writes: Thanks for the feedback. My reading of the above is that lst after sorting is expected to have something like: a/ a/b/ a/b/to-be-removed a/to-be-removed and we first show a/, remember that prefix in dir, not show a/b/ because it matches prefix, but still update the prefix to a/b/, not show a/b/to-be-removed, and because a/to-be-removed does not match the latest prefix, it is now shown. Am I confused??? No, it's a bug. The correct output should be just a/. Thanks for pointing it out, I'm going to fix that. I am not sure if the approach taken by the patch is an effective design to achieve what you are trying to do. Imagine the code is told to clean (or clean a) and is currentlly looking at a/b directory. If it cannot remove some paths under that directory, you know that you cannot abbreviate the result to removed a/b and have to report a/b/paths you managed to remove at that point. On the other hand, if you removed everything in that directory, you know you have only two possible outcomes regarding that directory in the final output: (1) You would say removed a/b if you failed to remove paths that are neighbours to that directory (e.g. a/to-be-removed may not go away for some reason), because you will also list removed a/other path next to it, and report that you couldn't remove a/to-be-removed. You will not report anything about a/b/to-be-removed in such a case; or (2) You would not even say removed a/b if you will successfully remove all other paths under a/. So in either case, if you managed to remove everything in a/b, I do not see any reason to keep the list of successfully removed paths annd report them upwards. They will never be used by the caller that is looking at a/, or its caller that is looking at the root level, will they? On the other hand, if you failed to remove some paths under a/b, before recursion leaves that directory, you know which paths to be reported as successful or failure, which means you can start producing output without waiting until the traversal touches the entire tree. That can be a huge latency win, which matters a lot in a large project. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t3600: Avoid cp -a which is a GNUism
With d4a7ffa (tests: cp -a is a GNUism, 2012-10-08), we got rid of most of them, but a topic that was still in flight was missed. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t3600-rm.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 97254e8..324924e 100755 --- a/t/t3600-rm.sh +++ b/t/t3600-rm.sh @@ -457,7 +457,7 @@ test_expect_success 'rm of a conflicted populated submodule with a .git director git submodule update (cd submod rm .git - cp -a ../.git/modules/sub .git + cp -R ../.git/modules/sub .git GIT_WORK_TREE=. git config --unset core.worktree ) test_must_fail git merge conflict2 @@ -491,7 +491,7 @@ test_expect_success 'rm of a populated submodule with a .git directory fails eve git submodule update (cd submod rm .git - cp -a ../.git/modules/sub .git + cp -R ../.git/modules/sub .git GIT_WORK_TREE=. git config --unset core.worktree ) test_must_fail git rm submod @@ -589,7 +589,7 @@ test_expect_success 'rm of a populated nested submodule with a nested .git direc git submodule update --recursive (cd submod/subsubmod rm .git - cp -a ../../.git/modules/sub/modules/sub .git + cp -R ../../.git/modules/sub/modules/sub .git GIT_WORK_TREE=. git config --unset core.worktree ) test_must_fail git rm submod -- 1.8.1.rc2.196.g90926c8 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t4014: fix arguments to grep
These expect-failure tests were not looking for the right string in the patch file. For example: grep ^ *S. E. Cipient scipi...@example.com\$ patch5 was looking for ^ *S. in three files: E. Cipient scipi...@example.com$ patch5 With some implementations of grep, the lack of file E. was reported as an error, leading to the expected failure of the test. With other implementations of grep, the pattern ^ *S. matched what was in patch5, without missing files diagnosed as an error, which lead to these tests to unexpectedly pass. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t4014-format-patch.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 16a4ca1..90fd598 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -155,7 +155,7 @@ test_expect_failure 'additional command line cc (rfc822)' ' git config --replace-all format.headers Cc: R E Cipient rcipi...@example.com git format-patch --cc=S. E. Cipient scipi...@example.com --stdout master..side | sed -e /^\$/q patch5 grep ^Cc: R E Cipient rcipi...@example.com,\$ patch5 - grep ^ *S. E. Cipient scipi...@example.com\$ patch5 + grep ^ *\S. E. Cipient\ scipi...@example.com\$ patch5 ' test_expect_success 'command line headers' ' @@ -183,7 +183,7 @@ test_expect_success 'command line To: header (ascii)' ' test_expect_failure 'command line To: header (rfc822)' ' git format-patch --to=R. E. Cipient rcipi...@example.com --stdout master..side | sed -e /^\$/q patch8 - grep ^To: R. E. Cipient rcipi...@example.com\$ patch8 + grep ^To: \R. E. Cipient\ rcipi...@example.com\$ patch8 ' test_expect_failure 'command line To: header (rfc2047)' ' @@ -203,7 +203,7 @@ test_expect_failure 'configuration To: header (rfc822)' ' git config format.to R. E. Cipient rcipi...@example.com git format-patch --stdout master..side | sed -e /^\$/q patch9 - grep ^To: R. E. Cipient rcipi...@example.com\$ patch9 + grep ^To: \R. E. Cipient\ rcipi...@example.com\$ patch9 ' test_expect_failure 'configuration To: header (rfc2047)' ' -- 1.8.1.rc2.196.g90926c8 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t9020: use configured Python to run test helper
The test helper svnrdump_sim.py is used as svnrdump during the
execution of this test, but the arrangement had a few undesirable
things:
- it relied on symbolic links;
- unportable export VAR=VAL was used;
- GIT_BUILD_DIR variable was not quoted correctly;
- it assumed that the Python interpreter is in /usr/bin/ and
called python (i.e. not python2.7 etc.)
Rework this by writing a small shell script that spawns the right
Python interpreter, using the right quoting.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* The analysis above counts more bugs than the number of lines that
are deleted in this section of the code...
t/t9020-remote-svn.sh | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/t/t9020-remote-svn.sh b/t/t9020-remote-svn.sh
index 4f2dfe0..d7be66a 100755
--- a/t/t9020-remote-svn.sh
+++ b/t/t9020-remote-svn.sh
@@ -12,9 +12,13 @@ then
test_done
fi
-# We override svnrdump by placing a symlink to the svnrdump-emulator in .
-export PATH=$HOME:$PATH
-ln -sf $GIT_BUILD_DIR/contrib/svn-fe/svnrdump_sim.py $HOME/svnrdump
+# Override svnrdump with our simulator
+PATH=$HOME:$PATH
+export PATH PYTHON_PATH GIT_BUILD_DIR
+
+write_script $HOME/svnrdump \EOF
+exec $PYTHON_PATH $GIT_BUILD_DIR/contrib/svn-fe/svnrdump_sim.py $@
+EOF
init_git () {
rm -fr .git
--
1.8.1.rc2.196.g90926c8
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t9502: do not assume GNU tar
The check_snapshot function inspects and makes sure that not cruft
outside the repository hierarchy is added to the tar archive, by
insisting that the output from tar tf on the resulting archive
does not contain anything that does not begin with $prefix/.
There are two issues with this implementation:
- Traditional tar implemenations that do not understand
pax_global_header will write it out as if it is a plain file at
the top-level;
- Some implementations of tar does not add trailing slash when
showing a directory entry (i.e. the output line for the entire
archive will show $prefix, not $prefix/).
Fix them so that what we want to validate can be tested with
traditional tar implementations.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t9502-gitweb-standalone-parse-output.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9502-gitweb-standalone-parse-output.sh
b/t/t9502-gitweb-standalone-parse-output.sh
index 731e64c..c662298 100755
--- a/t/t9502-gitweb-standalone-parse-output.sh
+++ b/t/t9502-gitweb-standalone-parse-output.sh
@@ -40,7 +40,7 @@ check_snapshot () {
echo basename=$basename
grep filename=.*$basename.tar gitweb.headers /dev/null 21
$TAR tf gitweb.body file_list
- ! grep -v ^$prefix/ file_list
+ ! grep -v -e ^$prefix$ -e ^$prefix/ -e ^pax_global_header$
file_list
}
test_expect_success setup '
--
1.8.1.rc2.196.g90926c8
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] tests: optionally fail passed todo immediately
Add --fail-passed-todo option to stop the test immediately when a
test that is expected to fail succeeds. After seeing the test stop,
the developer can go to the trash directory and inspect why it failed
to fail as expected.
I usually just insert exit after such test with an editor, but
an option like this might be easier to use. I dunno.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* Stopping immediately after a test that is failing (and expected
to fail) and then going to the trash directory to inspect the
status of the sandbox are the first two steps I often end up
doing while fixing a bug. It may make sense to add an option to
cause the test to stop at a failure of test_expect_failure, but
that is a separate topic.
t/test-lib.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..7b7cce6 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -176,6 +176,8 @@ do
debug=t; shift ;;
-i|--i|--im|--imm|--imme|--immed|--immedi|--immedia|--immediat|--immediate)
immediate=t; shift ;;
+ --fail-passed-todo)
+ fail_passed_todo=t; shift ;;
-l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
GIT_TEST_LONG=t; export GIT_TEST_LONG; shift ;;
-h|--h|--he|--hel|--help)
@@ -307,6 +309,7 @@ test_failure_ () {
test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
say_color ok $test_count - $@ # TODO known breakage
+ test $fail_passed_todo = || { GIT_EXIT_OK=t; exit 1; }
}
test_known_broken_failure_ () {
--
1.8.1.rc2.196.g90926c8
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ATMCard Maestro FREE LOTTO
ATMCard Maestro FREE LOTTO You just won £500,000. For claim send your name, address, email Phone No. to Email: atmcardremittanc...@qatar.io for claims. TCs Apply -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t0200: locale may not exist
On systems without locale installed, t0200-gettext-basic.sh leaked
error messages when checking if some test locales are available.
Hide them, as they are not very useful.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/lib-gettext.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/lib-gettext.sh b/t/lib-gettext.sh
index 0f76f6c..ae8883a 100644
--- a/t/lib-gettext.sh
+++ b/t/lib-gettext.sh
@@ -14,12 +14,14 @@ export GIT_TEXTDOMAINDIR GIT_PO_PATH
if test_have_prereq GETTEXT ! test_have_prereq GETTEXT_POISON
then
# is_IS.UTF-8 on Solaris and FreeBSD, is_IS.utf8 on Debian
- is_IS_locale=$(locale -a | sed -n '/^is_IS\.[uU][tT][fF]-*8$/{
+ is_IS_locale=$(locale -a 2/dev/null |
+ sed -n '/^is_IS\.[uU][tT][fF]-*8$/{
p
q
}')
# is_IS.ISO8859-1 on Solaris and FreeBSD, is_IS.iso88591 on Debian
- is_IS_iso_locale=$(locale -a | sed -n '/^is_IS\.[iI][sS][oO]8859-*1$/{
+ is_IS_iso_locale=$(locale -a 2/dev/null |
+ sed -n '/^is_IS\.[iI][sS][oO]8859-*1$/{
p
q
}')
--
1.8.1.rc2.196.g654d69e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
Am 12/18/2012 17:24, schrieb Jeff King: I am not really interested in pushing this forward myself, but I worked up this toy that somebody might find interesting (you can git replace HEAD~20 to get dumped in an editor). It should probably handle trees, and it would probably make sense to do per-object-type sanity checks (e.g., call verify_tag on tags). I know it's just a throw-away patch, but I would discourage to go this route without also adding all the sanity checks. Otherwise, it will have just created a porcelain command that can generate a commit object with any content you want! -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
