Bug? ignored files overwritten by checkout
git init git commit --allow-empty -m init git checkout -b test echo foo foo git add foo git commit -am 'add foo' git checkout master echo 'Important data' foo #[1] echo foo .gitignore git checkout test If I tried a `git checkout test` after [1], I would get the error message error: The following untracked working tree files would be overwritten by checkout: foo But after adding foo to .gitignore, I am able to checkout to branch test without warning. Of course this overwrites foo to the version in test. I tested this in version 1.8.3.4 and 1.7.10.4. -- 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: Git bug. make [all] does not use USE_LIBPCRE when configure --with-libpcre was previously run
On Wed, Aug 14, 2013 at 09:39:10AM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: This does not have anything to do with C, but is a breakage in our autoconf script. I've meant C-programmers does understand autoconf, too. But I do not :(. It appears that anything that is meant to be appended at end via $config_appended_defs mechanism is missing from the end result. In fact, symbols whose explicit substitution the above patch removes, e.g. CC_LD_DYNPATH, TCLTK_PATH, NEEDS_SSL_WITH_CRYPTO, etc. are all missing. Wait, I spoke too soon. $ rm -f configure config.status make configure ./configure --with-libpcre grep USE_LIBPCRE config.mak.autogen USE_LIBPCRE=YesPlease no longer reproduces for me (even though I _thought_ I tried and saw the breakage). Hmm. Oh! That have worked for me, too. No more error occured. Thank you! -- Alexey Shumkin -- 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: [RFC PATCH] repack: rewrite the shell script in C.
On 08/15/2013 01:25 AM, Martin Fick wrote: On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy wrote: Antoine Pelisse apeli...@gmail.com writes: On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller stefanbel...@googlemail.com wrote: builtin/repack.c | 410 + contrib/examples/git-repack.sh | 194 +++ git-repack.sh | 194 --- I'm still not sure I understand the trade-off here. Most of what git-repack does is compute some file paths, (re)move those files and call git-pack-objects, and potentially git-prune-packed and git-update-server-info. Maybe I'm wrong, but I have the feeling that the correct tool for that is Shell, rather than C (and I think the code looks less intuitive in C for that matter). There's a real problem with git-repack being shell (I already mentionned it in the previous thread about the rewrite): it creates dependencies on a few external binaries, and a restricted server may not have them. I have this issue on a fusionforge server where Git repos are accessed in a chroot with very few commands available: everything went OK until the first project grew enough to require a git gc --auto, and then it stopped accepting pushes for that project. I tracked down the origin of the problem and the sysadmins disabled auto-gc, but that's not a very satisfactory solution. C is rather painfull to write, but as a sysadmin, drop the binary on your server and it just works. That's really important. AFAIK, git-repack is the only remaining shell part on the server, and it's rather small. I'd really love to see it disapear. I didn't review the proposed C version, but how was it planning on removing the dependencies on these binaries? Was it planning to reimplement mv, cp, find? These small programms (at least mv and cp) are just convenient interfaces for system calls from within the shell. You can use these system calls to achieve a similar results compared to the commandline option. http://linux.die.net/man/2/rename http://linux.die.net/man/2/unlink Were there other binaries that were problematic that you were thinking of? From what I can tell it also uses test, mkdir, sed, chmod and naturally sh, that is 8 dependencies. mkdir, test, chmod are also easily done via system calls. The system calls are usually capsulated by the libc to have an easy C interface. (A standard C function call) sed and find are tricky indeed, but you can get around it with a few lines of C (maybe 10?) for each occurrence. We don't need the full power of sed and find, but rather only the exact specific matching regexp. If those can't be depended upon for existing, perhaps git should just consider bundling busy-box or some other limited shell utils, or yikes!, even its own reimplementation of these instead of implementing these independently inside other git programs? The C version as of now has twice the lines of code than the shell version. And I am pretty sure I did some rookie mistakes, so the code can be down-sized by better use of already existing functions. So I guess the final version will have less lines than in the proposed patch as of now. signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH] repack: rewrite the shell script in C.
On 08/15/2013 12:59 AM, Matthieu Moy wrote: Junio C Hamano gits...@pobox.com writes: Stefan Beller stefanbel...@googlemail.com writes: I asked for a todo wish list a few weeks ago, but got no real answer, but rather: Pick your choice and try to come up with good patches. Hmph, I hope that wasn't me. There are some good ones here; http://git-blame.blogspot.com/search?q=leftover See also: https://git.wiki.kernel.org/index.php/SmallProjectsIdeas Thanks, I bookmarked both of those pages. The wiki already lists Rewrite git repack in C at the very end, so my sense where to start wasn't way off. ;) signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH] repack: rewrite the shell script in C.
On 08/14/2013 07:04 PM, Junio C Hamano wrote: Stefan Beller stefanbel...@googlemail.com writes: diff --git a/builtin/repack.c b/builtin/repack.c new file mode 100644 index 000..d39c34e --- /dev/null +++ b/builtin/repack.c @@ -0,0 +1,410 @@ +/* + * The shell version was written by Linus Torvalds (2005) and many others. + * This is a translation into C by Stefan Beller (2013) + */ + +#include builtin.h +#include cache.h +#include dir.h +#include parse-options.h +#include run-command.h +#include sigchain.h +#include strbuf.h +#include string-list.h + +#include sys/types.h +#include unistd.h +#include stdio.h +#include dirent.h If you need these system-includes here, it means that our own platform-portability layer git-compat-util.h is broken. On various systems, often some system header files are missing, need a few feature macros to be defined before including, and/or need to be included in certain order, etc., and git-compat-util.h is meant to hide all such details from the programmers. I do not think the above four needs to be included in *.c, as long as you include either builtin.h or cache.h, both of which includes the compat-util header. Thanks. It works without these includes as well. I think I got those includes before I realized there is so much infrastructure already available and I forgot to remove these includes once I added the others. signature.asc Description: OpenPGP digital signature
Re: Proper URI for svn clone on a network share (Win32)
On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote: On 2013-08-14 12:49, Tim Chase wrote: If it makes any difference, this is within a cmd.exe shell (with $PATH set appropriately so git is being found). Just a follow-up, I tried it within the bashish shell included in the git install and got the same error regarding /tmp/report.tmp. It seems that report.tmp is something that SVN creates and for some reason the svn on your system is trying to create it in a Unix style temporary directory. What happens if you export TMPDIR=C:/Windows/Temp before running git-svn? -- 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: New special handing of '@' character broke my use case
On 08/14/2013 09:57 PM, Junio C Hamano wrote: Johannes Sixt j...@kdbg.org writes: [SNIP] Stefano's use-case, where @/foo is turned into HEAD/foo, indicates a bug. In my opinion, the topic, which touches a central part of ref handling, was a bit hurried (and this report is a symptom of it), and I wouldn't mind seeing it reverted. Thanks; you said it much better than I did. I think the short-hand is not a bad idea by itself, but the execution may need to be redone a bit more carefully, and it is prudent to revert it from the upcoming release. Thanks both for taking care of this issue with the usual speed and clarity. Best regards, Stefano -- 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: Reproducible, corrupt packfile after fresh git-svn checkout message
Just as a catchup for everybody being interested: I finally wrote to the linux-mm newsgroup and Linus pointed out, that this might be a known bug yet not fixed in mainline. Unfortunately this doesn't seem to stand the test; but as far as Git is concerned, it appears that that they are willing to take actions. http://thread.gmane.org/gmane.linux.kernel/1541707/focus=105432 -- 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
Understanding Git Under The Hood: Trees
Hi, I'm currently trying to understand the inner workings of git better by writing a git clone in Python. I find it rather hard to understand how to efficiently use trees. What I understand is this: Trees are in essence blobs with a specific content. The content is a relation between other blobs names, types and modes. With these lines they can refer to other blobs and trees and thus make a tine filesystem. Now I constructed a system to read and write blobs and have an index file that potentially references to a top tree object, which represents the currently cached repository state. I can add and remove files from the index manually, by creating the blob of the file and working my way up adding or updating trees until I hit the one referenced in INDEX. My algorithm to automate it is really ugly, error prone and inefficient, though. I also have a hard time to find my way around in C files, so maybe some people here in the list could explain the algorithm in Git to me. suppose we have the following Index: INDEX - tree - tree a/ - blob b.txt - tree c/ - blob d.txt Now you want to stage a file with the following reference a/e/g.txt. One approach would be to walk top-down, splitting the path into its elements and looking for the corresponding trees, either retrieving an existing tree or creating a new one. Then finally create the blob g.txt and be done with it. This seems rather inefficient, though, because each created or updated tree means that all trees way back up need to be updated as well, once for every step in the loop. The other way is to go bottom-up, first creating the blob, then creating trees up to the project root folder. But then I don't see a way to find which tree elements already exist and need to be updated. So the only algorithm I can come up with is this: 1. walk down the tree with help of the path string to the tree that is closest to the file I want to store. On the way remember all the trees on the path from INDEX to the resulting file. (In the example above I'd like to get the hash of the a/ tree) 2. create the blob (in the example with the context of g.txt) 3. create the trees bottom-up until one step before the tree found in 1. (in the example create a e/ tree, containing the g.txt's blob) 4. Add the resulting tree from 3. to the one found in 1. and create the updated hash 5. Now with help of the list from 1. walk the existing trees bottom-up and update each one with the new hashes until INDEX is hit. 6. Update INDEX. Alltogether the idea of trees looked really simple and recursive which makes me quite unhappy with the algorithm I came up with. What is the algorithm to stage single files in Git itself? How Also: I thought to myself, why not just make a function that returns the relative path to the repository root folder and consider that string the file name, drop the idea of trees at all and add the information that is traditionally stored in tree objects directly in a commit object. Wouldn't that be much simpler and still accomplish the same? I think the idea of keeping information in separate small files instead of single big files was dropped at one point anyway, when pack-files were introduced. Cheers Erik -- 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: Proper URI for svn clone on a network share (Win32)
On 2013-08-15 09:00, John Keeping wrote: On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote: On 2013-08-14 12:49, Tim Chase wrote: If it makes any difference, this is within a cmd.exe shell (with $PATH set appropriately so git is being found). Just a follow-up, I tried it within the bashish shell included in the git install and got the same error regarding /tmp/report.tmp. It seems that report.tmp is something that SVN creates and for some reason the svn on your system is trying to create it in a Unix style temporary directory. What happens if you export TMPDIR=C:/Windows/Temp before running git-svn? Still getting the same results. I tried: 1) cmd.exe with my local temp dir: c:\temp TEMPDIR=%TEMP% c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 2) cmd.exe with the windows temp dir as you specify: c:\temp TEMPDIR=c:\windows\temp c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 3) git's bash.exe with inline variable definition: $ TEMPDIR=c:/Windows/Temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 4) git's bash.exe with exported variable: $ export TEMPDIR=c:/Windows/Temp $ git svn clone file:///x:/path/to/repo/trunk/utils/project1 All of them died with the complaint about /tmp/report.tmp Thanks for the suggestion though. At least we've determined one thing that *isn't* the issue ;-) -tkc -- 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: Proper URI for svn clone on a network share (Win32)
On Thu, Aug 15, 2013 at 06:12:29AM -0500, Tim Chase wrote: On 2013-08-15 09:00, John Keeping wrote: On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote: On 2013-08-14 12:49, Tim Chase wrote: If it makes any difference, this is within a cmd.exe shell (with $PATH set appropriately so git is being found). Just a follow-up, I tried it within the bashish shell included in the git install and got the same error regarding /tmp/report.tmp. It seems that report.tmp is something that SVN creates and for some reason the svn on your system is trying to create it in a Unix style temporary directory. What happens if you export TMPDIR=C:/Windows/Temp before running git-svn? Still getting the same results. I tried: 1) cmd.exe with my local temp dir: c:\temp TEMPDIR=%TEMP% This should be TMPDIR - note the missing 'E'! You may also need to export TMPDIR but I don't know how cmd.exe decides what environment variables to export to subprocesses. c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 2) cmd.exe with the windows temp dir as you specify: c:\temp TEMPDIR=c:\windows\temp c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 3) git's bash.exe with inline variable definition: $ TEMPDIR=c:/Windows/Temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 4) git's bash.exe with exported variable: $ export TEMPDIR=c:/Windows/Temp $ git svn clone file:///x:/path/to/repo/trunk/utils/project1 All of them died with the complaint about /tmp/report.tmp Thanks for the suggestion though. At least we've determined one thing that *isn't* the issue ;-) -- 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? ignored files overwritten by checkout
On Thu, Aug 15, 2013 at 06:33:11AM +, Damien Robert wrote: git init git commit --allow-empty -m init git checkout -b test echo foo foo git add foo git commit -am 'add foo' git checkout master echo 'Important data' foo #[1] echo foo .gitignore git checkout test If I tried a `git checkout test` after [1], I would get the error message error: The following untracked working tree files would be overwritten by checkout: foo But after adding foo to .gitignore, I am able to checkout to branch test without warning. Of course this overwrites foo to the version in test. This is by design. Marking a file in .gitignore tells git that the content is not precious and can be removed if need be. For most ignored files, this is what you want (e.g., you mark *.o as ignored because it is generated; you do not want to add it, and you can always make it again). The less common case is a file that is precious and needs to live inside your repository directory, but which you do not want to add (e.g., a config file that affects your project, but should not ever be committed). People have occasionally asked for a .gitignore-like mechanism to mark such files as precious but do not add. However, nobody has actually implemented anything. -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: Bug: commit -p breaks with -m
On Thu, Aug 15, 2013 at 12:43:39AM -0400, Matan Nassau wrote: With git 1.8.3.3, $ seq 5 data $ git add data $ git commit -mdata $ sed -i '2 d' data $ git commit -pmchange At the prompt, type e to edit the hunk. The editor doesn't start, but git records a commit. I found that builtin/commit.c sets the GIT_EDITOR env var to : when the user specifies the -m option. This was done in 406400ce4f69. Removing these two lines, if (!use_editor) setenv(GIT_EDITOR, :, 1); seems to fix the issue, but I'm not sure this won't break the prepare-commit-msg hook. I'd like to submit a patch: can I get a hint if this change would break commit hooks or anything else I'm not seeing? Yeah, that is definitely a bug. Just removing those lines would not be the right fix, though, because the point of them is to let the prepare-commit-msg hook know whether or not an editor is in use. Instead, I think you would want to limit the scope of where we have set GIT_EDITOR. I.e., drop those lines, and then add GIT_EDITOR=: to the environment that we pass to the hook via the run_hook function. Unfortunately, I think that will require some refactoring of the run_hook interface, which does not allow arbitrary environment parameters to be set. -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: Understanding Git Under The Hood: Trees
On 2013-08-15 12:29, Erik Bernoth wrote: Hi, I'm currently trying to understand the inner workings of git better by writing a git clone in Python. I find it rather hard to understand how to efficiently use trees. What I understand is this: Trees are in essence blobs with a specific content. The content is a relation between other blobs names, types and modes. With these lines they can refer to other blobs and trees and thus make a tine filesystem. Now I constructed a system to read and write blobs and have an index file that potentially references to a top tree object, which represents the currently cached repository state. I can add and remove files from the index manually, by creating the blob of the file and working my way up adding or updating trees until I hit the one referenced in INDEX. My algorithm to automate it is really ugly, error prone and inefficient, though. I also have a hard time to find my way around in C files, so maybe some people here in the list could explain the algorithm in Git to me. suppose we have the following Index: INDEX - tree - tree a/ - blob b.txt - tree c/ - blob d.txt Now you want to stage a file with the following reference a/e/g.txt. One approach would be to walk top-down, splitting the path into its elements and looking for the corresponding trees, either retrieving an existing tree or creating a new one. Then finally create the blob g.txt and be done with it. This seems rather inefficient, though, because each created or updated tree means that all trees way back up need to be updated as well, once for every step in the loop. The other way is to go bottom-up, first creating the blob, then creating trees up to the project root folder. But then I don't see a way to find which tree elements already exist and need to be updated. So the only algorithm I can come up with is this: 1. walk down the tree with help of the path string to the tree that is closest to the file I want to store. On the way remember all the trees on the path from INDEX to the resulting file. (In the example above I'd like to get the hash of the a/ tree) 2. create the blob (in the example with the context of g.txt) 3. create the trees bottom-up until one step before the tree found in 1. (in the example create a e/ tree, containing the g.txt's blob) 4. Add the resulting tree from 3. to the one found in 1. and create the updated hash 5. Now with help of the list from 1. walk the existing trees bottom-up and update each one with the new hashes until INDEX is hit. 6. Update INDEX. Alltogether the idea of trees looked really simple and recursive which makes me quite unhappy with the algorithm I came up with. What is the algorithm to stage single files in Git itself? You seem to believe that the in-memory representation of trees have to be the same as the on-disk one. That's simply not true. Git cheats outrageously with internal formats for pretty much everything in order to squeeze out more performance. You also seem to believe that a tree is more than one directory. That's not true either. So... Each tree that's updated can (and does) have an in-memory link to its parent directory. Whenever we update a directory and create a commit from it, we make sure to write them out from right to left (ie, children before parents), so that we're never in a state where a tree on disk can't find any of its content blobs in the same object storage. With that information in hand, I'm sure you can quite easily create an algorithm that turns out a bit prettier than what you have now. Also: I thought to myself, why not just make a function that returns the relative path to the repository root folder and consider that string the file name, drop the idea of trees at all and add the information that is traditionally stored in tree objects directly in a commit object. Because commit objects must have parents and things like that. Also, the idea of trees containing trees saves a *huge* amount of disk I/O and space when updating a project with many subdirectories. Wouldn't that be much simpler and still accomplish the same? Simpler; Yes. More efficient; No. The commit that changed the tree structure from flat to hierarchical dates back to April of 2005. It's commit number 25 in the history of git and solves one of the first real problems from live-testing git on the kernel repository, which was that tree-files got so huge when they had to be rewritten in their entirety that creating a new commit took several seconds. I think the idea of keeping information in separate small files instead of single big files was dropped at one point anyway, when pack-files were introduced. Not really. We strive hard to minimize disk I/O whenever we can. The packfiles actually reduce I/O, since it lets the kernel use the disk's builtin caches a lot better, and read-ahead works to our advantage. Btw, when I say minimize disk I/O, I really mean minimize user
[no subject]
Greetings to you my Dear Beloved, my name is Gina Rinehart, a great citizen of Australia,born in Perth, Western Australia,I have a mission for you worth ($200,000,000 000.)Tow Hundred Million Dollars which I intend to use for CHARITY.Please reply if interested with this email below. Email: georginahoperineh...@yahoo.com.au God Bless You. Mrs. Gina Rinehart. -- 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: Proper URI for svn clone on a network share (Win32)
On 2013-08-15 12:35, John Keeping wrote: Just a follow-up, I tried it within the bashish shell included in the git install and got the same error regarding /tmp/report.tmp. It seems that report.tmp is something that SVN creates and for some reason the svn on your system is trying to create it in a Unix style temporary directory. What happens if you export TMPDIR=C:/Windows/Temp before running git-svn? Still getting the same results. This should be TMPDIR - note the missing 'E'! I wish I could blame it on my doofus mistype, but I tried the same 4 operations as my previous email, using TMPDIR this time instead of TEMPDIR but got the same errors regarding /tmp/report.tmp. You may also need to export TMPDIR but I don't know how cmd.exe decides what environment variables to export to subprocesses. From my understanding/experimentation, cmd.exe acts as if all environment variables are exported all the time (i.e., there is no such thing as a local non-exported environment variable). Any further ideas to try? Thanks, -tkc -- 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: Reproducible, corrupt packfile after fresh git-svn checkout message
On Thu, Aug 15, 2013 at 2:32 AM, Ben Tebulin tebu...@googlemail.com wrote: Just as a catchup for everybody being interested: I finally wrote to the linux-mm newsgroup and Linus pointed out, that this might be a known bug yet not fixed in mainline. Unfortunately this doesn't seem to stand the test; but as far as Git is concerned, it appears that that they are willing to take actions. http://thread.gmane.org/gmane.linux.kernel/1541707/focus=105432 Thanks for following this up. -- 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: [RFC PATCH] repack: rewrite the shell script in C.
On Thursday, August 15, 2013 01:46:02 am Stefan Beller wrote: On 08/15/2013 01:25 AM, Martin Fick wrote: On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy wrote: Antoine Pelisse apeli...@gmail.com writes: On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller stefanbel...@googlemail.com wrote: builtin/repack.c | 410 + contrib/examples/git-repack.sh | 194 +++ git-repack.sh | 194 --- I'm still not sure I understand the trade-off here. Most of what git-repack does is compute some file paths, (re)move those files and call git-pack-objects, and potentially git-prune-packed and git-update-server-info. Maybe I'm wrong, but I have the feeling that the correct tool for that is Shell, rather than C (and I think the code looks less intuitive in C for that matter). There's a real problem with git-repack being shell (I already mentionned it in the previous thread about the rewrite): it creates dependencies on a few external binaries, and a restricted server may not have them. I have this issue on a fusionforge server where Git repos are accessed in a chroot with very few commands available: everything went OK until the first project grew enough to require a git gc --auto, and then it stopped accepting pushes for that project. I tracked down the origin of the problem and the sysadmins disabled auto-gc, but that's not a very satisfactory solution. C is rather painfull to write, but as a sysadmin, drop the binary on your server and it just works. That's really important. AFAIK, git-repack is the only remaining shell part on the server, and it's rather small. I'd really love to see it disapear. I didn't review the proposed C version, but how was it planning on removing the dependencies on these binaries? Was it planning to reimplement mv, cp, find? These small programms (at least mv and cp) are just convenient interfaces for system calls from within the shell. You can use these system calls to achieve a similar results compared to the commandline option. http://linux.die.net/man/2/rename http://linux.die.net/man/2/unlink Sure, but have you ever looked at the code to mv? It isn't pretty. ;( But in all that ugliness is decades worth of portability and corner cases. Also, mv is smart enough to copy when rename doesn't work (on some systems it doesn't). So C may sound more portable, but I am not sure it actually is. Now hopefully you won't need all of that, but I think that some of the design decision that went into git-repack did consider some of the more eccentric filesystems out there, -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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
Git access to Bzr repository fails for enwc
I've had good success recently with the git-bzr bridge, but the following still fails. This is on Debian with the git from unstable. Stefan % git clone bzr::bzr://bzr.savannah.nongnu.org/enwc/trunk Cloning into 'trunk'... Note: checking out 'e8fa1a2339729de62d0ad85e44b8993bf25b7996'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name error: unable to find b8c01407a3e9f69bdfa5b8ab195a2680caa5d3d5 error: unable to read sha1 file of COPYING (b8c01407a3e9f69bdfa5b8ab195a2680caa5d3d5) error: unable to find 4cdecd08dd6cc2f196949b60b6daf6d4456840a1 error: unable to read sha1 file of Makefile (4cdecd08dd6cc2f196949b60b6daf6d4456840a1) error: unable to find 81a14bd73e6c11ae0fb78071c93dce5c80a7e8a3 error: unable to read sha1 file of doc/connman.txt (81a14bd73e6c11ae0fb78071c93dce5c80a7e8a3) error: unable to find 15a6ad4dc0c9d48bebc20cb267ae47ad66d1ccf9 error: unable to read sha1 file of doc/enwc.texi (15a6ad4dc0c9d48bebc20cb267ae47ad66d1ccf9) error: unable to find c34c35a3a641358b95d3c4fd34b6ac2f5268b291 error: unable to read sha1 file of doc/fdl.texi (c34c35a3a641358b95d3c4fd34b6ac2f5268b291) error: unable to find 1920a86cbab296d01763f975d004f4338f51269b error: unable to read sha1 file of doc/nm-dbus.txt (1920a86cbab296d01763f975d004f4338f51269b) error: unable to find 7fd9428f0bc56e0e5c132cdfc03f35a07a516160 error: unable to read sha1 file of doc/settings.txt (7fd9428f0bc56e0e5c132cdfc03f35a07a516160) error: unable to find b2f5df78313374b87d97996d72053cc5fd875fba error: unable to read sha1 file of doc/version.texi (b2f5df78313374b87d97996d72053cc5fd875fba) error: unable to find 26c50c2600457c8ae4c492496b6217d79a96da75 error: unable to read sha1 file of lisp/Makefile (26c50c2600457c8ae4c492496b6217d79a96da75) error: unable to find 3c3170e4fc62b68f05d4017e4bb88632527317e1 error: unable to read sha1 file of lisp/enwc-cm.el (3c3170e4fc62b68f05d4017e4bb88632527317e1) error: unable to find e7e64d3bd3af3bdbebfcf077c52363b2eec06b0d error: unable to read sha1 file of lisp/enwc-nm.el (e7e64d3bd3af3bdbebfcf077c52363b2eec06b0d) error: unable to find f4401ec703b96b34edee06b5f015f8a6d73e9a55 error: unable to read sha1 file of lisp/enwc-setup.el (f4401ec703b96b34edee06b5f015f8a6d73e9a55) error: unable to find fb83160d3352633558786e73e2d8c6f466e1967f error: unable to read sha1 file of lisp/enwc-wicd.el (fb83160d3352633558786e73e2d8c6f466e1967f) error: unable to find f765245c1cfb93c645be53dc56772cabc90cdb24 error: unable to read sha1 file of lisp/enwc.el (f765245c1cfb93c645be53dc56772cabc90cdb24) % git --version git version 1.7.10.4 % -- 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: [RFC PATCH] repack: rewrite the shell script in C.
Martin Fick mf...@codeaurora.org writes: On Wednesday, August 14, 2013 04:53:36 pm Junio C Hamano wrote: Martin Fick mf...@codeaurora.org writes: One suggestion would be to change the repack code to create pack filenames based on the sha1 of the contents of the pack file instead of on the sha1 of the objects in the packfile. ... I am not 100% sure if the change in naming convention I propose wouldn't cause any problems? But if others agree it is a good idea, perhaps it is something a beginner could do? I would not be surprised if that change breaks some other people's reimplementation. I know we do not validate the pack name with the hash of the contents in the current code, but at the same time I do remember that was one of the planned things to be done while I and Linus were working on the original pack design, which was the last task we did together before he retired from the maintainership of this project. Perhaps a config option? One that becomes standard for git 2.0? Anything new is too late for Git 2.0, as we do not want to hold the switching of push.default to simple too long. End of this year might be a bit too soon, but I want 2.0 to happen by the next spring. You can discuss, design the new naming and necessary transition plan for existing repositories, reach a concensus and declare the name switch in the future, and then schedule that for the next major version bump after 2.0 happens. -- 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: commit -p breaks with -m
Jeff King p...@peff.net writes: Unfortunately, I think that will require some refactoring of the run_hook interface, which does not allow arbitrary environment parameters to be set. Heh, I said that long time ago, e.g. $gmane/212284 ;-) This might turn out to be a good starting point, even though I didn't read it again before sending this message. http://thread.gmane.org/gmane.comp.version-control.git/192669/focus=192806 -- 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: Understanding Git Under The Hood: Trees
Andreas Ericsson a...@op5.se writes: You seem to believe that the in-memory representation of trees have to be the same as the on-disk one. That's simply not true. Git cheats outrageously with internal formats for pretty much everything in order to squeeze out more performance. While the last statement applies to other parts of the system, it is not true for the in-core index design. We always had a flat index, and it is not cheating at all. The original tree was also a flat representation of everything under the sun, and hierarchical tree objects came much later. -- 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: commit -p breaks with -m
On Thu, Aug 15, 2013 at 10:28:16AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Unfortunately, I think that will require some refactoring of the run_hook interface, which does not allow arbitrary environment parameters to be set. Heh, I said that long time ago, e.g. $gmane/212284 ;-) This might turn out to be a good starting point, even though I didn't read it again before sending this message. http://thread.gmane.org/gmane.comp.version-control.git/192669/focus=192806 Looking at both of those messages, I agree completely. I even started to sketch out the refactoring when I sent the previous message, and it looked a lot like the patch you sent. -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: git stash takes excessively long when many untracked files present
Junio C Hamano gits...@pobox.com writes:
In any case, this is a regression introduced in 'master' since the
last release, and the attempted fix was for an issue that has long
been with us, so I'll revert a7365313 (git stash: avoid data loss
when git stash save kills a directory, 2013-06-28) soon. For
today's -rc3, I'm already deep into the integration cycle, so it is
too late to do the revert it and then redo everything.
Then we will plan to re-apply the patch once ls-files --killed
gets fixed not to waste too much cycles needlessly, after the coming
release.
I've already reverted the problematic patch to git stash and it
will not be part of the upcoming release.
Here is a quick attempt to see if we can do better in ls-files -k.
We have an existing test t3010.3 that tries all the combinations of
directory turning into a regular file, symlink, etc. and vice versa,
and it seems to pass. The test has a directory path6 in the working
tree without any paths in it in the index, and the added bypass code
seems to correctly trigger and prevents us from digging into that
directory, so this patch may be sufficient to improve ls-files -k.
By the way, regarding the reverted commit, I do not think it is
enough to ask ls-files -k to see if the state recorded in the
current index is sufficient. Imagine your HEAD records path as a
file and then you did this:
$ git reset --hard ;# path is now a regular file
$ mv path path.bak
$ mkdir path
$ mv path.bak path/file
$ git add -A ;# path/file in the index and in the working tree
$ path/cruft ;# path/cruft in the working tree
Then call save_stash without saving untracked. The resulting
stash will save the contents of path/file but path/cruft is not
recorded anywhere, and then we would need to bring the state in the
working tree and the index back to the state recorded in HEAD, hence
path needs to be turned back to a directory.
But ls-files -k is asked to check with the index, which has the
path as a directory, so this case is missed.
So instead of
test -n $(git ls-files --killed | head -n 1)
in Pasky's patch, which probably is a right thing to do if you are
running git stash save --keep-index, you would need something like
this if you are not running with --keep-index:
test -n $(
GIT_INDEX_FILE=tmp_index
export GIT_INDEX_FILE
git read-tree HEAD
git ls-files -k
)
in order to make sure that the result of going back to the state in
the HEAD will not clobber leftover path/cruft.
builtin/ls-files.c | 2 ++
dir.c | 9 +
dir.h | 3 ++-
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 5cf3e31..8500446 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -219,6 +219,8 @@ static void show_files(struct dir_struct *dir)
/* For cached/deleted files we don't need to even do the readdir */
if (show_others || show_killed) {
+ if (!show_others)
+ dir-flags |= DIR_COLLECT_KILLED_ONLY;
fill_directory(dir, pathspec);
if (show_others)
show_other_files(dir);
diff --git a/dir.c b/dir.c
index 910bfcd..02939e2 100644
--- a/dir.c
+++ b/dir.c
@@ -1183,6 +1183,15 @@ static enum path_treatment treat_one_path(struct
dir_struct *dir,
cache_name_exists(path-buf, path-len, ignore_case))
return path_none;
+ /*
+* A directory can only contain killed files if the index
+* has a path that wants it to be a non-directory.
+*/
+ if ((dir-flags DIR_COLLECT_KILLED_ONLY)
+ (dtype == DT_DIR)
+ !cache_name_exists(path-buf, path-len, ignore_case))
+ return path_none;
+
exclude = is_excluded(dir, path-buf, dtype);
/*
diff --git a/dir.h b/dir.h
index 3d6b80c..4677b86 100644
--- a/dir.h
+++ b/dir.h
@@ -80,7 +80,8 @@ struct dir_struct {
DIR_HIDE_EMPTY_DIRECTORIES = 12,
DIR_NO_GITLINKS = 13,
DIR_COLLECT_IGNORED = 14,
- DIR_SHOW_IGNORED_TOO = 15
+ DIR_SHOW_IGNORED_TOO = 15,
+ DIR_COLLECT_KILLED_ONLY = 16
} flags;
struct dir_entry **entries;
struct dir_entry **ignored;
--
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: git stash takes excessively long when many untracked files present
On Thu, Aug 15, 2013 at 10:52:39AM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: In any case, this is a regression introduced in 'master' since the last release, and the attempted fix was for an issue that has long been with us, so I'll revert a7365313 (git stash: avoid data loss when git stash save kills a directory, 2013-06-28) soon. For today's -rc3, I'm already deep into the integration cycle, so it is too late to do the revert it and then redo everything. Then we will plan to re-apply the patch once ls-files --killed gets fixed not to waste too much cycles needlessly, after the coming release. I've already reverted the problematic patch to git stash and it will not be part of the upcoming release. Thanks! Here is a quick attempt to see if we can do better in ls-files -k. We have an existing test t3010.3 that tries all the combinations of directory turning into a regular file, symlink, etc. and vice versa, and it seems to pass. The test has a directory path6 in the working tree without any paths in it in the index, and the added bypass code seems to correctly trigger and prevents us from digging into that directory, so this patch may be sufficient to improve ls-files -k. By the way, regarding the reverted commit, I do not think it is enough to ask ls-files -k to see if the state recorded in the current index is sufficient. Imagine your HEAD records path as a file and then you did this: $ git reset --hard ;# path is now a regular file $ mv path path.bak $ mkdir path $ mv path.bak path/file $ git add -A ;# path/file in the index and in the working tree $ path/cruft ;# path/cruft in the working tree Then call save_stash without saving untracked. The resulting stash will save the contents of path/file but path/cruft is not recorded anywhere, and then we would need to bring the state in the working tree and the index back to the state recorded in HEAD, hence path needs to be turned back to a directory. But ls-files -k is asked to check with the index, which has the path as a directory, so this case is missed. Since git stash resets to the state in HEAD, whatever --killed check it does needs to check against HEAD, yes. It still doesn't need to check any path that doesn't exist in HEAD, though; it makes more sense to drive this from the list of files in HEAD rather than from the list of files in the working directory, even with a filter applied to the latter to prune bits not in HEAD. So instead of test -n $(git ls-files --killed | head -n 1) in Pasky's patch, which probably is a right thing to do if you are running git stash save --keep-index, you would need something like this if you are not running with --keep-index: test -n $( GIT_INDEX_FILE=tmp_index export GIT_INDEX_FILE git read-tree HEAD git ls-files -k ) in order to make sure that the result of going back to the state in the HEAD will not clobber leftover path/cruft. Sure, that works. However, wouldn't it make sense to just directly let git ls-files output to the screen, then test its return value (after adding some ls-files option to set the return value)? Since ls-files --killed will have no output if git stash can proceed, and since git stash should show the list of files that'd be killed before it fails, using the output directly makes sense. - Josh Triplett -- 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 v6 1/3] branch: not report invalid tracking branch
Command git branch -vv will report tracking branches, but invalid
tracking branches are also reported. This is because the function
stat_tracking_info() can not distinguish whether the upstream branch
does not exist, or nothing is changed between one branch and its
upstream.
This patch changes the return value of function stat_tracking_info().
Only returns false when there is no tracking branch or the tracking
branch is invalid, otherwise true. If the caller does not like to
report tracking info when nothing changed between the branch and its
upstream, simply checks if num_theirs and num_ours are both 0.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
builtin/branch.c | 24
remote.c | 43 ++-
t/t6040-tracking-info.sh | 8 ++--
wt-status.c | 13 +++--
4 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0903763..3e016a6 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -424,19 +424,8 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
struct branch *branch = branch_get(branch_name);
struct strbuf fancy = STRBUF_INIT;
- if (!stat_tracking_info(branch, ours, theirs)) {
- if (branch branch-merge branch-merge[0]-dst
- show_upstream_ref) {
- ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
- if (want_color(branch_use_color))
- strbuf_addf(stat, [%s%s%s] ,
-
branch_get_color(BRANCH_COLOR_UPSTREAM),
- ref,
branch_get_color(BRANCH_COLOR_RESET));
- else
- strbuf_addf(stat, [%s] , ref);
- }
+ if (!stat_tracking_info(branch, ours, theirs))
return;
- }
if (show_upstream_ref) {
ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
@@ -448,19 +437,22 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
strbuf_addstr(fancy, ref);
}
- if (!ours) {
- if (ref)
+ if (!ours !theirs) {
+ if (show_upstream_ref)
+ strbuf_addf(stat, _([%s]), fancy.buf);
+ } else if (!ours) {
+ if (show_upstream_ref)
strbuf_addf(stat, _([%s: behind %d]), fancy.buf,
theirs);
else
strbuf_addf(stat, _([behind %d]), theirs);
} else if (!theirs) {
- if (ref)
+ if (show_upstream_ref)
strbuf_addf(stat, _([%s: ahead %d]), fancy.buf, ours);
else
strbuf_addf(stat, _([ahead %d]), ours);
} else {
- if (ref)
+ if (show_upstream_ref)
strbuf_addf(stat, _([%s: ahead %d, behind %d]),
fancy.buf, ours, theirs);
else
diff --git a/remote.c b/remote.c
index 2433467..26bd543 100644
--- a/remote.c
+++ b/remote.c
@@ -1729,7 +1729,8 @@ int ref_newer(const unsigned char *new_sha1, const
unsigned char *old_sha1)
}
/*
- * Return true if there is anything to report, otherwise false.
+ * Return false if cannot stat a tracking branch (not exist or invalid),
+ * otherwise true.
*/
int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
{
@@ -1740,18 +1741,12 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
const char *rev_argv[10], *base;
int rev_argc;
- /*
-* Nothing to report unless we are marked to build on top of
-* somebody else.
-*/
+ /* Cannot stat unless we are marked to build on top of somebody else. */
if (!branch ||
!branch-merge || !branch-merge[0] || !branch-merge[0]-dst)
return 0;
- /*
-* If what we used to build on no longer exists, there is
-* nothing to report.
-*/
+ /* Cannot stat if what we used to build on no longer exists */
base = branch-merge[0]-dst;
if (read_ref(base, sha1))
return 0;
@@ -1766,8 +1761,10 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
return 0;
/* are we the same? */
- if (theirs == ours)
- return 0;
+ if (theirs == ours) {
+ *num_theirs = *num_ours = 0;
+ return 1;
+ }
/* Run rev-list --left-right ours...theirs internally... */
rev_argc = 0;
@@ -1809,31 +1806,35 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
*/
int format_tracking_info(struct branch *branch, struct strbuf
[PATCH v6 3/3] status: always show tracking branch even no change
In order to see what the current branch is tracking, one way is using
git branch -v -v, but branches other than the current are also
reported. Another way is using git status, such as:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
But this will not work if there is no change between the current
branch and its upstream. What if report upstream tracking info
always even if there is no difference. E.g.
$ git status
# On branch feature1
# Your branch is identical to 'github/feature1'.
...
$ git status -bs
## feature1...github/feature1
...
$ git checkout feature1
Already on 'feature1'
Your branch is identical to 'github/feature1'.
...
Also add some test cases in t6040.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
remote.c | 7 ---
t/t6040-tracking-info.sh | 34 +-
wt-status.c | 9 +
3 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/remote.c b/remote.c
index aa87381..1137394 100644
--- a/remote.c
+++ b/remote.c
@@ -1822,9 +1822,6 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
broken_upstream = 1;
break;
default:
- /* Nothing to report if neither side has changes. */
- if (!ours !theirs)
- return 0;
break;
}
@@ -1837,6 +1834,10 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
if (advice_status_hints)
strbuf_addf(sb,
_( (use \git branch --unset-upstream\ to
fixup)\n));
+ } else if (!ours !theirs) {
+ strbuf_addf(sb,
+ _(Your branch is identical to '%s'.\n),
+ base);
} else if (!theirs) {
strbuf_addf(sb,
Q_(Your branch is ahead of '%s' by %d commit.\n,
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index e362a01..404b629 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -32,7 +32,8 @@ test_expect_success setup '
git checkout -b brokenbase origin
git checkout -b b5 --track brokenbase
advance g
- git branch -d brokenbase
+ git branch -d brokenbase
+ git checkout -b b6 origin
)
git checkout -b follower --track master
advance h
@@ -61,6 +62,7 @@ b2 origin/master: ahead 1, behind 1
b3 origin/master: behind 1
b4 origin/master: ahead 2
b5 brokenbase: broken
+b6 origin/master
EOF
test_expect_success 'branch -vv' '
@@ -93,6 +95,13 @@ test_expect_success 'checkout (broken upstream)' '
test_i18ngrep is based on a broken ref actual
'
+test_expect_success 'checkout (identical to upstream)' '
+ (
+ cd test git checkout b6
+ ) actual
+ test_i18ngrep Your branch is identical to .origin/master actual
+'
+
test_expect_success 'status (diverged from upstream)' '
(
cd test
@@ -113,6 +122,16 @@ test_expect_success 'status (broken upstream)' '
test_i18ngrep is based on a broken ref actual
'
+test_expect_success 'status (identical to upstream)' '
+ (
+ cd test
+ git checkout b6 /dev/null
+ # reports nothing to commit
+ test_must_fail git commit --dry-run
+ ) actual
+ test_i18ngrep Your branch is identical to .origin/master actual
+'
+
cat expect \EOF
## b1...origin/master [ahead 1, behind 1]
EOF
@@ -139,6 +158,19 @@ test_expect_success 'status -s -b (broken upstream)' '
test_i18ncmp expect actual
'
+cat expect \EOF
+## b6...origin/master
+EOF
+
+test_expect_success 'status -s -b (identical to upstream)' '
+ (
+ cd test
+ git checkout b6 /dev/null
+ git status -s -b | head -1
+ ) actual
+ test_i18ncmp expect actual
+'
+
test_expect_success 'fail to track lightweight tags' '
git checkout master
git tag light
diff --git a/wt-status.c b/wt-status.c
index 60164d4..c66963c 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1394,10 +1394,6 @@ static void wt_shortstatus_print_tracking(struct
wt_status *s)
broken_upstream = 1;
break;
default:
- if (!num_ours !num_theirs) {
- fputc(s-null_termination ? '\0' : '\n', s-fp);
- return;
- }
break;
}
@@ -1406,6 +1402,11 @@ static void wt_shortstatus_print_tracking(struct
wt_status *s)
color_fprintf(s-fp, header_color, ...);
color_fprintf(s-fp, branch_color_remote, %s, base);
+ if (!broken_upstream !num_ours !num_theirs) {
+ fputc(s-null_termination ? '\0' : '\n',
[PATCH v6 2/3] branch: report invalid tracking branch as broken
If a branch has been set to track a upstream, but the upstream branch
is missing or invalid, the tracking info is silently ignored in the
output of some commands such as git branch -vv and git status,
as if there were no such tracking settings.
Junio suggested broken upstream should be reported [1]. E.g.
$ git branch -v -v
mastere67ac84 initial
* topic 3fc0f2a [topicbase: broken] topic
$ git status
# On branch topic
# Your branch is based on a broken ref 'topicbase'.
# (use git branch --unset-upstream to fixup)
...
$ git status -b -s
## topic...topicbase [broken]
...
In order to do like that, we need to distinguish these three cases
(i.e. no tracking, with configured but no longer valid tracking, and
with tracking) in function stat_tracking_info(). So the refactored
function stat_tracking_info() has three return values: -1 (with gone
base), 0 (no base), and 1 (with base).
[1]: http://thread.gmane.org/gmane.comp.version-control.git/231830/focus=232288
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Jiang Xin worldhello@gmail.com
---
builtin/branch.c | 17 +++--
remote.c | 43 ++
t/t6040-tracking-info.sh | 49 ++--
wt-status.c | 27 --
4 files changed, 110 insertions(+), 26 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 3e016a6..247785e 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -423,9 +423,19 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
char *ref = NULL;
struct branch *branch = branch_get(branch_name);
struct strbuf fancy = STRBUF_INIT;
+ int broken_upstream = 0;
- if (!stat_tracking_info(branch, ours, theirs))
+ switch (stat_tracking_info(branch, ours, theirs)) {
+ case 0:
+ /* Not set upstream. */
return;
+ case -1:
+ /* Upstream is missing or invalid. */
+ broken_upstream = 1;
+ break;
+ default:
+ break;
+ }
if (show_upstream_ref) {
ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
@@ -437,7 +447,10 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
strbuf_addstr(fancy, ref);
}
- if (!ours !theirs) {
+ if (broken_upstream) {
+ if (show_upstream_ref)
+ strbuf_addf(stat, _([%s: broken]), fancy.buf);
+ } else if (!ours !theirs) {
if (show_upstream_ref)
strbuf_addf(stat, _([%s]), fancy.buf);
} else if (!ours) {
diff --git a/remote.c b/remote.c
index 26bd543..aa87381 100644
--- a/remote.c
+++ b/remote.c
@@ -1729,8 +1729,11 @@ int ref_newer(const unsigned char *new_sha1, const
unsigned char *old_sha1)
}
/*
- * Return false if cannot stat a tracking branch (not exist or invalid),
- * otherwise true.
+ * Compare a branch with its tracking branch, and save their differences
+ * (number of commits) in *num_ours and *num_theirs.
+ *
+ * Return 0 if branch has no upstream, -1 if upstream is missing or invalid,
+ * otherwise 1.
*/
int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
{
@@ -1749,16 +1752,16 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
/* Cannot stat if what we used to build on no longer exists */
base = branch-merge[0]-dst;
if (read_ref(base, sha1))
- return 0;
+ return -1;
theirs = lookup_commit_reference(sha1);
if (!theirs)
- return 0;
+ return -1;
if (read_ref(branch-refname, sha1))
- return 0;
+ return -1;
ours = lookup_commit_reference(sha1);
if (!ours)
- return 0;
+ return -1;
/* are we the same? */
if (theirs == ours) {
@@ -1808,17 +1811,33 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
{
int ours, theirs;
const char *base;
+ int broken_upstream = 0;
- if (!stat_tracking_info(branch, ours, theirs))
- return 0;
-
- /* Nothing to report if neither side has changes. */
- if (!ours !theirs)
+ switch (stat_tracking_info(branch, ours, theirs)) {
+ case 0:
+ /* Not set upstream. */
return 0;
+ case -1:
+ /* Upstream is missing or invalid. */
+ broken_upstream = 1;
+ break;
+ default:
+ /* Nothing to report if neither side has changes. */
+ if (!ours !theirs)
+ return 0;
+ break;
+ }
base = branch-merge[0]-dst;
base =
Re: [PATCH v6 2/3] branch: report invalid tracking branch as broken
Jiang Xin worldhello@gmail.com writes: If a branch has been set to track a upstream, but the upstream branch is missing or invalid, the tracking info is silently ignored in the output of some commands such as git branch -vv and git status, as if there were no such tracking settings. Junio suggested broken upstream should be reported [1]. E.g. $ git branch -v -v mastere67ac84 initial * topic 3fc0f2a [topicbase: broken] topic I'd assume this is s/broken/gone/ to match what the rest of the log message says? $ git status # On branch topic # Your branch is based on a broken ref 'topicbase'. # (use git branch --unset-upstream to fixup) ... $ git status -b -s ## topic...topicbase [broken] ... In order to do like that, we need to distinguish these three cases (i.e. no tracking, with configured but no longer valid tracking, and with tracking) in function stat_tracking_info(). So the refactored function stat_tracking_info() has three return values: -1 (with gone base), 0 (no base), and 1 (with base). -- 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: git stash takes excessively long when many untracked files present
Josh Triplett j...@joshtriplett.org writes: I've already reverted the problematic patch to git stash and it will not be part of the upcoming release. Thanks! Here is a quick attempt to see if we can do better in ls-files -k. Having said that, I am curious if the result of applying the patch you are responding to, without reverting the git stash patch, is now usable in the working tree you earlier had trouble with. Sure, that works. However, wouldn't it make sense to just directly let git ls-files output to the screen, then test its return value (after adding some ls-files option to set the return value)? Not really. We may want to add exit early if we see even a single killed file option to the command so that we can simplify the are we going to abort logic, but the error codepath that is executed after that decision is made is not performance critical, and may need more flexibility than always spewing everything that will be killed, which could be thousands of crufts. So I think using two separate invocations to ls-files --killed is a necessity anyway. -- 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: Understanding Git Under The Hood: Trees
On Thu, Aug 15, 2013 at 7:31 PM, Junio C Hamano gits...@pobox.com wrote: While the last statement applies to other parts of the system, it is not true for the in-core index design. We always had a flat index, and it is not cheating at all. The original tree was also a flat representation of everything under the sun, and hierarchical tree objects came much later. To some degree that revalidates my interpretation of Andreas' statements. If I understand it correctly eacht time a shell command is executed, which requires tree interaction, the corresponding tree is read from filesystem to memory completely before anything is done? So if I git-add a file, the whole index is read first, then the memory object is changed and then the resulting change is written to disk bottom-up from the point of view of the tree? -- 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] lookup_object: split up displacement penalty for hash collisions
A little background on hash tables first: Consider you want to have the object X, which you'd expect at position i, but because that place was already taken by B, it is not found at position i, you start looking right of position i to find X until you find it. index | i-1 | i | i+1 | i+2 | i+3 | i+4 | entry ... | A | B | C | D | E | X | ... Once you have found X at i+4, the commit 9a414486d9f0 (2013-05-01, lookup_object: prioritize recently found objects) did an optimization and swapped the object B with X, so the placement looks like index | i-1 | i | i+1 | i+2 | i+3 | i+4 | entry ... | A | X | C | D | E | B | ... This would improve the lookup times, because you'd likely be looking up X again soon. However we are putting a heavy penalty on B for the collision. Also suppose we'd look up B now, which is expected to be at i or even left from there (i-n). So it is a long way to go until B is found. So if B were expected at the same place as X, we'd end up as before the swap, now penalizing the lookup of X again. Jeff stated in the referenced commit, that another solution, an LRU scheduling would be to shift all of the objects. So when looking for X in the first diagram, once we found X, we'd shift all the objects and put X to position i: index | i-1 | i | i+1 | i+2 | i+3 | i+4 | entry ... | A | X | B | C | D | E | ... But that strategy would need to go through all the positions, hence taking even longer. This patch proposes another strategy: We split the penalty into parts and add the penalty to different objects. To keep the overhead small, we're splitting up the penalty to only 2 portions and assign it to the object B and an arbitrary object in the range between B and X. The reason why moving that arbitrary object in between is analogous to the explanation of moving the first object. See 9a414486d9f0 (2013-05-01, lookup_object: prioritize recently found objects) for a detailed explanation. But which of the objects to choose from in between? At first I naively choose the exact mid between those 2 objects, so here is the diagram from the beginning again: index | i-1 | i | i+1 | i+2 | i+3 | i+4 | entry ... | A | B | C | D | E | X | ... If we now want to find X and X is expected at i, we put X to the position i and B to the middle position between B and X at D and D will go to the old position of X: index | i-1 | i | i+1 | i+2 | i+3 | i+4 | entry ... | A | X | C | B | E | D | ... So let's test how it works out: # running the current git.git master (c1ebd90c832e), repeat 25 times: perf stat -r 25 -- ./git-rev-list --all --objects /dev/null ... 5.294512141 seconds time elapsed( +- 7.88% ) # Now running with this patch applied: 5.111576725 seconds time elapsed( +- 8.17% ) This is an average 5 percent performance gain, though the measure times are varying itself by that amount (7.88 and 8.17 percent) This approach is faster than before, because it still doesn't touch too many object for resorting, but also doesn't put the penalty to one outlier. The lookup penalty is split up between two objects, which probably have nothing to do with each other. But is the mid object really the right thing to do? We could split the lookup penalty not into 2 halfs, but in a huge and a small amount. So instead of the mid object, we are free to choose any other arbitrary object in between B and X. Let's try to use the nearest object (C) and farest object(E), because there we may have better cache effects (near the objects we're accessing anyway) and the calculation is easier: If using C as the mid object, we'd end up with index | i-1 | i | i+1 | i+2 | i+3 | i+4 | entry ... | A | X | B | D | E | C | ... or if taking the E object we'd end up with index | i-1 | i | i+1 | i+2 | i+3 | i+4 | entry ... | A | X | C | D | B | E | ... # Test with C as mid object (25 repetitions as well): # 5.35 seconds time elapsed ( +- 7.09% ) # Test with E as mid object (25
[PATCH] create_delta_index: simplify condition always evaluating to true
When checking the previous lines in that function, we can deduct that hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because the entries is capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so i will never be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- diff-delta.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/diff-delta.c b/diff-delta.c index 93385e1..54da95b 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -154,8 +154,15 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize) */ entries = 0xfffeU / RABIN_WINDOW; } + + /* +* Do not check i 31 in the loop, because the assignement +* previous to the loop makes sure, hsize is definitely +* smaller than 131, hence the loop will always stop +* before i exceeds 31 resulting in an infinite loop. +*/ hsize = entries / 4; - for (i = 4; (1u i) hsize i 31; i++); + for (i = 4; (1u i) hsize; i++); hsize = 1 i; hmask = hsize - 1; -- 1.8.4.rc3.498.g5af1768 -- 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: git stash takes excessively long when many untracked files present
Junio C Hamano gits...@pobox.com writes: diff --git a/dir.c b/dir.c index 910bfcd..02939e2 100644 --- a/dir.c +++ b/dir.c @@ -1183,6 +1183,15 @@ static enum path_treatment treat_one_path(struct dir_struct *dir, cache_name_exists(path-buf, path-len, ignore_case)) return path_none; + /* + * A directory can only contain killed files if the index + * has a path that wants it to be a non-directory. + */ + if ((dir-flags DIR_COLLECT_KILLED_ONLY) + (dtype == DT_DIR) + !cache_name_exists(path-buf, path-len, ignore_case)) + return path_none; + I think this is wrong. When we are looking at a directory P in the working tree, there are three cases: (1) P exists in the index. Everything inside the directory P in the working tree needs to go when P is checked out from the index. (2) P does not exist in the index, but there is P/Q in the index. We know P will stay a directory when we check out the contents of the index, but we do not know yet if there is a directory P/Q in the working tree to be killed, so we need to recurse. (3) P does not exist in the index, and there is no P/Q in the index to require P to be a directory, either. Only in this case, we know that everything inside P will not be killed without recursing. The patch will break with the second case, I think. -- 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
Bug with `git branch HEAD` in a 'detached HEAD' state
Hello everyone, I think I have just found a bug in Git which basically occurs when I run `git log HEAD` in a detached HEAD state. To reproduce it, just run $ git init ... $ touch tmp ... $ git add tmp $ git commit -m tmp ... $ git checkout commit_sha ... $ git branch HEAD Segmentation fault (core dumped) My version of git is the following $ git --version git version 1.8.1.2 If that helps (and even if it doesn't actually), I'm running ubuntu 13.04 64-bit. Benoît Legat -- 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 with `git branch HEAD` in a 'detached HEAD' state
On 08/15/2013 10:50 PM, Benoît Legat wrote: Hello everyone, I think I have just found a bug in Git which basically occurs when I run `git log HEAD` in a detached HEAD state. To reproduce it, just run $ git init ... $ touch tmp ... $ git add tmp $ git commit -m tmp ... $ git checkout commit_sha ... $ git branch HEAD Segmentation fault (core dumped) My version of git is the following $ git --version git version 1.8.1.2 If that helps (and even if it doesn't actually), I'm running ubuntu 13.04 64-bit. Benoît Legat -- 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 This should be fixed by 8efb8899cfe866dddb3659b9e0a94232161db65e (2013-02-23, branch: segfault fixes and validation) I could reproduce with 1.8.1.2, but not on current master branch. If this annoys you too much, please update your git version. ;) Stefan signature.asc Description: OpenPGP digital signature
Re: [PATCH] create_delta_index: simplify condition always evaluating to true
On Thu, Aug 15, 2013 at 3:37 PM, Stefan Beller stefanbel...@googlemail.com wrote: When checking the previous lines in that function, we can deduct that s/deduct/deduce/ hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because the entries is s/the entries/entries/ reads a bit better. capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so i will never s/i/it/ be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- diff-delta.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/diff-delta.c b/diff-delta.c index 93385e1..54da95b 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -154,8 +154,15 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize) */ entries = 0xfffeU / RABIN_WINDOW; } + + /* +* Do not check i 31 in the loop, because the assignement +* previous to the loop makes sure, hsize is definitely +* smaller than 131, hence the loop will always stop +* before i exceeds 31 resulting in an infinite loop. +*/ This comment echoes the commit message, and indeed the explanation makes more sense in that context since someone can read the entire patch to see and understand the actual change. It may have less value as an in-code comment. hsize = entries / 4; - for (i = 4; (1u i) hsize i 31; i++); + for (i = 4; (1u i) hsize; i++); hsize = 1 i; hmask = hsize - 1; -- -- 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 0/3] Optimizing ls-files -k
ls-files -o and ls-files -k both traverse the working tree down to find either all untracked paths or those that will be killed (removed from the working tree to make room) when the paths recorded in the index are checked out. It is necessary to traverse the working tree fully when enumerating all the other paths, but when we are only interested in killed paths, we can take advantage of the fact that paths that do not overlap with entries in the index can never be killed. The first one is an independent clean-up. No public API in the working tree traversal takes alternate in-core index, so there is no reason to explicitly use the_index and index_* functions from the in-core index API. The second one is rerolled from the something like this patch I sent earlier, but corrects the we see a directory, it is not in the index, but a file in it is case. And the third one adds a testcase that illustrates why the earlier something like this patch is not sufficient. These are designed to apply on top of v1.8.3, and needs a bit of conflict resolution for the upcoming v1.8.4 codebase; I'll queue them in 'pu' for now. Note that t3010, especially after merged to 'pu', will use many different ways to create a test file. Some redirect date into it, some redirect : into it, some touch it, and some just redirect with no command. date file1 : file2 touch file3 file4 We should consolidate them all to just do file4 after making sure the contents do not matter (we kind of know it already, as date will output string that is not repeatable). Use of touch for anything other than updating the timestamp is especially bad, as it is misleading. Junio C Hamano (3): dir.c: use the cache_* macro to access the current index ls-files -k: a directory only can be killed if the index has a non-directory t3010: update to demonstrate ls-files -k optimization pitfalls builtin/ls-files.c | 2 ++ dir.c | 40 + dir.h | 3 ++- t/t3010-ls-files-killed-modified.sh | 12 --- 4 files changed, 45 insertions(+), 12 deletions(-) -- 1.8.4-rc3-232-ga8053f8 -- 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 1/3] dir.c: use the cache_* macro to access the current index
These codepaths always start from the_index and use index_*
functions, but there is no reason to do so. Use the compatibility
cache_* macro to access the current in-core index like everybody
else.
While at it, fix typo in the comment for a function to check if a
path within a directory appears in the index.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/dir.c b/dir.c
index a5926fb..2f82cd1 100644
--- a/dir.c
+++ b/dir.c
@@ -472,15 +472,14 @@ static void *read_skip_worktree_file_from_index(const
char *path, size_t *size)
unsigned long sz;
enum object_type type;
void *data;
- struct index_state *istate = the_index;
len = strlen(path);
- pos = index_name_pos(istate, path, len);
+ pos = cache_name_pos(path, len);
if (pos 0)
return NULL;
- if (!ce_skip_worktree(istate-cache[pos]))
+ if (!ce_skip_worktree(active_cache[pos]))
return NULL;
- data = read_sha1_file(istate-cache[pos]-sha1, type, sz);
+ data = read_sha1_file(active_cache[pos]-sha1, type, sz);
if (!data || type != OBJ_BLOB) {
free(data);
return NULL;
@@ -924,13 +923,13 @@ enum exist_status {
};
/*
- * Do not use the alphabetically stored index to look up
+ * Do not use the alphabetically sorted index to look up
* the directory name; instead, use the case insensitive
* name hash.
*/
static enum exist_status directory_exists_in_index_icase(const char *dirname,
int len)
{
- struct cache_entry *ce = index_name_exists(the_index, dirname, len +
1, ignore_case);
+ struct cache_entry *ce = cache_name_exists(dirname, len + 1,
ignore_case);
unsigned char endchar;
if (!ce)
--
1.8.4-rc3-232-ga8053f8
--
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 2/3] ls-files -k: a directory only can be killed if the index has a non-directory
ls-files -o and ls-files -k both traverse the working tree down
to find either all untracked paths or those that will be killed
(removed from the working tree to make room) when the paths recorded
in the index are checked out. It is necessary to traverse the
working tree fully when enumerating all the other paths, but when
we are only interested in killed paths, we can take advantage of
the fact that paths that do not overlap with entries in the index
can never be killed.
The treat_one_path() helper function, which is called during the
recursive traversal, is the ideal place to implement an
optimization.
When we are looking at a directory P in the working tree, there are
three cases:
(1) P exists in the index. Everything inside the directory P in
the working tree needs to go when P is checked out from the
index.
(2) P does not exist in the index, but there is P/Q in the index.
We know P will stay a directory when we check out the contents
of the index, but we do not know yet if there is a directory
P/Q in the working tree to be killed, so we need to recurse.
(3) P does not exist in the index, and there is no P/Q in the index
to require P to be a directory, either. Only in this case, we
know that everything inside P will not be killed without
recursing.
Note that this helper is called by treat_leading_path() that decides
if we need to traverse only subdirectories of a single common
leading directory, which is essential for this optimization to be
correct. This caller checks each level of the leading path
component from shallower directory to deeper ones, and that is what
allows us to only check if the path appears in the index. If the
call to treat_one_path() weren't there, given a path P/Q/R, the real
traversal may start from directory P/Q/R, even when the index
records P as a regular file, and we would end up having to check if
any leading subpath in P/Q/R, e.g. P, appears in the index.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/ls-files.c | 2 ++
dir.c | 29 +++--
dir.h | 3 ++-
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 2202072..c7eb6f4 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -213,6 +213,8 @@ static void show_files(struct dir_struct *dir)
/* For cached/deleted files we don't need to even do the readdir */
if (show_others || show_killed) {
+ if (!show_others)
+ dir-flags |= DIR_COLLECT_KILLED_ONLY;
fill_directory(dir, pathspec);
if (show_others)
show_other_files(dir);
diff --git a/dir.c b/dir.c
index 2f82cd1..ff768f3 100644
--- a/dir.c
+++ b/dir.c
@@ -1173,12 +1173,37 @@ static enum path_treatment treat_one_path(struct
dir_struct *dir,
int dtype, struct dirent *de)
{
int exclude;
+ int has_path_in_index = !!cache_name_exists(path-buf, path-len,
ignore_case);
+
if (dtype == DT_UNKNOWN)
dtype = get_dtype(de, path-buf, path-len);
/* Always exclude indexed files */
- if (dtype != DT_DIR
- cache_name_exists(path-buf, path-len, ignore_case))
+ if (dtype != DT_DIR has_path_in_index)
+ return path_none;
+
+ /*
+* When we are looking at a directory P in the working tree,
+* there are three cases:
+*
+* (1) P exists in the index. Everything inside the directory P in
+* the working tree needs to go when P is checked out from the
+* index.
+*
+* (2) P does not exist in the index, but there is P/Q in the index.
+* We know P will stay a directory when we check out the contents
+* of the index, but we do not know yet if there is a directory
+* P/Q in the working tree to be killed, so we need to recurse.
+*
+* (3) P does not exist in the index, and there is no P/Q in the index
+* to require P to be a directory, either. Only in this case, we
+* know that everything inside P will not be killed without
+* recursing.
+*/
+ if ((dir-flags DIR_COLLECT_KILLED_ONLY)
+ (dtype == DT_DIR)
+ !has_path_in_index
+ (directory_exists_in_index(path-buf, path-len) ==
index_nonexistent))
return path_none;
exclude = is_excluded(dir, path-buf, dtype);
diff --git a/dir.h b/dir.h
index 3d6b80c..4677b86 100644
--- a/dir.h
+++ b/dir.h
@@ -80,7 +80,8 @@ struct dir_struct {
DIR_HIDE_EMPTY_DIRECTORIES = 12,
DIR_NO_GITLINKS = 13,
DIR_COLLECT_IGNORED = 14,
- DIR_SHOW_IGNORED_TOO = 15
+ DIR_SHOW_IGNORED_TOO = 15,
+ DIR_COLLECT_KILLED_ONLY = 16
} flags;
struct dir_entry **entries;
struct
[PATCH 3/3] t3010: update to demonstrate ls-files -k optimization pitfalls
An earlier draft of the previous step used cache_name_exists() to check the directory we were looking at, which missed the second case described in its log message. Demonstrate why it is not sufficient. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t3010-ls-files-killed-modified.sh | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/t/t3010-ls-files-killed-modified.sh b/t/t3010-ls-files-killed-modified.sh index 95671c2..6ea7ca8 100755 --- a/t/t3010-ls-files-killed-modified.sh +++ b/t/t3010-ls-files-killed-modified.sh @@ -11,6 +11,7 @@ This test prepares the following in the cache: path1 - a symlink path2/file2 - a file in a directory path3/file3 - a file in a directory +pathx/ju- a file in a directory and the following on the filesystem: @@ -21,6 +22,7 @@ and the following on the filesystem: path4 - a file path5 - a symlink path6/file6 - a file in a directory +pathx/ju/nk - a file in a directory to be killed git ls-files -k should report that existing filesystem objects except path4, path5 and path6/file6 to be killed. @@ -44,16 +46,17 @@ then else date path1 fi -mkdir path2 path3 +mkdir path2 path3 pathx date path2/file2 date path3/file3 +pathx/ju : path7 date path8 : path9 date path10 test_expect_success \ 'git update-index --add to add various paths.' \ -git update-index --add -- path0 path1 path?/file? path7 path8 path9 path10 +git update-index --add -- path0 path1 path?/file? pathx/ju path7 path8 path9 path10 rm -fr path? ;# leave path10 alone date path2 @@ -65,7 +68,7 @@ else date path3 date path5 fi -mkdir path0 path1 path6 +mkdir -p path0 path1 path6 pathx/ju date path0/file0 date path1/file1 date path6/file6 @@ -73,6 +76,7 @@ date path7 : path8 : path9 touch path10 +pathx/ju/nk test_expect_success \ 'git ls-files -k to show killed files.' \ @@ -82,6 +86,7 @@ path0/file0 path1/file1 path2 path3 +pathx/ju/nk EOF test_expect_success \ @@ -98,6 +103,7 @@ path2/file2 path3/file3 path7 path8 +pathx/ju EOF test_expect_success \ -- 1.8.4-rc3-232-ga8053f8 -- 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] create_delta_index: simplify condition always evaluating to true
When checking the previous lines in that function, we can deduce that hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because entries is capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so the value of 'i' will never be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- Eric, thanks for reviewing my patch. I applied the first 2 proposals (deduce, entries), but I disagree on the third, so I reformulated the sentence, as I really meant the variable i and not it as a pronoun. Do I understand right, you're suggesting to remove the source code comment? I did this now, but I have a bad feeling with it. The change of this patch surely removes dead code as of now and makes it more readable. But also it could become alive again, once somebody changes things nearby and forgets about the assumption, hsize not exceeding a certain size. That's why I put a comment in there, so the future changes nearby may be more careful. Thanks, Stefan diff-delta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diff-delta.c b/diff-delta.c index 93385e1..3797ce6 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -155,7 +155,7 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize) entries = 0xfffeU / RABIN_WINDOW; } hsize = entries / 4; - for (i = 4; (1u i) hsize i 31; i++); + for (i = 4; (1u i) hsize; i++); hsize = 1 i; hmask = hsize - 1; -- 1.8.4.rc3.1.gc1ebd90 -- 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] create_delta_index: simplify condition always evaluating to true
Forwarding to the area expert... Stefan Beller stefanbel...@googlemail.com writes: When checking the previous lines in that function, we can deduct that hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because the entries is capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so i will never be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- diff-delta.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/diff-delta.c b/diff-delta.c index 93385e1..54da95b 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -154,8 +154,15 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize) */ entries = 0xfffeU / RABIN_WINDOW; } + + /* + * Do not check i 31 in the loop, because the assignement + * previous to the loop makes sure, hsize is definitely + * smaller than 131, hence the loop will always stop + * before i exceeds 31 resulting in an infinite loop. + */ hsize = entries / 4; - for (i = 4; (1u i) hsize i 31; i++); + for (i = 4; (1u i) hsize; i++); hsize = 1 i; hmask = hsize - 1; -- 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] create_delta_index: simplify condition always evaluating to true
On Thu, Aug 15, 2013 at 5:34 PM, Stefan Beller stefanbel...@googlemail.com wrote: When checking the previous lines in that function, we can deduce that hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because entries is capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so the value of 'i' will never be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- Eric, thanks for reviewing my patch. I applied the first 2 proposals (deduce, entries), but I disagree on the third, so I reformulated the sentence, as I really meant the variable i and not it as a pronoun. Thanks. Adding the quotes around 'i' makes your meaning clear. Without the quotes, apparently it was ambiguous, and my brain read it as a misspelling of 'it'. Do I understand right, you're suggesting to remove the source code comment? I did this now, but I have a bad feeling with it. The change of this patch surely removes dead code as of now and makes it more readable. But also it could become alive again, once somebody changes things nearby and forgets about the assumption, hsize not exceeding a certain size. That's why I put a comment in there, so the future changes nearby may be more careful. Indeed, I feel uncomfortable with the patch in general for the very reason that you state: it might become live again. Without the patch, the code remains safe without any extra effort. With this patch, even with the in-code comment, someone making changes needs to take special care. Sometimes it makes sense to leave safeties in place, even if they can't be triggered _today_; and safeties (such as i 31) also serve as documentation. Thanks, Stefan diff-delta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diff-delta.c b/diff-delta.c index 93385e1..3797ce6 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -155,7 +155,7 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize) entries = 0xfffeU / RABIN_WINDOW; } hsize = entries / 4; - for (i = 4; (1u i) hsize i 31; i++); + for (i = 4; (1u i) hsize; i++); hsize = 1 i; hmask = hsize - 1; -- 1.8.4.rc3.1.gc1ebd90 -- 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] create_delta_index: simplify condition always evaluating to true
Nicolas, I am sorry for not including you in the first mail. Just before Junio included you, there were these 2 mails http://www.mail-archive.com/git@vger.kernel.org/msg34101.html http://www.mail-archive.com/git@vger.kernel.org/msg34103.html Stefan On 08/15/2013 11:43 PM, Junio C Hamano wrote: Forwarding to the area expert... Stefan Beller stefanbel...@googlemail.com writes: When checking the previous lines in that function, we can deduct that hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because the entries is capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so i will never be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- diff-delta.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/diff-delta.c b/diff-delta.c index 93385e1..54da95b 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -154,8 +154,15 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize) */ entries = 0xfffeU / RABIN_WINDOW; } + +/* + * Do not check i 31 in the loop, because the assignement + * previous to the loop makes sure, hsize is definitely + * smaller than 131, hence the loop will always stop + * before i exceeds 31 resulting in an infinite loop. + */ hsize = entries / 4; -for (i = 4; (1u i) hsize i 31; i++); +for (i = 4; (1u i) hsize; i++); hsize = 1 i; hmask = hsize - 1; signature.asc Description: OpenPGP digital signature
Re: [PATCH] create_delta_index: simplify condition always evaluating to true
From: Stefan Beller stefanbel...@googlemail.com When checking the previous lines in that function, we can deduce that hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because entries is capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so the value of 'i' will never be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- Eric, thanks for reviewing my patch. I applied the first 2 proposals (deduce, entries), but I disagree on the third, so I reformulated the sentence, as I really meant the variable i and not it as a pronoun. Do I understand right, you're suggesting to remove the source code comment? I did this now, but I have a bad feeling with it. The change of this patch surely removes dead code as of now and makes it more readable. But also it could become alive again, once somebody changes things nearby and forgets about the assumption, hsize not exceeding a certain size. That's why I put a comment in there, so the future changes nearby may be more careful. Should the comment also include a note about potential undefined behaviour of a large shift, with the possible consequential bad compiler optimization, such as simply deleting the code. I understand the initial spot was part of the STACK tool check of such latent optimisation bugs. http://css.csail.mit.edu/stack/ Thanks, Stefan diff-delta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diff-delta.c b/diff-delta.c index 93385e1..3797ce6 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -155,7 +155,7 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize) entries = 0xfffeU / RABIN_WINDOW; } hsize = entries / 4; - for (i = 4; (1u i) hsize i 31; i++); + for (i = 4; (1u i) hsize; i++); hsize = 1 i; hmask = hsize - 1; -- 1.8.4.rc3.1.gc1ebd90 -- 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] send-email uses contacts to propose recipients
I have got an idea regarding the send-email. If there are no recipients
given, it could propose recipients using the new 'git contacts'
This would help people new to projects to not forget people, who may have
the most knowledge reviewing that specific patch.
Unfortunately I cannot read/write perl, so I cannot solve it
myself in the near future, but I'd put it on my todo list for later.
---
git-send-email.perl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 2162478..a34723d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -757,6 +757,12 @@ $sender = sanitize_address($sender);
my $prompting = 0;
if (!@initial_to !defined $to_cmd) {
+ if (git contacts is available) {
+ proposed senders = git contacts on the same range or set of
patches
+ print Suggesting these receivers:\n
+ print proposed senders
+ }
+
my $to = ask(Who should the emails be sent to (if any)? ,
default = ,
valid_re = qr/\@.*\./, confirm_only = 1);
--
1.8.4.rc3.1.gc1ebd90
--
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] send-email uses contacts to propose recipients
On Thu, Aug 15, 2013 at 6:17 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
I have got an idea regarding the send-email. If there are no recipients
given, it could propose recipients using the new 'git contacts'
This would help people new to projects to not forget people, who may have
the most knowledge reviewing that specific patch.
You can already do this with git-send-email's --cc-cmd option or
sendmail.cccmd configuration variable.
Unfortunately I cannot read/write perl, so I cannot solve it
myself in the near future, but I'd put it on my todo list for later.
---
git-send-email.perl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 2162478..a34723d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -757,6 +757,12 @@ $sender = sanitize_address($sender);
my $prompting = 0;
if (!@initial_to !defined $to_cmd) {
+ if (git contacts is available) {
git-contacts is very slow, so at the very least you would want to
prompt before invoking it.
+ proposed senders = git contacts on the same range or set of
patches
+ print Suggesting these receivers:\n
+ print proposed senders
+ }
+
my $to = ask(Who should the emails be sent to (if any)? ,
default = ,
valid_re = qr/\@.*\./, confirm_only = 1);
--
1.8.4.rc3.1.gc1ebd90
--
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
--
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] send-email uses contacts to propose recipients
Stefan Beller stefanbel...@googlemail.com writes:
I have got an idea regarding the send-email. If there are no recipients
given, it could propose recipients using the new 'git contacts'
This would help people new to projects to not forget people, who may have
the most knowledge reviewing that specific patch.
Unfortunately I cannot read/write perl, so I cannot solve it
myself in the near future, but I'd put it on my todo list for later.
---
git-send-email.perl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 2162478..a34723d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -757,6 +757,12 @@ $sender = sanitize_address($sender);
my $prompting = 0;
if (!@initial_to !defined $to_cmd) {
+ if (git contacts is available) {
+ proposed senders = git contacts on the same range or set of
patches
+ print Suggesting these receivers:\n
+ print proposed senders
+ }
+
my $to = ask(Who should the emails be sent to (if any)? ,
default = ,
valid_re = qr/\@.*\./, confirm_only = 1);
Cute.
It is OK while contacts is in contrib/, because people who has
git contact are those who opted into the heuristics of implemented
by that script. But if we are to eventually move the script out of
the contrib/ area, we may have to restrict is available a bit
tighter. Not everybody has to agree with its heuristics before the
script moves out of the contrib/ area, so there will be users who
are annoyed by the suggestion the script makes, which may not suit
their needs at all.
For contributors of _this_ list, the above will not kick in at all,
as they should always have sendemail.to set to the list, and
@initial_to will not be empty for them.
--
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
What's cooking in git.git (Aug 2013, #04; Thu, 15)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Due to unfortunate regressions, two topics had to be reverted: * An attempted fix to git stash save, to detect that going back to the state of the HEAD needs to lose killed files, and/or untracked files in a killed directory, to prevent the command from proceeding without --force. This used ls-files -k that was unusably slow. * An attempted enhancement to allow @ to be used to name HEAD. This rewrote @ in a ref where it shouldn't have, e.g. refs/@/foo. The schedule for 1.8.4 has been updated to have an extra rc this weekend (1.8.4-rc4) in order to make sure these reverts do not have unexpected fallout, even though I do not anticipate any. The final has to be delayed by a week, and the current plan is to tag it on Aug 23rd (see http://tinyurl.com/gitCal). These reverts do not mean what these topics tried to achieve have been rejected---they just need to be redone without introducing the regression. A new topic to optimize ls-files -k has been posted, and it may help resurrect the git stash save topic after 1.8.4 release. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * jc/ls-files-killed-optim (2013-08-15) 3 commits - t3010: update to demonstrate ls-files -k optimization pitfalls - ls-files -k: a directory only can be killed if the index has a non-directory - dir.c: use the cache_* macro to access the current index git ls-files -k needs to crawl only the part of the working tree that may overlap the paths in the index to find killed files, but shared code with the logic to find all the untracked files, which made it unnecessarily inefficient. Will merge to and cook in 'next'. -- [Stalled] * tf/gitweb-ss-tweak (2013-07-15) 4 commits - gitweb: make search help link less ugly - gitweb: omit the repository owner when it is unset - gitweb: vertically centre contents of page footer - gitweb: ensure OPML text fits inside its box Comments? * rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits - ### DONTMERGE: needs better explanation on what config they need - pack-refs.c: Add missing call to git_config() - show-ref.c: Add missing call to git_config() The changes themselves are probably good, but it is unclear what basic setting needs to be read for which exact operation. Waiting for clarification. $gmane/228294 * jh/shorten-refname (2013-05-07) 4 commits - t1514: refname shortening is done after dereferencing symbolic refs - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin - t1514: Demonstrate failure to correctly shorten refs/remotes/origin/HEAD - t1514: Add tests of shortening refnames in strict/loose mode When remotes/origin/HEAD is not a symbolic ref, rev-parse --abbrev-ref remotes/origin/HEAD ought to show origin, not origin/HEAD, which is fixed with this series (if it is a symbolic ref that points at remotes/origin/something, then it should show origin/something and it already does). Expecting a reroll, as an early part of a larger series. $gmane/225137 * jk/list-objects-sans-blobs (2013-06-06) 4 commits . archive: ignore blob objects when checking reachability . list-objects: optimize revs-blob_objects = 0 case . upload-archive: restrict remote objects with reachability check . clear parsed flag when we free tree buffers Attempt to allow archive --remote=$there $arbitrary_sha1 while keeping the reachability safety. Seems to break some tests in a trivial and obvious way. * mg/more-textconv (2013-05-10) 7 commits - grep: honor --textconv for the case rev:path - grep: allow to use textconv filters - t7008: demonstrate behavior of grep with textconv - cat-file: do not die on --textconv without textconv filters - show: honor --textconv for blobs - diff_opt: track whether flags have been set explicitly - t4030: demonstrate behavior of show with textconv Make git grep and git show pay attention to --textconv when dealing with blob objects. I thought this was pretty well designed and executed, but it seems there are some doubts on the list; kicked back to 'pu'. * jc/format-patch (2013-04-22) 2 commits - format-patch: --inline-single - format-patch: rename no_inline field A new option to send a single patch to the standard output to be appended at the bottom of a message. I personally have no need for this, but it was easy enough to cobble together. Tests, docs and stripping out more MIMEy stuff are left as exercises to interested parties. Not ready for inclusion. Will discard unless we hear from anybody who is interested in tying its loose ends. * jk/gitweb-utf8 (2013-04-08) 4
Re: [PATCH] send-email uses contacts to propose recipients
Junio C Hamano gits...@pobox.com writes: ... we may have to restrict is available a bit tighter. As Eric pointed out, that bit tighter opt-in could just be an explicit use of --cc-cmd option to specify this script ;-) -- 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] Add command `git bisect state` that checks if the current bisection process has reached the first bad commit.
This can be used for automated bisection without a check script.
Signed-off-by: Mattias Andrée maand...@operamail.com
---
Documentation/git-bisect.txt | 13 +
git-bisect.sh| 11 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index f986c5c..ca8c09d 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -25,6 +25,7 @@ on the subcommand:
git bisect visualize
git bisect replay logfile
git bisect log
+ git bisect state
git bisect run cmd...
This command uses 'git rev-list --bisect' to help drive the
@@ -104,6 +105,18 @@ For example, `git bisect reset HEAD` will leave you on the
current
bisection commit and avoid switching commits at all, while `git bisect
reset bisect/bad` will check out the first bad revision.
+Bisect state
+
+
+To see the bisection process has finnished, issue the following command:
+
+
+$ git bisect state
+
+
+Exit successfully (i.e., with return code 0), if and only if the current
+bisection has reached the first bad or possible first bad commit.
+
Bisect visualize
diff --git a/git-bisect.sh b/git-bisect.sh
index 9f064b6..6ddda34 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|state]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [--no-checkout] [bad [good...]] [--] [pathspec...]
@@ -23,6 +23,8 @@ git bisect log
show bisect log.
git bisect run cmd...
use cmd... to automatically bisect.
+git bisect state
+ check if the bisection is complete.
Please use git help bisect to get the full man page.'
@@ -491,6 +493,11 @@ bisect_log () {
cat $GIT_DIR/BISECT_LOG
}
+bisect_complete_state () {
+ cat $GIT_DIR/BISECT_LOG | tail -n 1 | grep -E '^# (possible |)first
bad commit:' /dev/null
+ exit $?
+}
+
case $# in
0)
usage ;;
@@ -519,6 +526,8 @@ case $# in
bisect_log ;;
run)
bisect_run $@ ;;
+ state)
+ bisect_complete_state ;;
*)
usage ;;
esac
--
1.8.3.4
--
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 v6 2/3] branch: report invalid tracking branch as broken
Jiang Xin worldhello@gmail.com writes: /* - * Return false if cannot stat a tracking branch (not exist or invalid), - * otherwise true. + * Compare a branch with its tracking branch, and save their differences + * (number of commits) in *num_ours and *num_theirs. + * + * Return 0 if branch has no upstream, -1 if upstream is missing or invalid, + * otherwise 1. */ What is the difference between a branch that has no upstream and upstream being missing? Or between missing and invalid? I think you are trying to say the difference between branch.name.merge is not set at all and branch.name.merge is in the configuration, but the named upstream ref does not exist. You are calling the latter missing or invalid, but how does one tell missing ones from invalid ones? I think there isn't a distinction, so it would be better to just say missing (or gone, which is very much more likely reason why you still have configuration without a ref). I am not sure it is a good idea to label missing as broken or invalid, but it seems that your tests, in code comments and variable names are full of these negative connotations. Hmph... -- 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 v6 3/3] status: always show tracking branch even no change
Jiang Xin worldhello@gmail.com writes: In order to see what the current branch is tracking, one way is using git branch -v -v, but branches other than the current are also reported. Another way is using git status, such as: $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. ... But this will not work if there is no change between the current branch and its upstream. What if report upstream tracking info always even if there is no difference. E.g. $ git status # On branch feature1 # Your branch is identical to 'github/feature1'. ... $ git status -bs ## feature1...github/feature1 ... $ git checkout feature1 Already on 'feature1' Your branch is identical to 'github/feature1'. ... The sentence that began with What if ... never completed? -- 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 4/3] git stash: avoid data loss when git stash save kills a directory
From: Petr Baudis pa...@ucw.cz
stash save is about saving the local change to the working tree,
but also about restoring the state of the last commit to the working
tree. When a local change is to turn a non-directory to a directory,
in order to restore the non-directory, everything in the directory
needs to be removed.
Which is fine when running git stash save --include-untracked,
but without that option, untracked, newly created files in the
directory will have to be discarded, if the state you are restoring
to has a non-directory at the same path as the directory.
Introduce a safety valve to fail the operation in such case, using
the ls-files --killed which was designed for this exact purpose.
The stash save is stopped when untracked files need to be
discarded because their leading path ceased to be a directory, and
the user is required to pass --force to really have the data
removed.
Signed-off-by: Petr Baudis pa...@ucw.cz
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* And this is the reverted patch ported on top of the ls-files -k
miniseries I sent earlier. The updates to the test in t3903
compared to the original illustrates that the check implemented
in the original did not protect once a path that was turned into
a directory from a file gets added to the index, which this round
also fixes by running ls-files -k against the state in the HEAD.
Documentation/git-stash.txt | 11 +--
git-stash.sh| 20
t/t3903-stash.sh| 22 ++
3 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 711ffe1..61fadc5 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -14,7 +14,7 @@ SYNOPSIS
'git stash' ( pop | apply ) [--index] [-q|--quiet] [stash]
'git stash' branch branchname [stash]
'git stash' [save [--patch] [-k|--[no-]keep-index] [-q|--quiet]
-[-u|--include-untracked] [-a|--all] [message]]
+[-u|--include-untracked] [-a|--all] [-f|--force] [message]]
'git stash' clear
'git stash' create
@@ -43,7 +43,7 @@ is also possible).
OPTIONS
---
-save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all]
[-q|--quiet] [message]::
+save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all]
[-q|--quiet] [-f|--force] [message]::
Save your local modifications to a new 'stash', and run `git reset
--hard` to revert them. The message part is optional and gives
@@ -70,6 +70,13 @@ linkgit:git-add[1] to learn how to operate the `--patch`
mode.
+
The `--patch` option implies `--keep-index`. You can use
`--no-keep-index` to override this.
++
+In some cases, saving a stash could mean irretrievably removing some
+data - if a directory with untracked files replaces a tracked file of
+the same name, the new untracked files are not saved (except in case
+of `--include-untracked`) but the original tracked file shall be restored.
+By default, `stash save` will abort in such a case; `--force` will allow
+it to remove the untracked files.
list [options]::
diff --git a/git-stash.sh b/git-stash.sh
index bbefdf6..2d539f3 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -156,10 +156,19 @@ create_stash () {
die $(gettext Cannot record working tree state)
}
+# This helper MUST be run inside a subshell.
+list_killed_files () {
+ GIT_INDEX_FILE=$TMP-ls-files-k
+ export GIT_INDEX_FILE
+ git read-tree HEAD
+ git ls-files --killed
+}
+
save_stash () {
keep_index=
patch_mode=
untracked=
+ force=
while test $# != 0
do
case $1 in
@@ -180,6 +189,9 @@ save_stash () {
-u|--include-untracked)
untracked=untracked
;;
+ -f|--force)
+ force=t
+ ;;
-a|--all)
untracked=all
;;
@@ -223,6 +235,14 @@ save_stash () {
say $(gettext No local changes to save)
exit 0
fi
+ if test -z $untracked$force
+ test -n $(list_killed_files | head -n 1)
+ then
+ say $(gettext The following untracked files would NOT be
saved but need to be removed by stash save:)
+ test -n $GIT_QUIET || (list_killed_files | sed 's/^/\t/')
+ say $(gettext Aborting. Consider using either the --force or
--include-untracked option.) 2
+ exit 1
+ fi
test -f $GIT_DIR/logs/$ref_stash ||
clear_stash || die $(gettext Cannot initialize stash)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 5dfbda7..08ce23b 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -637,4 +637,26 @@ test_expect_success 'stash where working directory
contains HEAD file' '
test_cmp output expect
Re: [Bug] git stash generates a different diff then other commands (diff, add, etc) resulting in merge conflicts!
On Tue, Aug 13, 2013 at 1:31 AM, Luke San Antonio lukesananto...@gmail.com wrote: So I found an isolated case, it's very strange... Here's a script! deleted Thanks for that. It was hard to read, but it demonstrates the problem well. ... Copy and paste that into a terminal and you should have a recreated version of my repository there! Now that the file is partly stashed and partly in the index, check out the difference in diffs: try: git diff --staged then try: git stash show -p This one is pretty sneaky. It is not limited to git-stash. I can demonstrate the problem now using 'git merge-file'. But I can only make this problem show itself when: 1. The collisions are separated by just one line of common code, and 2. One of the lines of common code is duplicated in one of the collisions, and 3. The first two lines of the file are duplicated, and 4. One of the first two lines is deleted on one side but not the other. I have managed to boil the test down to this script: #- cat base base 1 duplicate 1 duplicate 3 unchanged 4 will change 5 gets deleted 7 duplicated 8 will change base cat left left 1 duplicate 1 duplicate 3 unchanged 4 changed 7 duplicated 6 new line 7 duplicated 8 changed left sed -e 1d left right git merge-file -p left base right #- The result looks like this, showing the duplicate collision: 1 duplicate 3 unchanged 4 changed left 7 duplicated 6 new line 7 duplicated === 7 duplicated 6 new line 7 duplicated right 8 changed But it should look like this instead: 1 duplicate 3 unchanged 4 changed 7 duplicated 6 new line 7 duplicated 8 changed A similar (but different) stupidity shows up if you remove line 3 from all three files. I tested this in 1.6.5 and the same thing occurs there, so this is NOT recent regression. Phil -- 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 PATCHv2] repack: rewrite the shell script in C.
This is the beginning of the rewrite of the repacking.
* Removed unneeded system header files
* corrected remove_pack to really remove any pack files with the given
sha1
* fail if pack-objects fails
* Only test t7701 (2nd) fails now with this patch.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Makefile| 2 +-
builtin.h | 1 +
builtin/repack.c| 411
git-repack.sh = contrib/examples/git-repack.sh | 0
git.c | 1 +
5 files changed, 414 insertions(+), 1 deletion(-)
create mode 100644 builtin/repack.c
rename git-repack.sh = contrib/examples/git-repack.sh (100%)
diff --git a/Makefile b/Makefile
index ef442eb..4ec5bbe 100644
--- a/Makefile
+++ b/Makefile
@@ -464,7 +464,6 @@ SCRIPT_SH += git-pull.sh
SCRIPT_SH += git-quiltimport.sh
SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-remote-testgit.sh
-SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
@@ -972,6 +971,7 @@ BUILTIN_OBJS += builtin/reflog.o
BUILTIN_OBJS += builtin/remote.o
BUILTIN_OBJS += builtin/remote-ext.o
BUILTIN_OBJS += builtin/remote-fd.o
+BUILTIN_OBJS += builtin/repack.o
BUILTIN_OBJS += builtin/replace.o
BUILTIN_OBJS += builtin/rerere.o
BUILTIN_OBJS += builtin/reset.o
diff --git a/builtin.h b/builtin.h
index 8afa2de..b56cf07 100644
--- a/builtin.h
+++ b/builtin.h
@@ -102,6 +102,7 @@ extern int cmd_reflog(int argc, const char **argv, const
char *prefix);
extern int cmd_remote(int argc, const char **argv, const char *prefix);
extern int cmd_remote_ext(int argc, const char **argv, const char *prefix);
extern int cmd_remote_fd(int argc, const char **argv, const char *prefix);
+extern int cmd_repack(int argc, const char **argv, const char *prefix);
extern int cmd_repo_config(int argc, const char **argv, const char *prefix);
extern int cmd_rerere(int argc, const char **argv, const char *prefix);
extern int cmd_reset(int argc, const char **argv, const char *prefix);
diff --git a/builtin/repack.c b/builtin/repack.c
new file mode 100644
index 000..f72911d
--- /dev/null
+++ b/builtin/repack.c
@@ -0,0 +1,411 @@
+/*
+ * The shell version was written by Linus Torvalds (2005) and many others.
+ * This is a translation into C by Stefan Beller (2013)
+ */
+
+#include builtin.h
+#include cache.h
+#include dir.h
+#include parse-options.h
+#include run-command.h
+#include sigchain.h
+#include strbuf.h
+#include string-list.h
+
+static const char *const git_repack_usage[] = {
+ N_(git repack [options]),
+ NULL
+};
+
+/* enabled by default since 22c79eab (2008-06-25) */
+static int delta_base_offset = 1;
+
+static int repack_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, repack.usedeltabaseoffset)) {
+ delta_base_offset = git_config_bool(var, value);
+ return 0;
+ }
+ return git_default_config(var, value, cb);
+}
+
+static void remove_temporary_files() {
+ DIR *dir;
+ struct dirent *e;
+ char *prefix, *path, *fname;
+
+ prefix = xmalloc(strlen(.tmp-1-pack) + 1);
+ sprintf(prefix, .tmp-%d-pack, getpid());
+
+ path = xmalloc(strlen(get_object_directory()) + strlen(/pack) + 1);
+ sprintf(path, %s/pack, get_object_directory());
+
+ fname = xmalloc(strlen(path) + strlen(/)
+ + strlen(prefix) + strlen(/)
+ + 40 + strlen(.pack) + 1);
+
+ dir = opendir(path);
+ while ((e = readdir(dir)) != NULL) {
+ if (!prefixcmp(e-d_name, prefix)) {
+ sprintf(fname, %s/%s, path, e-d_name);
+ unlink(fname);
+ }
+ }
+ free(fname);
+ free(prefix);
+ free(path);
+ closedir(dir);
+}
+
+static void remove_pack_on_signal(int signo)
+{
+ remove_temporary_files();
+ sigchain_pop(signo);
+ raise(signo);
+}
+
+void get_pack_sha1_list(char *packdir, struct string_list *sha1_list)
+{
+ DIR *dir;
+ struct dirent *e;
+ char *path, *suffix;
+
+ path = xmalloc(strlen(get_object_directory()) + strlen(/pack) + 1);
+ sprintf(path, %s/pack, get_object_directory());
+
+ suffix = .pack;
+
+ dir = opendir(path);
+ while ((e = readdir(dir)) != NULL) {
+ if (!suffixcmp(e-d_name, suffix)) {
+ char buf[255], *sha1;
+ strcpy(buf, e-d_name);
+ buf[strlen(e-d_name) - strlen(suffix)] = '\0';
+ sha1 = buf[strlen(e-d_name) - strlen(suffix) - 40];
+ string_list_append(sha1_list, sha1);
+ }
+ }
+ free(path);
+ closedir(dir);
+}
+
+/*
+ * remove_pack will remove any files following the pattern *${SHA1}.{EXT}
+ * where EXT is one of {pack,
Re: [PATCH v2] git-p4: Ask p4 to interpret View setting
ksaitoh...@gmail.com wrote on Wed, 14 Aug 2013 09:59 +0900: My only concern is in the commit message, about performance. A change that has lots of files in it will cause many roundtrips to p4d to do p4 where on each. When the files don't have much edited content, this new approach will make the import take twice as long, I'll guess. Do you have a big repository where you could test that? I measured performance of git p4 clone --use-client-spec with a repository it has 1925 files, 50MB. Original:8.05s user 32.02s system 15% cpu 4:25.34 total Apply patch:9.02s user 53.19s system 14% cpu 6:56.41 total It is acceptable in my situation, but looks quite slow... Then I implemented one batch query version 7.92s user 33.03s system 15% cpu 4:25.59 total It is same as original My additional patch is below. I investigate call graph (attached rough sketch) and implement batch query in commit() and splitFilesIntoBranches(). In addition, modified map_in_client to just search cache value. Could you accept? This looks good. I've started my own performance testing on a few-hundred-thousand file repo to confirm your findings. If it seems to work out, we can clean up the patch. Otherwise maybe need to think about having both implementations and use the by-hand one for I don't like that approach. Let's hope it's not needed. -- Pete Subject: [PATCH] git p4: Implement as one batch p4 where query to interpret view spec Query for each file is decrese performance. So I implement query to get client file path as one batch query. The query must called before use client path (map_in_client() ). Result of performance measurement, about 40% speed up Signed-off-by: KazukiSaitoh ksaitoh...@gmail.com --- git-p4.py | 70 ++- 1 file changed, 51 insertions(+), 19 deletions(-) diff --git a/git-p4.py b/git-p4.py index 40522f7..8cbee24 100755 --- a/git-p4.py +++ b/git-p4.py @@ -1849,37 +1849,46 @@ class View(object): if not exclude: self.mappings.append(depot_side) -def map_in_client(self, depot_path): -Return the relative location in the client where this - depot file should live. Returns if the file should - not be mapped in the client. +def convert_client_path(self, clientFile): +# chop off //client/ part to make it relative +if not clientFile.startswith(self.client_prefix): +die(No prefix '%s' on clientFile '%s' % +(self.client_prefix, clientFile)) +return clientFile[len(self.client_prefix):] -if depot_path in self.client_spec_path_cache: -return self.client_spec_path_cache[depot_path] +def update_client_spec_path_cache(self, files): +fileArgs = [f for f in files if f not in self.client_spec_path_cache] -where_result = p4CmdList(['where', depot_path]) -if len(where_result) == 0: -die(No result from 'p4 where %s' % depot_path) -client_path = +if len(fileArgs) == 0: +return # All files in cache + +where_result = p4CmdList([-x, -, where], stdin=fileArgs) for res in where_result: if code in res and res[code] == error: # assume error is ... file(s) not in client view -client_path = continue if clientFile not in res: die(No clientFile from 'p4 where %s' % depot_path) if unmap in res: # it will list all of them, but only one not unmap-ped continue -# chop off //client/ part to make it relative -clientFile = res[clientFile] -if not clientFile.startswith(self.client_prefix): -die(No prefix '%s' on clientFile '%s' % -(self.client_prefix, clientFile)) -client_path = clientFile[len(self.client_prefix):] +self.client_spec_path_cache[res['depotFile']] = self.convert_client_path(res[clientFile]) + +# not found files or unmap files set to +for depotFile in fileArgs: +if depotFile not in self.client_spec_path_cache: +self.client_spec_path_cache[depotFile] = + +def map_in_client(self, depot_path): +Return the relative location in the client where this + depot file should live. Returns if the file should + not be mapped in the client. + +if depot_path in self.client_spec_path_cache: +return self.client_spec_path_cache[depot_path] -self.client_spec_path_cache[depot_path] = client_path -return client_path +die( Error: %s is not found in client spec path % depot_path ) +return class P4Sync(Command, P4UserMap): delete_actions = ( delete,
[PATCH] Git segmentation faults if submodule path is empty.
Git fails due to a segmentation fault if a submodule path is empty.
Here is an example .gitmodules that will cause a segmentation fault:
[submodule foo-module]
path
url = http://host/repo.git
$ git status
Segmentation fault (core dumped)
This occurs because in the function parse_submodule_config_option, the
variable 'value' is assumed not to be null, and when passed as an
argument to xstrdup a segmentation fault occurs if it is indeed null.
This is the case when using the .gitmodules example above.
This patch addresses the issue by returning from the function if
'value' is null before the call to xstrdup is made.
Signed-off-by: Jharrod LaFon jlafon at eyesopen.com
---
submodule.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/submodule.c b/submodule.c
index 1821a5b..880f21b 100644
--- a/submodule.c
+++ b/submodule.c
@@ -130,7 +130,7 @@ int parse_submodule_config_option(const char *var, const
char *value)
const char *name, *key;
int namelen;
- if (parse_config_key(var, submodule, name, namelen, key) 0 ||
!name)
+ if (parse_config_key(var, submodule, name, namelen, key) 0 ||
!name || !value)
return 0;
if (!strcmp(key, path)) {
--
1.7.9.5
--
Jharrod LaFon
OpenEye Scientific Software
--
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 v7 1/3] branch: not report invalid tracking branch
Command git branch -vv will report tracking branches, but invalid
tracking branches are also reported. This is because the function
stat_tracking_info() can not distinguish whether the upstream branch
does not exist, or nothing is changed between one branch and its
upstream.
This patch changes the return value of function stat_tracking_info().
Only returns false when there is no tracking branch or the tracking
branch is invalid, otherwise true. If the caller does not like to
report tracking info when nothing changed between the branch and its
upstream, simply checks if num_theirs and num_ours are both 0.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
builtin/branch.c | 24
remote.c | 43 ++-
t/t6040-tracking-info.sh | 8 ++--
wt-status.c | 13 +++--
4 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0903763..3e016a6 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -424,19 +424,8 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
struct branch *branch = branch_get(branch_name);
struct strbuf fancy = STRBUF_INIT;
- if (!stat_tracking_info(branch, ours, theirs)) {
- if (branch branch-merge branch-merge[0]-dst
- show_upstream_ref) {
- ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
- if (want_color(branch_use_color))
- strbuf_addf(stat, [%s%s%s] ,
-
branch_get_color(BRANCH_COLOR_UPSTREAM),
- ref,
branch_get_color(BRANCH_COLOR_RESET));
- else
- strbuf_addf(stat, [%s] , ref);
- }
+ if (!stat_tracking_info(branch, ours, theirs))
return;
- }
if (show_upstream_ref) {
ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
@@ -448,19 +437,22 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
strbuf_addstr(fancy, ref);
}
- if (!ours) {
- if (ref)
+ if (!ours !theirs) {
+ if (show_upstream_ref)
+ strbuf_addf(stat, _([%s]), fancy.buf);
+ } else if (!ours) {
+ if (show_upstream_ref)
strbuf_addf(stat, _([%s: behind %d]), fancy.buf,
theirs);
else
strbuf_addf(stat, _([behind %d]), theirs);
} else if (!theirs) {
- if (ref)
+ if (show_upstream_ref)
strbuf_addf(stat, _([%s: ahead %d]), fancy.buf, ours);
else
strbuf_addf(stat, _([ahead %d]), ours);
} else {
- if (ref)
+ if (show_upstream_ref)
strbuf_addf(stat, _([%s: ahead %d, behind %d]),
fancy.buf, ours, theirs);
else
diff --git a/remote.c b/remote.c
index 2433467..26bd543 100644
--- a/remote.c
+++ b/remote.c
@@ -1729,7 +1729,8 @@ int ref_newer(const unsigned char *new_sha1, const
unsigned char *old_sha1)
}
/*
- * Return true if there is anything to report, otherwise false.
+ * Return false if cannot stat a tracking branch (not exist or invalid),
+ * otherwise true.
*/
int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
{
@@ -1740,18 +1741,12 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
const char *rev_argv[10], *base;
int rev_argc;
- /*
-* Nothing to report unless we are marked to build on top of
-* somebody else.
-*/
+ /* Cannot stat unless we are marked to build on top of somebody else. */
if (!branch ||
!branch-merge || !branch-merge[0] || !branch-merge[0]-dst)
return 0;
- /*
-* If what we used to build on no longer exists, there is
-* nothing to report.
-*/
+ /* Cannot stat if what we used to build on no longer exists */
base = branch-merge[0]-dst;
if (read_ref(base, sha1))
return 0;
@@ -1766,8 +1761,10 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
return 0;
/* are we the same? */
- if (theirs == ours)
- return 0;
+ if (theirs == ours) {
+ *num_theirs = *num_ours = 0;
+ return 1;
+ }
/* Run rev-list --left-right ours...theirs internally... */
rev_argc = 0;
@@ -1809,31 +1806,35 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
*/
int format_tracking_info(struct branch *branch, struct strbuf
[PATCH v7 3/3] status: always show tracking branch even no change
In order to see what the current branch is tracking, one way is using
git branch -v -v, but branches other than the current are also
reported. Another way is using git status, such as:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
But this will not work if there is no change between the current
branch and its upstream. Always report upstream tracking info
even if there is no difference, so that git status is consistent
for checking tracking info for current branch. E.g.
$ git status
# On branch feature1
# Your branch is identical to 'github/feature1'.
...
$ git status -bs
## feature1...github/feature1
...
$ git checkout feature1
Already on 'feature1'
Your branch is identical to 'github/feature1'.
...
Also add some test cases in t6040.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
remote.c | 7 ---
t/t6040-tracking-info.sh | 34 +-
wt-status.c | 9 +
3 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/remote.c b/remote.c
index 4caccb5..79effe6 100644
--- a/remote.c
+++ b/remote.c
@@ -1822,9 +1822,6 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
upstream_is_gone = 1;
break;
default:
- /* Nothing to report if neither side has changes. */
- if (!ours !theirs)
- return 0;
/* with base */
break;
}
@@ -1838,6 +1835,10 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
if (advice_status_hints)
strbuf_addf(sb,
_( (use \git branch --unset-upstream\ to
fixup)\n));
+ } else if (!ours !theirs) {
+ strbuf_addf(sb,
+ _(Your branch is identical to '%s'.\n),
+ base);
} else if (!theirs) {
strbuf_addf(sb,
Q_(Your branch is ahead of '%s' by %d commit.\n,
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 6f678a4..b24a18c 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -32,7 +32,8 @@ test_expect_success setup '
git checkout -b brokenbase origin
git checkout -b b5 --track brokenbase
advance g
- git branch -d brokenbase
+ git branch -d brokenbase
+ git checkout -b b6 origin
)
git checkout -b follower --track master
advance h
@@ -61,6 +62,7 @@ b2 origin/master: ahead 1, behind 1
b3 origin/master: behind 1
b4 origin/master: ahead 2
b5 brokenbase: gone
+b6 origin/master
EOF
test_expect_success 'branch -vv' '
@@ -93,6 +95,13 @@ test_expect_success 'checkout (upstream is gone)' '
test_i18ngrep is based on .*, but the upstream is gone. actual
'
+test_expect_success 'checkout (identical to upstream)' '
+ (
+ cd test git checkout b6
+ ) actual
+ test_i18ngrep Your branch is identical to .origin/master actual
+'
+
test_expect_success 'status (diverged from upstream)' '
(
cd test
@@ -113,6 +122,16 @@ test_expect_success 'status (upstream is gone)' '
test_i18ngrep is based on .*, but the upstream is gone. actual
'
+test_expect_success 'status (identical to upstream)' '
+ (
+ cd test
+ git checkout b6 /dev/null
+ # reports nothing to commit
+ test_must_fail git commit --dry-run
+ ) actual
+ test_i18ngrep Your branch is identical to .origin/master actual
+'
+
cat expect \EOF
## b1...origin/master [ahead 1, behind 1]
EOF
@@ -139,6 +158,19 @@ test_expect_success 'status -s -b (upstream is gone)' '
test_i18ncmp expect actual
'
+cat expect \EOF
+## b6...origin/master
+EOF
+
+test_expect_success 'status -s -b (identical to upstream)' '
+ (
+ cd test
+ git checkout b6 /dev/null
+ git status -s -b | head -1
+ ) actual
+ test_i18ncmp expect actual
+'
+
test_expect_success 'fail to track lightweight tags' '
git checkout master
git tag light
diff --git a/wt-status.c b/wt-status.c
index 46d181a..c8c2d77 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1395,10 +1395,6 @@ static void wt_shortstatus_print_tracking(struct
wt_status *s)
break;
default:
/* with base */
- if (!num_ours !num_theirs) {
- fputc(s-null_termination ? '\0' : '\n', s-fp);
- return;
- }
break;
}
@@ -1407,6 +1403,11 @@ static void wt_shortstatus_print_tracking(struct
wt_status *s)
color_fprintf(s-fp, header_color, ...);
color_fprintf(s-fp,
[PATCH v7 0/3] some enhancements for reporting branch tracking info
Changes since v6: * s/broken/gone/ in [PATCH 2/3] (branch: mark missing tracking branch as gone) * rewrite commit log for [PATCH 3/3] (status: always show tracking branch even no change) Jiang Xin (3): branch: not report invalid tracking branch branch: mark missing tracking branch as gone status: always show tracking branch even no change builtin/branch.c | 36 remote.c | 72 +-- t/t6040-tracking-info.sh | 89 +--- wt-status.c | 26 +++--- 4 files changed, 175 insertions(+), 48 deletions(-) -- 1.8.4.rc2.479.g44abce8 -- 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 v7 2/3] branch: mark missing tracking branch as gone
If a branch has been set to track a upstream, but the upstream branch
is missing, the tracking info is silently ignored in the output of
some commands such as git branch -vv and git status, as if there
were no such tracking settings.
Junio suggested missing upstream should be reported [1], such as:
$ git branch -v -v
mastere67ac84 initial
* topic 3fc0f2a [topicbase: gone] topic
$ git status
# On branch topic
# Your branch is based on 'topicbase', but the upstream is gone.
# (use git branch --unset-upstream to fixup)
...
$ git status -b -s
## topic...topicbase [gone]
...
In order to do like that, we need to distinguish these three cases
(i.e. no tracking, with configured but no longer valid tracking, and
with tracking) in function stat_tracking_info(). So the refactored
function stat_tracking_info() has three return values: -1 (with gone
base), 0 (no base), and 1 (with base).
[1]: http://thread.gmane.org/gmane.comp.version-control.git/231830/focus=232288
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Jiang Xin worldhello@gmail.com
---
builtin/branch.c | 18 --
remote.c | 44 +++
t/t6040-tracking-info.sh | 49 ++--
wt-status.c | 28 +--
4 files changed, 113 insertions(+), 26 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 3e016a6..ad0f86d 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -423,9 +423,20 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
char *ref = NULL;
struct branch *branch = branch_get(branch_name);
struct strbuf fancy = STRBUF_INIT;
+ int upstream_is_gone = 0;
- if (!stat_tracking_info(branch, ours, theirs))
+ switch (stat_tracking_info(branch, ours, theirs)) {
+ case 0:
+ /* no base */
return;
+ case -1:
+ /* with gone base */
+ upstream_is_gone = 1;
+ break;
+ default:
+ /* with base */
+ break;
+ }
if (show_upstream_ref) {
ref = shorten_unambiguous_ref(branch-merge[0]-dst, 0);
@@ -437,7 +448,10 @@ static void fill_tracking_info(struct strbuf *stat, const
char *branch_name,
strbuf_addstr(fancy, ref);
}
- if (!ours !theirs) {
+ if (upstream_is_gone) {
+ if (show_upstream_ref)
+ strbuf_addf(stat, _([%s: gone]), fancy.buf);
+ } else if (!ours !theirs) {
if (show_upstream_ref)
strbuf_addf(stat, _([%s]), fancy.buf);
} else if (!ours) {
diff --git a/remote.c b/remote.c
index 26bd543..4caccb5 100644
--- a/remote.c
+++ b/remote.c
@@ -1729,8 +1729,11 @@ int ref_newer(const unsigned char *new_sha1, const
unsigned char *old_sha1)
}
/*
- * Return false if cannot stat a tracking branch (not exist or invalid),
- * otherwise true.
+ * Compare a branch with its upstream, and save their differences (number
+ * of commits) in *num_ours and *num_theirs.
+ *
+ * Return 0 if branch has no upstream (no base), -1 if upstream is missing
+ * (with gone base), otherwise 1 (with base).
*/
int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
{
@@ -1749,16 +1752,16 @@ int stat_tracking_info(struct branch *branch, int
*num_ours, int *num_theirs)
/* Cannot stat if what we used to build on no longer exists */
base = branch-merge[0]-dst;
if (read_ref(base, sha1))
- return 0;
+ return -1;
theirs = lookup_commit_reference(sha1);
if (!theirs)
- return 0;
+ return -1;
if (read_ref(branch-refname, sha1))
- return 0;
+ return -1;
ours = lookup_commit_reference(sha1);
if (!ours)
- return 0;
+ return -1;
/* are we the same? */
if (theirs == ours) {
@@ -1808,17 +1811,34 @@ int format_tracking_info(struct branch *branch, struct
strbuf *sb)
{
int ours, theirs;
const char *base;
+ int upstream_is_gone = 0;
- if (!stat_tracking_info(branch, ours, theirs))
- return 0;
-
- /* Nothing to report if neither side has changes. */
- if (!ours !theirs)
+ switch (stat_tracking_info(branch, ours, theirs)) {
+ case 0:
+ /* no base */
return 0;
+ case -1:
+ /* with gone base */
+ upstream_is_gone = 1;
+ break;
+ default:
+ /* Nothing to report if neither side has changes. */
+ if (!ours !theirs)
+ return 0;
+ /* with base */
+ break;
+ }
base =
Re: [PATCH] create_delta_index: simplify condition always evaluating to true
On Thu, 15 Aug 2013, Junio C Hamano wrote: Forwarding to the area expert... Stefan Beller stefanbel...@googlemail.com writes: When checking the previous lines in that function, we can deduct that hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because the entries is capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so i will never be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com Acked-by: Nicolas Pitre n...@fluxnic.net You probably could dispense with the comment. The code is obvious enough and the commit log has the rationale already. --- diff-delta.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/diff-delta.c b/diff-delta.c index 93385e1..54da95b 100644 --- a/diff-delta.c +++ b/diff-delta.c @@ -154,8 +154,15 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize) */ entries = 0xfffeU / RABIN_WINDOW; } + + /* +* Do not check i 31 in the loop, because the assignement +* previous to the loop makes sure, hsize is definitely +* smaller than 131, hence the loop will always stop +* before i exceeds 31 resulting in an infinite loop. +*/ hsize = entries / 4; - for (i = 4; (1u i) hsize i 31; i++); + for (i = 4; (1u i) hsize; i++); hsize = 1 i; hmask = hsize - 1; -- 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 -- 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] create_delta_index: simplify condition always evaluating to true
On Thu, 15 Aug 2013, Eric Sunshine wrote: On Thu, Aug 15, 2013 at 5:34 PM, Stefan Beller stefanbel...@googlemail.com wrote: When checking the previous lines in that function, we can deduce that hsize must always be smaller than (1u31), since 506049c7df2c6 (fix 4GiB source delta assertion failure), because entries is capped at an upper bound of 0xfffeU, so hsize contains a maximum value of 0x3fff, which is smaller than (1u31), so the value of 'i' will never be larger than 31. Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- Eric, thanks for reviewing my patch. I applied the first 2 proposals (deduce, entries), but I disagree on the third, so I reformulated the sentence, as I really meant the variable i and not it as a pronoun. Thanks. Adding the quotes around 'i' makes your meaning clear. Without the quotes, apparently it was ambiguous, and my brain read it as a misspelling of 'it'. Do I understand right, you're suggesting to remove the source code comment? I did this now, but I have a bad feeling with it. The change of this patch surely removes dead code as of now and makes it more readable. But also it could become alive again, once somebody changes things nearby and forgets about the assumption, hsize not exceeding a certain size. That's why I put a comment in there, so the future changes nearby may be more careful. Indeed, I feel uncomfortable with the patch in general for the very reason that you state: it might become live again. Without the patch, the code remains safe without any extra effort. With this patch, even with the in-code comment, someone making changes needs to take special care. Sometimes it makes sense to leave safeties in place, even if they can't be triggered _today_; and safeties (such as i 31) also serve as documentation. That's also a valid argument. I don't think this loop is going to appear on any trace profile either. I personally have no strong opinion here. Nicolas -- 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] Add command `git bisect state` that checks if the current bisection process has reached the first bad commit.
On Thu, Aug 15, 2013 at 6:35 PM, Mattias Andrée maand...@operamail.com wrote:
This can be used for automated bisection without a check script.
Signed-off-by: Mattias Andrée maand...@operamail.com
---
Documentation/git-bisect.txt | 13 +
git-bisect.sh| 11 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index f986c5c..ca8c09d 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -25,6 +25,7 @@ on the subcommand:
git bisect visualize
git bisect replay logfile
git bisect log
+ git bisect state
git bisect run cmd...
This command uses 'git rev-list --bisect' to help drive the
@@ -104,6 +105,18 @@ For example, `git bisect reset HEAD` will leave you on
the current
bisection commit and avoid switching commits at all, while `git bisect
reset bisect/bad` will check out the first bad revision.
+Bisect state
+
+
+To see the bisection process has finnished, issue the following command:
s/see the/see if the/
s/finnished/finished/
+
+
+$ git bisect state
+
+
+Exit successfully (i.e., with return code 0), if and only if the current
+bisection has reached the first bad or possible first bad commit.
+
Bisect visualize
diff --git a/git-bisect.sh b/git-bisect.sh
index 9f064b6..6ddda34 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|state]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [--no-checkout] [bad [good...]] [--] [pathspec...]
@@ -23,6 +23,8 @@ git bisect log
show bisect log.
git bisect run cmd...
use cmd... to automatically bisect.
+git bisect state
+ check if the bisection is complete.
Please use git help bisect to get the full man page.'
@@ -491,6 +493,11 @@ bisect_log () {
cat $GIT_DIR/BISECT_LOG
}
+bisect_complete_state () {
+ cat $GIT_DIR/BISECT_LOG | tail -n 1 | grep -E '^# (possible |)first
bad commit:' /dev/null
+ exit $?
+}
+
case $# in
0)
usage ;;
@@ -519,6 +526,8 @@ case $# in
bisect_log ;;
run)
bisect_run $@ ;;
+ state)
+ bisect_complete_state ;;
*)
usage ;;
esac
--
1.8.3.4
--
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
--
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] Add command `git bisect state` that checks if the current bisection process has reached the first bad commit.
On Fri, 16 Aug 2013 00:17:27 -0400
Eric Sunshine sunsh...@sunshineco.com wrote:
On Thu, Aug 15, 2013 at 6:35 PM, Mattias Andrée
maand...@operamail.com wrote:
This can be used for automated bisection without a
check script.
Signed-off-by: Mattias Andrée maand...@operamail.com
---
Documentation/git-bisect.txt | 13 +
git-bisect.sh| 11 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-bisect.txt
b/Documentation/git-bisect.txt index f986c5c..ca8c09d
100644 --- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -25,6 +25,7 @@ on the subcommand:
git bisect visualize
git bisect replay logfile
git bisect log
+ git bisect state
git bisect run cmd...
This command uses 'git rev-list --bisect' to help
drive the @@ -104,6 +105,18 @@ For example, `git bisect
reset HEAD` will leave you on the current bisection
commit and avoid switching commits at all, while `git
bisect reset bisect/bad` will check out the first bad
revision.
+Bisect state
+
+
+To see the bisection process has finnished, issue the
following command:
s/see the/see if the/
s/finnished/finished/
Oh, I should have proofread the text. However,
the command name ‘state’ may not be the best,
but I could not think of anything better, so
I am open for comments on a better name.
The purpose of this patch is to provide an
issue what to do an automated `git bisect`
without having to write an script file.
This patch allows you to an automated by section
by just like if it was a manual, i.e. stating
with `git bisect start git bisect bad
git bisect good commit` but then type:
while ! git bisect state; do
test command git bisect good || git bisect bad
done
I think this is useful to lower the barrier
of entry for `git bisect`, as well as making
it easy to create regression testing scripts
that do not have to be run with `git bisect run`.
For example if you have a lot of regression tests,
you can have a script for each that tests if
if their is a bug and if so bisect it, and print
information about what is testing, all from with
script for each regression test. This way, you
can have a directory of regression tests that
are invoked just as normal script files and have
a master script that runs all of them.
So other developers on the project does not even
need to know how to use `git bisect`.
+
+
+$ git bisect state
+
+
+Exit successfully (i.e., with return code 0), if and
only if the current +bisection has reached the first
bad or possible first bad commit. +
Bisect visualize
diff --git a/git-bisect.sh b/git-bisect.sh
index 9f064b6..6ddda34 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|state]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [--no-checkout] [bad [good...]]
[--] [pathspec...] @@ -23,6 +23,8 @@ git bisect log
show bisect log.
git bisect run cmd...
use cmd... to automatically bisect.
+git bisect state
+ check if the bisection is complete.
Please use git help bisect to get the full man page.'
@@ -491,6 +493,11 @@ bisect_log () {
cat $GIT_DIR/BISECT_LOG
}
+bisect_complete_state () {
+ cat $GIT_DIR/BISECT_LOG | tail -n 1 | grep -E
'^# (possible |)first bad commit:' /dev/null
+ exit $?
+}
+
case $# in
0)
usage ;;
@@ -519,6 +526,8 @@ case $# in
bisect_log ;;
run)
bisect_run $@ ;;
+ state)
+ bisect_complete_state ;;
*)
usage ;;
esac
--
1.8.3.4
--
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
--
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
