Re: "groups of files" in Git?
Hi, I will choose a bit of a less diplomatic path here. Instead of trying to tell you how you can make git fit your needs, I would say that you shouldn't. I've two arguments: 1. It's always painful when you try to use a tool in some way it's not intended or used to work. If you're doing something different than anyone else using that tool, you're probably doing something wrong! I doubt that your case is so special, so my suggestion is to either use git the way most people use it, with one branch for each feature, or do not use git at all, since perforce seems to be better with your workstyle. 2. Git is a snapshot based SCM system. That means that each commit unique identify a version of the code. With your system (as well as any time you're not commiting all changed files) the commit is never tested. You've no idea of actually knowing if your two changes is dependent or not. Of course you can guess, but it's still a guess and in your current work way with perforce you have no way of knowing if your changesets have a dependency between eachother or not since you never test them individually. -- Please let me know if you feel that I've missed something. I can see four solutions: 1. Now I would suggest that you have each feature in a commit and simply run your tests every few commits so you don't have to run it for each commit. 2. Improve your build and test time. I'm sure there's things here to improve. 3. Continue to use perforce. If I recall correctly perforce has even a git integration today. 4. Use integration branches in git and run the tests on that branch. This can be easy todo if you write some scripts for it. Good luck! -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com
Re: git repo vs project level authorization
On Mon, Dec 05, 2016 at 03:33:51PM -0500, ken edward wrote: > I am currently using svn with apache+mod_dav_svn to have a single > repository with multiple projects. Each of the projects is controlled > by an access control file that lists the project path and the allowed > usernames. > > Does git have this also? where is the doc? > > Ken Git does not do hosting or access control. For this you need to use a third party program. There are plenty of options for you and each has different features and limitations. For example you should take a look at gitolite, gitlab, bitbucket, github, gogs. Just to mention a few. It's also possible to setup git with ssh or http/https with your own access control methods. See the progit book for details here. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com
Re: Git status takes too long- How to improve the performance of git
On Wed, Nov 16, 2016 at 05:13:57PM +0530, Renuka Pampana wrote: > > On Tue, Nov 15, 2016 at 02:33:12AM -0700, ravalika wrote: > > > It is an centralized server and git status takes too long > > > > A centralized server? How? git is designed to be runned locally. If > > you're running git on a network file system, the performance will > > suffer. Could you elaborate on how your environment is setup? > > > > > We have setup main git repository in remote location on Linux server > And created a git repository in local Linux server, as a reference for the > remote git repository, > And update the local git repository for every 15 min in local server > > Users will be able to access the local git repository through NFS And each user will have their own copy of the repository locally on their machine? That is having done a git clone? > > All users will clone the git repository from remote project url by using > local git repo as reference > > For example : git clone --reference ~/gitcaches/reference user@drupal > :/home/project/drupal.git > > All the users have ssh credentials for the remote server Why are you using --reference for a 8.9MB big clone? > > > What is the best way to implement remote git repo and able to access the > git repo from other location, without any performance glitches? > Users should be able to access git repo from different servers and from > different locations. The best way is to have it locally cloned. Yes the initial clone will be expensive but operations after that will be fairly smooth. You do not(!) want to execute git on one machine and having the repository beeing on an other machine (for example via a network file system, except git clone, git fetch, git push, etc.). > > > > > How to improve the performance of git status > > > > > > Git repo details: > > > > > > Size of the .git folder is 8.9MB > > > Number of commits approx 53838 (git rev-list HEAD --count) > > > Number of branches - 330 > > > Number of files - 63883 > > > Working tree clone size is 4.3GB > > > > .git folder of 8.9 MEGABYTE and working tree of 4.3 GIGABYTE? Is this a > > typo? > > > > All git related information is stored in .git directory of the working > directory > It is 8.9M > And size of the local workspace is 4.3G Can you please elaborate on this? How can you store 8.9 MB of data that will result in a 4.3 G workspace? -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com
Re: Git status takes too long- How to improve the performance of git
Hi, On Tue, Nov 15, 2016 at 02:33:12AM -0700, ravalika wrote: > We are using git-1.8.2 version for version control. That's a three (almost four) year old version of git. Your first test should be to see if an upgrade to a recent version will improve things. > It is an centralized server and git status takes too long A centralized server? How? git is designed to be runned locally. If you're running git on a network file system, the performance will suffer. Could you elaborate on how your environment is setup? > > How to improve the performance of git status > > Git repo details: > > Size of the .git folder is 8.9MB > Number of commits approx 53838 (git rev-list HEAD --count) > Number of branches - 330 > Number of files - 63883 > Working tree clone size is 4.3GB .git folder of 8.9 MEGABYTE and working tree of 4.3 GIGABYTE? Is this a typo? > > time git status shows > real 0m23.673s > user 0m9.432s > sys 0m3.793s > > then after 5 mins > real0m4.864s > user0m1.417s > sys 0m4.710s A slow disc and empty caches are slow. Two ways of improving this is to have faster discs or make sure your cache is up to date. When I'd a really slow disc, I'd my shell to run a git status in the background to load the cache everytime I started working on a project. This is however an ugly hack that wasn't approved to be a part of git. > > And I have experimented the following ways > - - Setting core.ignorestat to true > - - Git gc clean > - - Shallow clone – Reducing number of commits > - - Clone only one branch > - Git repacking - git repack -ad && git prune > - - Cold/warm cache > > Could you please let me know, what are the ways to improve the git > performance ? > I have gone through the mailing lists. You could always check the --assume-unchanged bit, see the manual page for git update-index. However this is quite extreme and demanding for the user. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com
Re: Why are there multiple ways to get the manual in Git?
On Sat, Sep 17, 2016 at 01:47:52PM -0400, Andrew Johnson wrote: > $ git help > $ git --help > $ man git- > > I tested all three to confirm they were equivalent. While I'm not able to answer your question, I can shred a little light about them not being equal. For example using a windows machine $ man git does not work and $ git help opens a webbrowser instead of a man page. Using a unix system I would however assume that $ man git would work since it's the standard way of getting help on those systems. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com
Re: Problem with --shallow-submodules option
On Mon, Jun 20, 2016 at 01:06:39PM +, Istvan Zakar wrote: > I'm working on a relatively big project with many submodules. During > cloning for testing I tried to decrease the amount of data need to be > fetched from the server by using --shallow-submodules option in the clone > command. It seems to check out the tip of the remote repo, and if it's not > the commit registered in the superproject the submodule update fails > (obviously). Can I somehow tell to fetch that exact commit I need for my > superproject? Maybe. http://stackoverflow.com/questions/2144406/git-shallow-submodules gives a good overview of this problem. git fetches a branch and is shallow from that branch, which might be an other sha1 than the one the submodule points to, (as you say). This is/was one of the drawbacks with this method. However the since git 2.8, git will try to fetch the sha1 direct (and not the branch). So then it will work, if(!), the server supports direct access to sha1. This was previously not allowed due to security concerns (if I recall correctly). So the answer is, yes this will work if you've a recent version of git and support on the server side for doing this. Unfortunately I'm not sure which git version is needed on the server side for this to work. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] On the --depth argument when fetching with submodules
On Fri, Feb 05, 2016 at 04:05:01PM -0800, Junio C Hamano wrote: > Stefan Beller <sbel...@google.com> writes: > > > Currently when cloning a project, including submodules, the --depth argument > > is passed on recursively, i.e. when cloning with "--depth 2", both the > > superproject as well as the submodule will have a depth of 2. It is not > > garantueed that the commits as specified by the superproject are included > > in these 2 commits of the submodule. > > > > Illustration: > > (superproject with depth 2, so A would have more parents, not shown) > > > > superproject/master: A <- B > > / \ > > submodule/master: C <- D <- E <- F <- G > > > > (Current behavior is to fetch G and F) > The --depth option to git submodule is something I've wondered for some time if it was correct to implement it or not. It's clearly not a complete feature yet and it has some weaknesses, the most obvious one stated above. The reason for implementing --depth in submodules was for people having huge (or many) submodules, that they aren't interested in developing in, but need to download to build their project. So they want to save time and bandwidth. My first thought was to implement depth from the sha1 the superproject refered sha1. However, when implementing this, git didn't support fetching a sha1 from a remote repository for security reasons (you should never be allowed to fetch a commit that is not reachable from a branch or tag). Waiting for this to be supported (an (expensive) check could be done if the sha1 asked for exists in any branch or tag), the --depth was added and it's a guessing game on how deep you should fetch. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Known issues in Git
On Thu, Dec 03, 2015 at 03:14:31PM +, Hamann, Kerstin wrote:
> Hi,
>
> I would like to have a list of known issues for Git (Server and Client) in
> order to do the risk analysis for Git and Bitbucket usage for a software
> project in the medical device development. Where can I find such a list? For
> Bitbucket it is easy (go to jira and open the project).
> Note: Configuration management tools for software projects in a regulated
> environment (IEC62304) have to be validated. That is not a big issue but that
> have to be done before a new git version is installed.
>
> Regards Brita
>
> --- This communication contains confidential information. If you are not the
> intended recipient please return this email to the sender and delete it from
> your records. Diese Nachricht enthaelt vertrauliche Informationen. Sollten
> Sie nicht der beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte
> diese an den Absender zurueck und loeschen Sie die E-mail aus Ihrem System.
> N?r??yb?X??ǧv?^?){.n?+ا???ܨ}???Ơz?:+v???zZ+??+zf???h???~i???z? ?w?&?)ߢf
Hi!
here's the returned email as you requested. I'll now delete your email.
--
Fredrik Gustafsson
phone: +46 733-608274
e-mail: iv...@iveqy.com
website: http://www.iveqy.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Clone repositories recursive with depth 1
On Wed, Nov 11, 2015 at 03:09:18PM +0100, Lars Schneider wrote: > Apparently this does not clone the submodules with "--depth 1" (using Git > 2.4.9). As a workaround I tried: > > git clone --depth 1 --single-branch > cd > git submodule update --init --recursive --depth 1 > > However, this does not work either as I get: > fatal: reference is not a tree: the main project> > Unable to checkout project> in submodule path This looks like a familiar bug to me. I'm not sure if it's a bug or a known behaviour. When the depth argument was introduced to submodules a year (or two) ago there was a know bug. I not sure if it's fixed or not. The problem is that git is/was unable to fetch a sha1 but only a branch or a tag. So fetching a submodule will fetch the HEAD of the submodule with the requested depth. Then git will try to checkout a sha1 of that submodule, which may or maynot exists. Say that you fetch master of a submodule of depth 1 and do a checkout of a commit that exists. When someonen else has pushed to that submodule, the commit will not longer be reachable from depth 1 and if someone else tries to clone with depth 1 it will fail with the same error message as you got. The solution to this is to allow git to fetch the sha1 the superproject points to direct when fetching the submodule. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git feature request: mark a commit as minor
On Fri, Oct 02, 2015 at 06:38:46PM -0300, Felipe Micaroni Lalli wrote: > A minor change (also called "cosmetic") usually is a typo fix, doc > improvement, a little code refactoring that don't change the behavior etc. > > In Wikipedia we can mark an edition as "minor". > > It would be nice to have an argument like "--minor" in git-commit to > mark the commit as minor. Also, filter in git-log (like --hide-minor) to > hide the minor changes. The git-log could be optimized to show minor > commits more discreetly. I can see your problem and implement your suggest is a solution that would work. However since this is a common problem, git already has a solution, that is the interactive rebase. You can read a discussion about when to use merge and rebase here: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html This work method make the "minor" commits to go away. There shouldn't be any minor, or "fixup" commits in your history (of course there's exception). Minor things should be caught in your code review process and then fixed, rebased and the merged again. Or do I miss a usecase here? -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git on vagrant shared folder
Hi, I don't know if this helps you, but I found two strange things with your history that I want to point out. On Tue, Jul 14, 2015 at 05:49:43PM +0200, Peter Hüfner wrote: The problem: For development we are using virtual box controlled via vagrant with a shared folder on windows and mac hosts. The virtual OS ist ubuntu 14.04.2 LTS. In march this year we started with git in version around 2.3. With cloning a repo directly in the shared folder we haven’t had any problems. So you're running git on windows/os x and store the files on a shared folder on Ubuntu? This will have some strange side effects. Synchronization errors with the shared folder and the different file systems used might cause a problem (or might not). This is a unusual usecase and _very complex_ use case. I wouldn't be surprised if it breaks (git have had several bugs on shared folders before). My advise is to run git on the same machine as you store the git repo on. Git should not be runned over a network (no matter if the network is local on your computer or not). A few weeks ago we weren’t able to clone and get an error: could not commit /vagrant/.git/config file. Manually we were able to change that file and also the clone command works outside the shared folder. Why are you trying to commit a file inside the .git dir? Files in that dir should not be commited (and I'm pretty sure there was a patch about this a while ago). The .git/config file for example is local to each git repo and should not be commited. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ssh admin git accidentally deleted
On Tue, Jul 07, 2015 at 08:30:59PM +0700, agnes retnaningsih wrote: Dear git , I accidentally delete ssh admin git, unfortunately there just one admin so I can't make a change in the config and push to the repository. If there's a way undo the change or make an existing user become an admin or is there any super admin command? Git does not have access control at all. There's no admin in git. You're talking about a hosting solution for git and you're not telling which one you're using. If you want a better answer you need to provide more information. _Assuming_ you're using gitolite on Linux you can always use the root account on the server to correct any mistakes you did in the gitolite configuration. I use git version 1.7.5.4 What's the reason for using a 4 year old version? You're missing a lot of development. It's like using an iPhone 4s today instead of an iPhone 6. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ssh admin git accidentally deleted
On Wed, Jul 08, 2015 at 12:32:42AM +0700, agnes retnaningsih wrote: I use gitolite on linux. he2nk is account that I delete on server where gitolite-admin is repository to change gitolite configuration. I still can make editing such as add user to access gitolite-admin but when I push it, it error ( file attached), I think it because the he2nk has been deleted. he2nk is ssh that I have deleted and push it to the server. So, if there anyway to revert the change I pushed?? so that I can make a change on gitolite admin. So from what I understand he2nk is a gitolite account and not a linux account. And you deleted he2nk from your gitolite-admin repository. Yes you can revert this and you can also add he2nk again, whatever you like. But as you've seen you can't do this with gitolite. You've to do this directly on the server since you don't have access to edit the gitolite-admin repository (if I guess correct). Please don't forget to CC the git-list. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git lock files (Was: GIT for Microsoft Access projects)
On Tue, Jun 09, 2015 at 10:19:43AM -0700, Stefan Beller wrote: Just because Git allows distributed workflows, doesn't mean we should only focus on being distributed IMHO. The question for content not being mergable easily pops up all the time. (Game/Graphics designers, documents, all this binary stuff, where there is no good merge driver). I could imagine a git lock command which looks like this: You do know that gitolite has locking functionality? -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Clarify documentation on commit message strip
On Mon, Apr 27, 2015 at 10:31:28AM -0700, Junio C Hamano wrote: Fredrik Gustafsson iv...@iveqy.com writes: I agree that it is very clear once you do edit the commit message. My main point with this patch was to clarify -v, since it's not obvious from the documentation that it will be removed. While I agree with you that the documentation should make it clear that the patch will not be part of the commit, I think the root cause of the current unclear-ness is because the documentation does not make it clear *WHY* the -v option gives the patch text there. I agree. Doing something like this on top of your patch may clarify the reason what -v is used for, and I suspect that it may even make it unnecessary to explicitly say that the patch text will not be part of the log message (but I didn't remove that with this how about this follow-up). Even better. I would be glad if this could make it into a release. Thanks for the feedback, to make this a good patch. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Clarify documentation on commit message strip
When using `-v` to add a unified diff to the commit message, this is stripped and not a part of the commit message. This is not mentioned. Add a note about this with the `-v` description and slightly modify the description for the default `--cleanup` mode. Signed-off-by: Fredrik Gustafsson iv...@iveqy.com --- I'd prefer the description not to be _too_ explicit e.g. by mentioning unified diff, etc. Personally I think it is sufficient to do s/#comment/comment/ to the existing text, without doing anything else. What is commentary to be removed is fairly clear in the contents given to the user in the editor. I agree that it is very clear once you do edit the commit message. My main point with this patch was to clarify -v, since it's not obvious from the documentation that it will be removed. I've no objections about your suggestions about the `strip` part. I hope I've understood you correctly and that this patch is correct. Documentation/git-commit.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 617e29b..1db4c7f 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -180,8 +180,8 @@ OPTIONS + -- strip:: - Strip leading and trailing empty lines, trailing whitespace, and - #commentary and collapse consecutive empty lines. + Strip leading and trailing empty lines, trailing whitespace, + commentary and collapse consecutive empty lines. whitespace:: Same as `strip` except #commentary is not removed. verbatim:: @@ -283,7 +283,8 @@ configuration variable documented in linkgit:git-config[1]. Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template. Note that this diff output doesn't have its - lines prefixed with '#'. + lines prefixed with '#'. This diff will not be a part + of the commit message. + If specified twice, show in addition the unified diff between what would be committed and the worktree files, i.e. the unstaged -- 2.1.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
[PATCH] Clarify documentation on commit message strip
When using `-v` to add a unified diff to the commit message, this is stripped and not a part of the commit message. This is not mentioned. Add a note about this with the `-v` description as well as description for the default `--cleanup` mode. Signed-off-by: Fredrik Gustafsson iv...@iveqy.com --- Documentation/git-commit.txt | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 617e29b..e31d828 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -180,8 +180,9 @@ OPTIONS + -- strip:: - Strip leading and trailing empty lines, trailing whitespace, and - #commentary and collapse consecutive empty lines. + Strip leading and trailing empty lines, trailing whitespace, + #commentary, unified diff added with `-v` and collapse + consecutive empty lines. whitespace:: Same as `strip` except #commentary is not removed. verbatim:: @@ -283,7 +284,8 @@ configuration variable documented in linkgit:git-config[1]. Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template. Note that this diff output doesn't have its - lines prefixed with '#'. + lines prefixed with '#'. This diff will not be a part + of the commit message. + If specified twice, show in addition the unified diff between what would be committed and the worktree files, i.e. the unstaged -- 2.1.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-archive ignores submodules
On Thu, Apr 16, 2015 at 06:35:38PM +0100, Pedro Rodrigues wrote: I've been using git-archive as my main way of deploying to production servers, but today I've come across a git repo with submodules and found out that git archive has no option to include submodules on the output archive. As far as I know this is an known limitation that's just waiting for someone to solve. Thanks for bringing attention to it. This simply makes git-archive unusable on this scenario. Not completely. There's a simple workaround. Combine git submodule foreach with git archive and make an archive for each submodule. Not as simple as if git archive --recurse-submodule would have been implementet, but hopefully it can make things work for you at the moment. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VCS popularity
On Wed, Apr 01, 2015 at 12:14:52AM +0200, Øyvind A. Holm wrote: On 1 April 2015 at 00:03, David Lang da...@lang.hm wrote: On Tue, 31 Mar 2015, Øyvind A. Holm wrote: openhub.net (formerly ohloh.net) has an interesting comparison of the number of public repositories on the net, based on searches of popular hosting services. This comparison is available at https://www.openhub.net/repositories/compare and shows an estimated market share between Bazaar, CVS, Git, Mercurial and Subversion. I've been monitoring this since 2014-08-05 to see how things were developing, and it's a good indication of the popularity of the various version control systems. number of repositories is an interesting datapoint, but activity in the repos would be far more interesting. There are a lot of repos of various types out there that haven't been touched for years. I do agree on that. Many repositories won't be deleted if they are converted to other VC systems to avoid breaking links and so on. What I found pretty interesting is the relative growth between the various systems. That's why I created the graphs that show creation of new repositories since August 2014 instead, for example https://github.com/sunny256/openhub-repositories/blob/master/graph/relative-zoom.svg Github is serving every git repo as a svn repo too (or at least did). In a talk they claimed to be the worlds biggest subversion host (if I recall correctly). However most people hosting on github doesn't do it to use svn but git. Anyway, this mean that for every github git repo there's one svn repo. Is github big enough to make the plots above invalid? -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git submodule purge
On Tue, Mar 17, 2015 at 09:18:26AM +0100, Patrick Steinhardt wrote: Is it even possible to create a new submodule without any upstream repository? At least `git submodule init` does not work without a corresponding entry in .gitmodules which the user would have needed to create himself manually. In this case one _could_ assume that the user knows what he is doing and expect him not to call `submodule purge` (or whatever the command will be called) on the authoritative copy. Other than that I've got no idea how to assure safety. Look at git/t/t7400-submodule-basic.sh for example at the test starting at line 84 on how to add a submodule without any upstream. Git has already a disadvantage against other SCM (like mercurial) because it's too easy to loose data with git. Meaning that we purge unrefered commits. (Yes this is up to debate if this is good or bad, but here's not the place). I think we should be very carefully with adding commands that permanently removes data. They should be really well crafted so that there's no way to do this by mistake. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Promoting Git developers
On Wed, Mar 11, 2015 at 09:53:22PM -0700, Junio C Hamano wrote: I'd first suggest to employ icase to unify *-By and *-by. Perhaps we would want a recommended list somewhere in SubmittingPatches to discourage people from getting too creative? There's already such list in SubmittingPatches, so there's already quite a few to choose from: Also notice that a real name is used in the Signed-off-by: line. Please don't hide your real name. If you like, you can put extra tags at the end: 1. Reported-by: is used to credit someone who found the bug that the patch attempts to fix. 2. Acked-by: says that the person who is more familiar with the area the patch attempts to modify liked the patch. 3. Reviewed-by:, unlike the other tags, can only be offered by the reviewer and means that she is completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. 4. Tested-by: is used to indicate that the person applied the patch and found it to have the desired effect. You can also create your own tag or use one that's in common usage such as Thanks-to:, Based-on-patch-by:, or Mentored-by:. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Thinning a repository
On Sun, Nov 30, 2014 at 01:18:34PM +0100, Yuri D'Elia wrote: Is there a quick way to reproduce the effect of a shallow clone on a local repository that doesn't involve filter-branch and/or re-clone? I'm curious, why is it a bad thing to do a re-clone? If you clone your local repo it would be really fast. -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to reduce disk usage for large .git dirs?
On Fri, Nov 14, 2014 at 11:14:27AM +0100, Olaf Hering wrote: So my repo-master is now bare. I pushed from repo-branchA into repo-master and see my commits in both repos. But pushing from repo-master to the remote fails because repo-master does not have outstanding remote commits. However, git fetch doesnt do anything: Are you mixing up your branches? So that you're updating one branch in your master repo but trying to push an other branch to your remote repo? -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to reduce disk usage for large .git dirs?
On Thu, Nov 13, 2014 at 12:14:44PM +0100, Olaf Hering wrote: How can I reduce the disk usage for multiple copies of the same repo? You can use --local och --shared. As you say --shared can be dangerous. If you don't understand the man page enough to know how you should manage your clones you should probably not use it. --local seems to be what you're looking for. However as a side note I'm curious about what your use case is. Why do you need this many repos? Your setup looks familiar to me for a subversion user switching to git and trying to use git as subversion. The common usecase is not to have multiple worktrees but to do a checkout to the worktree you need to work on. This is possible with git since it's very fast and I recommend you to try to use one worktree. -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to reduce disk usage for large .git dirs?
Thanks for sharing your notes! A few comments: On Thu, Nov 13, 2014 at 04:44:57PM +0100, Olaf Hering wrote: First clone the remote repository as usual. Then create a local branch for each remote branch that is supposed to be worked on: # git clone git://host/repo.git repo-master # cd repo-master # git checkout -b branchA origin/branchA # git checkout -b branchB origin/branchB # cd - Now clone each work branch into its own directory. The work dir references the master repo. All changes come from and go into this repo, instead of the remote repo. # git clone -l -b branchA repo-master repo-branchA # git clone -l -b branchB repo-master repo-branchB To make changs in a work dir, commit as usual. The changes will be pushed from the work copy into the local master repo. Its required to have some other branch than branchA active in repo-master, or push from work copy to repo-master will fail. That's one of the reason it's not recommended to push into a non-bare repository. You should clone your repo-master with the --bare option to avoid having a work dir there. To publish the outstanding changes its required to do this from the master repo. First checkout the work branch, then pull the local changes and finally push them to the remote repo. # cd repo-master # git checkout branchA # git pull # git push origin branchA # cd - It's not. You could just add your remote repository as a remote to each of your clones of your master repo and push directly from them. It would be much simplier and it would allow you to directly fetch changes from your remote into your branches as well. (however, I'm not sure but I think, that this will slowly increase the difference between your repositories when you develop. So that they won't change any new data since to local clone was made). -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Opinions] Integrated tickets
Hi, many developers rely on ticket systems (githubs issues, trac, bugzilla, etc.). To me a ticket often has a relation to one or more commits. Hence, even if git is functional in an offline enviroment, I can't work fully since none of the ticket systems above is distributed. This can be solved with a distributed ticket system. Fossil SCM is one example of an integrated ticket system into a scm (although please don't think about this is something that must be web-based). So my question is: what's your opinions on building an integrated ticket system on top of git? and (maybe mostly for Junio) Would such system possible be included in git.git? TL;DR; Is an integrated ticket system something for git? -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there way to set git commit --date to be older than 1970 ?
On Wed, Oct 29, 2014 at 07:49:19PM +0100, Peter Vojtek wrote: I am playing with git in slightly unusual manner - e.g., to use git to store history of europe: Actually you're the second person I hear that is trying to use git as a timeline of some sort. The previous person had the exact same problem. Unfortunately I couldn't find a mailthread about it in the archives. I'm curious, why did you choose git for this? Maybe this is a use case we should consider? -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] submodule: add ability to shallowly clone any branch in a submodule
On Thu, Sep 11, 2014 at 10:33:51PM +0200, Cole wrote: Also if there is anything else you are currently looking at regarding submodules or thinking about, I would be glad to hear about it or to try look at it while I am working on these changes. Or if there is anything you can think of for me to check with regards to these changes that would also be appreciated. When implementing the --depth argument for submodules, I would have prefered that the depth was set from the commit of the submodules refered from the superprojekt and not it's branch. However this can't be done, since you can only clone from refs and not from a commit. However there's nothing that stops us from allowing to clone from a commit (of course we need to make sure that that commit is in a tree with a ref as leaf). I see this as a natural next step for the --depth function and something needed for it to be really useful. I'm actually suprised that people successfully uses the --depth function already since you always need to know how deep down the commit is. -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why is git submodule slow under windows
On Fri, Jul 18, 2014 at 02:08:36PM +0200, Thomas Braun wrote: Am 18.07.2014 12:14, schrieb Armbruster Joachim (BEG/EMS1): Hello, We split a monolithic repository into ~50 submodules. The stored data has the same size. In the 1:1 comparison to the monolithic repository, the submodule handling is very slow. Under Linux everything remains fast, but windows is slow. So, why is git getting slow when it has to deal with a lot of submodules? I read something about the lack of the underlying cygwin to handle NTFS in a efficient way. Is this the root cause, or are there other causes also? Hi, I assume you are using the latetst git from https://msysgit.github.io on windows. I would guess that submodules on windows are slow because git-submodules.sh is a shell script, and bash on windows is not really that fast. My guess is that because the shell script uses fork() heavily and fork() is an expensive operation on Windows, that alone causes the slowddown. I did a quick test a while back when I rewrote part of git-submodule.sh in lua and runned it on my repo with ~45 submodules. The speedup was significant and should be even bigger on windows. -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Relative submodule URLs, and forks that haven't forked the submodule
So let me see if I understand you correctly. On Wed, Jun 11, 2014 at 12:15:39PM +0200, Charles Brossollet wrote: Hi, I'm banging my head on this problem: I have a central repo cloned by SSH, and a fork on the same server. The central remote is origin, and the fork is chbrosso-wip. $ git remote -v | grep origin origin chbrosso@lltech:/git/lightct.git (fetch) origin chbrosso@lltech:/git/lightct.git (push) $ git remote -v | grep chbrosso-wip chbrosso-wipchbrosso@lltech:~/prog/git/lightct.git (fetch) chbrosso-wipchbrosso@lltech:~/prog/git/lightct.git (push) On a local working copy, fetched my fork and checked out a remote branch out of it. Its remote-tracking branch is on the fork. $ git branch -vv | grep \* * actor d98ec24 [chbrosso-wip/actor] (commit msg) Now, submodules for this repo have relative URLs. And this is where the problem begins, because the submodule isn't forked, but resides only in origin. Fork is not a git thing. It's not a git command and it's not supported by git. You can of course easily do a fork of a git project, but git will be unaware of it beeing a fork. What you're saying is that you've one repository: lightct.git and one other repository which is a submodule to lightct.git at motors.git. Then you've made a copy of lightct.git to an other place for example: /some/other/path/lightct.git and the naturally the submodule path that's relative will point to /some/other/path/motors.git that doesn't exists, since you haven't copied motors.git But this shouldn't cause any problem, right? The docs says that if relative URL are used, they resolve using the origin URL. First issue, it's not the case: Orgin refers to the repository you cloned from. That is if you did git clone lightct.git my_working_copy the origin for my_working_copy would be lightct.git. However if you did git clone /some/other/path/lightct.git my_working_copy the origin for my_working_copy would be /some/other/path/lightct.git So to me it seems to be correct. $ cat .gitmodules [submodule motors] path = motors url = ../motors.git branch = master $ git submodule init motors Submodule 'motors' (chbrosso@lltech:~/prog/git/motors.git) registered for path 'motors' Here the submodule is registered on my fork, which doesn't exist, and it's wrong with what the documentation says. Fine, I'll edit the .git/config entry to make it point to origin: $ git config submodule.motors.url chbrosso@lltech:/git/motors.git $ git config submodule.motors.url chbrosso@lltech:/git/motors.git $ ssh chbrosso@lltech if [ -d /git/motors.git ]; then echo 'ok'; fi Password: ok So the submodule's url is changed, and points to a correct path, let's update so that I can work $ git submodule update motors Password: fatal: '~/prog/git/motors.git' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Unable to fetch in submodule path 'motors' That's right, it is still the old url, and I can't have my submodule! Here you change the path to the submodule at /some/other/path/lightct.git and then it isn't changed in my_working_copy. How could it? They don't communicate if you don't tell them to. Can someone explain what's going on? And how can I get my submodule in the working copy? Either created a copy of the submodule just as you did with lightct.git or use non-relative paths. -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sort entries numerically
On Sat, Jun 07, 2014 at 08:05:34AM +0200, Toralf Förster wrote: is there any chance to have 1.8 before 1.10 in an output like the following : ... From https://code.wireshark.org/review/wireshark 52fe0aa..b69642d master - origin/master 460db8a..540f061 master-1.10 - origin/master-1.10 25bb29a..5741a40 master-1.12 - origin/master-1.12 4ee4fc11..97898a2 master-1.8 - origin/master-1.8 I don't find anything about it in git branch man page. However there's always: git command | sort -d -r as a workaround. -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC memory leak?] Minor memory leak fix
Strbuf needs to be released even if it's locally declared.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
archive.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/archive.c b/archive.c
index 346f3b2..d6d56e6 100644
--- a/archive.c
+++ b/archive.c
@@ -113,6 +113,7 @@ static int write_archive_entry(const unsigned char *sha1,
const char *base,
struct git_attr_check check[2];
const char *path_without_prefix;
int err;
+ int to_ret = 0;
args-convert = 0;
strbuf_reset(path);
@@ -126,8 +127,10 @@ static int write_archive_entry(const unsigned char *sha1,
const char *base,
setup_archive_check(check);
if (!git_check_attr(path_without_prefix, ARRAY_SIZE(check), check)) {
- if (ATTR_TRUE(check[0].value))
- return 0;
+ if (ATTR_TRUE(check[0].value)) {
+ to_ret = 0;
+ goto cleanup;
+ }
args-convert = ATTR_TRUE(check[1].value);
}
@@ -135,14 +138,20 @@ static int write_archive_entry(const unsigned char *sha1,
const char *base,
if (args-verbose)
fprintf(stderr, %.*s\n, (int)path.len, path.buf);
err = write_entry(args, sha1, path.buf, path.len, mode);
- if (err)
- return err;
- return (S_ISDIR(mode) ? READ_TREE_RECURSIVE : 0);
+ if (err) {
+ to_ret = err;
+ goto cleanup;
+ }
+ to_ret = (S_ISDIR(mode) ? READ_TREE_RECURSIVE : 0);
+ goto cleanup;
}
if (args-verbose)
fprintf(stderr, %.*s\n, (int)path.len, path.buf);
- return write_entry(args, sha1, path.buf, path.len, mode);
+ to_ret = write_entry(args, sha1, path.buf, path.len, mode);
+cleanup:
+ strbuf_release(path);
+ return to_ret;
}
int write_archive_entries(struct archiver_args *args,
--
1.8.3.1.490.g39d9b24.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[[RFC memory leak, v.2]] Minor memory leak fix
Strbuf needs to be released even if it's locally declared.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
archive.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/archive.c b/archive.c
index 346f3b2..dfc557d 100644
--- a/archive.c
+++ b/archive.c
@@ -113,6 +113,7 @@ static int write_archive_entry(const unsigned char *sha1,
const char *base,
struct git_attr_check check[2];
const char *path_without_prefix;
int err;
+ int to_ret = 0;
args-convert = 0;
strbuf_reset(path);
@@ -127,22 +128,25 @@ static int write_archive_entry(const unsigned char *sha1,
const char *base,
setup_archive_check(check);
if (!git_check_attr(path_without_prefix, ARRAY_SIZE(check), check)) {
if (ATTR_TRUE(check[0].value))
- return 0;
+ goto cleanup;
args-convert = ATTR_TRUE(check[1].value);
}
if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
if (args-verbose)
fprintf(stderr, %.*s\n, (int)path.len, path.buf);
- err = write_entry(args, sha1, path.buf, path.len, mode);
- if (err)
- return err;
- return (S_ISDIR(mode) ? READ_TREE_RECURSIVE : 0);
+ to_ret = write_entry(args, sha1, path.buf, path.len, mode);
+ if (!to_ret)
+ to_ret = (S_ISDIR(mode) ? READ_TREE_RECURSIVE : 0);
+ goto cleanup;
}
if (args-verbose)
fprintf(stderr, %.*s\n, (int)path.len, path.buf);
- return write_entry(args, sha1, path.buf, path.len, mode);
+ to_ret = write_entry(args, sha1, path.buf, path.len, mode);
+cleanup:
+ strbuf_release(path);
+ return to_ret;
}
int write_archive_entries(struct archiver_args *args,
--
1.8.3.1.490.g39d9b24.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC memory leak?] Minor memory leak fix
On Tue, Mar 11, 2014 at 06:58:11PM +0700, Duy Nguyen wrote:
On Tue, Mar 11, 2014 at 5:45 PM, Fredrik Gustafsson iv...@iveqy.com wrote:
Strbuf needs to be released even if it's locally declared.
path is declared static. So yes it's a leak but the leak is minimum.
Your patch would make more sense if static is gone and it's leaked
after every write_archive_entry call.
That's one of the reasons of the RFC. I know Junio thinks that minor
things shouldn't be fixed by themselfes because it takes up review
bandwidth, so it's better to fix them once you touch that part of the
code anyway. (At least that's how I've understood him).
This leak is at about 4.1 kB so it's not huge.
+ if (ATTR_TRUE(check[0].value)) {
+ to_ret = 0;
+ goto cleanup;
+ }
to_ret is already 0 so I think goto cleanup; is enough.
Agree, fixed in next iteration.
err = write_entry(args, sha1, path.buf, path.len, mode);
- if (err)
- return err;
- return (S_ISDIR(mode) ? READ_TREE_RECURSIVE : 0);
+ if (err) {
+ to_ret = err;
+ goto cleanup;
+ }
+ to_ret = (S_ISDIR(mode) ? READ_TREE_RECURSIVE : 0);
+ goto cleanup;
Maybe if (err) to_ret = ...; else to_ret = ...; so we only need one
goto cleanup statement. Going even further:
to_ret = write_entry(...);
if (!to_ret) to_ret = (S_ISDIR(...));
goto cleanup;
Agree, fixed in next iteration.
--
Med vänlig hälsning
Fredrik Gustafsson
tel: 0733-608274
e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to shrink repository size
On Wed, Mar 05, 2014 at 08:55:30PM -0600, Robert Dailey wrote: What I'd like to do is somehow hunt down the largest commit (*not* blob) in the entire history of the repository to hopefully find out where huge directories have been checked in. I can't do a search for largest file (which most google results seem to show to do) since the culprit is really thousands of unnecessary files checked into a single subdirectory somewhere in history. Can anyone offer me some advice to help me reduce the size of my repo further? Thanks. I'm not sure if you can do this with git. However since git is a command line application it's pretty easy to script it with sh. The negative part beeing the lack of speed, but since this is a one-time thing I don't think that it matters. Since you told us that it is a commit with a huge number of files that you're looking for, I took that approach instead of calculating the size of each commit, since that would be more expensive to do. for commit in $(git log --pretty=oneline | cut -d -f 1) do nbr=$(git show --pretty=format: --name-only $commit | wc -l) echo $nbr: $commit done | sort | tail -1 This will give you the commit with most files changed. (Although, there will be a +1 error on the number of files edited). -- Med vänlig hälsning Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Limiting disk usage
On Wed, Oct 30, 2013 at 04:39:02PM +0100, Jakub Narębski wrote: From time to time you can find there ideas about adding floating mode to git-submodule, but as far as I know up till now without effect... How about git submodule update --remote ? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation for fetch, url, branches, tags keywords in git config?
On Tue, Oct 29, 2013 at 07:23:20PM +, Jim Garrison wrote: A typical config [svn-remote svn] noMetadata = 1 url = http://repository.url/svn fetch = trunk/etl_app:refs/remotes/etl_app/trunk branches = branches/etl_app/*:refs/remotes/branches/* tags = tags/etl_app/*:refs/remotes/tags/* However, the manpage for git-config(1) does not include anything exlicit on url, fetch, branches, 'tags, and the meaning of the syntax following the colon. Where can I find this info? Is the info in here what you're looking for? http://jk.gs/git-svn.html -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: separate-git-dir doesn't work with mapped drive
On Sat, Oct 19, 2013 at 11:49:27AM +0300, Ain Valtin wrote: Hi I want to use git in a VirtualBox guest so that the repository is on the host drive. So in the VB settings for the guest I set up a shared folder gitRepos to /home/ain with full access rights. Then in the guest OS (Windows XP) I map this shared folder as G drive. Now in the project dir I execute C:\...\TPPgit init --separate-git-dir g:/TPP Initialized empty Git repository in g:/TPP/ Checked, the repo structure is in the g:/TPP/ (thus the guest OS can write to the mapped dir) and in the .git file created to the project dir there is line gitdir: g:/TPP However when tring to use the repo it fails to recognise the g:/TPP path, ie C:\...\TPPgit add . fatal: unable to access '../../../../../../g:/TPP/config': Invalid argument Also tryed gitdir: //VBOXSVR/gitRepos/TPP but this fails too: C:\...\TPPgit add . fatal: Unable to create 'C:/Documents and Settings/Ain/prog/AVT/TPP/../../../../../..///VBOXSVR/gitRepos/TPP/index.lock': No such file or directory Am I doing something wrong or is it a bug? Any idea how to get it to work? BTW the VB is 3.0.14 ie rather old version but it seems that this isn't the problem as the git init recognises the mapped drive but other commands fail. git version is 1.8.4.msysgit.0 TIA ain -- 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 has a bad history with mapped drives in windows. It's also usually a bad idea to use git over the network (and most mapped drives are over the network and not local between virt. machines). I would advise not to use this setup since for the past two years that git has sometime worked and sometimes not with this setup. (It's not just seperate git dir, a git dir at all over a smb share have been problematic). (This is probably something we should have in a test-suite somewhere.) -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: separate-git-dir doesn't work with mapped drive
On Sat, Oct 19, 2013 at 02:45:46PM +0300, Ain Valtin wrote: On Sat, Oct 19, 2013 at 2:11 PM, Fredrik Gustafsson iv...@iveqy.com wrote: Git has a bad history with mapped drives in windows. It's also usually a bad idea to use git over the network (and most mapped drives are over the network and not local between virt. machines). I would advise not to use this setup since for the past two years that git has sometime worked and sometimes not with this setup. (It's not just seperate git dir, a git dir at all over a smb share have been problematic). That's a shame :( As I wrote I want to use git in a virtual machine and as a extra precaution it would be nice to have the repo outside of the VM, on the host drive - should the VM not to start up for whatever reason I wouldn't lose my repo with it... ain A better way (if you can afford it) is to have a repo on the virtual machine and push to a repo on your hostmachine (so that you've two repos). However your solution should work but I personally have had some problems with that area. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2014: Summary so far, discussion starter: how to improve?
Hi, so I was a GSoC:er, I got some (most) of my code merged but didn't fully met my (personal) goals for the project. However I do passed in the eyes of Google. GSoC is _hard_. You end up feeling completely stupid over and over again. Git has hard standards. Beeing just a single programmer and/or just learnt programming in school, there's a lot of difference. I started with learning git (better), read documentation and looking at the codebase and still felt lost. After that I'd to learn communication skills, who to mail, when to mail, how to write a commit message, been real strict with codestyle, setting up a github account, configuring git in a git contributor friendly way, etc. On Sat, Oct 19, 2013 at 08:09:33AM +0200, Thomas Rast wrote: Theories These are the hypotheses that I have heard (mostly in [1] and [2]) as to what is bad about Git's prior GSoC participations. * Aiming far too high, focusing on cool/shiny projects with a large impact. This also affects the students, who tend to cluster around the largest, shiniest project suggestions. * Diminishing returns: Git is too mature, with little low-hanging fruit left, making such projects harder * Projects are too political, progress depending on non-technical arguments * Our mentors suck on various axes, notably not supporting students enough in things that matter: - smooth interaction with community - ensure fast iteration/short cycles - navigating the code base * Scope creep: projects tend to get blocked on some bigger refactoring/restructuring task that was not in the original proposal * View GSoC much more as a lot of work than free labor Totally agree, GSoC is an investment for future labor, not labor. * Break projects into smaller, easier tasks - They should individually be simple, quick things if the mentor did them. - Should be parallelizable so students don't have to block on reviews. I'd 5-6 smaller projects setup for the summer, I think I managed to do 2-3 of them. (I did however do everything I applied for). I really think it's an excellent idea. This also meant that while one patch waited for review, I'd other things to work on. * Mentoring improvements: - Always have a co-mentor - Focus on social aspects (who to Cc, etc.) - Nominate separate review mentors to ensure fast review cycles I like the idea of review mentors. However bear in mind that you'll already have three people reviewing the patches (two mentors and Junio). We will not make it look like it's impossible to get things into git.git. * Have students review some patches This would be excellent. That's a part that I thinks is very usefull and would easy students remaining with git. It's easier to review patches than to make them. As a last part I would say that GSoC learned me a lot. I'm good at git, I know test driven development, I learned shell, I got to play with a huge C-codebase for the first time and I learned open source projects, QA, etc. I would like to thank Jens and Heiko for good mentoring and a lot of patience! (as a sidenote, I did get extremly busy when the school started. I didn't even had time to fix a serious bug in my code (Jens had to clean up after me). However two years later I'd some time again and got a few patches in and I hope to get a few patches into git in the future too). A successful GSoC for git isn't a merged project but continued contribution to git (not necessairly in patches, but also in support and review). A successful GSoC for Google/student is a merged project. A successful GSoC for student is a great learning experience. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: book version
On Thu, Oct 03, 2013 at 04:08:57PM -0400, DynV wrote: Hello, I haven't subscribed to the mail-list as the beginning of Community http://git-scm.com/community hint it's not necessary ; please inform me if I need to be in order to get a reply. I have an old PDF version of Pro Git. In the file, there doesn't seem to be a version. Both the local (downloaded) and the on-line file names are the same. I'd rather not download the same thing twice. I would have hoped there would have been either a version or a check-sum so I'd be sure I have the most up-to-date book. The following are the check-sums of my local book md5 301c91ac7084bea424e753dec694d9ca sha1 139d593611ed366700abfb291bd90e262e40afe3 Thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I looks like you've the latest version. Details: iveqy@kolya:~$ wget https://github.s3.amazonaws.com/media/progit.en.pdf --2013-10-03 22:11:58-- https://github.s3.amazonaws.com/media/progit.en.pdf Slår upp github.s3.amazonaws.com (github.s3.amazonaws.com)... 205.251.242.248 Ansluter till github.s3.amazonaws.com (github.s3.amazonaws.com)|205.251.242.248|:443... ansluten. HTTP-begäran skickad, väntar på svar... 200 OK Längd: 5630471 (5,4M) [application/pdf] Sparar till: progit.en.pdf 100%[==] 5 630 471144K/s på 44s 2013-10-03 22:12:48 (124 KB/s) - progit.en.pdf sparades [5630471/5630471] iveqy@kolya:~$ md5sum progit.en.pdf 301c91ac7084bea424e753dec694d9ca progit.en.pdf iveqy@kolya:~$ sha1sum progit.en.pdf 139d593611ed366700abfb291bd90e262e40afe3 progit.en.pdf iveqy@kolya:~$ -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] New hash table implementation
On Tue, Sep 24, 2013 at 11:50:16AM +0200, Karsten Blees wrote: Tests can be reproduced with 'time echo perfhash[map] method 1000 | ./test-hashmap', see test-hashmap.c for definition of method flags. So I'm still curious about the actual performance improvements for git. I runned git describe on the linux kernel with both the old hashmap and this new one: With old hashmap iveqy@minilla:/srv/slask/linux$ time ../git/git describe v3.12-rc2-83-g4b97280 real0m0.236s user0m0.216s sys 0m0.020s iveqy@minilla:/srv/slask/linux$ time ../git/git describe v3.12-rc2-83-g4b97280 real0m0.236s user0m0.220s sys 0m0.016s iveqy@minilla:/srv/slask/linux$ time ../git/git describe v3.12-rc2-83-g4b97280 real0m0.236s user0m0.212s sys 0m0.024s With new hashmap iveqy@minilla:/srv/slask/linux$ time ../git/git describe v3.12-rc2-83-g4b97280 real0m0.236s user0m0.216s sys 0m0.020s iveqy@minilla:/srv/slask/linux$ time ../git/git describe v3.12-rc2-83-g4b97280 real0m0.235s user0m0.216s sys 0m0.020s iveqy@minilla:/srv/slask/linux$ time ../git/git describe v3.12-rc2-83-g4b97280 real0m0.235s user0m0.208s sys 0m0.028s I can't see any improvements at all here. What do I miss? Am I running git describe in the wrong way? Does linux.git have too few tags to be important? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] New hash table implementation
On Thu, Sep 26, 2013 at 05:26:27PM +0700, Duy Nguyen wrote: On Thu, Sep 26, 2013 at 5:16 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Tue, Sep 24, 2013 at 11:50:16AM +0200, Karsten Blees wrote: Tests can be reproduced with 'time echo perfhash[map] method 1000 | ./test-hashmap', see test-hashmap.c for definition of method flags. So I'm still curious about the actual performance improvements for git. I runned git describe on the linux kernel with both the old hashmap and this new one: ... I can't see any improvements at all here. What do I miss? Am I running git describe in the wrong way? Does linux.git have too few tags to be important? I wonder if it makes any difference if there are a lot more refs. I hear gerrit creates a lot but don't know how many. linux-2.6 has ~350 refs. How about increasing the number of refs to 3500 refs? So I runned: for i in $(git rev-list HEAD ); do git tag tag$i $i ; done in my linux repo and aborted it after a while: iveqy@minilla:/srv/slask/linux$ git tag | wc -l 9323 So it's a few at least. Not sure how those artificial tagnames would hurt or improve the performance. Old hashtable = iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280 real0m0.384s user0m0.288s sys 0m0.092s iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280 real0m0.383s user0m0.284s sys 0m0.100s iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280 real0m0.386s user0m0.312s sys 0m0.072s New hashtable = iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280 real0m0.382s user0m0.300s sys 0m0.084s iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280 real0m0.382s user0m0.288s sys 0m0.092s iveqy@minilla:/srv/slask/linux$ time ../git/git describe HEAD v3.12-rc2-83-g4b97280 real0m0.384s user0m0.296s sys 0m0.088s -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] New hash table implementation
On Tue, Sep 24, 2013 at 11:50:16AM +0200, Karsten Blees wrote: Regarding performance, I have to admit that the difference between the two implementations is far greater than I had anticipated. The following times (in seconds) are from Linux x64 (Debian Sarge) on a Core i7 860 @2.8GHz. All tests have been run with 1,000 rounds of 100,000 entries each. The 'get 10% hits' test does 100,000 lookups on a table with 10,000 entries (i.e. 90% unsuccessful lookups). The rows denote different hash functions with different qualities: - FNV: FNV-1 hash on stringified loop counter (i.e. fnv1(itoa(i))), as an example of a high quality / low collision hash - i: just the loop counter (i.e. 0, 1, 2,...), guaranteed collision free - i/10: every 10 entries share the same hash code, lots of collisions The i and i/10 tests show that open addressing suffers badly from clustering, i.e. with adjacent hash codes, it degrades to linear search. The *2 versions provide for some space between used buckets to better compare it to the chaining version. | add| get 100% hits |get 10% hits | hash | hashmap | hash | hashmap | hash | hashmap ++-+---+-+-+ FNV | 14.815 | 2.345 | 3.059 | 1.642 | 4.085 | 0.976 FNV x2 | 14.409 | 2.706 | 2.888 | 1.959 | 3.905 | 1.393 i | 7.432 | 1.593 | 1.364 | 1.142 | 413.023 | 0.589 ix2 | 9.169 | 1.866 | 1.427 | 1.163 | 0.757 | 0.670 i/10| 1.800 | 1.555 | 5.365 | 6.465 | 32.918 | 1.052 i/10 x2 | 1.892 | 1.555 | 5.386 | 6.474 | 1.123 | 1.206 Tests can be reproduced with 'time echo perfhash[map] method 1000 | ./test-hashmap', see test-hashmap.c for definition of method flags. So I did this improved hash implementation a few months back. Although I could do a test like this and see an improvement, I failed to see an improvement in actual git usage. Hopefully it was just me doing something wrong, but I abandonned the idea of a better hashmap since I couldn't see any major performance boost using git and the current implementation is really simple and easy to maintain. So my question to you is, does your hashmap speed up git? And does it speed it up enough to justify that your implementation is the double amount of code than the current? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/7] Support for Ruby
On Sun, Sep 22, 2013 at 12:36:51AM -0500, Felipe Contreras wrote: I think it's a bad idea to introduce an entirely new runtime, especially one known to occasionally blow up on less-common architectures, without some advance notice. This is just FUD. What do you mean blow up on less-common architectures? Do you have actual evidence or can we just dismiss that as a baseless argument? For example, at work I would not be able to deploy a git using Ruby immediately because Git is an RPM and Ruby is compiled from source, if it is even present at all. Again, what do you mean? In all the distributions I've seen, vim is compiled with Ruby support by default, so unless you think vim is an essoteric package, libruby is almost definetly packaged and available. It would actually be usefull to know stats on where git is runned. In my world of embedded computing, ruby support definitely isn't a standard, nor is glibc. As for architecture speaking I think it's important that git works on ARM since that architecture increases on the server market. I've no idea if this is a problem with ruby or not. Also, the only Python script that is shipped with Git is git-p4, which is essentially optional, since most git users probably do not use Perforce. Otherwise, all the scripts in git are shell or Perl. Neither perl, nor shell, nor python scripts solve the forking problem. My proposal does. It does, and so does Lua, which can be bundled with git and used in the configuration files as well and is pure ansi C. However bundling something has it bad sides too. At least this will solve the dependency problem. So let the language war begin =). -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/7] Support for Ruby
On Sun, Sep 22, 2013 at 02:43:39AM -0500, Felipe Contreras wrote: It would actually be usefull to know stats on where git is runned. In my world of embedded computing, ruby support definitely isn't a standard, nor is glibc. I come from the embedded world as well, and I've never seen Git used there. I'd say Windows support is much more important than embedded, and we are not supporting that properly. Me neither, it doesn't mean that it isn't used though... I agree with the lack of windows support from git.git. However since Microsoft working with libgit2 on a Visual Studio plugin this it might be that the need for windows support decreases. Also, the only Python script that is shipped with Git is git-p4, which is essentially optional, since most git users probably do not use Perforce. Otherwise, all the scripts in git are shell or Perl. Neither perl, nor shell, nor python scripts solve the forking problem. My proposal does. It does, No, it does not. All the **current** perl/shell/python scripts use 'git foo' commands to achieve everything. As I said, It does meaning Your solution solves the forking problem. and so does Lua, There is no lua in Git. There's no ruby in git either as far as I know... (and no, I don't think contrib/ counts). which can be bundled with git and used in the configuration files as well and is pure ansi C. However bundling something has it bad sides too. At least this will solve the dependency problem. So let the language war begin =). Talk is cheap, show me the code. See this thread by Jeff King: http://thread.gmane.org/gmane.comp.version-control.git/206335/focus=206337 And see my humble test of what the speedup would be for git-submodule even with a faulty lua integration (still forking... but huge performance boost anyway): http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051 As you can see a lua integration would increase the git binary with 300kb. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Locking files / git
On Tue, Sep 17, 2013 at 09:45:26PM +0200, Nicolas Adenis-Lamarre wrote: Ooops. It seems that each time somebody says these two words together, people hate him, and he is scorned by friends and family. For the moment, i want a first feedback, an intermediate between locking is bad and ok, but i would prefer in the negativ answer something with arguments (Take CVS as an example of what not to do; if in doubt, make the exact opposite decision. is one), and in the positiv answer, good remarks about problems with my implementation that could make it better. So working with locks and text-files is generally stupid to do with git since you don't use git merging capabilities. Working with binary files in git is stupid because git doesn't handle them very well because they the deltas can't be calculated very good. It seems to me that if you need to do locking one of the above scenarios is true for you and you should not use git at all. However, there's always the case when you've a mixed project with both binary and text-files. In that case I believe Jeff gave an excellent answer. But think twice, are you using git in a sane way? Even a small binary file will result in a huge git repo if it's updated often and the project has a long history. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git undo # last command
On Fri, Aug 16, 2013 at 04:21:59PM +0200, Saša Tomić wrote: git commit == git reset --soft HEAD^ The commit does still exists, you can find it in the reflog. This is important if you for example commits a huge file and wants to remove it. That commit needs to be gc:ed too, and this is dangerous... It's a not common, but often asked, question on #git@freenode . And for many it's hard to understand why a git rm doesn't shrink their repo. Also consider that many git commands relies on eachother. For example the submodule scripts uses git checkout, clone, etc. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I automatically create a GIT branch that represents a sequence of tags?
On Sun, Aug 11, 2013 at 07:16:30AM +0200, Michael Haggerty wrote: On 08/11/2013 01:20 AM, Fredrik Gustafsson wrote: [...] It would be very hard to do a tool such as you describe, the reason is that there's no sane way to order your tags. Git today show tags alphabetically, all versions does not have a alphabtic order. [...] It would be quite easy to make a script that create such branch for you, if you only can sort the tags somehow. GNU sort has a nice option that can sort this way: -V, --version-sort Sort by version name and number. It behaves like a standard sort, except that each sequence of decimal digits is treated numerically as an index/version number. That's a nice feature, I remember we had that one as a feature request for git tag just a few days ago. It works well with git.git version numbers but won't be usefull in this case for git.git since git.git has other tags too (like the gitgui version tags). However if you've a nice namespace for the tags where you only tags versions, it might be an alternative. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I automatically create a GIT branch that represents a sequence of tags?
On Sun, Aug 11, 2013 at 12:13:18PM +0100, Kristian Freed wrote: On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson iv...@iveqy.com wrote: I don't understand, why is it better to find between which tags a error was found and not in what commit. It's much easier to find a bug introduced in a commit than in a tag/release. It sounds like you're doing the bug hunting harder. Could you explain this further? For better or worse, the current state includes a lot of noisy fixing tests type commits which I would like to automatically skip over when hunting bugs. This is not great and is being addressed, but I am trying to make the most of the historical data we have today - which does contain tags for all builds that passed automated testing etc but does not have only good commits on the related branch. Thank you, that make sense (even if it's really sad to have such history). My suggestion if you want to do this, is to have your buildtool to checkout a special branch (let's call it tag_branch) do a git reset to get the worktree from the newly tagged commit and commit on that branch once for each tag it's creating, when it creates the tag. I can see how this would work, but only for future builds. I would need something like it but loop over all existing tags as this is a problem with historical data. Could you please be more specific as to the steps required to automatically form a commit that represents the change between two commits (i.e. tags)? Create an orphan branch: git checkout --orphan tag_branch Now for every tag, t: git checkout t git reset --soft tag_branch git add . git commit -m t -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone doesn't work in symlink dir roots on Windows
On Sat, Aug 10, 2013 at 03:10:49PM +0300, Sedat Kapanoglu wrote: My D:\src folder is a symlink to another folder in my Google Drive, created by Windows command mklink /d d:\src d:\Google Drive\src D:\srcgit clone https://github.com/jlewallen/jenkins-hipchat-plugin.git Cloning into 'jenkins-hipchat-plugin'... fatal: Invalid symlink 'D:/src': Function not implemented git is a disk intense program, so this setup is not sane at all. With that said I know that git on windows historically had problems with working on smb-mounted shares (sometimes you're forced to have stupid setups). I doubt that git really is the right tool for your work, since you're using a decentralized tool in a centralized work flow. Maybe something like subversion would suite you better. (or just simple use a hosting service such as github/bitbucket/your own server). However I can't find that error message in the git source code which make me wonder if this actually is a git problem. Could you investigate more on where that error message comes from? Using dropbox git users have experienced corrupt repositories due to the dropbox sync algoritm isn't suited for the git file access patterns, I would imagine that you could have the same problems using google drive. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I automatically create a GIT branch that represents a sequence of tags?
On Sat, Aug 10, 2013 at 11:29:45PM +0100, Kristian Freed wrote: In our current setup, we have automatic tagging in git of all successful release builds. This makes it easy to go back to stable points in history and compare functionality, check when bugs were introduced etc. To help with this process further, it would be useful to be able to use git bisect, but as these are just a sequence of tags, not commits on a branch, git bisect will not work as is. Is there any tooling for automatically recreating a branch from a sequence of tags, where each generated commit is the calculated delta between each two neighbouring tags? I don't understand, why is it better to find between which tags a error was found and not in what commit. It's much easier to find a bug introduced in a commit than in a tag/release. It sounds like you're doing the bug hunting harder. Could you explain this further? It would be very hard to do a tool such as you describe, the reason is that there's no sane way to order your tags. Git today show tags alphabetically, all versions does not have a alphabtic order. You could argue that it should be in the order of the tagged commits commit date, however the commits are not ordered by date, an older commit can have a younger commit as a parent. You could say that the tag order is the order you find the tags if you go from a branch and backwards in the history, however how do you then choose which path to take when you find a merge? My suggestion if you want to do this, is to have your buildtool to checkout a special branch (let's call it tag_branch) do a git reset to get the worktree from the newly tagged commit and commit on that branch once for each tag it's creating, when it creates the tag. It would be quite easy to make a script that create such branch for you, if you only can sort the tags somehow. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] rm: delete .gitmodules entry of submodules removed from the work tree
On Thu, Aug 08, 2013 at 07:11:04PM +0200, Jens Lehmann wrote: Am 07.08.2013 20:28, schrieb Fredrik Gustafsson: On Tue, Aug 06, 2013 at 02:11:56PM -0700, Junio C Hamano wrote: Thanks, will replace the top two commits and queue. Looks like we are getting ready for 'next'? I'm a bit curious about if we should move towards a reentrent libgit (which would for example make multithreading easier) or not. I'm not aware of such an effort in core Git (I always thought that libgit2 is the project doing what you seem to aim for). If so, I suggest that this patch only use die() in builtin/. However I know that there's a lot of die() all over libgit today, I'm curious about what direction we're heading. The die() calls are just one part. Global variables are another issue, we have memory which is implicitly freed on exit ... so unless we commit ourselves to fix all those issues I see no point in moving the die() calls into builtin/ in my series. Okay, thanks for your answer. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] rm: delete .gitmodules entry of submodules removed from the work tree
On Tue, Aug 06, 2013 at 02:11:56PM -0700, Junio C Hamano wrote: Thanks, will replace the top two commits and queue. Looks like we are getting ready for 'next'? I'm a bit curious about if we should move towards a reentrent libgit (which would for example make multithreading easier) or not. If so, I suggest that this patch only use die() in builtin/. However I know that there's a lot of die() all over libgit today, I'm curious about what direction we're heading. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] submodule: fix confusing variable name
On Sun, Aug 04, 2013 at 07:34:48PM +0200, Jens Lehmann wrote: But we'll have to use sm_path here (like everywhere else in the submodule script), because we'll run into problems under Windows otherwise (see 64394e3ae9 for details). Apart from that the patch is fine. We're still using path= in the foreach-script. Or rather, we're setting it. From what I can see and from the commit message 64394e3ae9 it could possible be a problem. Not sure how to solve it though... Just a simple correction would break all script depending on that. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Rewriting git-repack.sh in C
On Fri, Aug 02, 2013 at 09:10:59PM +0700, Duy Nguyen wrote: So my question is, how you'd generally approach rewriting a shell script in C. Start a new process via start_command/run_command interface. It's safer to retain the process boundary at this stage. You can try to integrate further later. Is it really the right approach to just replace sh with C? IMHO forking and wait for the result should not be done if it can be avoided. It just adds overhead. Of course you can argue that just replace sh with C is a good first step towards to actually do the command in full C. Altough I'm afraid that that will get such low priority that it won't be done. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] Teach mv to move submodules using a gitfile
On Tue, Jul 30, 2013 at 09:50:03PM +0200, Jens Lehmann wrote:
+/* Update gitfile and core.worktree setting to connect work tree and git dir
*/
+void connect_work_tree_and_git_dir(const char *work_tree, const char
*git_dir)
+{
+ struct strbuf file_name = STRBUF_INIT;
+ struct strbuf rel_path = STRBUF_INIT;
+ const char *real_work_tree = xstrdup(real_path(work_tree));
+ FILE *fp;
+
+ /* Update gitfile */
+ strbuf_addf(file_name, %s/.git, work_tree);
+ fp = fopen(file_name.buf, w);
+ if (!fp)
+ die(_(Could not create git link %s), file_name.buf);
+ fprintf(fp, gitdir: %s\n, relative_path(git_dir, real_work_tree,
+ rel_path));
+ fclose(fp);
+
+ /* Update core.worktree setting */
+ strbuf_reset(file_name);
+ strbuf_addf(file_name, %s/config, git_dir);
+ if (git_config_set_in_file(file_name.buf, core.worktree,
+relative_path(real_work_tree, git_dir,
+ rel_path)))
+ die(_(Could not set core.worktree in %s),
+ file_name.buf);
+
+ strbuf_release(file_name);
+ strbuf_release(rel_path);
+ free((void *)real_work_tree);
+}
Would it make sense to return an int here and do the dying in
builtin/mv.c instead? Again thinking of libgit and the die_errno for
non-submodule errors are in mv.c and not in rename().
If that's the case the same applies for stage_updated_gitmodules() and
update_path_in_gitmodules().
update_path_in_gitmodules() also needs a strbuf_release() if you haven't
already found it.
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Remove tabs from howto documents
On Wed, Jul 31, 2013 at 06:54:07PM +0200, Dirk Wallenstein wrote: I really think that tabs are generally bad here. So, this will remove all tabs from the howto folder and prevent indenting with tabs through gitattributes. Dirk Wallenstein (2): howto: Suppress indentation with tabs howto: Eliminate all tabs Documentation/howto/.gitattributes | 1 + .../howto/rebase-from-internal-branch.txt | 8 ++-- Documentation/howto/rebuild-from-update-hook.txt | 4 +- .../howto/recover-corrupted-blob-object.txt| 50 +++--- Documentation/howto/revert-a-faulty-merge.txt | 16 +++ Documentation/howto/revert-branch-rebase.txt | 2 +- Documentation/howto/update-hook-example.txt| 8 ++-- Documentation/howto/use-git-daemon.txt | 10 ++--- 8 files changed, 50 insertions(+), 49 deletions(-) create mode 100644 Documentation/howto/.gitattributes How about adding a line about this in Documentation/CodingGuidelines? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Don't close pack fd when free'ing pack windows
On Wed, Jul 31, 2013 at 11:08:21PM +0200, Antoine Pelisse wrote: On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey bca...@nvidia.com wrote: --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- I'm certainly not a lawyer, and I'm sorry for not reviewing the content of the patch instead, but is that not a problem from a legal point of view ? Talking about legal, is it a problem if a commit isn't signed-off by it's committer or author e-mail? Like in this case where the sign-off is from gmail.com and the committer from nvidia.com? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Don't close pack fd when free'ing pack windows
On Wed, Jul 31, 2013 at 02:31:34PM -0700, Brandon Casey wrote: On Wed, Jul 31, 2013 at 2:21 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Wed, Jul 31, 2013 at 11:08:21PM +0200, Antoine Pelisse wrote: On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey bca...@nvidia.com wrote: --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- I'm certainly not a lawyer, and I'm sorry for not reviewing the content of the patch instead, but is that not a problem from a legal point of view ? Talking about legal, is it a problem if a commit isn't signed-off by it's committer or author e-mail? Like in this case where the sign-off is from gmail.com and the committer from nvidia.com? It never has been. My commits should have the author and committer set to my gmail address actually. Oh, that's why the extra From: - field below the header is for. Others have sometimes used the two fields to distinguish between a corporate identity (i.e. m...@somecompany.com) that represents the funder of the work and a canonical identity (m...@personalemail.com) that identifies the person that performed the work. In some contries your work when you're employed does not belong to you but to your employer and when you're acting for your employer you're representing the corporate legal person. Therefore two different e-mails can be seen as two different (legal not physical) persons. At least that's how I understand those legal tips for developers I've got. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)
On Thu, Aug 01, 2013 at 12:25:32AM +0200, Jens Müller wrote: Hi all! I mainly use Git for version control, but have also tried out Mercurial. While I don't really like Mercurial in general, the idea of maintaining clearly separated patches with Mercurial Queues (MQ) is quite appealing. Therefore, I am looking for something similar (but easier to use, more gitty and maybe even more powerful) in Git. So I will first explain what I have in mind: As an example, let's say I am doing test-driven development. My master branch follows the main repository of the software. Branched out from that, I have a branch called feature-test, and branched out from that, feature-implementation: master |_ feature-test |_ feature-implementation For each branch, I remember the parent branch. Implementation would then work like this: I checkout feature-test and write some test. Then I checkout feature-implementation, rebase it to the current status of feature-test and write the implemenation. And so on. At some point, I update master, and then rebase both feature-test and feature-implementation. As a side note: Instead of rebasing the branches, an alternative would be to merge the changes from the parent branch. This makes conflict resolution easier. The cascading merge through the chain of branches is like a rebase, anyway. Of course, the process described above contains a lot of tedious manual work. So I am looking for tooling for tasks like the following: * While on a branch, pull master from a remote branch it tracks and merge the changes down the chain of branches. When a conflict is encountered, switch to the branch where it occured, allow the user to resolve the conflict, and then continue the cascading merge (similar to what git rebase does when it encounters a conflict). * When checking out a branch, cascadingly merge from the ancestor branches automatically. Conflict handling should work as in the previous point. The cascading merge should not check out master and the branches below it (unless necessary to resolve conflicts), in order to avoid rebuilds due to touched but unchanged files. Do these requirements make sense? Is there some existing tool with a similar workflow? BR - Jens -- 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 Since all commits in feature-test is in feature-implementation, how about rebase feature-implementation on master and then move the branch pointer for feature-test to the new commit (git reset)? If it's still not trivial enough, a script for this would be fairly easy to implement (if I don't miss anything big here). -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help using git subtree
On Tue, Jul 30, 2013 at 11:32:22AM +0200, Gabriel Jover wrote: Dear all, I am trying to avoid using git submodules and thus I am testing if git subtree fit my needs. I have a set of sub-projects linked to a main-project. Just out of curiosity, why are you trying to avoid submodules? Git subtree is very convenient to get all the sub-projects into the main-project directory tree and to send back sub-project commits to the corresponding repository. But I don't understand the work flow very well. I haven't used subtree that much however how do you commit to upstream? AFAIK every commit to the subtree must be done in the subtree branch and then merged back to the superproject-branch with a subtree merge. I can add a subtree with a given prefix and pull/push my commits to the repository, but how do I do to pull/push commits from the main-project to the corresponding repository avoiding sub-projects to be sent? You don't. A subtree is a subtree in your git-repo and is therefore a part of your repository. When you're using subtree that project will be a part of you project. An other question I have is when will be subtree included in git packages. I had to compile git from sources in order to get this feature. git-subtree is a part of git, located in the contrib section. When your software distribution choose to distribute that with your git-package is not up to the git project to decide but something you need to ask your package maintainer. If you're asking when git-subtree will move from contrib/ to core git, I don't know. That's a decision for Junio. I would argue that it shouldn't because submodules can do everything that subtrees are good at and git.git should focus on doing one solution well instead of doing the same thing in two bad ways. However since git.git already uses a subtree-like style for gitk, git-gui, etc. it doesn't seem like Junio agrees with me on this point. Si heu rebut aquest correu per error, us informo que pot contenir informació confidencial i privada i que està prohibit el seu ús. Us agrairiem que ho comuniqueu al remitent i l'elimineu. Gràcies. Si ha recibido este correo por error, le informo de que puede contener información confidencial y privada y que está prohibido su uso. Le agradeceré que lo comunique a su remitente y lo elimine. Gracias. If you have received this e-mail by error, please note that it may contain confidential and private information, therefore, the use of this information is strictly forbidden. Please inform the sender of the error and delete the information received. Thank you. Is this really something to have in e-mails to a public list? Some lists won't accept this type of e-mails, or simply just ignore you. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Specify UK English for the documentation source files.
On Tue, Jul 30, 2013 at 11:11:54AM -0400, Marc Branchaud wrote: This will hopefully avoid questions over which spelling and grammar should be used. Translators are of course free to create localizations for other English dialects. Signed-off-by: Marc Branchaud marcn...@xiplink.com --- Although I'm Canadian I figured en_CA would be a little too parochial. I don't have a strong preference for en_UK over en_US though. Since the settings (for example color) use en_US, I suggest _not_ to specify en_UK as documentation language. Either set en_US or rather don't set anything at all but go after google correct. That's the most populair alternative. For example colour gets 422 000 000 hits and color gets 2 260 000 000 hits. We should use color even if it's not en_UK. It's a more pragmatic approach and most git users aren't native english speakers anyway. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] rm: delete .gitmodules entry of submodules removed from the work tree
On Tue, Jul 30, 2013 at 09:51:51PM +0200, Jens Lehmann wrote:
+/*
+ * Try to remove the submodule.name section from .gitmodules where the
given
+ * path is configured. Return 0 only if a .gitmodules file was found, a
section
+ * with the correct path=path setting was found and we could remove it.
+ */
+int remove_path_from_gitmodules(const char *path)
+{
+ struct strbuf sect = STRBUF_INIT;
+ struct string_list_item *path_option;
+
+ if (!file_exists(.gitmodules)) /* Do nothing without .gitmodules */
+ return -1;
+
+ if (gitmodules_is_unmerged)
+ die(_(Cannot change unmerged .gitmodules, resolve merge
conflicts first));
+
+ path_option = unsorted_string_list_lookup(config_name_for_path, path);
+ if (!path_option) {
+ warning(_(Could not find section in .gitmodules where
path=%s), path);
+ return -1;
+ }
+ strbuf_addstr(sect, submodule.);
+ strbuf_addstr(sect, path_option-util);
+ if (git_config_rename_section_in_file(.gitmodules, sect.buf, NULL)
0) {
+ /* Maybe the user already did that, don't error out here */
+ warning(_(Could not remove .gitmodules entry for %s), path);
+ return -1;
+ }
+ strbuf_release(sect);
+ return 0;
+}
This question applies for this function and a few more functions in this
patch that has the same characteristics.
If we're in a state when we need to return non-zero, we don't do any
cleaning (that is strbuf_release()). Since this file is in the part
called libgit AFAIK, shouldn't we always clean after us?
Would it make sense to have different return values for different
errors?
I do like the comments above the function, more functions (at least
non-static ones) should follow this good style IMHO.
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] git_path() returns relative paths
On Sat, Jul 27, 2013 at 04:40:12PM +0530, Ramkumar Ramachandra wrote: Hi, I noticed a regression in the latest master, and I've been trying to debug it for 30 minutes now. I'm still clueless about the root cause, but I'll list whatever I found so far: I suddenly noticed that I wasn't able to commit to a certain repository with submodules anymore. This was because git commit was opening a COMMIT_EDITMSG in the wrong path. To reproduce the problem, you need a setup like mine: When I hear submodules, latest master and path the only thing that comes to my mind that have touched these areas is 091a6eb0feed820a43663ca63dc2bc0bb247bbae submodule: drop the top-level requirement. A first test could be to see if it's this patch does anything strange. However this patch is in git since 1.8.3.3 so it's almost a month old. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why can't I push from a shallow clone?
On Thu, Jul 25, 2013 at 07:33:16PM -0700, Gulshan Singh wrote: I've been trying to figure out why I can't push from a shallow clone (using --depth) to a repository. I've made simple examples where it works, but I've read that in doesn't work in every case. However, I can't come up with a case where it doesn't work. Googling gives this answer: http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone, but I don't completely understand the explanation, so I was hoping someone could explain it. I can't explain it better than what Junio did in the link you just provide. However there's ongoing work to allow shallow clones to be able to push. You can read about it here: http://thread.gmane.org/gmane.comp.version-control.git/230612/focus=230878 -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting git from kernel.org is failing
On Tue, Jul 23, 2013 at 09:41:44PM +0200, Stefan Beller wrote: git clone https://git.kernel.org/cgit/git/git.git Cloning into 'git'... error: Unable to get pack index https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx error: Unable to get pack file https://git.kernel.org/cgit/git/git.git/objects/pack/pack-6bfd3af75af71d7bf66a80d6374ac09245ad3ce5.pack The requested URL returned error: 404 Not found error: Unable to find bce6db96a333c2d47b07580c5a9207cf10935378 under https://git.kernel.org/cgit/git/git.git Cannot obtain needed blob bce6db96a333c2d47b07580c5a9207cf10935378 while processing commit 5addd1c7531cc644787cd562a3c22a3b714c7d77. error: Fetch failed. as reported by ivegy on freenode/#git-devel Stefan Confirmed (tested both with and without trailing /, IIRC there was some configuration change recently that effect that): iveqy@kolya:~/slask/git$ git clone https://git.kernel.org/cgit/git/git.git/ Klonar till git... error: Unable to get pack index https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx ^C iveqy@kolya:~/slask/git$ git clone https://git.kernel.org/cgit/git/git.git Klonar till git... error: Unable to get pack index https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx error: Unable to find d6b65e204c6009e5c30f358810198319b70eda25 under https://git.kernel.org/cgit/git/git.git Cannot obtain needed blob d6b65e204c6009e5c30f358810198319b70eda25 while processing commit 5addd1c7531cc644787cd562a3c22a3b714c7d77. error: Fetch failed. fatal: Reading from helper 'git-remote-https' failed iveqy@kolya:~/slask/git$ -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git in nutshell Inbox
On Wed, Jul 10, 2013 at 12:10:55PM +0200, Muhammad Bashir Al-Noimi wrote: On Tue, Jul 9, 2013 at 10:47 PM, Muhammad Bashir Al-Noimi mbno...@gmail.com wrote: Now I've to make some tests because the new version is completely different than the old one so I'll send a feedback soon. Thanks guys, the recent git-cola fabulous so I don't need to use the terminal anymore for git. Glad you found something that works for you. As I mentioned above, I came from bzr background so git not completely strange to me I just want to learn more about some commands so may you please guide me to a quick reference (as simple as possible) git help gives you a list of a few usefull commands. if you search after git cheat sheat you will get a lot of hits, however I don't know any that would be better than anyone else. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git in nutshell Inbox
On Tue, Jul 09, 2013 at 04:50:20PM +0200, Muhammad Bashir Al-Noimi wrote: I tried to use git-cola and found it complicated and not user friendly (maybe because I came from Bazaar Explorer) I noticed that it needs terminal to be able to work (ex. it can't create new repository). I can't even ask for merge modifications (I'm still know nothing in git)! so do you know better GUI utility? You don't need the terminal to create a new repository. When starting git-cola from a non-git directory you get a menu where you can open an existing git-repository, clone an existing git-repository or create a new one. However I agree with Matthieu that it's easier to understand git from the command line. Git is developed and mostly used from the command line. It's the commandline that will give you most controll and most functionality. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git in nutshell Inbox
On Tue, Jul 09, 2013 at 07:26:57PM +0200, Muhammad Bashir Al-Noimi wrote: On Tue, Jul 9, 2013 at 7:02 PM, Fredrik Gustafsson iv...@iveqy.com wrote: You don't need the terminal to create a new repository. When starting git-cola from a non-git directory you get a menu where you can open an existing git-repository, clone an existing git-repository or create a new one I'm using git-cola 1.4.3.5-1 it doesn't create a new repository it just open or clone. Its interface doesn't appear unless the user launched git repository folder Well, I can't speak for such old version. git-cola is about six years old and you're using a two year old release. You miss 1/3 of all development that has been done on git-cola. I suggest you update to a newer version. Too bad that ubuntu shipped such old version. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] git svn geotrust certificate problem
On Fri, Jul 05, 2013 at 07:16:01PM +0400, Ilya Holinov wrote: I have svn repository on https singed with GeoTrust issued certificate. Every time i try to access this repository i have message : $ git svn rebase Error validating server certificate for 'https://svn.egspace.ru:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: *.egspace.ru - Valid: from Apr 28 01:38:17 2013 GMT until Apr 30 12:00:40 2014 GMT - Issuer: GeoTrust, Inc., US - Fingerprint: b2:8d:f8:3b:7c:d2:a2:36:e2:1d:c3:5c:56:ec:87:6f:22:3e:4b:a8 Certificate problem. (R)eject, accept (t)emporarily or accept (p)ermanently? p Authentication realm: https://svn.egspace.ru:443 VisualSVN Server Username: holinov Password for 'holinov': Even if i choose permanently every next attempt to access in i have same issue. And this happens on svn rebase on every commit. I mean if i have 10 commits in local repository i will be asked about cert and user login\passwor for every one of them (and that's is verry annoying). But if i use TortoiseSVN i have no problem with checking that cert. P.S.: I'm using Windows 8 x64. P.P.S: I like git very much but in this case it makes me impossible to work in this way. This isn't really my thing to answer, I don't know windows well enough. However since you still haven't got an answer I'll give it a try. Please see the following link: https://confluence.atlassian.com/display/SOURCETREEKB/Resolving+SSL+Self-Signed+Certificate+Errors -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git subtree push-all and pull-all
On Wed, Jul 03, 2013 at 03:56:36PM -0400, Gareth Collins wrote: Hello, I see over the last year (on the web and in this mailing list) there was some activity to extend subtree with a .gittrees file and push-all/pull-all commands. Perhaps I missed it, but looking through the latest git code on the github mirror I can't find any reference to the .gittrees file or these commands. Does anyone know the status of this feature? Was it decided that this was a bad idea and the feature has been rejected? Or is this a feature still cooking...which will likely make it into git mainline at some point? I ask because I would like to use something like this to be able to keep a combined repository and separate project repositories in sync. Of course, if it was decided that this feature is fundamentally a bad idea then I will do something different. Any pointers would be a big help. thanks in advance, Gareth Collins Still no answer to this? I suggest that you CC the persons discussing this the last time. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitweb on Godaddy
On Thu, Jul 04, 2013 at 11:56:40AM +0530, RR wrote: HI Can someone share procedure to setup gitweb on a Godaddy hosting server ? Any pointers to tutorials would be helpful Hi, I suggest that you contact godaddy and check with them what options you have. Gitweb is a cgi program and you need support to run cgi-applicatios from godaddy. You would also have to host your git repository on the same server (or at least you should). If that's not a possibility you might need to use a static html creator like http://hssl.cs.jhu.edu/~neal/git2html/ . -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I don't get it. The message from the hook is replaced with the message from the hook? What I don't get is how you can amend to a commit that doesn't yet exists. How is that possible? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 04, 2013 at 01:03:31PM +0300, Orgad Shaneh wrote: On Thu, Jul 4, 2013 at 1:01 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I don't get it. The message from the hook is replaced with the message from the hook? What I don't get is how you can amend to a commit that doesn't yet exists. How is that possible? Did I say anything about a commit that doesn't exist? I have a commit which I want to amend. If I click the Amend button before the hook is done, this commit's message is replaced (in the editor, not the actual commit) with the hook's result. When you click on amend the prepare-commit-msg hook is runned. But you say that you click amend before the hook is done. Which hook are you talking about in this case? Are you clicking twice on amend? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui replaces amend message when prepare-commit-msg hook is used
On Thu, Jul 04, 2013 at 01:59:10PM +0300, Orgad Shaneh wrote: On Thu, Jul 4, 2013 at 1:34 PM, John Keeping j...@keeping.me.uk wrote: On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote: Hi, If a prepare-commit-msg hook is used, git gui executes it for New Commit. If the New Commit is selected, and then immediately Amend (before the hook returns), when the hook returns the message is replaced with the one produced by the hook. I think this is a problem with the hook you are running. The hook is given arguments specifying the message file and optionally the source of whatever is already in the file (see githooks(5) for details). It sounds like your hook is blindly overwriting the file, rather than preserving its contents in the cases where you wish to do so. Let me try to explain. When git gui is executed, it calls the prepare-commit-msg script with .git/PREPARE_COMMIT_MSG as an argument. When amend is selected, the hook is *not* called at all (what would it prepare? The message is already committed) Use the following hook to reproduce: --- snip --- #!/bin/sh sleep 5 echo $@ /tmp/hook.log echo 'Hello hook' $1 --- snip --- Now run git gui (or press F5 if it is already running), and before 5 seconds pass, click Amend last commit. You'll see the commit's message, but when the 5 seconds pass it is replaced with Hello hook. That's the bug. Yeah I got what you mean, it looks like it's an update problem of the test-box in git-gui. You can also get that textbox to be completely empty if you click back and foward between new commit and amend. The hook is not always runned. I can confirm this bug. I don't think it related to pure git but to git-gui. I imagine that new commit exectures the prepare-commit-msg hook and replaces the textbox content with it. Something that should be correct, but the you've already told the textbox to have an other value (the value of the commit to amend). There should be a check before writing to the textbox if new commit still is set. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] [submodule] Add --depth to submodule update/add
On Wed, Jul 03, 2013 at 01:13:12AM -0700, Junio C Hamano wrote: Jens Lehmann jens.lehm...@web.de writes: The only minor problem is that this patch still does not apply cleanly to master, next or pu (I wonder what you based this on ;-). Thanks; will replace what I queued on 'pu'. I based it on master, but have forgott to rebase since v2. This is based on 3e7a5b489e45ae8a3a0b222893d58b172d883136. The merge conflict is pretty clean, would you (Junio) stil like a rebased update of this patch? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] [submodule] Add --depth to submodule update/add
Add the --depth option to the add and update commands of git submodule,
which is then passed on to the clone command. This is useful when the
submodule(s) are huge and you're not really interested in anything but
the latest commit.
Tests are added and to make --depth work the path for test setup a submodule
tree had to be modified. Also did some indent adjustments to conform to the
rest of the testfile on submodule update can handle symbolic links in pwd.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
The first line of the commit message still sounds strange to me, please see
my answer in the thread you quoted.
Also the documentation still talks about --clone-depth.
Sorry about that, it's fixed in this patch
The assignment to reference right above that is quoted like that too. I wonder
if we should also use ${depth:+$depth} as argument to clone.
I don't have any opinion about this. I guess it works the way it is, I just
don't
understand it according to the shell-syntax I know.
If we should fix it, perhaps fix it in an other patch together with $reference?
Documentation/git-submodule.txt | 10 --
git-submodule.sh| 24 +---
t/t7400-submodule-basic.sh | 15 +++
t/t7406-submodule-update.sh | 24 +---
4 files changed, 61 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e576713..77a052a 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,12 +10,12 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [--clone-depth depth] [--]
repository [path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] deinit [-f|--force] [--] path...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
- [-f|--force] [--rebase] [--reference repository]
+ [-f|--force] [--rebase] [--reference repository] [--clone-depth
depth]
[--merge] [--recursive] [--] [path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
[commit] [--] [path...]
@@ -328,6 +328,12 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+--depth::
+ This option is valid for add and update commands. Create a 'shallow'
+ clone with a history truncated to the specified number of revisions.
+ See linkgit:git-clone[1]
+
+
path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..1cfe2bf 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -32,6 +32,7 @@ nofetch=
update=
prefix=
custom_name=
+depth=
# The function takes at most 2 arguments. The first argument is the
# URL that navigates to the submodule origin repo. When relative, this URL
@@ -211,6 +212,7 @@ module_clone()
name=$2
url=$3
reference=$4
+ depth=$5
quiet=
if test -n $GIT_QUIET
then
@@ -233,7 +235,7 @@ module_clone()
mkdir -p $gitdir_base
(
clear_local_git_env
- git clone $quiet -n ${reference:+$reference} \
+ git clone $quiet $depth -n ${reference:+$reference} \
--separate-git-dir $gitdir $url $sm_path
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
@@ -309,6 +311,14 @@ cmd_add()
custom_name=$2
shift
;;
+ --depth)
+ case $2 in '') usage ;; esac
+ depth=--depth=$2
+ shift
+ ;;
+ --depth=*)
+ depth=$1
+ ;;
--)
shift
break
@@ -405,7 +415,7 @@ Use -f if you really want to add it. 2
echo $(eval_gettext Reactivating local git
directory for submodule '\$sm_name'.)
fi
fi
- module_clone $sm_path $sm_name $realrepo $reference ||
exit
+ module_clone $sm_path $sm_name $realrepo $reference
$depth || exit
(
clear_local_git_env
cd $sm_path
@@ -676,6 +686,14 @@ cmd_update()
--checkout
Re: Feature request: author branch in commit object
On Tue, Jul 02, 2013 at 12:37:13PM -0700, Ed Hutchins wrote: I realize that branch names are ephemeral repo-specific things, but it would be really useful to be able to determine what branch a commit was authored from (as a hint to ancestry graph layout tools, for example). Is there any way to do this currently, is it planned, or would it be deemed useful enough to be worth adding to each commit object? Let's see if I understand you. You want to (for each commit) to be able to tell the branch-name the commit had at the creation time? Not all commits have branches (however, loose commits is usually not wanted). Many commits are part of many branches. A branch is not a collection of commits but a pointer to a commit (which has parents). -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] [submodule] Add --depth to submodule update/add
Add the --depth option to the add and update commands of git submodule,
which is then passed on to the clone command. This is useful when the
submodule(s) are huge and you're not really interested in anything but
the latest commit.
Tests are added and some indention adjustments were made to conform to the
rest of the testfile on submodule update can handle symbolic links in pwd.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
And I finally thought I'd everything right. I appriciate your reviews.
I left the on $5 for consistency as suggested.
Documentation/git-submodule.txt | 10 --
git-submodule.sh| 24 +---
t/t7400-submodule-basic.sh | 15 +++
t/t7406-submodule-update.sh | 24 +---
4 files changed, 61 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e576713..605419f 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,12 +10,12 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [--depth depth] [--] repository
[path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] deinit [-f|--force] [--] path...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
- [-f|--force] [--rebase] [--reference repository]
+ [-f|--force] [--rebase] [--reference repository] [--depth
depth]
[--merge] [--recursive] [--] [path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
[commit] [--] [path...]
@@ -328,6 +328,12 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+--depth::
+ This option is valid for add and update commands. Create a 'shallow'
+ clone with a history truncated to the specified number of revisions.
+ See linkgit:git-clone[1]
+
+
path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..2458e1f 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -32,6 +32,7 @@ nofetch=
update=
prefix=
custom_name=
+depth=
# The function takes at most 2 arguments. The first argument is the
# URL that navigates to the submodule origin repo. When relative, this URL
@@ -211,6 +212,7 @@ module_clone()
name=$2
url=$3
reference=$4
+ depth=$5
quiet=
if test -n $GIT_QUIET
then
@@ -233,7 +235,7 @@ module_clone()
mkdir -p $gitdir_base
(
clear_local_git_env
- git clone $quiet -n ${reference:+$reference} \
+ git clone $quiet ${depth:+$depth} -n
${reference:+$reference} \
--separate-git-dir $gitdir $url $sm_path
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
@@ -309,6 +311,14 @@ cmd_add()
custom_name=$2
shift
;;
+ --depth)
+ case $2 in '') usage ;; esac
+ depth=--depth=$2
+ shift
+ ;;
+ --depth=*)
+ depth=$1
+ ;;
--)
shift
break
@@ -405,7 +415,7 @@ Use -f if you really want to add it. 2
echo $(eval_gettext Reactivating local git
directory for submodule '\$sm_name'.)
fi
fi
- module_clone $sm_path $sm_name $realrepo $reference ||
exit
+ module_clone $sm_path $sm_name $realrepo $reference
$depth || exit
(
clear_local_git_env
cd $sm_path
@@ -676,6 +686,14 @@ cmd_update()
--checkout)
update=checkout
;;
+ --depth)
+ case $2 in '') usage ;; esac
+ depth=--depth=$2
+ shift
+ ;;
+ --depth=*)
+ depth=$1
+ ;;
--)
shift
break
@@ -735,7 +753,7 @@ Maybe you want to use 'update --init'?)
if ! test -d $sm_path/.git -o -f $sm_path/.git
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
Hi, On Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote: This allows the user some finer grained control over how the update is done. The primary motivation for this was interoperability with stgit however being able to intercept the submodule update process may prove useful for integrating or extending other tools. Signed-off-by: Chris Packham judge.pack...@gmail.com -- Hi, At $dayjob we have a number of users that are accustomed to using stgit. Stgit doesn't play nicely with git rebase which would be the logical setting for submodule.*.update for our usage. Instead we need to run 'stg rebase --merged' on those submodules that have been initialised with stgit. Our current solution is an in-house script which is a poor substitute for git submodule update. I'd much rather replace our script with git submodule update but we do have a requirement to keep stgit for the foreseeable future. Rather than narrowing in on stgit it seems logical to allow an arbitrary update command to be executed. --- Documentation/git-submodule.txt | 8 +++- git-submodule.sh| 22 +- 2 files changed, 28 insertions(+), 2 deletions(-) technically it looks fine to me (except for the lack of tests) but I'm not sure I follow the use case. In your case, you want to run a script to determinate if that certain submodule should use merge or rebase depending on whatever. And this can't be done with git submodule foreach because you want to know the sha1 to update to. Have I understood you correctly? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone -b
On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote: Hi there! Is there any reason why 'git clone -b' only takes a branch (from refs/heads/) or a tag (from refs/tags/) ? Background: At $dayjob we're using some kind of 'hidden' refs (in refs/releases/) to communicate between the 'branch integrator' (who creates the ref in refs/releases/) and the 'build master' who wants to build that ref. It would be a little easier if the build master could simply say git clone -b refs/releases/the-release-for-today URL instead of: git clone... ; cd ... ; git fetch... ; git checkout Any answer or even a better idea to solve that is appreciated. Stefan I don't understand what the alternative should be. You can't look in /refs/* because there's a lot of other stuff like bisect/remotes etc. there. Of course you could add to also look in /refs/releases/ but as I understand you that a special solution for your company. Why should all git users have that addition? Two questions about your setup: 1. Why do you always clone your repository? To me clone is a one time operation. 2. Why don't you tag your releases with an ordinary tag? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [submodule] Add --depth to submodule update/add
When a submodule is clone, clone it width the --depth flag. This is useful
when the submodule(s) are huge and you're not really interested in anything
but the latest commit.
Tests are added and to make --depth work the path for test setup a submodule
tree had to be modified. Also did some indent adjustments to conform to the
rest of the testfile on submodule update can handle symbolic links in pwd.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
Documentation/git-submodule.txt | 13 +++--
git-submodule.sh| 24 +---
t/t7400-submodule-basic.sh | 18 ++
t/t7406-submodule-update.sh | 28
4 files changed, 70 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e576713..b17001a 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,12 +10,12 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [--depth depth] [--] repository
[path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] deinit [-f|--force] [--] path...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
- [-f|--force] [--rebase] [--reference repository]
+ [-f|--force] [--rebase] [--reference repository] [--depth
depth]
[--merge] [--recursive] [--] [path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
[commit] [--] [path...]
@@ -328,6 +328,15 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+--depth::
+ This option is valid for add and update commands. Create a 'shallow'
+ clone with a history truncated to the specified number of revisions.
+ A shallow repository has a number of limitations (you cannot clone
+ or fetch from it, nor push from nor into it), but is adequate if
+ you are only interested in the recent history of a large project
+ with a long history.
+
+
path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..c99bc7c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -32,6 +32,7 @@ nofetch=
update=
prefix=
custom_name=
+depth=
# The function takes at most 2 arguments. The first argument is the
# URL that navigates to the submodule origin repo. When relative, this URL
@@ -211,6 +212,7 @@ module_clone()
name=$2
url=$3
reference=$4
+ depth=$5
quiet=
if test -n $GIT_QUIET
then
@@ -234,7 +236,7 @@ module_clone()
(
clear_local_git_env
git clone $quiet -n ${reference:+$reference} \
- --separate-git-dir $gitdir $url $sm_path
+ --separate-git-dir $gitdir $depth $url
$sm_path
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
fi
@@ -309,6 +311,14 @@ cmd_add()
custom_name=$2
shift
;;
+ --depth)
+ case $2 in '') usage ;; esac
+ depth=--depth=$2
+ shift
+ ;;
+ --depth=*)
+ depth=$1
+ ;;
--)
shift
break
@@ -405,7 +415,7 @@ Use -f if you really want to add it. 2
echo $(eval_gettext Reactivating local git
directory for submodule '\$sm_name'.)
fi
fi
- module_clone $sm_path $sm_name $realrepo $reference ||
exit
+ module_clone $sm_path $sm_name $realrepo $reference
$depth || exit
(
clear_local_git_env
cd $sm_path
@@ -676,6 +686,14 @@ cmd_update()
--checkout)
update=checkout
;;
+ --depth)
+ case $2 in '') usage ;; esac
+ depth=--depth=$2
+ shift
+ ;;
+ --depth=*)
+ depth=$1
+ ;;
--)
shift
break
@@ -735,7 +753,7 @@ Maybe you want to use 'update --init
Parse --o in format-patch
Hi, I don't quite manage to figure out gits argv parsing and would need some help on the way. I want: git format-patch -o outdir HEAD~ Work exactly the way it does now, setting output_directory to outdir. But I also want git format-patch -o HEAD~ to set output_directory with a NULL value so that I can assign a default value to it. Is that even possible with the current argv-parsing implementation? The currect argv parser is using OPTION_CALLBACK so I thought that that callback should be able to determine if there was an outdir supplied or not. Or is the correct solution to also add a bolean type OPTION_BOOLEAN for -o? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Parse --o in format-patch
On Fri, Jun 28, 2013 at 12:31:53PM -0400, Jeff King wrote: It's possible to have an optional argument by using the PARSE_OPT_OPTARG flag. However, it is not backwards compatible from the user's perspective, as they must use the sticked form: git format-patch -ooutdir ... to specify the argument. Otherwise, it is not clear in: git format-patch -o outdir HEAD~ whether outdir is the argument to -o, or if it is simply the next argument. That would be a possibility but I don't like breaking backwards compability. I'm not clear how that interacts with your example, though. Your example tries to use -o to set output_directory to NULL. But it is already NULL if you do not specify any -o at all. my goal is to make: git format-patch [-k] [(-o|--output-directory) dir | --stdout] [ since | revision range ] to be: git format-patch [-k] [(-o|--output-directory) [dir] | --stdout] [ since | revision range ] that would do: git format patch - current dir git format patch -o - default dir (for example GIT_DIR/.outgoing/) git format patch -o dir - user defined dir But I guess I would need a new option instead. Something like --default-output-dir. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH --clone-depth version] [submodule] Add --depth to submodule update/add
When a submodule is clone, clone it width the --depth flag. This is useful
when the submodule(s) are huge and you're not really interested in anything
but the latest commit.
Tests are added and to make --depth work the path for test setup a submodule
tree had to be modified. Also did some indent adjustments to conform to the
rest of the testfile on submodule update can handle symbolic links in pwd.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
I neither have an opinion about what word to use. --depth is more
consistent and easier to code. But also eaiser to be confused about.
Here is a --clone-depth version of the patch. Nothing else is changed.
Please take the one thats most suited.
Documentation/git-submodule.txt | 13 +++--
git-submodule.sh| 24 +---
t/t7400-submodule-basic.sh | 18 ++
t/t7406-submodule-update.sh | 28
4 files changed, 70 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e576713..41b9610 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,12 +10,12 @@ SYNOPSIS
[verse]
'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [--clone-depth depth] [--]
repository [path]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
'git submodule' [--quiet] init [--] [path...]
'git submodule' [--quiet] deinit [-f|--force] [--] path...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
- [-f|--force] [--rebase] [--reference repository]
+ [-f|--force] [--rebase] [--reference repository] [--clone-depth
depth]
[--merge] [--recursive] [--] [path...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
[commit] [--] [path...]
@@ -328,6 +328,15 @@ for linkgit:git-clone[1]'s `--reference` and `--shared`
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
+--clone-depth::
+ This option is valid for add and update commands. Create a 'shallow'
+ clone with a history truncated to the specified number of revisions.
+ A shallow repository has a number of limitations (you cannot clone
+ or fetch from it, nor push from nor into it), but is adequate if
+ you are only interested in the recent history of a large project
+ with a long history.
+
+
path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..0a949d1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -32,6 +32,7 @@ nofetch=
update=
prefix=
custom_name=
+clone_depth=
# The function takes at most 2 arguments. The first argument is the
# URL that navigates to the submodule origin repo. When relative, this URL
@@ -211,6 +212,7 @@ module_clone()
name=$2
url=$3
reference=$4
+ clone_depth=$5
quiet=
if test -n $GIT_QUIET
then
@@ -234,7 +236,7 @@ module_clone()
(
clear_local_git_env
git clone $quiet -n ${reference:+$reference} \
- --separate-git-dir $gitdir $url $sm_path
+ --separate-git-dir $gitdir $clone_depth
$url $sm_path
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
fi
@@ -309,6 +311,14 @@ cmd_add()
custom_name=$2
shift
;;
+ --clone-depth)
+ case $2 in '') usage ;; esac
+ clone_depth=--depth=$2
+ shift
+ ;;
+ --clone-depth=*)
+ clone_depth=$(echo $1 | sed -e 's/^--clone/-/')
+ ;;
--)
shift
break
@@ -405,7 +415,7 @@ Use -f if you really want to add it. 2
echo $(eval_gettext Reactivating local git
directory for submodule '\$sm_name'.)
fi
fi
- module_clone $sm_path $sm_name $realrepo $reference ||
exit
+ module_clone $sm_path $sm_name $realrepo $reference
$clone_depth || exit
(
clear_local_git_env
cd $sm_path
@@ -676,6 +686,14 @@ cmd_update()
--checkout)
update=checkout
;;
+ --clone-depth
Re: [PATCH] [submodule] Add depth to submodule update
On Fri, Jun 28, 2013 at 03:51:41PM -0700, Junio C Hamano wrote: Jens Lehmann jens.lehm...@web.de writes: Am 28.06.2013 20:44, schrieb Junio C Hamano: Heiko Voigt hvo...@hvoigt.net writes: ... Hmm, but does it have a --depth option for revisions? Maybe we should call it --clone-depth or --rev-depth to make it clear? --depth and --max-depth would be completely orthogonal but the name does not allow to distinguish them properly. I do not have a strong opinion either way, but as you suggest, it might be a good idea to call this new option --clone-depth to be more specific. No strong opinion here either, but I'm leaning towards --depth because on one hand we already have the --reference option which is passed on to the clone command (and not --clone-reference)... OK, then --depth it is. The points in your review on the last version with --depth (which I picked up and parked on 'pu') still need to be addressed, I think? I agree, I'm on it -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
On Thu, Jun 27, 2013 at 08:46:56PM +0800, Woody Wu wrote: Hi, I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? There's a number of ways that git can communicate with an other git repo. However, communication needs access. You can for example e-mail changes or sen them as files manually with git sneakernet functionality. However those cases would be as bad (or worse) than to open your firewall. The best solution would be a remote repository outside your firewall where your inhouse team and your outhouse developer can share stuff with eachother. However the securitry for this special project will be lower. (Maybe this isn't an important project to you, I don't know). This repository can be at your inhouse-site, at your developer or at some third part. Use ssh with keys and passphrases to communicate. Keep in mind that a git repository contains all of your source history. Your security for that source code will be whatever security your outhouse developer has. If he fails with his security, there's no meaning with having great inhouse security. If this isn't an option I would suggest that you establish an encrypted sneakernet (for example over UPS/bike messengers/whatever) between your developer and your office. Or just ask yourself if your security settings really is sane. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: device files should be handled by git
On Wed, Jun 26, 2013 at 08:27:56PM -0700, Perry Wagle wrote: Hi -- I have a disk image of a small embedded device whose root file system I'd like to check-in to git as a means of distributing its GPL'd software. In that disk image are device files, which GIT studiously ignores. If symlinks are handled (contents being the path that the symlink points at), I don't see why device files can't be handled (contents being the type (char or block) and the major and minor device number). TAR, for example, handles this fine, except that using tar in git sort-of goes against the granularity of the objects being modified (like adding a bunch of extra sd?? devices), such that you are modifying a whole tar ball instead of the individual (device) files. Is there a reason not to handle device files other than its not traditional? That's the only reason given in google or the IRC channel. Thanks! In linux you can't create device files if your not root. On windows those files won't even exists (afaik). Wouldn't this be very unportable and hard to use (meaning that you need to handle your git repo as root or give git setuid root)? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: snip +# See if we are configured to rebase by default. +# The value $rebase is, throughout the main part of the code: +#(empty) - the user did not have any preference +#true- the user told us to integrate by rebasing +#flase - the user told us to integrate by merging s/flase/false And isn't all config settings documented somewhere? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [submodule] Add depth to submodule update
On Wed, Jun 26, 2013 at 12:11:32AM +0200, Heiko Voigt wrote: On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote: Used only when a clone is initialized. This is useful when the submodule(s) are huge and you're not really interested in anything but the latest commit. Signed-off-by: Fredrik Gustafsson iv...@iveqy.com I this is a valid use case. But this option only makes sense when a submodule is newly cloned so I am not sure whether submodule update is the correct place. Let me think about this a little more. Since we do not have any extra command that initiates the clone this is probably the only place we can put this option. But at the moment it does not feel completely right. Apart from that the code looks good. If the user does a checkout of a revision that was not fetched submodule update will error out the same way as if someone forgot to push his submodule changes. So that should not be a problem. I agree and would love to say that I've a more beautiful solution, but I haven't. The only other solution I can think about is to add a git submodule clone that will do only clones of non-cloned submodules. I'm no UI expert so I don't know what's best. Maybe that's more intuitive. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] push: give early feedback
On Mon, Jun 24, 2013 at 11:11:02PM +0530, Ramkumar Ramachandra wrote:
There are many configuration variables that determine exactly what a
push does. Give the user early feedback so that she has a chance to
abort if she doesn't mean to push those refspecs to that destination
like:
$ git push
# pushing refspecs 'master next' to ram (^C to abort)
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Goes without saying: this is an early preview.
builtin/push.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/push.c b/builtin/push.c
index 2d84d10..085d5ab 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -330,6 +330,7 @@ static int do_push(const char *repo, int flags)
{
int i, errs;
struct remote *remote = pushremote_get(repo);
+ struct strbuf sb = STRBUF_INIT;
const char **url;
int url_nr;
@@ -375,6 +376,11 @@ static int do_push(const char *repo, int flags)
}
errs = 0;
url_nr = push_url_of_remote(remote, url);
+
+ for (i = 0; i refspec_nr; i++)
+ strbuf_addf(sb, %s%s, refspec[i], i == refspec_nr - 1 ? :
);
+ printf(# pushing refspecs '%s' to %s (^C to abort)\n, sb.buf,
remote-name);
+
How about a strbuf_release here?
Can you really be sure that refspec_nr is set here?
if (url_nr) {
for (i = 0; i url_nr; i++) {
struct transport *transport =
--
1.8.3.1.549.g1f3a412.dirty
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: add git transport security notice
On Tue, Jun 25, 2013 at 07:57:35AM +1000, Fraser Tweedale wrote: The git transport is insecure and should be used with caution on unsecured networks. I don't understand this. How is git:// insecure? It's protocol with no authentication, because it's a protocol used for public sharing. The only point of encrypt git:// would be to verify that the recieved data has not been altered along the way. However you can always trust that the end result is an valid copy of the remote. To me that means that it's as secure as a non-authentication protocoll needs to be. How would an evil network be able to do any harm to a git transport over git://? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] documentation: add git transport security notice
On Mon, Jun 24, 2013 at 03:35:19PM -0700, Junio C Hamano wrote: I don't understand this. How is git:// insecure? If your DNS is poisoned, or your router is compromised to allow your traffic diverted, you may be fetching from somewhere you did not intend to. As I explained in a separate message, that does not necessarily result in your repository corrupting, but the result, even though it may be git fsck clean at the bit level, needs additional validation measure, such as signed tags, to be safely used to base your further work on top. Thanks for the explanation. Of course you need to verify your latest commit sha1 against a trustworthy source. That would be enough to prevent this scenario, yes? If we add warnings for git:// should we also add warnings for http://? Or do we consider that common knowledge? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [submodule] Add depth to submodule update
Used only when a clone is initialized. This is useful when the submodule(s)
are huge and you're not really interested in anything but the latest commit.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
git-submodule.sh | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..b102fa8 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -211,12 +211,18 @@ module_clone()
name=$2
url=$3
reference=$4
+ depth=$5
quiet=
if test -n $GIT_QUIET
then
quiet=-q
fi
+ if test -n $depth
+ then
+ depth=--depth=$depth
+ fi
+
gitdir=
gitdir_base=
base_name=$(dirname $name)
@@ -233,7 +239,7 @@ module_clone()
mkdir -p $gitdir_base
(
clear_local_git_env
- git clone $quiet -n ${reference:+$reference} \
+ git clone $quiet $depth -n ${reference:+$reference} \
--separate-git-dir $gitdir $url $sm_path
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
@@ -676,6 +682,9 @@ cmd_update()
--checkout)
update=checkout
;;
+ --depth)
+ depth=$2
+ ;;
--)
shift
break
@@ -735,7 +744,7 @@ Maybe you want to use 'update --init'?)
if ! test -d $sm_path/.git -o -f $sm_path/.git
then
- module_clone $sm_path $name $url $reference ||
exit
+ module_clone $sm_path $name $url $reference
$depth || exit
cloned_modules=$cloned_modules;$name
subsha1=
else
--
1.8.0
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [submodule] Add depth to submodule update
Used only when a clone is initialized. This is useful when the submodule(s)
are huge and you're not really interested in anything but the latest commit.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
git-submodule.sh | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..b102fa8 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -211,12 +211,18 @@ module_clone()
name=$2
url=$3
reference=$4
+ depth=$5
quiet=
if test -n $GIT_QUIET
then
quiet=-q
fi
+ if test -n $depth
+ then
+ depth=--depth=$depth
+ fi
+
gitdir=
gitdir_base=
base_name=$(dirname $name)
@@ -233,7 +239,7 @@ module_clone()
mkdir -p $gitdir_base
(
clear_local_git_env
- git clone $quiet -n ${reference:+$reference} \
+ git clone $quiet $depth -n ${reference:+$reference} \
--separate-git-dir $gitdir $url $sm_path
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
@@ -676,6 +682,9 @@ cmd_update()
--checkout)
update=checkout
;;
+ --depth)
+ depth=$2
+ ;;
--)
shift
break
@@ -735,7 +744,7 @@ Maybe you want to use 'update --init'?)
if ! test -d $sm_path/.git -o -f $sm_path/.git
then
- module_clone $sm_path $name $url $reference ||
exit
+ module_clone $sm_path $name $url $reference
$depth || exit
cloned_modules=$cloned_modules;$name
subsha1=
else
--
1.8.0
--
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] [submodule] Remove duplicate call to set_rev_name
set_rev_name is a possible expensive operation. If a submodule has changes in it, set_rev_name was called twice. Solution is to move set_rev_name so it's only called once, no matter the codepath taken. Signed-off-by: Fredrik Gustafsson iv...@iveqy.com --- git-submodule.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh index 79bfaac..75feaf1 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -1129,16 +1129,16 @@ cmd_status() say -$sha1 $displaypath continue; fi - set_name_rev $sm_path $sha1 if git diff-files --ignore-submodules=dirty --quiet -- $sm_path then + set_name_rev $sm_path $sha1 say $sha1 $displaypath$revname else if test -z $cached then sha1=$(clear_local_git_env; cd $sm_path git rev-parse --verify HEAD) - set_name_rev $sm_path $sha1 fi + set_name_rev $sm_path $sha1 say +$sha1 $displaypath$revname fi -- 1.8.0 -- 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 error
On Mon, Jun 17, 2013 at 01:28:30PM +, justin.sathyanat...@accenture.com wrote: 1.Iam getting error attached when cloning of repository is done: What error? 2.Also, when file is tried to be added,it gives error below: $ git add * fatal: unable to stat 'src/development_architecture/integration_application_proj ect_template/provider_archetype/provider_archetype/src/main/resources/archetype- resources/__rootArtifactId__-data/src/main/java/com/accenture/afpj/sample/skelet on/visitor/data/VisitorRepositoryJpaImpl.java': Filename too long As it said, filename is too long. See the FAQ: https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions and the thread: http://thread.gmane.org/gmane.comp.version-control.msysgit/14572 Request you to help to resolve same asap as it is affecting the project. If you want reliable and direct help I suggest you hire a git-consult or buy support. This list will help you in the best way it can (and mostly that's enough) but cannot do things asap. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New User Question
On Mon, Jun 17, 2013 at 11:39:44AM -0400, Joel McGahen wrote: I have a question about GIT remote repos. Here is my scenario. 1. Work client has a repo (origin, branch of master). 2. Due to contractual issues I need to host a remote copy of this repo that my developers can utilize while we get the contractual issues resolved as development must continue. 3. I have a virtual machine from the client which already has a remote of origin setup. 4. I have created a bare repo on a server my developer's have access to. 5. I have added that remote to my copy of the client VM local repo and pushed its contents to my newly created bare repo. What I need to understand is how to a) Connect my developer's VM local repos to the new remote repo I created so they can continue to work. b) Once the contractual issues are resolved reconnect the developer's local repos back to the original orgin/master repo and merge all their changes. I'm fairly new to GIT but have worked with version control for a long time (CVS, PVCS, Subversion etc). Any help would be greatly appreciated! Hi! The short answer is: git remote add (and git help remote for details). It's also possible to manally edit .git/config if it's basically just a adress change you're doing. The long answer is harder. You've experience with centralized systems. Remember that git is decentralized. Every developer you've is a fully functional unit on his own. All you need is a way for the developers to interact with eachothers. It can be done via e-mail, or with them pulling from eachother directly or as you've done, with one central repository that everyone sync to. The questions you've is rather fundamental to git. I tells me that you do not fully utilize the strengths of git. I suggest reading the progit book. Good luck! -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] speed up git submodule
I've been playing a bit with lua. It's an embedded scripting language
with strong c integration. It's small and fast.
The interesting feature would be to run C-functions direct inside lua. I
suppose that would increase speed even more, at the same time as we have
the convinence of a interpreted language. Lua is smaller and faster
(well as always, it depends on what you're doing) than python and ruby.
Perl is a really pain for the windows folks (I've heard).
A correct implementation for lua support would be to start a
lua-interpreter from inside git.c (or somewhere) and load the lua code
for a specific command. That would make us independent of any target
installation of lua (althought the git binary would increase with the
lua library around 300 kb).
However I did a quick test using lua as a replacement for sh (without
direct calls to c-functions) and the result is impressive. (However this
is the wrong way of using lua, shell scripting is not something lua is
good at).
I did some runs on a project with 52 submodules (or 53 if you count the
ones in .gitmodules). These results are pretty typical:
iveqy@kolya:~/projects/eracle_core$ time
/home/iveqy/projects/git/git-submodule.lua /dev/null
real0m1.665s
user0m0.276s
sys 0m0.452s
iveqy@kolya:~/projects/eracle_core$ time git submodule /dev/null
real0m3.413s
user0m0.476s
sys 0m1.224s
For me, that speedup does matter.
NOTICE!!!
This code is experimental. It does have some known bugs, it does have
some style issues. A state of the art complete implementation would
contain a few more tests/jumps and less concat (which is extremely
expensive in lua) and less git-invokation.
Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
git-submodule.lua | 104 ++
1 file changed, 104 insertions(+)
create mode 100755 git-submodule.lua
diff --git a/git-submodule.lua b/git-submodule.lua
new file mode 100755
index 000..14f71e6
--- /dev/null
+++ b/git-submodule.lua
@@ -0,0 +1,104 @@
+#!/usr/bin/lua
+
+function run_cmd(cmd)
+ local f = io.popen(cmd, 'r');
+ local out = f:read('*a');
+ f:close()
+ return out
+end
+
+function fwrite(fmt, ...)
+ return io.write(string.format(fmt, ...))
+end
+
+function read_gitmodules()
+ local inf = assert(io.open('.gitmodules', 'r'))
+ local config = inf:read(*all)
+ gitmodules = {}
+ for sm in string.gmatch(config, '%[[^]]*%][^%[]*') do
+ local thismod = {}
+ local name = string.match(sm, '%[%s-submodule%s-(.+)%s-%]')
+ thismod[name] = name
+ local path = ''
+ for k, v in string.gmatch(sm, '\n%s*([^=^%s]*)%s*=%s*([^\n]*)')
do
+ if k == 'path' then
+ path = v
+ else
+ thismod[k] = v
+ end
+ end
+ if path == '' then
+ fwrite(No path found for %s in .gitmodules\n, name)
+ os.exit(1)
+ end
+ gitmodules[path] = thismod
+ end
+
+ return gitmodules
+end
+
+function module_list()
+ local lsfiles = 'git ls-files --stage --error-unmatch -z || echo
#unmatched'
+ local out = run_cmd(lsfiles)
+ local unmerged = ''
+ local subs = read_gitmodules()
+
+ for row in string.gmatch(out, '.-\0') do
+ if row == '#unmatched' then
+ os.exit(1)
+ end
+
+ local mode, sha1, stage, path = string.match(row,
'(%d+)%s([0-9a-f]+)%s(.)%s(.*)\0')
+ if mode == '16' then
+ if stage == '0' then
+ subs[path][sha1] = sha1
+ subs[path][stage] = stage
+ else
+ if unmerged ~= path then
+ local null_sha1 =
''
+ subs[path][sha1] = null_sha1
+ subs[path][stage] = 'U'
+ end
+ unmerged = path
+ end
+ end
+ end
+ return subs
+end
+
+function get_name_rev(path, sha1)
+ if sha1 == nil then sha1= end
+ local cmd = cd \ .. path .. \ (git describe .. sha1 ..
+2/dev/null || git describe --tags .. sha1
..
+2/dev/null || git describe --contains ..
sha1 ..
+2/dev/null || git describe --all --always
.. sha1 ..
+2/dev/null)
+ return string.gsub(run_cmd(cmd), '\n', '')
+end
+
+function cmd_status()
+ subs = module_list()
+ for smpath in pairs(subs) do
+ if (subs[smpath].sha1
