* need help adjusting workflow to git (or vice versa) @ 2014-11-13 15:35 Stephen Berman 2014-11-13 15:49 ` Kelvin White 2014-11-13 16:29 ` martin rudalics 0 siblings, 2 replies; 19+ messages in thread From: Stephen Berman @ 2014-11-13 15:35 UTC (permalink / raw) To: emacs-devel I'm learning how to use git and am still stumbling over basic things. With bzr I had a shared repository of Emacs sources, containing several branches, including a mirror of trunk that I only updated, and a branch that I did my regular builds from, which I pulled from the trunk mirror but occasionally made small changes to, which went into my builds. I also had a task branch for longer term development, and occasionally copied or merged changes from there to the build branch. All of these branches had there own source files, which weren't touched by changes in the other branches (unless I merged or copied over changes). Now I've cloned the new git repository from Savannah and followed the instructions on the Emacs Wiki to make a task branch. But there is still only one set of sources. I do see the task branch and can check it out, but when I added my changes from the corresponding bzr task branch and then checked out master again, it shows the (still uncommitted) changes. I also made a build branch but when I check it out, it likewise shows the uncommitted changes from the task branch, so if I now do make, the changes from my task branch will AFAICT be included in the build, which I don't want. So how can I (i) keep a pristine copy of trunk (master) and (ii) build with possibly some local changes but without all changes from the task branch? Steve Berman ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 15:35 need help adjusting workflow to git (or vice versa) Stephen Berman @ 2014-11-13 15:49 ` Kelvin White 2014-11-13 19:50 ` Stephen Berman 2014-11-13 16:29 ` martin rudalics 1 sibling, 1 reply; 19+ messages in thread From: Kelvin White @ 2014-11-13 15:49 UTC (permalink / raw) To: Stephen Berman; +Cc: Emacs development discussions Stephen Berman <stephen.berman@gmx.net> wrote: > I'm learning how to use git and am still stumbling over basic things. > With bzr I had a shared repository of Emacs sources, containing several > branches, including a mirror of trunk that I only updated, and a branch > that I did my regular builds from, which I pulled from the trunk mirror > but occasionally made small changes to, which went into my builds. I > also had a task branch for longer term development, and occasionally > copied or merged changes from there to the build branch. All of these > branches had there own source files, which weren't touched by changes in > the other branches (unless I merged or copied over changes). Now I've > cloned the new git repository from Savannah and followed the > instructions on the Emacs Wiki to make a task branch. But there is > still only one set of sources. I do see the task branch and can check > it out, but when I added my changes from the corresponding bzr task > branch and then checked out master again, it shows the (still > uncommitted) changes. I also made a build branch but when I check it > out, it likewise shows the uncommitted changes from the task branch, so > if I now do make, the changes from my task branch will AFAICT be > included in the build, which I don't want. So how can I (i) keep a > pristine copy of trunk (master) and (ii) build with possibly some local > changes but without all changes from the task branch? The uncommitted changes will not be included unless you add them and commit them. If you want to keep your changes to apply later you can use git stash, or just commit them in the task branch before checking out other branches. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 15:49 ` Kelvin White @ 2014-11-13 19:50 ` Stephen Berman 2014-11-13 20:53 ` Kelvin White 0 siblings, 1 reply; 19+ messages in thread From: Stephen Berman @ 2014-11-13 19:50 UTC (permalink / raw) To: Kelvin White; +Cc: Emacs development discussions On Thu, 13 Nov 2014 10:49:05 -0500 Kelvin White <kwhite@gnu.org> wrote: > Stephen Berman <stephen.berman@gmx.net> wrote: >> I'm learning how to use git and am still stumbling over basic things. >> With bzr I had a shared repository of Emacs sources, containing several >> branches, including a mirror of trunk that I only updated, and a branch >> that I did my regular builds from, which I pulled from the trunk mirror >> but occasionally made small changes to, which went into my builds. I >> also had a task branch for longer term development, and occasionally >> copied or merged changes from there to the build branch. All of these >> branches had there own source files, which weren't touched by changes in >> the other branches (unless I merged or copied over changes). Now I've >> cloned the new git repository from Savannah and followed the >> instructions on the Emacs Wiki to make a task branch. But there is >> still only one set of sources. I do see the task branch and can check >> it out, but when I added my changes from the corresponding bzr task >> branch and then checked out master again, it shows the (still >> uncommitted) changes. I also made a build branch but when I check it >> out, it likewise shows the uncommitted changes from the task branch, so >> if I now do make, the changes from my task branch will AFAICT be >> included in the build, which I don't want. So how can I (i) keep a >> pristine copy of trunk (master) and (ii) build with possibly some local >> changes but without all changes from the task branch? > > The uncommitted changes will not be included unless you add them and > commit them. But they are included in the build (I confirmed this by building from my build branch, not from task branch (i.e., with my build branch currently checked out), and that's what I want to avoid. Steve Berman ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 19:50 ` Stephen Berman @ 2014-11-13 20:53 ` Kelvin White 0 siblings, 0 replies; 19+ messages in thread From: Kelvin White @ 2014-11-13 20:53 UTC (permalink / raw) To: Stephen Berman; +Cc: Emacs development discussions [-- Attachment #1: Type: text/plain, Size: 2165 bytes --] On Nov 13, 2014 2:51 PM, "Stephen Berman" <stephen.berman@gmx.net> wrote: > > On Thu, 13 Nov 2014 10:49:05 -0500 Kelvin White <kwhite@gnu.org> wrote: > > > Stephen Berman <stephen.berman@gmx.net> wrote: > >> I'm learning how to use git and am still stumbling over basic things. > >> With bzr I had a shared repository of Emacs sources, containing several > >> branches, including a mirror of trunk that I only updated, and a branch > >> that I did my regular builds from, which I pulled from the trunk mirror > >> but occasionally made small changes to, which went into my builds. I > >> also had a task branch for longer term development, and occasionally > >> copied or merged changes from there to the build branch. All of these > >> branches had there own source files, which weren't touched by changes in > >> the other branches (unless I merged or copied over changes). Now I've > >> cloned the new git repository from Savannah and followed the > >> instructions on the Emacs Wiki to make a task branch. But there is > >> still only one set of sources. I do see the task branch and can check > >> it out, but when I added my changes from the corresponding bzr task > >> branch and then checked out master again, it shows the (still > >> uncommitted) changes. I also made a build branch but when I check it > >> out, it likewise shows the uncommitted changes from the task branch, so > >> if I now do make, the changes from my task branch will AFAICT be > >> included in the build, which I don't want. So how can I (i) keep a > >> pristine copy of trunk (master) and (ii) build with possibly some local > >> changes but without all changes from the task branch? > > > > The uncommitted changes will not be included unless you add them and > > commit them. > > But they are included in the build (I confirmed this by building from my > build branch, not from task branch (i.e., with my build branch currently > checked out), and that's what I want to avoid. Before checking out your build branch, either commit your changes, or stash them. This will keep the changes in the build branch and not carry them over into whatever branch you check out first. [-- Attachment #2: Type: text/html, Size: 2771 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 15:35 need help adjusting workflow to git (or vice versa) Stephen Berman 2014-11-13 15:49 ` Kelvin White @ 2014-11-13 16:29 ` martin rudalics 2014-11-13 16:43 ` Andreas Schwab 1 sibling, 1 reply; 19+ messages in thread From: martin rudalics @ 2014-11-13 16:29 UTC (permalink / raw) To: Stephen Berman, emacs-devel > So how can I (i) keep a > pristine copy of trunk (master) and (ii) build with possibly some local > changes but without all changes from the task branch? From what I understand from here http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00790.html and subsequent comments you have to make a spearate clone. martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 16:29 ` martin rudalics @ 2014-11-13 16:43 ` Andreas Schwab 2014-11-13 19:51 ` Stephen Berman 0 siblings, 1 reply; 19+ messages in thread From: Andreas Schwab @ 2014-11-13 16:43 UTC (permalink / raw) To: martin rudalics; +Cc: Stephen Berman, emacs-devel martin rudalics <rudalics@gmx.at> writes: >> So how can I (i) keep a >> pristine copy of trunk (master) and (ii) build with possibly some local >> changes but without all changes from the task branch? > > From what I understand from here > > http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00790.html > > and subsequent comments you have to make a spearate clone. You can also use git new-workdir (not yet part of the git core, a proper replacement is being worked on). Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 16:43 ` Andreas Schwab @ 2014-11-13 19:51 ` Stephen Berman 2014-11-13 20:10 ` Paul Eggert ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Stephen Berman @ 2014-11-13 19:51 UTC (permalink / raw) To: Andreas Schwab; +Cc: martin rudalics, emacs-devel On Thu, 13 Nov 2014 17:43:27 +0100 Andreas Schwab <schwab@suse.de> wrote: > martin rudalics <rudalics@gmx.at> writes: > >>> So how can I (i) keep a >>> pristine copy of trunk (master) and (ii) build with possibly some local >>> changes but without all changes from the task branch? >> >> From what I understand from here >> >> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00790.html >> >> and subsequent comments you have to make a spearate clone. > > You can also use git new-workdir (not yet part of the git core, a proper > replacement is being worked on). I would be very surprised if either of these approaches is used by most developers using git, because if so, I'd have expected them to be part of the standard toolkit and well documented. So I think my workflow is suboptimal for git. What do people who have several branches of a single project repository and want to build from one of them without including changes from another in the build usually do? Isn't that a common scenario, especially for Emacs developers? What do you people do? Steve Berman ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 19:51 ` Stephen Berman @ 2014-11-13 20:10 ` Paul Eggert 2014-11-13 20:44 ` Stephen Berman 2014-11-14 5:18 ` Rob Browning 2014-11-15 5:08 ` Bill Wohler 2 siblings, 1 reply; 19+ messages in thread From: Paul Eggert @ 2014-11-13 20:10 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel On 11/13/2014 11:51 AM, Stephen Berman wrote: > I would be very surprised if either of these approaches is used by most > developers using git, because if so, I'd have expected them to be part > of the standard toolkit and well documented. "git clone" is part of the standard Git toolkit, and is well documented. It's what I use for your scenario, if I understand the scenario correctly. And "git clone" should be fast enough; for Emacs it takes 1.3 seconds on my 3-year-old desktop's hard disk. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 20:10 ` Paul Eggert @ 2014-11-13 20:44 ` Stephen Berman 2014-11-13 20:58 ` Paul Eggert ` (3 more replies) 0 siblings, 4 replies; 19+ messages in thread From: Stephen Berman @ 2014-11-13 20:44 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel On Thu, 13 Nov 2014 12:10:45 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: > On 11/13/2014 11:51 AM, Stephen Berman wrote: >> I would be very surprised if either of these approaches is used by most >> developers using git, because if so, I'd have expected them to be part >> of the standard toolkit and well documented. > > "git clone" is part of the standard Git toolkit, and is well documented. It's > what I use for your scenario, if I understand the scenario correctly. And > "git clone" should be fast enough; for Emacs it takes 1.3 seconds on my > 3-year-old desktop's hard disk. That's what Martin referred to, isn't it? It takes considerably longer on my older and feebler hardware, also compared with `bzr update' and `bzr pull --overwrite' in a shared repository. And the size is also not insignificant, if it means having a copy of the entire Emacs repository for each build (~540M). Is that really the standard procedure? If so, I guess I'll get used to it, but it does surprise me. Steve Berman ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 20:44 ` Stephen Berman @ 2014-11-13 20:58 ` Paul Eggert 2014-11-13 21:19 ` Stephen Berman 2014-11-13 20:58 ` Harald Hanche-Olsen ` (2 subsequent siblings) 3 siblings, 1 reply; 19+ messages in thread From: Paul Eggert @ 2014-11-13 20:58 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel On 11/13/2014 12:44 PM, Stephen Berman wrote: > That's what Martin referred to, isn't it? It takes considerably longer > on my older and feebler hardware, also compared with `bzr update' and > `bzr pull --overwrite' in a shared repository. By "shared repository" do you mean you have just one copy of the working files? I thought you had multiple copies, one for each branch. That's what I do, as it helps 'make' go faster. > And the size is also not insignificant, if it means having a copy of > the entire Emacs repository for each build (~540M). No, the repository is shared: $ time git clone master tmp Cloning into 'tmp'... done. real 0m1.314s user 0m0.997s sys 0m0.280s $ du -s master/.git tmp/.git 205500 master/.git 768 tmp/.git ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 20:58 ` Paul Eggert @ 2014-11-13 21:19 ` Stephen Berman 0 siblings, 0 replies; 19+ messages in thread From: Stephen Berman @ 2014-11-13 21:19 UTC (permalink / raw) To: Paul Eggert; +Cc: Kelvin White, Harald Hanche-Olsen, emacs-devel On Thu, 13 Nov 2014 12:58:24 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: > On 11/13/2014 12:44 PM, Stephen Berman wrote: >> That's what Martin referred to, isn't it? It takes considerably longer on my >> older and feebler hardware, also compared with `bzr update' and `bzr pull >> --overwrite' in a shared repository. > > By "shared repository" do you mean you have just one copy of the working > files? I thought you had multiple copies, one for each branch. That's what I > do, as it helps 'make' go faster. I also have copies of the working files for each bzr branch, but just one copy of the history; but it appears I had a wrong idea of what cloning does... >> And the size is also not insignificant, if it means having a copy of the >> entire Emacs repository for each build (~540M). > > No, the repository is shared: > > $ time git clone master tmp > Cloning into 'tmp'... > done. > > real 0m1.314s > user 0m0.997s > sys 0m0.280s > $ du -s master/.git tmp/.git > 205500 master/.git > 768 tmp/.git Ok, this is not what I had thought, but I'm glad I was mistaken. On Thu, 13 Nov 2014 21:58:27 +0100 (CET) Harald Hanche-Olsen <hanche@math.ntnu.no> wrote: > [Stephen Berman <stephen.berman@gmx.net> (2014-11-13 20:44:22 UTC)] > >> That's what Martin referred to, isn't it? It takes considerably longer >> on my older and feebler hardware, also compared with `bzr update' and >> `bzr pull --overwrite' in a shared repository. And the size is also not >> insignificant, if it means having a copy of the entire Emacs repository >> for each build (~540M). > > You might have a look at the options --local and --shallow to git > clone. The idea would be to have one full clone that pulls from > savannah, then any number of local clones pulling from from that one. > > After running git clone --local emacs emacs2 > I get this: > > ; du -sh emacs/.git emacs2/.git > 199M emacs/.git > 392K emacs2/.git > > The clone operation was pretty fast, too. 7 seconds on an SSD. Thanks, that's information I was missing, and seems to be just what I want. On Thu, 13 Nov 2014 15:53:24 -0500 Kelvin White <kwhite@gnu.org> wrote: > On Nov 13, 2014 2:51 PM, "Stephen Berman" <stephen.berman@gmx.net> wrote: >> >> On Thu, 13 Nov 2014 10:49:05 -0500 Kelvin White <kwhite@gnu.org> wrote: >> [...] >> > >> > The uncommitted changes will not be included unless you add them and >> > commit them. >> >> But they are included in the build (I confirmed this by building from my >> build branch, not from task branch (i.e., with my build branch currently >> checked out), and that's what I want to avoid. > > Before checking out your build branch, either commit your changes, or stash > them. This will keep the changes in the build branch and not carry them over > into whatever branch you check out first. Thanks, I didn't know about stashing either, and it seems to be close to what I wanted. Thanks to all of you for the feedback, it's been edifying. Steve Berman ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 20:44 ` Stephen Berman 2014-11-13 20:58 ` Paul Eggert @ 2014-11-13 20:58 ` Harald Hanche-Olsen 2014-11-13 21:22 ` Stefan Monnier 2014-11-14 5:26 ` Eli Zaretskii 3 siblings, 0 replies; 19+ messages in thread From: Harald Hanche-Olsen @ 2014-11-13 20:58 UTC (permalink / raw) To: stephen.berman; +Cc: eggert, emacs-devel [Stephen Berman <stephen.berman@gmx.net> (2014-11-13 20:44:22 UTC)] > That's what Martin referred to, isn't it? It takes considerably longer > on my older and feebler hardware, also compared with `bzr update' and > `bzr pull --overwrite' in a shared repository. And the size is also not > insignificant, if it means having a copy of the entire Emacs repository > for each build (~540M). You might have a look at the options --local and --shallow to git clone. The idea would be to have one full clone that pulls from savannah, then any number of local clones pulling from from that one. After running git clone --local emacs emacs2 I get this: ; du -sh emacs/.git emacs2/.git 199M emacs/.git 392K emacs2/.git The clone operation was pretty fast, too. 7 seconds on an SSD. – Harald ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 20:44 ` Stephen Berman 2014-11-13 20:58 ` Paul Eggert 2014-11-13 20:58 ` Harald Hanche-Olsen @ 2014-11-13 21:22 ` Stefan Monnier 2014-11-14 5:26 ` Eli Zaretskii 3 siblings, 0 replies; 19+ messages in thread From: Stefan Monnier @ 2014-11-13 21:22 UTC (permalink / raw) To: Stephen Berman; +Cc: Paul Eggert, emacs-devel > for each build (~540M). Is that really the standard procedure? If so, > I guess I'll get used to it, but it does surprise me. I also find it surprising. While Git is pretty fast and uses network resources efficiently (i.e. there's obviously been a fair bit of effort put into making it use resources efficiently), it doesn't seem to try and optimize resource usage in this case: the duplication of repositories is a problem for disk usage, RAM usage, and network usage (unless you're careful to only fetch from the remote repository into one particular local repository and then to propagate those changes locally between your local repositories, but I don't see any tool that would help you do that). Personally I use git-new-workdir, which lets me set things up in the same way I had them with lightweight checkouts, with a single shared repository. You just have to be careful not to have 2 workdirs checkout the same branch. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 20:44 ` Stephen Berman ` (2 preceding siblings ...) 2014-11-13 21:22 ` Stefan Monnier @ 2014-11-14 5:26 ` Eli Zaretskii 2014-11-15 22:24 ` Stephen Berman 3 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2014-11-14 5:26 UTC (permalink / raw) To: Stephen Berman; +Cc: eggert, emacs-devel > From: Stephen Berman <stephen.berman@gmx.net> > Date: Thu, 13 Nov 2014 21:44:22 +0100 > Cc: emacs-devel@gnu.org > > On Thu, 13 Nov 2014 12:10:45 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: > > > On 11/13/2014 11:51 AM, Stephen Berman wrote: > >> I would be very surprised if either of these approaches is used by most > >> developers using git, because if so, I'd have expected them to be part > >> of the standard toolkit and well documented. > > > > "git clone" is part of the standard Git toolkit, and is well documented. It's > > what I use for your scenario, if I understand the scenario correctly. And > > "git clone" should be fast enough; for Emacs it takes 1.3 seconds on my > > 3-year-old desktop's hard disk. > > That's what Martin referred to, isn't it? Yes. > It takes considerably longer on my older and feebler hardware, also > compared with `bzr update' and `bzr pull --overwrite' in a shared > repository. Did you "git clone" from your local repo or from the remote savannah address? The former should be very fast. > And the size is also not insignificant, if it means having a copy of > the entire Emacs repository for each build (~540M). I think if you clone locally, git uses hard links for the meta-data (or maybe it's an optional behavior that you need to activate with some switch, see the documentation). > Is that really the standard procedure? If so, I guess I'll get used > to it, but it does surprise me. Every VCS has its downsides. Bzr had only separate branches (co-located branches were initially implemented in the last version); git has only co-located branches. You need to work around that. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-14 5:26 ` Eli Zaretskii @ 2014-11-15 22:24 ` Stephen Berman 2014-11-16 18:57 ` Bill Wohler 0 siblings, 1 reply; 19+ messages in thread From: Stephen Berman @ 2014-11-15 22:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel On Fri, 14 Nov 2014 07:26:19 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Date: Thu, 13 Nov 2014 21:44:22 +0100 >> Cc: emacs-devel@gnu.org >> >> On Thu, 13 Nov 2014 12:10:45 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: >> >> > On 11/13/2014 11:51 AM, Stephen Berman wrote: >> >> I would be very surprised if either of these approaches is used by most >> >> developers using git, because if so, I'd have expected them to be part >> >> of the standard toolkit and well documented. >> > >> > "git clone" is part of the standard Git toolkit, and is well documented. It's >> > what I use for your scenario, if I understand the scenario correctly. And >> > "git clone" should be fast enough; for Emacs it takes 1.3 seconds on my >> > 3-year-old desktop's hard disk. >> >> That's what Martin referred to, isn't it? > > Yes. > >> It takes considerably longer on my older and feebler hardware, also >> compared with `bzr update' and `bzr pull --overwrite' in a shared >> repository. > > Did you "git clone" from your local repo or from the remote savannah > address? The former should be very fast. I actually didn't realize there was a difference, I assumed cloning grabs the remote source, which in my case takes much longer than 1.3 seconds. >> And the size is also not insignificant, if it means having a copy of >> the entire Emacs repository for each build (~540M). > > I think if you clone locally, git uses hard links for the meta-data > (or maybe it's an optional behavior that you need to activate with > some switch, see the documentation). > >> Is that really the standard procedure? If so, I guess I'll get used >> to it, but it does surprise me. > > Every VCS has its downsides. Bzr had only separate branches > (co-located branches were initially implemented in the last version); > git has only co-located branches. You need to work around that. Yes, there's lots to learn and get used to. Steve Berman ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-15 22:24 ` Stephen Berman @ 2014-11-16 18:57 ` Bill Wohler 0 siblings, 0 replies; 19+ messages in thread From: Bill Wohler @ 2014-11-16 18:57 UTC (permalink / raw) To: emacs-devel Stephen Berman <stephen.berman@gmx.net> writes: > On Fri, 14 Nov 2014 07:26:19 +0200 Eli Zaretskii <eliz@gnu.org> wrote: > >> Every VCS has its downsides. Bzr had only separate branches >> (co-located branches were initially implemented in the last version); >> git has only co-located branches. You need to work around that. > > Yes, there's lots to learn and get used to. I'd suggest reading Conversational Git [1] for a gentle introduction and Pro Git [2] for a deeper dive (especially the chapter on branching). 1. http://blog.anvard.org/conversational-git/ 2. http://git-scm.com/book/en/v2 -- Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov> http://www.newt.com/wohler/ GnuPG ID:610BD9AD ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 19:51 ` Stephen Berman 2014-11-13 20:10 ` Paul Eggert @ 2014-11-14 5:18 ` Rob Browning 2014-11-18 9:34 ` Eric S Fraga 2014-11-15 5:08 ` Bill Wohler 2 siblings, 1 reply; 19+ messages in thread From: Rob Browning @ 2014-11-14 5:18 UTC (permalink / raw) To: Stephen Berman, Andreas Schwab; +Cc: martin rudalics, emacs-devel Stephen Berman <stephen.berman@gmx.net> writes: > I would be very surprised if either of these approaches is used by most > developers using git, because if so, I'd have expected them to be part > of the standard toolkit and well documented. So I think my workflow is > suboptimal for git. What do people who have several branches of a > single project repository and want to build from one of them without > including changes from another in the build usually do? Isn't that a > common scenario, especially for Emacs developers? What do you people do? I don't know if this will help, but personally -- with git, in most cases I only have one (or very few) clones, and I just switch branches (a *lot*). For example, if I were on say tmp/fix-foo, and I wanted to switch to work on master, but I still had local changes that I wanted to come back to later, I'd probably either use stash, or a trivial commit. For example (via stash): $ git stash 'stuff I want to deal with later' $ git checkout master ... do whatever... $ git checkout tmp/fix-foo $ git stash pop And now I'm exactly where I was (plus or minus any build detritus that differs between the two branches.). Though often it's more convenient to use an actual dummy commit since git's stash is somewhat "one dimensional". Here's the same thing via a temporary commit: $ git commit -am 'stuff I want to deal with later' $ git checkout master ... do whatever... $ git checkout tmp/fix-foo $ git reset HEAD^ # "Undoes" the top commit, putting the changes back on disk. And I'm again back where I was. Some caveats: * If you have any new files, you'll need to "git add ..." them before the "commit -am" or stash above, otherwise they'll be left out (and also be left alone in the current working directory). * If the build process isn't really solid (and even if it is), it may sometimes be helpful to run a "make clean" before you switch branches. Alternately, you can use this command if you want to *completely* clean your tree -- likely more thoroughly, and possibly more quickly than via make: $ git clean -fdx But that deletes *everything* git doesn't know about, including ignored files, so be sure that's what you want. You can see what it's going to do beforehand with the "-n" (--dry-run) option. Note too that no working directory (copy) is more special than any other, so if you have the disk space, you can always "cp -a" or rsync your working dir before you do something you're uncertain about, and move it back if things go horribly wrong (no one need ever know...unless it's a push). (Technically, if your working directory is clean, all you need is the .git subdir, but it's less complicated to save/restore the whole tree -- otherwise you may need a "get reset --hard HEAD" or similar afterward.) Some other comments that might or might not be useful... For what it's worth, I almost always work on a temporary branch. It's trivial to migrate the changes back to master (or wherever), via merge, rebase, or cherry-pick, once I decide I'm ready to push. I find gitk (--all) to be tremendously helpful as a tool to see what's going on, and to see whether or not I did what I think I did, especially when stumbling around unfamiliar bits of git. Or, if you can't (or don't want to) fire up a GUI, this may be useful: $ git log --decorate --oneline --graph And as compared to "git status", if you want briefer status output, perhaps $ git status -s $ git status -s -uno Another item in the category of "knowing what's going on" -- the fancy git prompt component that Debian (at least) provides by default, i.e.: GIT_SHOW_DIRTYSTATE=true GIT_SHOW_STASHSTATE=true PS1='...$(__git_ps1)...' Finally, I'd definitely recommend eventually learning "git rebase --interactive ..." *for local use*. I find it extremely useful. (Note: I didn't talk about magit because I'm not using it heavily yet, but it's probably useful to understand some of the command line operations regardless.) Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-14 5:18 ` Rob Browning @ 2014-11-18 9:34 ` Eric S Fraga 0 siblings, 0 replies; 19+ messages in thread From: Eric S Fraga @ 2014-11-18 9:34 UTC (permalink / raw) To: emacs-devel Rob, thanks for a very useful yet concise tutorial on using branches with git. -- : Eric S Fraga, GnuPG: 0xFFFCF67D : in Emacs 24.4.1 + Ma Gnus v0.12 + evil-git-1a8f9bd : BBDB version 3.0.50 (2013-11-16 11:30:49 -0600) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: need help adjusting workflow to git (or vice versa) 2014-11-13 19:51 ` Stephen Berman 2014-11-13 20:10 ` Paul Eggert 2014-11-14 5:18 ` Rob Browning @ 2014-11-15 5:08 ` Bill Wohler 2 siblings, 0 replies; 19+ messages in thread From: Bill Wohler @ 2014-11-15 5:08 UTC (permalink / raw) To: emacs-devel Stephen Berman <stephen.berman@gmx.net> writes: > On Thu, 13 Nov 2014 17:43:27 +0100 Andreas Schwab <schwab@suse.de> wrote: > >> martin rudalics <rudalics@gmx.at> writes: >> >>>> So how can I (i) keep a >>>> pristine copy of trunk (master) and (ii) build with possibly some local >>>> changes but without all changes from the task branch? >>> >>> From what I understand from here >>> >>> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00790.html >>> >>> and subsequent comments you have to make a spearate clone. >> >> You can also use git new-workdir (not yet part of the git core, a proper >> replacement is being worked on). > > I would be very surprised if either of these approaches is used by most > developers using git, because if so, I'd have expected them to be part > of the standard toolkit and well documented. So I think my workflow is > suboptimal for git. What do people who have several branches of a > single project repository and want to build from one of them without > including changes from another in the build usually do? Isn't that a > common scenario, especially for Emacs developers? What do you people do? I usually just "git co <other-branch>" since it's very fast. If I have outstanding changes, I either first check them into a temporary branch (cheap), or use git stash. If I need to have the two versions visible at the same time, I'll either clone the repository in another directory as suggested, or simply copy my git directory to another. Note that either of these are a great idea when experimenting with new git functionality. If you mess up, just delete the copy/clone. -- Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov> http://www.newt.com/wohler/ GnuPG ID:610BD9AD ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2014-11-18 9:34 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-13 15:35 need help adjusting workflow to git (or vice versa) Stephen Berman 2014-11-13 15:49 ` Kelvin White 2014-11-13 19:50 ` Stephen Berman 2014-11-13 20:53 ` Kelvin White 2014-11-13 16:29 ` martin rudalics 2014-11-13 16:43 ` Andreas Schwab 2014-11-13 19:51 ` Stephen Berman 2014-11-13 20:10 ` Paul Eggert 2014-11-13 20:44 ` Stephen Berman 2014-11-13 20:58 ` Paul Eggert 2014-11-13 21:19 ` Stephen Berman 2014-11-13 20:58 ` Harald Hanche-Olsen 2014-11-13 21:22 ` Stefan Monnier 2014-11-14 5:26 ` Eli Zaretskii 2014-11-15 22:24 ` Stephen Berman 2014-11-16 18:57 ` Bill Wohler 2014-11-14 5:18 ` Rob Browning 2014-11-18 9:34 ` Eric S Fraga 2014-11-15 5:08 ` Bill Wohler
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).