need help adjusting workflow to git (or vice versa)

need help adjusting workflow to git (or vice versa)

[Stephen Berman]

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

Re: need help adjusting workflow to git (or vice versa)

[Kelvin White]

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.

Re: need help adjusting workflow to git (or vice versa)

[martin rudalics]

 > 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

Re: need help adjusting workflow to git (or vice versa)

[Andreas Schwab]

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."

Re: need help adjusting workflow to git (or vice versa)

[Stephen Berman]

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

Re: need help adjusting workflow to git (or vice versa)

[Stephen Berman]

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

Re: need help adjusting workflow to git (or vice versa)

[Paul Eggert]

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.

Re: need help adjusting workflow to git (or vice versa)

[Stephen Berman]

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

Re: need help adjusting workflow to git (or vice versa)

[Kelvin White]

[-- 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 --]

Re: need help adjusting workflow to git (or vice versa)

[Paul Eggert]

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

Re: need help adjusting workflow to git (or vice versa)

[Harald Hanche-Olsen]

[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

Re: need help adjusting workflow to git (or vice versa)

[Stephen Berman]

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

Re: need help adjusting workflow to git (or vice versa)

[Stefan Monnier]

> 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

Re: need help adjusting workflow to git (or vice versa)

[Rob Browning]

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

Re: need help adjusting workflow to git (or vice versa)

[Eli Zaretskii]

> 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.

Re: need help adjusting workflow to git (or vice versa)

[Bill Wohler]

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

Re: need help adjusting workflow to git (or vice versa)

[Stephen Berman]

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

Re: need help adjusting workflow to git (or vice versa)

[Bill Wohler]

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

Re: need help adjusting workflow to git (or vice versa)

[Eric S Fraga]

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)