Re: [git-users] starting out with git -- a problem with branching....

2013-09-03 Thread maya melnick

thank you all very much for your responses  this is the first time I'm 
back on Usenet in a long time... it had become practically unusable b/c of 
the spam, but I see that google got its act together here, and has somehow 
managed to deal with the spam...;-)  this is good to know...

yes, I see that I have to commit changes before switching branches in order 
for the changes to NOT show up in branch master

to me personally this doesn't matter, I work in my localhost, and just want 
the changes to be visible that I want to push at that moment...  so I guess 
all I have to do is stage  commit, then switch to the branch for the 
changes I want to push at that moment, and push...  does this make sense? 
 it's the first time I'm using git for my personal stuff...

but I imagine in other situations, to have to commit every time before 
switching branches is weird... what if you haven't finished work on a 
branch and need to switch branches to take care of another problem, but 
don't want to commit what you just did because, well, you're not ready to 
commit?  ;-)

I mean scenario described here,
http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
on very first section, near the top of this page...

(they never said you'd have to commit every time you switch branches.;-)

thank you very much

-- 
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] starting out with git -- a problem with branching....

2013-09-03 Thread John McKown
If you don't want to do a commit, then do a stash. It puts the current
working directory off to the side. Like a temporary branch. When you want
to come back, then you do a git stash pop.

I think I understand how you're working. You likely only do a commit when
you think something is finished. I, on the other hand, think of commit
as take a checkpoint. And I use the commit comment to tell me where I am
and what I'm thinking about.  I have a bare repository to which I do a git
push when I think that something is finished. Well, to the extent that
anything that _I_ do is ever finished grin/.


On Tue, Sep 3, 2013 at 10:05 AM, maya melnick maya778...@yahoo.com wrote:


 thank you all very much for your responses  this is the first time I'm
 back on Usenet in a long time... it had become practically unusable b/c of
 the spam, but I see that google got its act together here, and has somehow
 managed to deal with the spam...;-)  this is good to know...

 yes, I see that I have to commit changes before switching branches in
 order for the changes to NOT show up in branch master

 to me personally this doesn't matter, I work in my localhost, and just
 want the changes to be visible that I want to push at that moment...  so I
 guess all I have to do is stage  commit, then switch to the branch for the
 changes I want to push at that moment, and push...  does this make sense?
  it's the first time I'm using git for my personal stuff...

 but I imagine in other situations, to have to commit every time before
 switching branches is weird... what if you haven't finished work on a
 branch and need to switch branches to take care of another problem, but
 don't want to commit what you just did because, well, you're not ready to
 commit?  ;-)

 I mean scenario described here,
 http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
 on very first section, near the top of this page...

 (they never said you'd have to commit every time you switch
 branches.;-)

 thank you very much

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




-- 
As of next week, passwords will be entered in Morse code.

Maranatha! 
John McKown

-- 
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] starting out with git -- a problem with branching....

2013-09-03 Thread Paul Smith
On Tue, 2013-09-03 at 08:05 -0700, maya melnick wrote:
 but I imagine in other situations, to have to commit every time before
 switching branches is weird... what if you haven't finished work on a
 branch and need to switch branches to take care of another problem,
 but don't want to commit what you just did because, well, you're not
 ready to commit?  ;-)

That's what the git stash command is for.  Check 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] starting out with git -- a problem with branching....

2013-09-03 Thread Dale R. Worley
 From: maya melnick maya778...@yahoo.com
 
 (I haven't commited, it's just a test branch, I don't want to commit;-) 
  make sense?

The way to think about it is that you've just changed a file in the
working directory, it isn't *in* the branch or the repository.  So
when you tell Git to shuffle the working directory to show the top of
master, Git sees that there's this entirely un-archived change in the
working directory, and it leaves it unchanged.

You can stash the change, but I think that what you really want is to
commit it into test.  The change may not be complete, but it safely
saves the change into test.  You can add further changes to the top
commit of test using git commit --amend, or you can combine several
commits using git rebase --interactive.

Dale

-- 
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] starting out with git -- a problem with branching....

2013-09-03 Thread Konstantin Khomoutov
On Tue, 3 Sep 2013 10:20:06 -0500
John McKown john.archie.mck...@gmail.com wrote:

 If you don't want to do a commit, then do a stash. It puts the current
 working directory off to the side. Like a temporary branch.

This comparison is quite to the point -- the `git stash` command even
allows to create a new branch from any stash entry.

 When you want to come back, then you do a git stash pop.
 
 I think I understand how you're working. You likely only do a
 commit when you think something is finished. I, on the other
 hand, think of commit as take a checkpoint.

Again, a very good suggestion.
To those introduced to video games, I like to explain commits as saving
the game just before opening a door to a yet not visited room with your
gun ready ;-)

[...]

-- 
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] starting out with git -- a problem with branching....

2013-09-03 Thread Konstantin Khomoutov
On Tue, 3 Sep 2013 08:05:23 -0700 (PDT)
maya melnick maya778...@yahoo.com wrote:

[...]
 but I imagine in other situations, to have to commit every time
 before switching branches is weird... what if you haven't finished
 work on a branch and need to switch branches to take care of another
 problem, but don't want to commit what you just did because, well,
 you're not ready to commit?  ;-)

You do not *have to* commit -- if you dislike the idea of
work-in-progress commits, then just use stash -- it was invented
precisely for dealing with such scenarious when you want to
disrupt your hacking session to switch to another branch temporarily
to do, say, a quick fix.

But it helps to actually ponder the possibility of throw-away commits
even if you do not intend to use them.  This is because in Git
philosophy your *local* (unpushed) history is not sacred (this is
in stark contrast with certain other DVCS systems, for instance, Fossil
[1] in which each commit is cast in stone), and you're free to
manipulate it however you're pleased to do so until it's pushed
somewhere else.  This allows you to spit a series of miniscule dirty
commits and then lump them together to form a larger beautiful
commit or several of them and bless the result as something you
intend to share or publish.

If you lament the fact the work tree is not tied to a branch then
there's nothing which could be do to it -- this is the design choice,
and Git developers are highly unlikely to ever change that.

It also helps pondering that there are technical difficulties
implementing such affinity: what to do with untracked files?
Obviously, when you hack a feature, you're likely to create new files
-- should Git auto save them when you switch branches?  Yes?  But what
if while hacking that feature you performed a test run of your program
and it spewed a few hundred gigabytes of tracing data to your work tree?
Saving just everything hence has unexpected (and possibly crazy) hidden
costs, and not saving everything has the great WTF potential.  So in
fact what Git does is a) simple and predictable, and b) has low WTF
potential once you know the rules (and you do now).

1. http://www.fossil-scm.org

-- 
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] starting out with git -- a problem with branching....

2013-09-03 Thread David
On 4 September 2013 01:20, John McKown john.archie.mck...@gmail.com wrote:
 If you don't want to do a commit, then do a stash. It puts the current
 working directory off to the side. Like a temporary branch. When you want
 to come back, then you do a git stash pop.

 I think I understand how you're working. You likely only do a commit when
 you think something is finished. I, on the other hand, think of commit
 as take a checkpoint. And I use the commit comment to tell me where I am
 and what I'm thinking about.  I have a bare repository to which I do a git
 push when I think that something is finished. Well, to the extent that
 anything that _I_ do is ever finished grin/.

The following additional comments are directed to maya melnick, based
on John's above:

I agree. At this state I'd encourage you more toward getting more
comfortable with commits rather than stashing, although both are fine.

Like John wrote, I think of commits as snapshots. The less sure I am
of how todays code is going to develop, the more interim commits I
make, in case I go in a direction that doesn't work out, or might not.
I make lots of commits and little branches. Then when the final design
becomes clearer, I remove the unwanted stuff, usually by rebasing or
amending commits. I find the graphical tools gitk and git-gui help
with this.

This is different to thinking of commits as finished milestones,
although you can of course have other commits and/or branches that
have that role.

It takes a while to become that comfortable with git, but when you do,
it is great.

It is very important (and took me too long) to realise that branches
are just pointers, and so this: when you want to do anything in git
that you are unsure about (like rebasing or tidying up a branch), just
create another temporary branch that points to the exactly same place
and modify it. So if you mess it up, the original branch will still be
there unchanged, as a fallback. Repeat until happy with results.

-- 
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] starting out with git -- a problem with branching....

2013-09-03 Thread John McKown
For milestones, I either create a new branch at that commit point (rarely)
or tag the commit with a nice name.


On Tue, Sep 3, 2013 at 10:40 AM, David bouncingc...@gmail.com wrote:

 On 4 September 2013 01:20, John McKown john.archie.mck...@gmail.com
 wrote:
  If you don't want to do a commit, then do a stash. It puts the current
  working directory off to the side. Like a temporary branch. When you
 want
  to come back, then you do a git stash pop.
 
  I think I understand how you're working. You likely only do a commit
 when
  you think something is finished. I, on the other hand, think of
 commit
  as take a checkpoint. And I use the commit comment to tell me where I
 am
  and what I'm thinking about.  I have a bare repository to which I do a
 git
  push when I think that something is finished. Well, to the extent that
  anything that _I_ do is ever finished grin/.

 The following additional comments are directed to maya melnick, based
 on John's above:

 I agree. At this state I'd encourage you more toward getting more
 comfortable with commits rather than stashing, although both are fine.

 Like John wrote, I think of commits as snapshots. The less sure I am
 of how todays code is going to develop, the more interim commits I
 make, in case I go in a direction that doesn't work out, or might not.
 I make lots of commits and little branches. Then when the final design
 becomes clearer, I remove the unwanted stuff, usually by rebasing or
 amending commits. I find the graphical tools gitk and git-gui help
 with this.

 This is different to thinking of commits as finished milestones,
 although you can of course have other commits and/or branches that
 have that role.

 It takes a while to become that comfortable with git, but when you do,
 it is great.

 It is very important (and took me too long) to realise that branches
 are just pointers, and so this: when you want to do anything in git
 that you are unsure about (like rebasing or tidying up a branch), just
 create another temporary branch that points to the exactly same place
 and modify it. So if you mess it up, the original branch will still be
 there unchanged, as a fallback. Repeat until happy with results.

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




-- 
As of next week, passwords will be entered in Morse code.

Maranatha! 
John McKown

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