Consulting for implementation
good afternoon GIT Community We are a group of people interested in using management software versions of GIT for the solution of social problems and citizen empowerment in smart cities. I need to speak with a representative of the community, to explain the idea and have an advice of the feasibility of the proposal. Thanks for your time, I´ll wait for your answer. Sincerely José from BioRed
See my offer
Please read my email for a transfer offer of 6.5 Million Euro -- 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
Read my offer
Please read my bleow email for a transfer offer of 6.5 Million Euro -- 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
Using git svn rebase at quarantine environment or a feasible alternative to synchronize git and svn repositories
Dear members of the Git community, The enterprise I work for is planning to switch from svn to git. Before the complete switch to git we have decided to implement a scenario where the two SCMs live together, being the svn repository the reference. We also want this scenario to be transparent for both SCM users. I read the articles referenced at the end of the email and I come to the following solution. My proposal consists to import the svn repository to git using git svn and set receive.denyCurrentBranch to updateInstead. Then install pre-receive and post-receive hooks and set that repository as the central repository for git users. The pre-receive hook does git svn rebase and, if there is an update at the svn repository, rejects the push and instructs the user to do git pull. The post-receive hook does git svn dcommit to update the state of the svn repository, then instructs the user to do git pull too. Both scripts check the changes pushed are made at master before doing anything and exit after performing these tasks. branches.master.rebase is set to merges at the user repository to avoid the histories of the central and the user repositories diverge after doing git svn dcommit. However I'm stuck at this point because the pre-receive hook it's not allowed to do git svn rebase because update refs are not allowed at the quarantine environment. I was sure that I tried this solution with a past version of git and it worked, but now I doubt this because the restriction to update refs at quarantine environment was delivered at version 2.13, that dates from April 2017, if I'm not wrong. I don't know if this solution could be implemented or is there a better way to accomplish this kind of synchronization (I tried Tmate SubGit, but it didn't work for me and I don't know if we will be willing to purchase a license). Could you help me with this question? I come here asking for help because I think this is the appropriate place to do so. I apologise if this is not the case. Any help is welcome. If anything needs to be clarified, please, ask me to do so. I can share with you the source code of the hook scripts, if necessary. Thanks in advance. Regards, Jose - https://stackoverflow.com/q/5586993 - https://stackoverflow.com/q/2014422 - http://davidsouther.com/#/posts/2012/04/13/git-svn-dcommit-hooks/ - https://gist.github.com/DavidSouther/8dfc6575f4d3a293be7c
RE: Using git svn rebase at quarantine environment or a feasible alternative to synchronize git and svn repositories
> > Dear members of the Git community, > > > > The enterprise I work for is planning to switch from svn to git. > > > > Before the complete switch to git we have decided to implement a scenario > > where the two SCMs live together, being the svn repository the reference. > > We also want this scenario to be transparent for both SCM users. > > > > I read the articles referenced at the end of the email and I come to the > > following solution. > > > > My proposal consists to import the svn repository to git using git svn and > > set receive.denyCurrentBranch to updateInstead. Then install pre-receive > > and post-receive hooks and set that repository as the central repository > > for git users. > > > > The pre-receive hook does git svn rebase and, if there is an update at the > > svn repository, rejects the push and instructs the user to do git pull. > > The post-receive hook does git svn dcommit to update the state of the svn > > repository, then instructs the user to do git pull too. > > > > Both scripts check the changes pushed are made at master before doing > > anything and exit after performing these tasks. branches.master.rebase is > > set to merges at the user repository to avoid the histories of the central > > and the user repositories diverge after doing git svn dcommit. > > > > However I'm stuck at this point because the pre-receive hook it's not > > allowed to do git svn rebase because update refs are not allowed at the > > quarantine environment. I was sure that I tried this solution with a past > > version of git and it worked, but now I doubt this because the restriction > > to update refs at quarantine environment was delivered at version 2.13, > > that dates from April 2017, if I'm not wrong. > > > > I don't know if this solution could be implemented or is there a better > > way to accomplish this kind of synchronization (I tried Tmate SubGit, but > > it didn't work for me and I don't know if we will be willing to purchase a > > license). Could you help me with this question? > > > > I come here asking for help because I think this is the appropriate place > > to do so. I apologise if this is not the case. Any help is welcome. If > > anything needs to be clarified, please, ask me to do so. I can share with > > you the source code of the hook scripts, if necessary. > > A very long time ago I had a similar setup where some clients were using > git-svn. This was for the first attempt to migrate the Wikimedia > repositories away from SVN. > > There I had a setup where users could fetch my git-svn clone, which was > hosted on github, and through some magic (I forgot the details) "catch up" > with their local client. I.e. there was some mapping data that wasn't sent > over. > > But users would always push to svn, not git. I think if you can live with > that you'd have a much easier time, having this setup where you push to git > and you then have to carry that push forward to svn is a lot more complex > than just having the clients do that. > > GitHub also has a SVN gateway, that has no open source equivalent that I > know of: https://help.github.com/articles/support-for-subversion-clients/ > > Maybe that's something you'd like to consider, i.e. fully migrate to git > sooner than later, and for any leftover SVN clients have them push to a > private repo on GitHub. Even if you only keep that GitHub repo as a bride > during the migration and host Git in-house it'll be a lot easier with git as > a DVCS to continually merge in those changes than pulling the same trick > with a centralized system like SVN. Hi Ævar, First of all, thank you very much for your early response. I don't think making users always commit to svn is necessary. In fact, from my point of view, updating the svn repository with the changes committed to the git central repository is easy because there is no obstacle preventing to run git svn dcommit at the post-update hook. What I haven't managed to accomplish is to pull diffs from the svn repository into the git central repository without manual intervention. I suppose that in the setup you describe you manually pulled changes from the svn repository into your git-svn repository at GitHub. If don't, it would be very useful for me if you could remember how did you managed to do it automatically. I guess GitHub svn bridge (thank you for telling me about it, I didn't know about its existence) could be the solution if it was not for the fact that we want to keep our svn repository. Our whole CD infrastructure feeds from that repository and we'd like to figure out if everybody is comfortable using git and what is the actual value of using it as a team before making the effort of changing everything. Regards, Jose
RE: Using git svn rebase at quarantine environment or a feasible alternative to synchronize git and svn repositories
> As you noticed, this used to be allowed. But it's dangerous, because if > the movement of the objects out of quarantine fails, then you're left > with a corrupted ref (ditto, anybody looking at the ref after update but > before quarantine ends will see what appears to be a corrupted > repository). > > There are two solutions I can think of: > > 1. The unsafe thing is to just unset $GIT_QUARANTINE_PATH before > running "git svn rebase". That will skip the safety check > completely, enabling the pre-v2.13 behavior. I don't really > recommend this, but modulo the race and unlikely file-moving > errors, it would probably generally work. > > 2. Store intermediate results from pre-receive not as actual refs, and > then install the refs as part of the post-receive. I don't think > there's out of the box support for this, since "git svn rebase" is > always going to call "git rebase", which is going to try to write > refs. > > The smoothest thing would be for the refs code to see that > $GIT_QUARANTINE_PATH is set, write a journal of ref updates into a > file in that path, and then have the quarantine code try to apply > those ref updates immediately after moving the objects out of > quarantine (with the usual lease-locking mechanism). > > That's likely to be pretty tricky to implement, so I'm not even > going to try to sketch out a patch in this email. > > You might be able to do something similar by hand by using a > temporary sub-repository. E.g., "clone -s" to a temp repo, do the > rebase there, and then in the post-receive fetch the refs back. > That's less efficient, but the boundaries of the operation are very > easy to understand. I read about the dangers of updating refs at the pre-receive hook at git-receive-pack man pages and, of course, it's something to take into account. But, given that this setup will be temporary and the technical complexity of the other solutions you propose (solution #2 seems unfeasible and I don't know where to find and how to modify refs code or quarantine code) I'm more predisposed to try solution #1 by now. Moreover, assuming that solution #1 will generally work and the facts that: - I think it would be possible to us to recover from a corrupted repository somehow easily. Couldn't we, for instance, reset from a failed push and try it again? - the chances of corrupting the svn repository, our reference here, seem small because git svn dcommit is the last operation in the chain and is only performed when everything else went ok - we are a small team and git is not our main CVS, so we can stop pushing to git while we fix the repository I'm more inclined to apply this solution. Maybe I'm being too much optimistic with my assumptions. Nevertheless I will investigate the "clone -s" alternative. It seems easy to implement and performance is currently not a limitation for us. > This is definitely the right place. Sorry I don't have a better answer! Thank you for your elaborated response Jeff. It has been a pleasure to write to the git community email group. Regards, Jose
RE: Using git svn rebase at quarantine environment or a feasible alternative to synchronize git and svn repositories
> Makes sense. It's certainly not impossible to have some magic "push to > git". I only wanted to point out that it's extra complexity, so if you > could do away with that aspect of it you'd save yourself some > complexity. I was going to elaborate a bit on how that can go wrong, > but I see Jeff sent a mail just now that was better than what I had :) > > I'll only add that I think you're somewhat fooling yourself if you > think you can run Subversion and Git side-by-side and evaluate both on > their merits, even if you solve the technical aspects of doing that. > Such a system will always need to cater to the lowest common > denominator of Subversion's very centralized workflow. > > The big advantage you get out of DVCSs is being able to be more > flexible, and e.g. using hosting sites (in-house or external) like > GitHub or GitLab which are built around that flexibility. So > ultimately any decision about switching SCMs needs to be a > forward-looking management decision for the project, not based on how > well Git can emulate a SVN-based workflow, which is ultimately not > what you're interested in if you do make the switch. I agree with you about the extra complexity of letting users push to git and carrying the changes to svn through git hooks, Ævar. The reason because we decided to do this is to avoid forcing those who will play git to use svn to perform some actions. We think letting them focus on using git will provide them with a better understanding of git and all of its mechanisms. I know well about the benefits of git, I've been a git user since 2009. But I agreed with development team leaders that this temporary setup will give team members the opportunity to learn git while, at the same time, we avoid to change all of our CD infrastructure until we are ready. Besides that, this will allow both team leaders and members to experience git advantages, for instance, developers will be able to use branches to work on specific features or commit only changes that are ready. Though, as you well say, they won't know about git veritable benefits until we definitely migrate to git and discard svn. Nevertheless, thank you very much for your advice, I will consider it. Regards, Jose
git submodule, multi-threading the update process for large number of registered submodules
Dear Git community Is there any way to run "git submodule update" in multiple threads? The use case: --- "git submodule update" seems to be inefficient when running sequentially on a large .gitmodules file. Assuming a git forest with over 7K gits it takes hours to complete the update (running on Windows+Cygwin) If not supported, this feature could be a good candidate for "git submodule" enhancement. What is your opinion or advice? Thanks and regards José -- 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
Please reply
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please read and reply I would be grateful. Jose Calvache -- 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
Please reply
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please read and reply I would be grateful. Jose Calvache -- 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
Please reply
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please read and reply I would be grateful. Jose Calvache -- 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
Please reply
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please read and reply I would be grateful. Jose Calvache -- 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
Please reply
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please read and reply I would be grateful. Jose Calvache -- 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
Please reply
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please read and reply I would be grateful. Jose Calvache -- 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 Report - Binary Files as plain files, line endings conversions
Hi, $ git add . warning: LF will be replaced by CRLF in web/images/logo_twitter.png. The file will have its original line endings in your working directory. JOSE@COMPAQ /d/wamp/www/internationalstudies.co (master) $ git --version git version 1.7.11.msysgit.0 JOSE@COMPAQ /d/wamp/www/internationalstudies.co (master) $ cat .gitattributes # Auto detect text files and perform LF normalization * eol=crlf JOSE@COMPAQ /d/wamp/www/internationalstudies.co (master) Binary files as an image not may perform any line ending operations, many binary files will be corrupt when are restoring from repository, Saludos, José Nobile -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG Report. Why GIT commit need 30GB of memory for a commit?
I have a big repository, around 80GB git --version #git version 1.7.12 git init . #Initialized empty Git repository in /reponame/.git/ git add -A . git commmit -m "Backup 2012-08-19 03:43:44" #fatal: Out of memory, malloc failed (tried to allocate 32220431361 bytes) #[master (root-commit) 8053f0d] Backup 2012-08-19 03:43:44 Why GIT need 30GB of memory for a commit? This is not in accordance with the first paragraph of the homepage of main page of GIT: Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Greetings, José Nobile -- 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
problems installing GIT on my MAC OS X 10.11.5
Hello, I am doing a data science course and need to download GIT but for some reason I can’t installed it. I called Apple but they couldn’t help and suggested me to contact you guys. I hope you can help me. Thank you very much, Maria Jose Freeman-- 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: problems installing GIT on my MAC OS X 10.11.5
I am very sorry but I am not understanding what you are saying. I will try with homebrew and see if it works that way. > On 14 Jun 2016, at 17:48, Torsten Bögershausen wrote: > > On 14.06.16 18:45, Maria Jose Fernandez wrote: >> From http://git-scm.com/download/mac I clicked to download manually. >> Then it goes to >> https://sourceforge.net/projects/git-osx-installer/files/git-2.8.1-intel-universal-mavericks.dmg/download?use_mirror=autoselect >> I found the git - 2.8.1-intel-universal-mavericks.dmg >> <https://sourceforge.net/projects/git-osx-installer/files/git-2.8.1-intel-universal-mavericks.dmg/download?use_mirror=autoselect> >> downloaded on my desktop. I open that and go through the installation >> process and then it says is installed but not found anywhere on my computer. >> >> > It says ? > > Do you think that you open a terminal and type > which git > git --version > and post the output here ? > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How to combine git repos with similar code and keep all branches and tags?
Hi All, I've got an interesting problem and the possible solutions I've found from searching google don't seem to work for us. In a nutshell, I need to combine multiple git repositories into single repository and preserve all history, branches and tags from each repository. Does anybody have a solution for this, how do this kind of thing, is it even possible? For some unknown reason to me, our developers started a git project, called Ver1, this was the first version. Then sometime later, they created a new git repository called Ver2, the initial commit for Ver2 was essentially a copy of the code in Ver1 from the master. They didn't clone it, they just copied the code at the latest point. This wasn't done by forking. Then they repeated this for Ver3 and Ver4, etc. On top of all that, they have been adding new code to Ver1, Ver2, etc. that has caused each to divert from the other and each have their own branch and tag sets. They have similar directory structure and similar file names, but there are some slight differences in structure. Well, this has become unmanageable and now we want to combine them into one single git repository. Logically, these are the same project but at different versions, basically, Ver1 and Ver2, etc, should be simply branches at different times if these were combined into a single repository. -- 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 combine git repos with similar code and keep all branches and tags?
Thank you! -Original Message- From: Max Horn [mailto:m...@quendi.de] Sent: Tuesday, April 14, 2015 10:15 AM To: Jose de Leon Cc: git@vger.kernel.org Subject: Re: How to combine git repos with similar code and keep all branches and tags? Hi Jose, On 14.04.2015, at 18:44, Jose de Leon wrote: > Hi All, > > > I've got an interesting problem and the possible solutions I've found from > searching google don't seem to work for us. In a nutshell, I need to combine > multiple git repositories into single repository and preserve all history, > branches and tags from each repository. > > Does anybody have a solution for this, how do this kind of thing, is it even > possible? > > For some unknown reason to me, our developers started a git project, called > Ver1, this was the first version. Then sometime later, they created a new > git repository called Ver2, the initial commit for Ver2 was essentially a > copy of the code in Ver1 from the master. They didn't clone it, they just > copied the code at the latest point. This wasn't done by forking. Then they > repeated this for Ver3 and Ver4, etc. On top of all that, they have been > adding new code to Ver1, Ver2, etc. that has caused each to divert from the > other and each have their own branch and tag sets. They have similar > directory structure and similar file names, but there are some slight > differences in structure. > > Well, this has become unmanageable and now we want to combine them into one > single git repository. > > Logically, these are the same project but at different versions, basically, > Ver1 and Ver2, etc, should be simply branches at different times if these > were combined into a single repository. Here is one possible way to go about this using grafts (I used something similar in the past); 1) Get all the data into a single git repository. Since everything is already in a git repositories, you could e.g. create a clone of Ver1; then add remotes for Ver2 ... VerN, and fetch them all, along with tags. If there are conflicts between branch or tag names, deal with them at this point. 2) Create graft points to tie the history together. Identify the commit in Ver1 at which Ver2 branched off. Then, graft that as parent for the initial commits of Ver2. See here for some basic instructions <http://cp.mcafee.com/d/1jWVIq6hEi6jqb2pEVKOyUqenztPqqdNPaabzz1Jd6UVB54sepdFET7cEEKefCQQrzCkknxPVIhgY_WM1nMF9nBPvMF9nBPqa91x1dZ_HYCCMOeWZOWr8W_c3AnXYJteOaqJT6ul3PWApmU6CQjqpK_nd7bwUsMyqemnPtPpesRG9px6k-ciaOUHYouvM070bU8U4EWXcblB2pJngY52PvMgBO7CS1Ob1I5-Aq80LkMq89Rd42V2kfd416kPh17RGQd41ykOpEwF9mh-Nd45GEuq8dwwq82L-Iq8dffd412eMIj-xEwS21EwDF6x8SeudOB_GPPAJ5zzZ> or feel free to ask for details (or Google, or... :) Repeat vor Ver2+Ver3, Ver3+Ver4, etc. 3) Finally, you can get rid of the graft points, and turn everything into a "proper" history, by running "git filter-branch". Something like git filter-branch -- --all ought to do it, but I might be forgetting something (I am sure somebody will correct me soon in that case, though ;-). Best to have a look at <http://cp.mcafee.com/d/2DRPowcCQm4PhPtB5MQsL6XCQQrzCkkn763qqdNPaa8UsOrjhKephhssvdFET7cEEL3DPoyxV_Rw2LxiiLbC_xiiLbCQki322rX_nVddxAtRXBQShR-o78LTVqWtAkRrKcYG7DR8OJMddFCQPt-Kqen1MVx4QsILCXCM0p6kOZbaYLy5rkMzaptShY_yn8hS5ypJngY52PvMgBO7CS1Ob1I5-Aq80LkMq89Rd42V2kfd416kPh17RGQd41ykOpEwF9mh-Nd45GEuq8dwwq82L-Iq8dffd412eMIj-xEwS21EwDF6x8SeudXyyH> for yourself, though. This all is under the assumption that you want to stay as close to how things really were (usually a good idea). But sometimes it may be desirable to make further adjustments. E.g. you may wish to adjust committer names, rearrange some stuff (though usually git is quite good at doing the right thing automatically, etc. How to do that of course depends on what exactly you want to do, but in many cases, filter-branch is your friend. Hope that helps! Max -- 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 hook commit similar to subversion start-commit hook
Hello, Is there any hook in Git similar to start-commit subversion hook? The requirements would be: 1- A hook on the server side (as pre-receive) 2- It will execute the actions *before* the begin of transaction (pre-receive hook needs the references already pushed before). For example, it would be useful to refuse a push if the server has a high load. I have read man githook, but there is nothing similar. Best regard, and excuse my poor english. pgpW9RXG_kEMB.pgp Description: PGP signature
[PATCH] Fixing segmentation fault when merging FETCH_HEAD
From: "Jose Ivan B. Vilarouca Filho"
A segmentaion fault is raised when trying to merge FETCH_HEAD
formed only by "not-for-merge" refs.
Ex:
git init .
git remote add origin ...
git fetch origin
git merge FETCH_HEAD
Signed-off-by: Jose Ivan B. Vilarouca Filho
---
builtin/merge.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 101ffef..7e419dc 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1270,9 +1270,9 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
"an empty head"));
remoteheads = collect_parents(head_commit, &head_subsumed,
argc, argv, NULL);
- remote_head = remoteheads->item;
- if (!remote_head)
+ if ((!remoteheads) || (!remoteheads->item))
die(_("%s - not something we can merge"), argv[0]);
+ remote_head = remoteheads->item;
if (remoteheads->next)
die(_("Can merge only exactly one commit into empty
head"));
read_empty(remote_head->object.oid.hash, 0);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixing segmentation fault when merging FETCH_HEAD
From: "Jose Ivan B. Vilarouca Filho"
Hello, Eric.
Thanks for suggestions. I've added a test in commit replacing git fetch origin
by a fake FETCH_HEAD content.
merge: don't dereference NULL pointer
A segmentaion fault is raised when trying to merge FETCH_HEAD
formed only by "not-for-merge" refs.
Ex:
git init .
git remote add origin ...
git fetch origin
git merge FETCH_HEAD
Signed-off-by: Jose Ivan B. Vilarouca Filho
---
builtin/merge.c |4 ++--
test-merge-fetchhead.sh | 23 +++
2 files changed, 25 insertions(+), 2 deletions(-)
create mode 100755 test-merge-fetchhead.sh
diff --git a/builtin/merge.c b/builtin/merge.c
index 101ffef..098aa8a 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1270,9 +1270,9 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
"an empty head"));
remoteheads = collect_parents(head_commit, &head_subsumed,
argc, argv, NULL);
- remote_head = remoteheads->item;
- if (!remote_head)
+ if (!remoteheads || !remoteheads->item)
die(_("%s - not something we can merge"), argv[0]);
+ remote_head = remoteheads->item;
if (remoteheads->next)
die(_("Can merge only exactly one commit into empty
head"));
read_empty(remote_head->object.oid.hash, 0);
diff --git a/test-merge-fetchhead.sh b/test-merge-fetchhead.sh
new file mode 100755
index 000..383415a
--- /dev/null
+++ b/test-merge-fetchhead.sh
@@ -0,0 +1,23 @@
+#!/bin/bash
+GIT=$(pwd)/git
+REPO_DIR=./test-fetch-head-repo
+
+if [ ! -x "${GIT}" ]; then
+echo "Missing git binary"
+exit 1
+fi
+
+${GIT} init ${REPO_DIR} || rm -rf ${REPO_DIR} || exit 1
+pushd ${REPO_DIR} || rm -rf ${REPO_DIR} || exit 1
+#Let's fake a FETCH_HEAD only formed by not-for-merge (git fetch origin)
+echo -ne "f954fc9919c9ec33179e11aa1af562384677e174\tnot-for-merge\tbranch
'master' of https://github.com/git/git.git"; > .git/FETCH_HEAD
+${GIT} merge FETCH_HEAD
+GRET=$?
+popd
+if [ ${GRET} -eq 139 ]; then
+rm -rf ${REPO_DIR}
+exit 1
+fi
+
+rm -rf ${REPO_DIR}
+exit 0
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
