Search Results

Search found 6054 results on 243 pages for 'git extensions'.

Page 61/243 | < Previous Page | 57 58 59 60 61 62 63 64 65 66 67 68  | Next Page >

  • How to force rebase when same changes applied to both branches manually?

    - by Dmitry
    My repository looks like: X - Y- A - B - C - D - E branch:master \ \ \ \ merge master -> release \ \ M --- BCDE --- N branch:release Here "M - BCDE - N" are manually (unfortunately!) applied changes approximately same as separate commits "A - B - C - D - E" (but seems GIT does not know that these changes are the same). I'd like to rebase and get the following structure: X - Y- A - B - C - D - E branch:master \ * branch:release I.e. I want to make branch:release to be exactly the same as branch:master and fork it from the master's HEAD. But when I run "git rebase master" sitting at the branch release, GIT reports about lots of conflicts and refuces rebasing. How could I solve this? Other explaination of this: I'd like to "re-create" branch:release from scratch from master's HEAD. And there are a lot of other people who had already made "git pull" for the branch:release, so I cannot use git reset + git push -f.

    Read the article

  • What's happened to my directory on GitHub?

    - by Greg K
    I added a new subdir within my git respository: git add feeds Then commited this and pushed it up to GitHub but it seems as though I've commited a symlink / shortcut but not the actual directory and files within. See here: http://github.com/G4EGK/RSS-Reader Any idea what 'feeds' is? I'd like to remove that and correctly add my files. I tried the following but git status said nothing had changed: git rm feeds git add feeds/\*.php To remove feeds do I run the following? git filter-branch --tree-filter 'rm -f feeds' HEAD

    Read the article

  • Translate parse_git_branch function to zsh from bash (for prompt)

    - by yar
    I am using this function in Bash function parse_git_branch { git_status="$(git status 2> /dev/null)" pattern="^# On branch ([^${IFS}]*)" if [[ ! ${git_status}} =~ "working directory clean" ]]; then state="*" fi # add an else if or two here if you want to get more specific if [[ ${git_status} =~ ${pattern} ]]; then branch=${BASH_REMATCH[1]} echo "(${branch}${state})" fi } but I'm determined to use zsh. While I can use this perfectly as a shell script (even without a shebang) in my .zshrc the error is a parse error on this line if [[ ! ${git_status}}... What do I need to do to get it ready for zshell? Edit: The "actual error" I'm getting is " parse error near } and it refers to the line with the strange double }}, which works on Bash. Edit: Here's the final code, just for fun: parse_git_branch() { git_status="$(git status 2> /dev/null)" pattern="^# On branch ([^[:space:]]*)" if [[ ! ${git_status} =~ "working directory clean" ]]; then state="*" fi if [[ ${git_status} =~ ${pattern} ]]; then branch=${match[1]} echo "(${branch}${state})" fi } setopt PROMPT_SUBST PROMPT='$PR_GREEN%n@$PR_GREEN%m%u$PR_NO_COLOR:$PR_BLUE%2c$PR_NO_COLOR%(!.#.$)' RPROMPT='$PR_GREEN$(parse_git_branch)$PR_NO_COLOR' Thanks to everybody for your patience and help. Edit: The best answer has schooled us all: git status is porcelain (UI). Good scripting goes against GIT plumbing. Here's the final function: parse_git_branch() { in_wd="$(git rev-parse --is-inside-work-tree 2>/dev/null)" || return test "$in_wd" = true || return state='' git diff-index HEAD --quiet 2>/dev/null || state='*' branch="$(git symbolic-ref HEAD 2>/dev/null)" test -z "$branch" && branch='<detached-HEAD>' echo "(${branch#refs/heads/}${state})" } PROMPT='$PR_GREEN%n@$PR_GREEN%m%u$PR_NO_COLOR:$PR_BLUE%2c$PR_NO_COLOR%(!.#.$)' RPROMPT='$PR_GREEN$(parse_git_branch)$PR_NO_COLOR' Note that only the prompt is zsh-specific. In Bash it would be your prompt plus "\$(parse_git_branch)". This might be slower (more calls to GIT, but that's an empirical question) but it won't be broken by changes in GIT (they don't change the plumbing). And that is very important for a good script moving forward. Days Later: Ugh, it turns out that diff-index HEAD is NOT the same as checking status against working directory clean. So will this mean another plumbing call? I surely don't have time/expertise to write my own porcelain....

    Read the article

  • Install php extensions on ubuntu

    - by nute
    I have a Ubuntu 9.10 server. I have installed apache2 and php5 using the apt-get commands. How does one install php extensions? Are there commands like apt-get to get them? Or should I manually look for the files on the php website and set them up in the php.ini? More specifically, I need mcrypt, curl and gd. Thanks

    Read the article

  • Useful extensions for MediaWiki

    - by Stan
    Can anyone suggestion some useful MediaWiki extension? I've installed PDF export, syntax lighlight, file link protocol, submit in toolbar, enforce strong password. But still eager to know any good/handy extensions. Thanks

    Read the article

  • Dependent on CVS tagging for automated builds

    - by OMG Ponies
    My current work relies on using tags in CVS for an automated build process (ANT currently) to build for respective environments (development, QA, production). From our research, neither Git or Subversion support tagging in the same manner. If we use Subversion or Git, they don't support tags (in the same manner - please correct me?). So how would ANT or Maven know what to pick up for the respective build? Example: For a webapp, when viewing our repository say for the web.xml file -- the history would look like: web.xml v1 ... web.xml v1.2.3 Tag: Prod web.xml v1.2.4 web.xml v1.2.5 Tag: QA web.xml v1.2.6 web.xml v1.2.7 Head The ANT build scripts are run as CRON jobs, at different times & intervals for different environments. The environment build is based on the repository checkout, based on the tag. Development continues, and eventually the respective tags are moved: web.xml v1 ... web.xml v1.2.3 web.xml v1.2.4 web.xml v1.2.5 web.xml v1.2.6 Tag: Prod web.xml v1.2.7 Tag: QA web.xml v1.2.8 Head

    Read the article

  • What's a good approach to adding debug code to your application when you want more info about what's going wrong?

    - by Andrei
    When our application doesn't work the way we expect it to (e.g. throws exceptions etc.), I usually insert a lot of debug code at certain points in the application in order to get a better overview of what exactly is going on, what the values for certain objects are, to better trace where this error is triggered from. Then I send a new installer to the user(s) that are having the problem and if the problem is triggered again I look at the logs and see what they say. But I don't want all this debug code to be in the production code, since this would create some really big debug files with information that is not always relevant. The other problem is that our code base changes, and the next time, the same debug code might have to go in different parts of the application. Questions Is there a way to merge this debug code within the production code only when needed and have it appear at the correct points within the application? Can it be done with a version control system like git so that all would be needed is a git merge? P.S. The application I'm talking about now is .NET, written in C#.

    Read the article

  • What's so difficult about SVN merges? [closed]

    - by Mason Wheeler
    Possible Duplicate: I’m a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS? Every once in a while, you hear someone saying that distributed version control (Git, HG) is inherently better than centralized version control (like SVN) because merging is difficult and painful in SVN. The thing is, I've never had any trouble with merging in SVN, and since you only ever hear that claim being made by DVCS advocates, and not by actual SVN users, it tends to remind me of those obnoxious commercials on TV where they try to sell you something you don't need by having bumbling actors pretend that the thing you already have and works just fine is incredibly difficult to use. And the use case that's invariably brought up is re-merging a branch, which again reminds me of those strawman product advertisements; if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!) So, discounting the ridiculous strawman use case, what is there in SVN merging that is inherently more difficult than merging in a DVCS system?

    Read the article

  • Can MKS Integrity integrate with other source control tools? (SVN, Git...)

    - by bnsmith
    My boss is interested in using MKS Integrity for bug tracking, feature requests, Wiki documentation and so on. However, we currently use Subversion, and he doesn't want to force us devs to use a version control system that we don't like. Is is possible to integrate a different version control program into MKS Integrity? I'm particularly interested in SVN, Git, Mercurial and Bazaar. If you've tried mixing tools like this before, I'd love to hear about your experiences.

    Read the article

  • Understanding branching strategy/workflow correctly

    - by burnersk
    I'm using svn without branches (trunk-only) for a very long time at my workplace. I had discovered most or all of the issues related to projects which do not have any branching strategy. Unlikely this is not going to change at my workplace but for my private projects. For my private projects which most includes coworkers and working together at the same time on different features I like to have an robust branching strategy with supports long-term releases powered by git. I find out that the Atlassian Toolchain (JIRA, Stash and Bamboo) helped me most and it also recommending me an branching strategy which I like to verify for the team needs. The branching strategy was taken directly from Atlassian Stash recommendation with a small modification to the hotfix branch tree. All hotfixes should also merged into mainline. The branching strategy in words mainline (also known as master with git or trunk with svn) contains the "state of the art" developing release. Everything here was successfully checked with various automated tests (through Bamboo) and looks like everything is working. It is not proven as working because of possible missing tests. It is ready to use but not recommended for production. feature covers all new features which are not completely finished. Once a feature is finished it will be merged into mainline. Sample branch: feature/ISSUE-2-A-nice-Feature bugfix fixes non-critical bugs which can wait for the next normal release. Sample branch: bugfix/ISSUE-1-Some-typos production owns the latest release. hotfix fixes critical bugs which have to be release urgent to mainline, production and all affected long-term *release*es. Sample branch: hotfix/ISSUE-3-Check-your-math release is for long-term maintenance. Sample branches: release/1.0, release/1.1 release/1.0-rc1 I am not an expert so please provide me feedback. Which problems might appear? Which parts are missing or slowing down the productivity?

    Read the article

  • Git: Can I commit my working directory to a new branch without commiting it to a current branch?

    - by Noli
    Somewhat new at Git.. I am working on a project, and had all of my tests passing on the master branch. I then made some changes, and when everything started failing, I realized that maybe I should have made those changes in a different branch. Is there I way I can commit the changes to a new branch without commiting them to my master branch, so that the master still has my passing tests?

    Read the article

  • Many small scripts, one repository or multiple?

    - by The Jug
    A co-worker and myself have run into an issue that we have multiple opinions on. Currently we have a git repository that we are keeping all of our cronjobs in. There are about 20 crons and they are not really related except for the fact that they are all small python scripts and essential for some activity. We are using a fabric.py file to deploy and a requirements.txt file to manage requirements for all of the scripts. Our issue is basically, do we keep all of these scripts in one git repository or should we be separating them out into their own repositories? By keeping them in one repository it is easier to deploy them onto one server. We can use just one cron file for all the scripts. However this feels wrong, as the 20 cronjobs are not logically related. Additionally, when using one requirements.txt file for all the scripts, it's hard to figure out what the dependencies are for a particular script and they all have to use the same versions of packages. We could separate all of the scripts out into their own repositories but this creates 20 different repositories that need to be remembered and dealt with. Most of these scripts are not very large and that solution seems to be overkill. A related question is, do we use one big crontab file for all cronjobs, or a separate file for each? If each has their own, how does one crontab's installation avoid overwriting the other 19? This also seems like a pain as there would then by 20 different cron files to keep track of. In short, our main question and issue is do we keep them all closely bundled as one repository or do we separate them out into their own repository with their own requirements.txt and fabfile.py? We feel like we're also probably looking over some really simple solution. Is there an easier way to deal with this issue?

    Read the article

  • Keeping files that are often changed in sync between desktop and laptop

    - by N.N.
    I'm looking for a way to keep a desktop and a laptop in sync. What I want to keep in sync are some folders, mainly ~/Documents, that are changed often when working on them. If it matters I can connect to my desktop from anywhere via an URL but my laptop is harder to access since it might be behind NAT and such. I have been looking at Ubuntu One but it seems to not go well with working on documents written in LaTeX. If I work on a .tex file in the Ubuntu One directory and compile it (with pdflatex) every now and then (as often as every 10 sec when working) it will create several new files including a pdf which are uploaded to Ubuntu One and this seems stupid since it will create continuous upload when working on .tex files. I also usually keep .tex documents version controlled by git and then every commit (which also can happen frequently) will cause upload (by changes in ./.git) so that it happens continuously when working. Another example is editing images that are saved often. What I think would be best is for sync to happen every tenth minute or at the end of every working session (but there might be some other way to handle this?).

    Read the article

< Previous Page | 57 58 59 60 61 62 63 64 65 66 67 68  | Next Page >