[git-users] Re: Strange problem on Mac OS X git 1.8.4
On Wednesday, August 28, 2013 5:09:02 AM UTC+2, TC Wan wrote: Hi, I'm having a strange problem with git but only on Mac OS X. There is a public repository https://github.com/mindboards/ev3sources.gitwhich when cloned to Linux works correctly, but when cloned to Mac OS X (tested on 10.8.4, git 1.8.4), gives the following output immediately after a fresh clone: $ git --version git version 1.8.4 $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # #modified: extra/linux-03.20.00.13/Documentation/IO-mapping.txt #modified: extra/linux-03.20.00.13/include/linux/netfilter/xt_CONNMARK.h #modified: extra/linux-03.20.00.13/include/linux/netfilter/xt_DSCP.h #modified: extra/linux-03.20.00.13/include/linux/netfilter/xt_MARK.h #modified: extra/linux-03.20.00.13/include/linux/netfilter/xt_RATEEST.h #modified: extra/linux-03.20.00.13/include/linux/netfilter/xt_TCPMSS.h #modified: extra/linux-03.20.00.13/include/linux/netfilter_ipv4/ipt_ECN.h #modified: extra/linux-03.20.00.13/include/linux/netfilter_ipv4/ipt_TTL.h #modified: extra/linux-03.20.00.13/include/linux/netfilter_ipv6/ip6t_HL.h #modified: extra/linux-03.20.00.13/net/ipv4/netfilter/ipt_ECN.c #modified: extra/linux-03.20.00.13/net/netfilter/xt_CONNMARK.c #modified: extra/linux-03.20.00.13/net/netfilter/xt_DSCP.c #modified: extra/linux-03.20.00.13/net/netfilter/xt_HL.c #modified: extra/linux-03.20.00.13/net/netfilter/xt_MARK.c #modified: extra/linux-03.20.00.13/net/netfilter/xt_RATEEST.c #modified: extra/linux-03.20.00.13/net/netfilter/xt_TCPMSS.c #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libip6t_HL.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libipt_ECN.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libipt_TTL.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libxt_CONNMARK.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libxt_DSCP.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libxt_MARK.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libxt_RATEEST.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libxt_SET.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libxt_TCPMSS.so #modified: extra/linux-devkit/arm-none-linux-gnueabi/usr/libexec/xtables/libxt_TOS.so #modified: lms2012/lms2012/doc/html/PWMModule.html #modified: lms2012/lmssrc/TEST/CVS/Entries #modified: lms2012/lmssrc/TEST/CVS/Repository #modified: lms2012/lmssrc/TEST/TEST/CVS/Entries #modified: lms2012/lmssrc/TEST/TEST/CVS/Repository #modified: lms2012/lmssrc/TEST/update # $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true precomposeunicode = false [remote origin] url = g...@github.com:mindboards/ev3sources.git fetch = +refs/heads/*:refs/remotes/origin/* [branch master] remote = origin merge = refs/heads/master Is this a known problem? What is the fix? TIA I get the same situation on my machine (OS X 10.8.4). Funny thing is that there are actually real diffs, not just some EOL conversion stuff. Excerpt: diff --git a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt index 1b5aa10..473e43b 100644 --- a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt +++ b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt @@ -1,208 +1,82 @@ -[ NOTE: The virt_to_bus() and bus_to_virt() functions have been - superseded by the functionality provided by the PCI DMA interface - (see Documentation/PCI/PCI-DMA-mapping.txt). They continue - to be documented below for historical purposes, but new code - must not use them. --davidm 00/12/12 ] +The io_mapping functions in linux/io-mapping.h provide an abstraction for +efficiently mapping small regions of an I/O device to the CPU. The initial +usage is to support the large graphics aperture on 32-bit processors where +ioremap_wc cannot be used to statically map the entire aperture to the CPU +as it would consume too much of the kernel address space. What's even stranger is that I can't get rid of the changes. git checkout . has no effect. I then had a look at what commits these two pieces of contents appear in: commit fea79c0e219cd5e43193ce2987b496e04758f3e2 Author: Xander Soldaat xan...@botbench.com Date: Wed Jul 31 14:58:56 2013 -0700 Additional files, like
[git-users] Re: Strange problem on Mac OS X git 1.8.4
Doh, I managed to paste the same content twice in my previous mail. I'll try again, and delete the original in the online forum one for easier reading. my mail again, this time with correct paste I get the same situation on my machine (OS X 10.8.4). Funny thing is that there are actually real diffs, not just some EOL conversion stuff. Excerpt: diff --git a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt index 1b5aa10..473e43b 100644 --- a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt +++ b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt @@ -1,208 +1,82 @@ -[ NOTE: The virt_to_bus() and bus_to_virt() functions have been - superseded by the functionality provided by the PCI DMA interface - (see Documentation/PCI/PCI-DMA-mapping.txt). They continue - to be documented below for historical purposes, but new code - must not use them. --davidm 00/12/12 ] +The io_mapping functions in linux/io-mapping.h provide an abstraction for +efficiently mapping small regions of an I/O device to the CPU. The initial +usage is to support the large graphics aperture on 32-bit processors where +ioremap_wc cannot be used to statically map the entire aperture to the CPU +as it would consume too much of the kernel address space. What's even stranger is that I can't get rid of the changes. git checkout . has no effect. I then had a look at what commits these two pieces of contents appear in: commit fea79c0e219cd5e43193ce2987b496e04758f3e2 Author: Xander Soldaat xan...@botbench.com Date: Wed Jul 31 14:58:56 2013 -0700 Additional files, like kernel, uboot and device specific lib/includes diff --git a/extra/linux-03.20.00.13/Documentation/io-mapping.txt b/extra/linux-03.20.00.13/Documentation/io-mapping.txt new file mode 100644 index 000..473e43b --- /dev/null +++ b/extra/linux-03.20.00.13/Documentation/io-mapping.txt @@ -0,0 +1,82 @@ +The io_mapping functions in linux/io-mapping.h provide an abstraction for +efficiently mapping small regions of an I/O device to the CPU. The initial +usage is to support the large graphics aperture on 32-bit processors where +ioremap_wc cannot be used to statically map the entire aperture to the CPU +as it would consume too much of the kernel address space. and commit fea79c0e219cd5e43193ce2987b496e04758f3e2 Author: Xander Soldaat xan...@botbench.com Date: Wed Jul 31 14:58:56 2013 -0700 Additional files, like kernel, uboot and device specific lib/includes diff --git a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt new file mode 100644 index 000..1b5aa10 --- /dev/null +++ b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt @@ -0,0 +1,208 @@ +[ NOTE: The virt_to_bus() and bus_to_virt() functions have been + superseded by the functionality provided by the PCI DMA interface + (see Documentation/PCI/PCI-DMA-mapping.txt). They continue + to be documented below for historical purposes, but new code + must not use them. --davidm 00/12/12 ] The same commit! And in the same file! Or is it really? No, the first file has lowercase letters only, while the other one as IO uppercase. This means that the author has a filesystem that is case-sensitive, while ours is not. So effectively, the second file is checked out on top of the other (or the other way around). So either you have to check out the code on a case sensitive file system, or the author has to be a bit nicer and not check in files like that :) -- 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.
[git-users] Re: Strange problem on Mac OS X git 1.8.4
On Wednesday, August 28, 2013 2:56:55 PM UTC+8, Thomas Ferris Nicolaisen wrote: Doh, I managed to paste the same content twice in my previous mail. I'll try again, and delete the original in the online forum one for easier reading. my mail again, this time with correct paste I get the same situation on my machine (OS X 10.8.4). Funny thing is that there are actually real diffs, not just some EOL conversion stuff. Excerpt: diff --git a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt index 1b5aa10..473e43b 100644 --- a/extra/linux-03.20.00.13/Documentation/IO-mapping.txt +++ b/extra/linux-03.20.00.13/Documentation/IO-mapping.txt @@ -1,208 +1,82 @@ -[ NOTE: The virt_to_bus() and bus_to_virt() functions have been - superseded by the functionality provided by the PCI DMA interface - (see Documentation/PCI/PCI-DMA-mapping.txt). They continue - to be documented below for historical purposes, but new code - must not use them. --davidm 00/12/12 ] +The io_mapping functions in linux/io-mapping.h provide an abstraction for +efficiently mapping small regions of an I/O device to the CPU. The initial +usage is to support the large graphics aperture on 32-bit processors where +ioremap_wc cannot be used to statically map the entire aperture to the CPU +as it would consume too much of the kernel address space. What's even stranger is that I can't get rid of the changes. git checkout . has no effect. This was what I found also. I cannot revert the checkouts. In addition, the diffs appear to come from (random) past versions. The same commit! And in the same file! Or is it really? No, the first file has lowercase letters only, while the other one as IO uppercase. This means that the author has a filesystem that is case-sensitive, while ours is not. So effectively, the second file is checked out on top of the other (or the other way around). So either you have to check out the code on a case sensitive file system, or the author has to be a bit nicer and not check in files like that :) But this is the first time I'm encountering this problem. I've checked out other repositories created on Linux previously to Mac OS X without any consistency issues, but this is the first time I'm seeing this on Mac OS X where git seems to think that there are modified files. On a Linux system the repository appears to be correctly handled by git. Setting ignorecase = false does not have any effect. -- 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.
[git-users] Re: Strange problem on Mac OS X git 1.8.4
On Wednesday, August 28, 2013 3:29:19 PM UTC+8, TC Wan wrote: On Wednesday, August 28, 2013 2:56:55 PM UTC+8, Thomas Ferris Nicolaisen wrote: The same commit! And in the same file! Or is it really? No, the first file has lowercase letters only, while the other one as IO uppercase. This means that the author has a filesystem that is case-sensitive, while ours is not. So effectively, the second file is checked out on top of the other (or the other way around). So either you have to check out the code on a case sensitive file system, or the author has to be a bit nicer and not check in files like that :) Ok I went back to a Linux system and checked the contents of the directory. There are two separate files in the directory: $ ll io-mapping.txt IO-mapping.txt -rw-rw-r--. 1 ev3builder ev3builder 3288 Aug 5 12:14 io-mapping.txt -rw-rw-r--. 1 ev3builder ev3builder 8049 Aug 5 12:14 IO-mapping.txt On Mac OS X: $ ll io-mapping.txt IO-Mapping.txt -rw-r--r-- 1 tcmac staff 3288 Aug 28 10:57 IO-Mapping.txt -rw-r--r-- 1 tcmac staff 3288 Aug 28 10:57 io-mapping.txt Technically there's only one file, but Mac OS X ls -l permitted the display of the capitalized IO-Mapping.txt, which is confusing... but tab-completion only found io-mapping.txt. Thanks a lot for solving this mystery. Looks like the original repository needs cleaning up. -- 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.
[git-users] Regarding cloning and best practices
Here's my situation and I need advice on what the best way to handle it is as I'm newer to Git. I'm using these repositories as my own and I'm not working in tandem with anyone else but I want to keep my workflow clean and able to incorporate anybody I add to the project later. Here goes: I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? Thanks, Jason -- 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] Regarding cloning and best practices
There was a tutorial'ish post here on the list a few days ago about named remotes. If you clone a remote repository, a named remote is created, called origin, and your local master (or whatever) branch is set to track origin/master. Now if you change origin's URL (git remote --set-url user@host:new-repo.git), and do a git push, your changes will go to the new repo. Best, Gergely On 28 Aug 2013 16:55, Jaace jb5...@gmail.com wrote: Here's my situation and I need advice on what the best way to handle it is as I'm newer to Git. I'm using these repositories as my own and I'm not working in tandem with anyone else but I want to keep my workflow clean and able to incorporate anybody I add to the project later. Here goes: I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? Thanks, Jason -- 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] Regarding cloning and best practices
Thanks for the quick reply Gergely! I will look into doing this On Wednesday, August 28, 2013 11:00:10 AM UTC-4, Gergely Polonkai wrote: There was a tutorial'ish post here on the list a few days ago about named remotes. If you clone a remote repository, a named remote is created, called origin, and your local master (or whatever) branch is set to track origin/master. Now if you change origin's URL (git remote --set-url user@host:new-repo.git), and do a git push, your changes will go to the new repo. Best, Gergely On 28 Aug 2013 16:55, Jaace jb5...@gmail.com javascript: wrote: Here's my situation and I need advice on what the best way to handle it is as I'm newer to Git. I'm using these repositories as my own and I'm not working in tandem with anyone else but I want to keep my workflow clean and able to incorporate anybody I add to the project later. Here goes: I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? Thanks, Jason -- 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+...@googlegroups.com javascript:. 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] Nuevo con Git...
Hola, empecé de nuevo... borré el repositorio en el servidor y lo hice de nuevo, luego desde el repositorio en mi lap traté de hacer inicializar y push al repositorio del servidor, y me marca lo siguiente: Reinitialized existing shared Git repository in //apliserver/Repository/SIIACPlus/ Pushing to \\apliserver\Repository\SIIACPlus fatal: '\apliserver\Repository\SIIACPlus' 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. Los dos pasos los estoy haciendo desde mi lap, primero crear el repositorio en el servidor y luego desde el proyecto que tengo en mi lap hacer el push Gracias y Saludos Pedro El 27 de agosto de 2013 15:15, Pedro Contreras jpce@gmail.comescribió: si, tengo entendido que con eso ya quedan relacionados mi proyecto Master y mi proyecto Repositorio 2013/8/27 Juan Fernando Obando Saldarriaga juancho...@gmail.com Ya has adicionado el remote a tu repositorio Git? On Tue, Aug 27, 2013 at 3:03 PM, Pedro Contreras jpce@gmail.comwrote: Hola, el que instalé es el Git GUI y desde el Visual el Extensions Si puedo hace el Commit en el master, pero al querer hacer el Push para subir los cambios al Repositorio me marca lo siguiente: C:\Program Files\Git\bin\git.exe push --recurse-submodules=check --progress SIIACPlus master:master fatal: '\apliserver\Repository\SIIACPlus' 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. Done Gracias Pedro El 27 de agosto de 2013 14:31, Juan Fernando Obando Saldarriaga juancho...@gmail.com escribió: Hola, - Cuál servicio estas utilizando (GitHub, BitBucket, etc)? - Con cuál comando estás haciendo el push? 2013/8/27 Pedro Contreras jpce@gmail.com Hola, Estoy iniciando con Git y no he podido hacer que teniendo un Repositorio (en el Servidor) y teniendo un Master (Local) pueda hacer el push para actualizar el Repositorio, el manejo en el Master al parecer si me funciona bien, pero me interesa poder usar un Repositorio para controlar varias personas en un mismo proyecto... ¿Alguien me puede orientar por favor? Gracias y Saludos Pedro -- 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. -- *Juan Obando* about.me/juanchopx2 -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/x97P0qesh1w/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Pedro Contreras http://mx.linkedin.com/in/pedrocontreras/ -- 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. -- *Juan Obando* about.me/juanchopx2 -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/x97P0qesh1w/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Pedro Contreras http://mx.linkedin.com/in/pedrocontreras/ -- Pedro Contreras http://mx.linkedin.com/in/pedrocontreras/ -- 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] Regarding cloning and best practices
On Wed, 28 Aug 2013 07:55:11 -0700 (PDT) Jaace jb5...@gmail.com wrote: [...] I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? No. `git clone`, being a pretty high-level command, does certain convenience magic with the local repository it creates and populates, which ties it to the original repository. But in fact these ties are very loose, and are rooted in a single bit of the local repository configuration, which is the named remote -- origin. `git clone` goes like this: 1) Initializes a local repo (possibly creating a directory for it first). 2) Adds a single remote named origin to the repository's configuration. 3) Runs `git fetch origin` which makes Git fetch all the branches the remote repository has, and create a single so-called remote branch (these are those origin/master, origin/devel etc branches you can list by running `git branch -r`) for each branch the remote repository has. 4) It then asks the remote where its HEAD reference points, and, if it points to a branch (true in 99.9% cases), creates a local branch in your repository which is linked to the matching remote branch in it (created in step 3). Most of the time remote repositories, being bare, have their HEAD point to a branch named master, and that's why `git clone` most of the time ends up creating a local branch master which is set to track the remote branch origin/master. If you feel yourself lost in these remotes, remote branches and remote-tracking branches, then read [1] and [2], in this order (reading the whole book before embarking on using Git is highly recommended); also see [3]. So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? It's so simple it's ridiculous -- just do git remote set-url origin GIT_URL_OF_ANOTHER_REPOSITORY and then all Git commands to which you supply the name origin would reach for that new URL. That URL, obviously, should be of a new repository (supposedly created somewhere using `git init --bare`). 1. http://git-scm.com/book/en/Git-Basics-Working-with-Remotes 2. http://git-scm.com/book/en/Git-Branching-Remote-Branches 3. http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html -- 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] Regarding cloning and best practices
Awesome, thanks! On Wednesday, August 28, 2013 11:23:22 AM UTC-4, Konstantin Khomoutov wrote: On Wed, 28 Aug 2013 07:55:11 -0700 (PDT) Jaace jb5...@gmail.com javascript: wrote: [...] I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? No. `git clone`, being a pretty high-level command, does certain convenience magic with the local repository it creates and populates, which ties it to the original repository. But in fact these ties are very loose, and are rooted in a single bit of the local repository configuration, which is the named remote -- origin. `git clone` goes like this: 1) Initializes a local repo (possibly creating a directory for it first). 2) Adds a single remote named origin to the repository's configuration. 3) Runs `git fetch origin` which makes Git fetch all the branches the remote repository has, and create a single so-called remote branch (these are those origin/master, origin/devel etc branches you can list by running `git branch -r`) for each branch the remote repository has. 4) It then asks the remote where its HEAD reference points, and, if it points to a branch (true in 99.9% cases), creates a local branch in your repository which is linked to the matching remote branch in it (created in step 3). Most of the time remote repositories, being bare, have their HEAD point to a branch named master, and that's why `git clone` most of the time ends up creating a local branch master which is set to track the remote branch origin/master. If you feel yourself lost in these remotes, remote branches and remote-tracking branches, then read [1] and [2], in this order (reading the whole book before embarking on using Git is highly recommended); also see [3]. So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? It's so simple it's ridiculous -- just do git remote set-url origin GIT_URL_OF_ANOTHER_REPOSITORY and then all Git commands to which you supply the name origin would reach for that new URL. That URL, obviously, should be of a new repository (supposedly created somewhere using `git init --bare`). 1. http://git-scm.com/book/en/Git-Basics-Working-with-Remotes 2. http://git-scm.com/book/en/Git-Branching-Remote-Branches 3. http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html -- 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.
[git-users] Two way mirroring because over network zones
Hi, We have an set up with two network zones. One is the secure zone (no internet access) and the other is the dev zone. Strangely development will happen in both zones, not just the dev zone. :) I use Gitolite to manage rights. Between the zones I have one opening: Ssh from one machine in the secure zone to one machine in the dev zone. So I want to establish both these machines as Git repo's that clients in each zone pulls and pushes from. And I was hoping changes would flow seamlessly between the two hosts in seaprate zons. How can I sync between them? I have looked into the clone --mirror option, but from what I can gather a remote update will actually overwrite changes done to that repo, so it would not work two way. I have managed to get a setup where I pull from both via a clone with added remotes, but this seems cumbersome and doesn't include all branches by default. Any suggestions? Cheers, Anders, -- 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.
[git-users] How i make to commit the changes of the clients(COMO EU FASSO PARA DAR COMMIT NAS ALTERAÇOES DOS CLIENTES EM MEU SERVIDOR)
PT-BR(COMO EU FASSO PARA DAR COMMIT NAS ALTERAÇOES DOS CLIENTES EM MEU SERVIDOR) ENG-(How i make to commit the changes of the clients) -- 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] Two way mirroring because over network zones
On Wed, 28 Aug 2013 08:46:25 -0700 (PDT) Anders Sveen anders.r.sv...@gmail.com wrote: We have an set up with two network zones. One is the secure zone (no internet access) and the other is the dev zone. Strangely development will happen in both zones, not just the dev zone. :) I use Gitolite to manage rights. Between the zones I have one opening: Ssh from one machine in the secure zone to one machine in the dev zone. So I want to establish both these machines as Git repo's that clients in each zone pulls and pushes from. And I was hoping changes would flow seamlessly between the two hosts in seaprate zons. How can I sync between them? I have looked into the clone --mirror option, but from what I can gather a remote update will actually overwrite changes done to that repo, so it would not work two way. I have managed to get a setup where I pull from both via a clone with added remotes, but this seems cumbersome and doesn't include all branches by default. I'm afraid the setup you intend to create cannot really be implemented in an automated fashion simply becase you're facing a case of multi-master replication with no way to automatically sort out arising conflicts. I mean, if someone updates a branch named master on the dev machine and someone else updates the same-named branch on the secured machine, you're facing a fork, and since branches in Git are light-weight (have only the single head and are in fact fully defined by it solely) you can't just have this fork maintained at a central rendez-vouz repo, and hence you ought to have a human (an integrator) to deal with it. So my proposition is to have double mirroring: each of the boundary machines should have full sets of bare repos -- one set of R/W repos is for its own network and another set of R/O repos are mirrors of the repos from the secured network; on the other box, the sets are reversed. Then provide no-brainer synchronization (either through gitolite's built-in mirroring support or via cron tasks etc) between matching sets of repos (say, each R/O repo mirror-fetches from its respective R/W repo). This way, each network would see an R/O view of another network. Each developer could fetch from the other network's repos but would only ever push to its own network's R/W repos. On the other hand, I fail to see what a setup that compilcated is called for. Is it possible to make a single machine available via SSH from both networks and hence have a single set of centralized repos? -- 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.
[git-users] how to apply multiple git patches in one shot
I am having around 100 patches like below,is there a way to apply all of them in one shot? 0001-*.patch,0002-*.patch,0003-*.patch -- 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.
[git-users] git subtree pull
I have a repository named bar. I added a sub repository using the following subtree command. git subtree add --squash -P foodir/ foo master I then pushed these changes to bar. A few days ago I made changes to the foo repository and I am now trying to pull them into the bar repository using the following command. git subtree pull --squash -P foodir/ foo master However, at the end I receive an error that says the following. Fatal: entry not found in tree (Some SHA number) Does anyone have a clue to what I am doing wrong? -- 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.
[git-users] Re: how to apply multiple git patches in one shot
On Wednesday, August 28, 2013 7:50:40 PM UTC+2, python.b...@gmail.com wrote: I am having around 100 patches like below,is there a way to apply all of them in one shot? 0001-*.patch,0002-*.patch,0003-*.patch Doesn't git apply do this? https://www.kernel.org/pub/software/scm/git/docs/git-apply.html $ cd repo $ git apply /path/to/patchfiles/*.patch Not sure what the order will be that they are applied, but just try it 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] Two way mirroring because over network zones
- Original Message - From: Philip Oakley philipoak...@iee.org To: git-users@googlegroups.com Cc: Anders Sveen anders.r.sv...@gmail.com; Konstantin Khomoutov flatw...@users.sourceforge.net Sent: Wednesday, August 28, 2013 10:38 PM Subject: Re: [git-users] Two way mirroring because over network zones That said, is the two sides won't talk you will get conflicts, so do expect the tool to do everything ;-) Oops, Should read: That said, if the two sides won't talk you will get conflicts, so don't expect the tool to do everything ;-) Do have a look at how git itself is developed with a layered approach to the synchronization problem; 'master' is never rewound, 'next' is occasionally rewound at choreographed points, 'pu' (potential updates) is often rewound, so folks have a good handle on levels of stability and where their patches have progressed to. Philip -- 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.
[git-users] Re: Strange problem on Mac OS X git 1.8.4
Oops. With further googling on this issue, it appears that the Linux source tree cannot be checked out to a non-case sensitive file system and be expected to compile/work properly: http://stackoverflow.com/questions/7383426/cloning-a-git-repo-and-it-already-has-a-dirty-working-directory-wha On Wednesday, August 28, 2013 3:41:36 PM UTC+8, TC Wan wrote: Thanks a lot for solving this mystery. Looks like the original repository needs cleaning up. So NO, the repository was fine, it is just not compatible with HFS+ default non-case sensitive configuration. There appears to be no workaround (the sparsecheckout workaround appears to just not checkout the problematic directories) that I have found. -- 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.
