[git-users] Moving from svn
Hi, I'm moving my projects from svn. With svn I use ssh and a svnserve wrapper like this one : #!/bin/sh umask 002 exec /usr/bin/svnserve $@ -r /very/long/path/to/projets So I can use URI like this one : svn co svn+ssh://m...@my-server.com/my-super-project/trunk How can I achieve the same behavior with git (i.e. something like git clone m...@my-server.com:my-super-project) ? Thanks for your coming answers :) -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Git / vcs newbie question: Sharing changes between branches
Hi Alex, thanks for the explainations. I maybe misunderstood the way rebase works, so thank you for clarifying. I did have a look into the git documentation already (brilliant!), but I reached a point where it doesn't cover my particular case, so I decided to ask on the mailing list / group where people with experience could do that. There have been a lot of hints to diffenrent documentation, so I'll work my way through it. While I still have no idea on how exactly to use git with our project, I now better understand how git works and what is technically possible. Cheers Michael On Wed, 25 Sep 2013 05:43:09 -0700 (PDT) Alex Lewis alex.lewis...@gmail.com wrote: Hi Michael, No problem. Yes rebase *or merge*. I'll add an explanation here for both, apologies if you already know the difference. Rebase: Replay one branch on top of another. Merge: Take the commits from each branch and combine them to form a new commit. E.g. Before... m o---o---o---o \--*---* b Rebase: m o---o---o---o \---*---* b Or will often be displayed in tools as m b o---o---o---o---*---* If you wanted the changes on the branch to be included in the history of master you will still need to merge (which would be a fast-forward merge). Merge : m o---o---o---o---# \--*---*--/ b So at # master will now include the changes in the branch *combined* with the code on master. The Git Documentation http://git-scm.com/documentation is very good at explaining this and the rest of Git. Also you may want to try this interactive guide/demo http://pcottle.github.io/learnGitBranching as a way to learn the git commands and see their effect visually (and pretty :) I thoroughly recommend looking at both, maybe the Git docs first followed by the interactive guide. HTH Cheers, Alex On Wednesday, 25 September 2013 13:23:56 UTC+1, Michael Weise wrote: Hi Alex, thanks for your quick and helpful answer. I was just going to ask some question on how exactly to work with branch and diff ... ... and then David already gave the answer and added the missing puzzle-piece: rebase :-) Thanks a lot guys, this was exactly the kind of information I was looking for! Michael Am Mittwoch, 25. September 2013 12:16:33 UTC+2 schrieb Alex Lewis: The first thing I'd like to say is nice one for considering VCS from day one, even many real programmers have not considered it up front. As for your choice of Git, I don't think you'll regret it :) In short I think the answer is sadly a bit of a) and b) and that's the art of writing good software. I don't know C well enough to know how easy or achievable this is but if you can aim for something where you can compartmentalise (modularise) functionality be it customer specific or agnostic. I found this linkhttp://deans-avr-tutorials.googlecode.com/svn/trunk/ManagingLargeProjects/Output/ManagingLargeProjects.pdf which *might* be useful on how to do that. All of this would be on your master branch regardless of whether it was common or customer specific. Hopefully you can then just have various build scripts that will combine those modules into customer specific builds. Your branches in this case would be used to apply bug fixes, patches, etc. to a specific release of the software. E.g. You couldn't give the customer the latest build of the software (Version 2.1.2) including the fix you've needed to apply as it includes new features, changes to API's, etc. It needs to be version 1.4.1 + bug fix (I.e. soon to be 1.4.2, or 1.4.1_1 depending on how you want to number your releases). In this case you would branch from the 1.4.1 release, apply your fix and release from that branch. That branch would live around for as long as a customer is using that version and any subsequent bug fixes, enhancements, etc. would be done on that branch. If those changes apply to the latest version of the code as well you could merge those changes into master. There are *many* ways this can be achieved, all with pros and cons. Like I say I don't know enough about C to suggest whether #ifdefs are the right way to modularise the code and I'm sure people will respond with other suggestions. One thing I will say is try to always consider whether you're trying to use Git for versioning or trying to compensate for the design of the code or the way in which it is built. So having a branch per customer is probably airing towards trying to compensate for the structure of the code, not about a good versioning process. That probably sounds very vague and useless, I'm just finding it very difficult to put it into succinct sentences :) Hope this helps. Alex On Wednesday, 25 September 2013 10:36:39 UTC+1, Michael Weise wrote: Hello
[git-users] gitignore ignored?
Hello. My .gitignore is: *.iws *Db.properties *Db.script .settings stacktrace.log /*.zip /plugin.xml /*.log /*DB.* /cobertura.ser .DS_Store /target/ /out/ /web-app/plugins /web-app/WEB-INF/classes /.link_to_grails_plugins/ /target-eclipse/ When I push my commits I see target and its subdirs in the repository. But target is gitignored, why is it pushed? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Git / vcs newbie question: Sharing changes between branches
Hi David, haha, looks like our minds work in a similar way. I also started disliking the one branch per customer approach. I was planning some kind of refactoring anyway, so using git as a VCS will be part of it. Cheers Christoph On Thu, 26 Sep 2013 16:25:04 +1000 David bouncingc...@gmail.com wrote: On 25 September 2013 22:23, Michael Weise michael.we...@ek-team.de wrote: Thanks a lot guys, this was exactly the kind of information I was looking for! Hi again Michael I just came across this today, I recommend it: https://github.com/pluralsight/git-internals-pdf/releases (click on the pdf download button) Also, I'm writing again because I'm feeling its necessary to clarify my previous message ... its aim was to convey my view that git would assist your project, and that point stands. However, as part of illustrating that for you in terms that you would relate to your project, I gave an example of how you might use git to create separate branches for each customer. But ... the more I think about this as a proposed architecture, the more I dislike it. It is not zero work to manage all those branches, and I feel sure there must be simpler ways to solve the problem. So I still encourage you to use git, but I suggest you could use it to plan and implement a transition towards a better code structure than the one I used in that example. Restating what I wrote before: It might be much cleaner to handle some of the customer difference logic in the executable C, rather than conditional compiles. You could implement a set of meaningful flags, and use combinations of those flags to describe the requirements for each customer. That way, the codebase could be the same for every customer. There could be one file that defines what feature flags are enabled for each customer. You could do that with #ifdefs, or preferably in other nicer ways. #ifdefs are ugly. They are good for keeping code out of the build, to keep it small or ensure that customers can't reverse engineer access to features they haven't paid for. If those issues are not important, then in your situation I would work towards refactoring out the #ifdefs in favour of some other method that is clearer and easier to maintain. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Michael Weise michael.we...@ek-team.de -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Git / vcs newbie question: Sharing changes between branches
Hi Konstantin Gergely,
in principle I understand the concept of modularization.
My problem is that the differences in the code are on multiple
layers that make it very hard to modularize. I'll give some real
examples (bootloader for an embedded device) and detail:
a) Basic Setup: Device should accept firmware updates on pushing a
certain button-combination. Then it should do a memory test. If
there's no firmware update, it should boot the installed firmware.
If the buttons are pressed, it should receive a firmware update
over a usb connection an install it into flash.
b) Customer wants a device without buttons, so it should wait for a
firmware update for 15 seconds and then boot the installed firmware
if no update is received
Currently, most of this is implemented in the main() function. As
far as I know, one concept of C is that some crt0()-function
sets up the environt. When using a clean approach, as soon
as main() is called, everything should be set up correctly: Stack
pointer, ram modules, etc.
The ram test routine however destroys the contents of the memory, so
it should happen before calling main(). Currently checking the
button status happens IN main(), but the ram test should happen
afterwards ...
Looks like the code needs some refactoring ;-)
Yeah, I see this is getting off topic, so I'll stop here. Just
wanted to let you know what I'm actually talking about.
Thanks for pointing to StackOverflow and the comp.lang.c newsgroup,
might be helpful soon ...
Cheers
Michael
On Wed, 25 Sep 2013 18:07:11 +0400
Konstantin Khomoutov flatw...@users.sourceforge.net wrote:
On Wed, 25 Sep 2013 02:36:39 -0700 (PDT)
Michael Weise michael.we...@ek-team.de wrote:
[...]
One problem I'm facing is that we have different customers who get
different versions of our program (programming language is C).
Currently these versions are implemented with lots of #ifdefs that
make the code hard to read.
Not sure if this applicable to your particular situation but one way to
go about solving this is modularising: you extract all the common code
to a library (static or dynamic -- depends on the exact requirements)
and then write a *separate* program for each customer, and each would
use the library by linking with it. Yes, this *is* code duplication
as these separate programs will have much in common and possibly even
some exact parts but it's quite possibly this won't be code you change
much.
A refinement to this approach is to turn functions which have #ifdef-ed
code into several (similar) functions each, or may be a single
-- framework -- function which, when called, receives one of more
pointers to other functions which provide bits currently coded inside
#ifdefs, like this:
int foo()
{
int x;
x = quux();
#ifdef SOME
blurb(x);
#else
mumble(x);
#endif /* SOME */
return x;
}
turns into
typedef void (* handle_x_fn) (int *); // see [1], for instance
int foo(handle_x_fn fn)
{
int x;
x = quux();
fn(x);
return x;
}
which is then called
y = foo(blurb);
or
y = foo(mumble);
depending on which customer's program this is, with foo() being located
in the library both programs share.
This is called modularisation.
I've consciously diverged from the topic in the hope this would be of
some help, but if it is, you're better off asking about the exact
techniques for modularisation in C using other venues such as Stack
Overflow and comp.lang.c newsgroup available here on Google Groups.
Hope this helps.
1. http://stackoverflow.com/a/1591492/720999
--
You received this message because you are subscribed to the Google Groups
Git for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an
email to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] gitignore ignored?
On Fri, 27 Sep 2013 00:53:21 -0700 (PDT) Mauro Sanna mrsan...@gmail.com wrote: [...] When I push my commits I see target and its subdirs in the repository. But target is gitignored, why is it pushed? There are several misunderstandings here: 1) Mechanisms for ignoring files in Git have nothing to do with pushing and fetching: these operations manipulate existing commits and references pointing at them. It's index updates (`git add`) and, in certain cases, work tree oprtations (`git rm`, `git clean` etc) which consider ignore lists (so that, say `git add '*'` won't add auto-built cruft added to an ignore list). 2) Mere updating of a branch in a remote repo does not do anything to the subdirs in the repository because such subdirs only occur in the work tree of a non-bare repository, and the push operation is not concerned about the work tree (short of respecting the receive.denyCurrentBranch configuration variable which forbids updating of a branch which is currently checked out in a non-bare repository). So it might be that if you actually *deleted* already tracked unwanted files and recorded a commit which does not contain them anymore and then arranged for them to be excluded by the Git file ignoring mechanism, and then updated a remote branch with your commit, you now need to actually update your work tree to the new state of the updated branch -- for instance, by doing git reset --hard in the work tree (provided the updated branch is what is currently checked out, -- otherwise a mere `git checkout that_branch` would suffice). -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Moving from svn
On Fri, 27 Sep 2013 00:29:47 -0700 (PDT) Fabien Bourigault dra...@gmail.com wrote: I'm moving my projects from svn. With svn I use ssh and a svnserve wrapper like this one : #!/bin/sh umask 002 exec /usr/bin/svnserve $@ -r /very/long/path/to/projets So I can use URI like this one : svn co svn+ssh://m...@my-server.com/my-super-project/trunk How can I achieve the same behavior with git (i.e. something like git clone m...@my-server.com:my-super-project) ? Nothing different if you're okay with having real system Unix accounts for your developer on a target system. The only problem is short pathnames of projects but I'll show ways to deal with it after explaining the basic setup. The main premise to make things work is that your Git-repositories should be group-shared. Git has support for this, but for convenience you'd better off helping it to do its part of the work properly. 1) Install Git. There's no special server-side Git binary if you intend to access your repositories using SSH [*], so just install Git like `apt-get install git`. 2) Make sure all your system accounts for Git developers are members of a single special group -- be it devel or git, -- it doesn't matter. Suppose we've picked git for this. 3) Create a central place for your repositories. On a typical GNU/Linux system conforming to FHS, I'd recommend to create the /srv/git directory (you already have /srv) and make it belong to root:git and have access rights 2755 (or 2750 if you're paranoid), that is, group writable with group sticky bit set on. 4) For each of your project, create a *bare, shared* repository by running something like this: # cd /srv/git # umask 002 # git init --bare --shared project1.git Verify that the created project directory and its files have sensible access rights -- the --shared option which is short for --shared=group ensures the directory is group-writable and has group sticky bit set on it, and the step (3) should have made the directory's owning group to be git. 5) Now try to push something to is from a client: git remote add origin ssh://m...@my-server.com/srv/git/project1.git git push origin master You can now see that you can't easily drop the leading part of the project's directory pathname from the remote repository's URL because there's no layer of indirection when accessing Git repositories via SSH: the client Git process just spawns another Git process on the remote machine after setting up an SSH channel, and hands it off the pathname. The only supported shortcut is ~ with the expected meaning. I'd say that is not really a problem because: 1) Most of the time you're working with named remotes, so you only have to type in the URL once. 2) If the repositories are located in a somewhat standardized place (/srv/git), the leading pathname part is not a big deal to type. Anyway, there's another approach which is a layer of indirection between you and Git. These days, a low-level de-facto standard tool for this is gitolite [1]. It provides *virtualized* Git users (so that you only have one system account to access Git repositories, and still each developer has their own SSH key), repository- and branch-level access controls, and more. And as a by-product, since it requires all the repositories be located under a single directory, and it knows which one, it provides for short-cut syntax, like ssh://me@my-server/myproject [*] There's a special Git daemon, unsurprisingly called git-daemon, which is able to serve Git repositories: unauthenticated and hence read-only (but you can turn certain knobs to make it serve R/W as well--in certain controlled environments this might be OK to do). This daemon works kind of like svnserve in that it allows to specify a base directory for the projects using its --base-path command-line option. 1. https://github.com/sitaramc/gitolite -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Question: git merge origin/master
This will work (if use 3 dots instead off 2), but only on entire branch, ( I will see ALL my changes on this branch) If, on the other hand, I want to see changes for, say, last 2 days, I will also get all changes introduced by merge commits that happend in this period. What I want is to see something like git diff A B MINUS origin/master That was my question On Fri, Sep 27, 2013 at 3:48 PM, Marcelo Avila mav...@cpqd.com.br wrote: Sorry, I think I lost the focus here... Suppose you have something like this: B---E---F---H topic / / A---C---D---G master I think that what you want is: git diff master..topic Which will show differences introduced by commits B, E, F and H I hope this helps... -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com If we get back to my question - there is no way to see difference between between two arbitrary commits in my task branch excluding diffs resulted from merges, right ? четверг, 26 сентября 2013 г., 16:21:46 UTC+4 пользователь Marcelo Avila написал: Yes, if somebody do any commit based on your commits you can not use rebase, but this must only happen when your task is done and you do not want to use rebase anymore. In other words, work in you tasks rebasing when needed, you can share your commits to someone but nobody can make commits based in your commits until your work is done and submitted to the main line, when this happens it's time to start working in another task... Recompilations: I can't see any difference in using rebase or merge in this specific topic, I think that the number of recompilations will be exactly the same using one method or the other. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/26 Gergely Polonkai ger...@polonkai.eu Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstan...@gmail.com wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I have done. I always can find what I have done in my branch from the start, by 'git diff origin/master...task_b' but I cannot find my changes between two given commits or by several last commits, as it always shows any merges that have been done in-between. Is there any remedy for this problem ? Regards, Konstantin -- You received this message because you are subscribed to
Re: [git-users] restrict history/messages on push?
On Wed, 25 Sep 2013 22:19:35 -0400 Tom Roche tom_ro...@pobox.com wrote: [...] 23rw4kf 23 Sep 2013 09:39 Foo? 98bjttr 24 Sep 2013 12:34 Rollback! Bar. 07657ab 25 Sep 2013 10:11 Arrggg! Baz. 1495fcc 25 Sep 2013 23:45 Self-serving explanation. Fred wants to push 1495fcc to the public repo, but doesn't want manager Ethel (or anyone else) to see commits=[23rw4kf, 98bjttr, 07657ab], much less those commit messages. Fred wants one of two options: [...] Another option is `git merge --squash` of 1495fcc (which is supposedly a tip or a branch) into another branch into which this one is about to be integrated. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Question: git merge origin/master
The use of .. or ... will depend if you want to include the commit G (in my example) or not. With this command you get something next you want: git log --no-merges -p commi1..commit2 --not master -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com This will work (if use 3 dots instead off 2), but only on entire branch, ( I will see ALL my changes on this branch) If, on the other hand, I want to see changes for, say, last 2 days, I will also get all changes introduced by merge commits that happend in this period. What I want is to see something like git diff A B MINUS origin/master That was my question On Fri, Sep 27, 2013 at 3:48 PM, Marcelo Avila mav...@cpqd.com.br wrote: Sorry, I think I lost the focus here... Suppose you have something like this: B---E---F---H topic / / A---C---D---G master I think that what you want is: git diff master..topic Which will show differences introduced by commits B, E, F and H I hope this helps... -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/27 Konstantin Kivi konstantin.k...@gmail.com If we get back to my question - there is no way to see difference between between two arbitrary commits in my task branch excluding diffs resulted from merges, right ? четверг, 26 сентября 2013 г., 16:21:46 UTC+4 пользователь Marcelo Avila написал: Yes, if somebody do any commit based on your commits you can not use rebase, but this must only happen when your task is done and you do not want to use rebase anymore. In other words, work in you tasks rebasing when needed, you can share your commits to someone but nobody can make commits based in your commits until your work is done and submitted to the main line, when this happens it's time to start working in another task... Recompilations: I can't see any difference in using rebase or merge in this specific topic, I think that the number of recompilations will be exactly the same using one method or the other. -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/26 Gergely Polonkai ger...@polonkai.eu Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits. The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, Konstantin Kivi konstan...@gmail.com wrote: Honestly, I right now I don't have to publish (make public ) branches, as for current progects I use git locally, and use svn as main repository. But new projects use git only, so I have to return to right track. All documenation says that rebasing a branch that was made public is a bad idea, as people who used my branch will have numerous conflicts after I do rebase. As to recompilations, it of course depend on the nature of changes in master branch and in my task branch. If in my task I have heavy header file changes (C++) then switching to master ( which is requiried to do svn up or git pull ) will cause timestamp changes of that header and thus recompliations. Updates of master branch can also change header files, so sometimes it doesn't matter. The main reason of not useing rebase is that it is not recommended by books. среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila написал: Yes, the solution is to switch back to the rebase approach... I didn't understand some points: Why you could not publish your task branch? Why the rebase approach leads to massive recompilations? -- *Marcelo Ávila de Oliveira* CPqD - Information Technology Engineer Tel.: +55 19 3705-4125 mav...@cpqd.com.br www.cpqd.com.br 2013/9/25 Konstantin Kivi konstan...@gmail.com Hello All. First I must apologize for asking a question in other people's thread (which I don't like myself) , but you are talking about the approach that I am going to use, so decided that this will be appropriate in this case. Here is the question. I recently decided to switch from 'task branch rebase' aproach to 'merge' approach. I used to work in the task branch, periodically switching to master, making pull and rebasing task branch. This worked fine, except I could not publish my task branch. And it also leads to massive recompilations, since I have to switch to master and then back. I decided to switch to merge apporoach, that is do fetch periodically, and then merge 'origin/master' to my task branch. The problem now is how to check what I
[git-users] Static build of git
I'm having trouble building git statically. I have an entire toolchain that
is built statically, there are no shared libraries. I'm trying to build
git as a part of this toolchain and it has all kinds of link errors that I
think have to do with the configure.
I'm running the following configure command...
./configure --prefix=$PREFIX CFLAGS=${CFLAGS} -static
If I build I add NO_OPENSSL and NO_CURL things will compile fine. I would
like to have at the least https functionality so I'm trying to get curl to
link which seems to get me hung up on the library dependencies when
linking. I have to add things like LIBS=-lcrypto -lssl to the configure
to get remotely close to linking properly.
Can better support for static linking get added to the configure/Makefile
scripts?
On thing I've noticed with configure scripts is that they always expect
dynamic libraries to be present. This is not always the case. If the static
option is specified during configure, the configuration tests should do
static linking as well to verify the library is present.
One thing that I've found that normally always works is when the configure
scripts make use of pkg-config. If pkg-config is given the --static
argument all of the linking dependencies are returned and compilation works
perfectly.
I'd love to see some improvements to the compilation process for static
builds, but at the very least I'd appreciate some help getting this built.
Thanks,
Jared
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Static build of git
On Fri, 27 Sep 2013 11:21:27 -0700 (PDT) Jared Szechy jared.sze...@gmail.com wrote: I'm having trouble building git statically. [...] Sorry for not answering the question directly (have no time for this at the moment) but attempting to build Git statically may have little sense indeed -- please see [1]. I'd say if you have a requirement like this, consider using a tool which was created with this in mind [2]. 1. https://groups.google.com/d/msg/git-users/xjgaMTb8JWw/atQkXc5gqbQJ 2. http://www.fossil-scm.org -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
