Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #77915 > unrolled thread

[OT] Question about Git branches

Back to article view | Back to comp.lang.python

Contents

  [OT] Question about Git branches "Frank Millman" <frank@chagford.com> - 2014-09-16 08:22 +0200
    Re: [OT] Question about Git branches Marko Rauhamaa <marko@pacujo.net> - 2014-09-16 11:21 +0300
      Re: [OT] Question about Git branches Chris Angelico <rosuav@gmail.com> - 2014-09-16 18:29 +1000
        Re: [OT] Question about Git branches Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-09-16 22:14 +1000
          Re: [OT] Question about Git branches Chris Angelico <rosuav@gmail.com> - 2014-09-16 22:48 +1000
          Re: [OT] Question about Git branches Tim Delaney <timothy.c.delaney@gmail.com> - 2014-09-16 22:50 +1000
          Re: [OT] Question about Git branches Robert Kern <robert.kern@gmail.com> - 2014-09-16 17:08 +0100
          Re: [OT] Question about Git branches Chris Angelico <rosuav@gmail.com> - 2014-09-17 02:25 +1000
          Re: [OT] Question about Git branches Robert Kern <robert.kern@gmail.com> - 2014-09-16 20:11 +0100
          Re: [OT] Question about Git branches Tim Delaney <timothy.c.delaney@gmail.com> - 2014-09-17 11:47 +1000
      Re: [OT] Question about Git branches "Frank Millman" <frank@chagford.com> - 2014-09-16 10:59 +0200
        Re: [OT] Question about Git branches Sergey Organov <sorganov@gmail.com> - 2014-09-17 14:16 +0400
      Re: [OT] Question about Git branches Jason Swails <jason.swails@gmail.com> - 2014-09-16 09:19 -0400
        Re: [OT] Question about Git branches Marko Rauhamaa <marko@pacujo.net> - 2014-09-17 02:26 +0300
    Re: [OT] Question about Git branches Sergey Organov <sorganov@gmail.com> - 2014-09-17 16:04 +0400
      Re: [OT] Question about Git branches "Frank Millman" <frank@chagford.com> - 2014-09-17 17:52 +0200
      Re: [OT] Question about Git branches Chris Angelico <rosuav@gmail.com> - 2014-09-18 02:00 +1000

#77915 — [OT] Question about Git branches

Hi all

I know there some Git experts on this list, so I hope you don't mind me 
posting this question here.

I am slowly getting comfortable with Git, but there is something that 
confuses me.

You are encouraged to make liberal use of 'branches', and if required you 
can have multiple branches running concurrently. When you commit changes on 
one branch, those changes are not visible to other branches until you merge, 
so each branch can be worked on independently.

However, if you are working on a branch and make some changes, those changes 
are visible to *all* branches until you commit. If you run 'git status' from 
any branch, you can see all files that have been modified or added.

It seems to me that this can be confusing. When you are ready to commit 
changes on one branch, you have to -
  - check that it is the currently checked-out branch, which is not always 
obvious
  - choose which altered files you want to add to the staging area
  - stage them and then commit

This seems error-prone. Am I missing something?

Frank Millman

[toc] | [next] | [standalone]

#77920

"Frank Millman" <frank@chagford.com>:

> You are encouraged to make liberal use of 'branches',

Personally, I only use forks, IOW, "git clone". I encourage that
practice. Then, there is little need for "git checkout". Instead, I just
cd to a different directory.

Branches and clones are highly analogous processwise; I would go so far
as to say that they are redundant.


Marko

[toc] | [prev] | [next] | [standalone]

#77921

On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> "Frank Millman" <frank@chagford.com>:
>
>> You are encouraged to make liberal use of 'branches',
>
> Personally, I only use forks, IOW, "git clone". I encourage that
> practice. Then, there is little need for "git checkout". Instead, I just
> cd to a different directory.
>
> Branches and clones are highly analogous processwise; I would go so far
> as to say that they are redundant.

But rather than listening to, shall we say, *strange* advice like
this, Frank, you'll do well to pick up a reliable git tutorial, which
should explain branches, commits, the working tree, etc, etc, etc.

ChrisA

[toc] | [prev] | [next] | [standalone]

#77929

Chris Angelico wrote:

> On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> "Frank Millman" <frank@chagford.com>:
>>
>>> You are encouraged to make liberal use of 'branches',
>>
>> Personally, I only use forks, IOW, "git clone". I encourage that
>> practice. Then, there is little need for "git checkout". Instead, I just
>> cd to a different directory.
>>
>> Branches and clones are highly analogous processwise; I would go so far
>> as to say that they are redundant.
> 
> But rather than listening to, shall we say, *strange* advice like
> this, Frank, you'll do well to pick up a reliable git tutorial, which
> should explain branches, commits, the working tree, etc, etc, etc.

Isn't this "strange advice" standard operating procedure in Mercurial? I'm
not an expert on either hg or git, but if I've understood hg correctly, the
way to begin an experimental branch is to use hg clone.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#77932

On Tue, Sep 16, 2014 at 10:14 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Chris Angelico wrote:
>
>> On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> "Frank Millman" <frank@chagford.com>:
>>>
>>>> You are encouraged to make liberal use of 'branches',
>>>
>>> Personally, I only use forks, IOW, "git clone". I encourage that
>>> practice. Then, there is little need for "git checkout". Instead, I just
>>> cd to a different directory.
>>>
>>> Branches and clones are highly analogous processwise; I would go so far
>>> as to say that they are redundant.
>>
>> But rather than listening to, shall we say, *strange* advice like
>> this, Frank, you'll do well to pick up a reliable git tutorial, which
>> should explain branches, commits, the working tree, etc, etc, etc.
>
> Isn't this "strange advice" standard operating procedure in Mercurial? I'm
> not an expert on either hg or git, but if I've understood hg correctly, the
> way to begin an experimental branch is to use hg clone.

I don't know Mercurial well enough to be able to say, but definitely
branching is a very normal thing there, too. And since merging can be
done only within a single repo, ultimately you need to end up with
branches in one repo (rather than separate repos) if you're going to
combine them in any way. So even if you do start some experimental
work in a separate clone, you're probably going to need to end up with
it as a separate branch in the same repo if you ever publish it, for
instance.

ChrisA

[toc] | [prev] | [next] | [standalone]

#77933

[Multipart message — attachments visible in raw view] — view raw

On 16 September 2014 22:14, Steven D'Aprano <
steve+comp.lang.python@pearwood.info> wrote:

> Chris Angelico wrote:
>
> > On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <marko@pacujo.net>
> wrote:
> >> "Frank Millman" <frank@chagford.com>:
> >>
> >>> You are encouraged to make liberal use of 'branches',
> >>
> >> Personally, I only use forks, IOW, "git clone". I encourage that
> >> practice. Then, there is little need for "git checkout". Instead, I just
> >> cd to a different directory.
> >>
> >> Branches and clones are highly analogous processwise; I would go so far
> >> as to say that they are redundant.
> >
> > But rather than listening to, shall we say, *strange* advice like
> > this, Frank, you'll do well to pick up a reliable git tutorial, which
> > should explain branches, commits, the working tree, etc, etc, etc.
>
> Isn't this "strange advice" standard operating procedure in Mercurial? I'm
> not an expert on either hg or git, but if I've understood hg correctly, the
> way to begin an experimental branch is to use hg clone.


It depends entirely on how you're comfortable working. I tend to have a
clone per feature branch (they all push to the same central repo) and then
create a named branch per task (which may be a prototype, bugfix,
enhancement, whatever).

Makes it very easy to switch between tasks - I just update to a different
changeset (normally the tip of a named branch) and force a refresh in my
IDE. When I'm happy, I merge into the feature branch, then pull the
necessary changesets into other feature branch repos to merge/graft as
appropriate.

Branches and clones are two different ways of organising, and I find that
things work best for me when I use both.

Tim Delaney

[toc] | [prev] | [next] | [standalone]

#77938

On 2014-09-16 13:14, Steven D'Aprano wrote:
> Chris Angelico wrote:
>
>> On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> "Frank Millman" <frank@chagford.com>:
>>>
>>>> You are encouraged to make liberal use of 'branches',
>>>
>>> Personally, I only use forks, IOW, "git clone". I encourage that
>>> practice. Then, there is little need for "git checkout". Instead, I just
>>> cd to a different directory.
>>>
>>> Branches and clones are highly analogous processwise; I would go so far
>>> as to say that they are redundant.
>>
>> But rather than listening to, shall we say, *strange* advice like
>> this, Frank, you'll do well to pick up a reliable git tutorial, which
>> should explain branches, commits, the working tree, etc, etc, etc.
>
> Isn't this "strange advice" standard operating procedure in Mercurial? I'm
> not an expert on either hg or git, but if I've understood hg correctly, the
> way to begin an experimental branch is to use hg clone.

Yes, but this is due to different design decisions of git and Mercurial. git 
prioritized the multiple branches in a single clone use case; Mercurial 
prioritized re-cloning. It's natural to do this kind of branching in git, and 
more natural to re-clone in Mercurial.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#77939

On Wed, Sep 17, 2014 at 2:08 AM, Robert Kern <robert.kern@gmail.com> wrote:
> Yes, but this is due to different design decisions of git and Mercurial. git
> prioritized the multiple branches in a single clone use case; Mercurial
> prioritized re-cloning. It's natural to do this kind of branching in git,
> and more natural to re-clone in Mercurial.

Ah, I wasn't aware of that philosophical difference. Does hg use
hardlinks or something to minimize disk usage when you clone, or does
it actually copy everything? (Or worse, does it make the new directory
actually depend on the old one?)

ChrisA

[toc] | [prev] | [next] | [standalone]

#77943

On 2014-09-16 17:25, Chris Angelico wrote:
> On Wed, Sep 17, 2014 at 2:08 AM, Robert Kern <robert.kern@gmail.com> wrote:
>> Yes, but this is due to different design decisions of git and Mercurial. git
>> prioritized the multiple branches in a single clone use case; Mercurial
>> prioritized re-cloning. It's natural to do this kind of branching in git,
>> and more natural to re-clone in Mercurial.
>
> Ah, I wasn't aware of that philosophical difference. Does hg use
> hardlinks or something to minimize disk usage when you clone, or does
> it actually copy everything? (Or worse, does it make the new directory
> actually depend on the old one?)

I haven't kept up with the internals recently, but at least at one point, 
hardlinks were the order of the day, yes.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#77950

[Multipart message — attachments visible in raw view] — view raw

On 17 September 2014 02:25, Chris Angelico <rosuav@gmail.com> wrote:

> On Wed, Sep 17, 2014 at 2:08 AM, Robert Kern <robert.kern@gmail.com>
> wrote:
> > Yes, but this is due to different design decisions of git and Mercurial.
> git
> > prioritized the multiple branches in a single clone use case; Mercurial
> > prioritized re-cloning. It's natural to do this kind of branching in git,
> > and more natural to re-clone in Mercurial.
>

I disagree that it's more natural to re-clone in Mercurial. It's just that
the preferred workflow of the Mercurial developers is to use clones,
anonymous branches and bookmarks (almost the same as git branches) rather
than named branches - and so that is the workflow that is most associated
with using Mercurial.

Mercurial fully supports multiple lines of development by:

1. cloning;

2. anonymous branching (i.e. multiple heads on the same branch) - normally
combined with bookmarks;

3. named branching (the branch name is an integral part of the commit);

4. all of the above combined.

Eventually if you want to merge between lines of development then you end
up with multiple branches (either anonymous or named) in the one repo.


> Ah, I wasn't aware of that philosophical difference. Does hg use
> hardlinks or something to minimize disk usage when you clone, or does
> it actually copy everything? (Or worse, does it make the new directory
> actually depend on the old one?)
>

If you clone a repo to the same filesystem (e.g. the same disk partition)
then Mercurial will use hardlinks for the repository files (i.e. things in
.hg). This means that clones are quick (although if you don't prevent
updating the working directory while cloning that can take some time ...).

Hardlinks may be broken any time changesets are added to the repo e.g. via
a commit or pull. Only the hardlinks involved in the commit (and the
manifest) will be broken.

Mercurial provides a standard extension (relink) to re-establish hardlinks
between identical storage files. For example, running hg relink in my
current feature branch repo:

[feature_branch_repo:65179] [feature_branch]> hg relink default
relinking d:\home\repos\feature_branch_repo\.hg/store to
d:\home\repos\default_repo\.hg/store
tip has 22680 files, estimated total number of files: 34020
collected 229184 candidate storage files
pruned down to 49838 probably relinkable files
relinked 359 files (221 MB reclaimed)

Tim Delaney

[toc] | [prev] | [next] | [standalone]

#77923

"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmr5gh8=1zPjG_KdTmA2QgT_5jj=kh=jyvRFv1atL1EeKw@mail.gmail.com...
> On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> "Frank Millman" <frank@chagford.com>:
>>
>>> You are encouraged to make liberal use of 'branches',
>>
>> Personally, I only use forks, IOW, "git clone". I encourage that
>> practice. Then, there is little need for "git checkout". Instead, I just
>> cd to a different directory.
>>
>> Branches and clones are highly analogous processwise; I would go so far
>> as to say that they are redundant.
>
> But rather than listening to, shall we say, *strange* advice like
> this, Frank, you'll do well to pick up a reliable git tutorial, which
> should explain branches, commits, the working tree, etc, etc, etc.
>

I don't want to turn this into a full-on Git discussion, so briefly -

1. I have read all the 'git' tutorials I can find, but they have not 
addressed my question.
2. Albert's response 'commit or stash files before switching branches' makes 
sense, and actually answers my question.
3. I have sympathy for Marko's position of using clones rather than 
branches. I realise it does not follow the 'git' philosophy, but it does 
make it more obvious 'where you are', and lessens the chances of shooting 
yourself in the foot.

Frank

[toc] | [prev] | [next] | [standalone]

#77955

"Frank Millman" <frank@chagford.com> writes:

> 3. I have sympathy for Marko's position of using clones rather than 
> branches. I realise it does not follow the 'git' philosophy,

IMHO one important thing about git that made it is so popular is the
fact that it tries hard not to impose any policy or particular work-flow
on you, so if clones work better for you, using them still follows git
philosophy.

-- Sergey.

[toc] | [prev] | [next] | [standalone]

#77934

On Tue, 2014-09-16 at 10:59 +0200, Frank Millman wrote:
> "Chris Angelico" <rosuav@gmail.com> wrote in message 
> news:CAPTjJmr5gh8=1zPjG_KdTmA2QgT_5jj=kh=jyvRFv1atL1EeKw@mail.gmail.com...
> > On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> >> "Frank Millman" <frank@chagford.com>:
> >>
> >>> You are encouraged to make liberal use of 'branches',
> >>
> >> Personally, I only use forks, IOW, "git clone". I encourage that
> >> practice. Then, there is little need for "git checkout". Instead, I just
> >> cd to a different directory.
> >>
> >> Branches and clones are highly analogous processwise; I would go so far
> >> as to say that they are redundant.
> >
> > But rather than listening to, shall we say, *strange* advice like
> > this, Frank, you'll do well to pick up a reliable git tutorial, which
> > should explain branches, commits, the working tree, etc, etc, etc.
> >
> 
> I don't want to turn this into a full-on Git discussion, so briefly -
> 
> 1. I have read all the 'git' tutorials I can find, but they have not 
> addressed my question.
> 2. Albert's response 'commit or stash files before switching branches' makes 
> sense, and actually answers my question.
> 3. I have sympathy for Marko's position of using clones rather than 
> branches. I realise it does not follow the 'git' philosophy, but it does 
> make it more obvious 'where you are', and lessens the chances of shooting 
> yourself in the foot.

I'm with Chris on this one.  I use git extensively (I manage more than
just software with it -- I used it as version tracking when I was
working on my dissertation, articles I'm writing, script databases,
project management, etc.)

One of the code git repos I work with every day is ~4 GB for a working
repo and ~1.6 GB for a bare one.  At any given time, I have ~6 branches
I'm working on.  To have a separate repo for each branch is madness
(especially on a SSD where storage is expensive).  A trick I use to
avoid ever getting lost inside my git repository is to set up my
command-line prompt so it always displays the active branch [1]:

swails@batman ~/amber (master) $ git branch
  amber12-with-patches
  amber13-with-patches
  amber14-with-patches
  amoeba2
  amoeba2_diis
* master
  sander-python
  yorkmaster
swails@batman ~/amber (master) $ git checkout sander-python
Switched to branch 'sander-python'
Your branch is up-to-date with 'origin/sander-python'.
swails@batman ~/amber (sander-python) $ 

Doing everything as branches in the same repository has a number of
other advantages as well.  Merges don't have to be preceded by a fetch
(e.g., a git-pull).  You can cherry-pick individual commits between
branches.  You only have one copy of the git objects.  You can use "git
diff" or "git difftool" to directly compare specific files or folders
between branches or different revisions in diverged history between
branches.  I wouldn't expect you to know all of this git-magic from the
outset, but you will learn it as you need to.  Assigning each branch to
a new clone severely limits git's capabilities. [2]

All the best,
Jason

[1] See http://jswails.wikidot.com/using-git#toc48 for details of how to
do this

[2] Technically this isn't true since each repository will know about
the branches of the other repositories it pulls from, but
cherry-picking, merging, diffing, etc. between a branch and a remote
copy of a branch on the same machine is a lot more convoluted than
working with everything in the same repo (that and you never
accidentally look at an outdated version of a 'local' branch because you
forgot to fetch or pull!)

[toc] | [prev] | [next] | [standalone]

#77947

Jason Swails <jason.swails@gmail.com>:

> One of the code git repos I work with every day is ~4 GB for a working
> repo and ~1.6 GB for a bare one. At any given time, I have ~6 branches
> I'm working on.

Well, branches could be seen as a compression technique.

I'm trying to keep my git repositories in the < 1 MB range.


Marko

[toc] | [prev] | [next] | [standalone]

#77959

"Frank Millman" <frank@chagford.com> writes:
> Hi all
>
> I know there some Git experts on this list, so I hope you don't mind me 
> posting this question here.
>
> I am slowly getting comfortable with Git, but there is something that 
> confuses me.

If you want to be really comfortable with Git, you need to understand
basics of its rather simple underlying data model. Find a toutorial that
discusses this, and things will start to take their natural places.

You need to become aware that from Git point of view, your project
history is a DAG of commits, and branches are just pointers to specific
nodes of the DAG. It's very essential, so I repeat: "branch" in Git is
nothing more than a named pointer to specific commit in the DAG.

You should also learn that the files you are changing constitute
"working tree", and working tree does not belong to the DAG (and
therefore to any branch). Git simply remembers particular commit in the
DAG the working tree is checked-out from in the special HEAD pointer
(that usually points to the current branch, that in turn points to the
commit).

> You are encouraged to make liberal use of 'branches', and if required you 
> can have multiple branches running concurrently.

I'm afraid "multiple branches running concurrently" could be rather
confusing. Recalling that Git branches are just pointers, they don't
"run", they just exist. One needs to clearly understand the difference
between Git branch, being a pointer to a commit, and the sequence of
commits that lead to the commit at which Git branch points. When we say
"branch of development", we usually mean the latter, and when we run
"git checkout <branch_name>" we should understand we mean the former.

> When you commit changes on one branch, 

Strictly speaking, when you commit, you don't commit changes, you create
commit that contains entire state of your tree, and then this new commit
is attached to the DAG where current branch points to. Then current
branch is changed to point to this new commit.

> those changes are not visible to other branches

Exaclty. Any commit in the DAG is either reachable or not from given
branch when history is traversed backwards. That's how "visible" is
defined in Git. Right after commit is made, it's only reachable from the
current branch (if any) indeed.

> until you merge,

Exactly. When you merge a branch to another branch, all commits
reachable from the "branch" become reachable from "another branch" as
well.

> so each branch can be worked on independently.
>
> However, if you are working on a branch and make some changes, those changes 
> are visible to *all* branches until you commit.

No, as they are not in the DAG yet, they are not reachable from any
branches, so they are not visible to any of them.

What you see are changes in your working tree with respect to the commit
that is currently checked-out (usually those one to which the current
branch points).

> If you run 'git status' from any branch, you can see all files that
> have been modified or added.

You don't run 'git status' on a branch. You run it from within
repository/working tree, and then repository (usually) has some specific
branch being current at the time of invokation of 'git status' that 'git
status' will report as such.

> It seems to me that this can be confusing. When you are ready to commit 
> changes on one branch, you have to -
>   - check that it is the currently checked-out branch, which is not always 
>     obvious

What exactly "it" means in the "it is the currently..." above? Do you
mean you need to check that the current branch is those one you want to
commit changes into? If so, ask youself why do you do changes to a state
of your working tree that was checked out from any other branch in the
first place?

Usually, you checkout a branch, make changes and commit them. Only if
you realize that you was (and still are) on the wrong branch, you need
to switch branches, and Git allows you to take your changes along with
you, exactly what you need in this case.

If what you want is to temporarily stop working on these particular
changes and visit (checkout) another branch, you can stash your changes
using "git stash" and restore them later, or you can commit the changes
(remember that commits are local unless you publish them), and then,
after you return to this branch later, use, e.g., "git reset HEAD~1" to
continue editing your changes, or you can just edit further and then
commit the changes as the new commit, or amend those temporary commit
with your new changes ("git commit --amend").

>   - choose which altered files you want to add to the staging area
>   - stage them and then commit

You rather usually choose them by adding them to the staging area
(unless we talk about some GUI on top of Git), so it rather looks like:

- choose which changes you want to commit by adding them to the
  staging area.
- commit.

You can often bypass staging by "git commit -a", but anyway, "staging
area" or "index" is yet another thing in Git it's better to make
yourself familiar with, as you won't be able to ignore it if you ever
reabase or merge.

> This seems error-prone. Am I missing something?

What exactly is error-prone? Are you afraid to commit to a wrong branch?
Are you afraid to commit the changes you didn't want to commit? Anyway,
if you did a mistake, you should be able to examine situation and fix it
rather easily, provided you didn't yet publish your history.

HTH,

-- Sergey.

[toc] | [prev] | [next] | [standalone]

#77972

"Sergey Organov" <sorganov@gmail.com> wrote in message 
news:lvbtd2$fsg$1@speranza.aioe.org...
> "Frank Millman" <frank@chagford.com> writes:
>> Hi all
>>
[snip lots of really valuable information]
>

Thanks a stack, Sergey, that is a really useful explanation.

For the record, this is where my initial confusion came from.

The following quote comes from the book Pro Git, by Scott Chacon. It is 
typical of the advice found in other tutorials and notes I have read.

"""
Let's go through a simple example of branching and merging with a workflow 
that you might use in the real world. You'll follow these steps:
1. Do work on a web site.
2. Create a branch for a new story you're working on.
3. Do some work in that branch.
At this stage, you'll receive a call that another issue is critical and you 
need a hotfix. You'll do the following:
1. Revert back to your production branch.
2. Create a branch to add the hotfix.
3. After it's tested, merge the hotfix branch, and push to production.
4. Switch back to your original story and continue working.
"""

Nowhere does it state that you must commit or stash your current changes 
before switching branches. Maybe it is implied by 'revert', but as a newbie 
I had missed that.

With your help and input from others, I have a much better understanding 
now.

Frank

[toc] | [prev] | [next] | [standalone]

#77974

On Thu, Sep 18, 2014 at 1:52 AM, Frank Millman <frank@chagford.com> wrote:
> Nowhere does it state that you must commit or stash your current changes
> before switching branches. Maybe it is implied by 'revert', but as a newbie
> I had missed that.

No, it's more implied in "Do some work". Basically, what you should be
doing, as much as possible, is making changes and immediately
committing them. This applies to all forms of source control; once
you're done sorting everything out, you can then squash the entire
topic branch into a single commit that you put onto the main branch,
or you can keep the full history (I prefer to do the latter). All
magic comes at a price [1], and the price of the time travel that git
lets you do is the discipline of making frequent commits while you
work. As I see it, that's pretty cheap for the power you get :)

[1] You're welcome to hear that in the voice of Rumpelstiltskin if you wish

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web