[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Git question: when using branches, how does git treat working files
From: |
Davis Herring |
Subject: |
Re: Git question: when using branches, how does git treat working files when changing branches? |
Date: |
Thu, 29 Oct 2015 11:45:27 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110717 Lanikai/3.1.11 |
> It wouldn't work well for me. The word "commit" has a meaning,
> something like "hand over on a permanent basis".
And, with a limited scope, that's what "git commit" does: hands over
your code (actually the "index" or "staging area") to the repository
permanently (unless/until countermanded, of course). That the
destination is "your repository" rather than "the Emacs central
repository" does not prevent its being a commit, but it does (as has
been discussed to death elsewhere on this thread) change the social
implications of the commit drastically.
> If I were were to commit unfinished changes just for lack of somewhere
> proper to store them, inevitably some of these changes would find
> themselves becoming permanent, embarassingly so. Having continually to
> remember to cancel a commit each time I change branches would be an
> extra level of stress, of which there is already enough with git.
If you want, maintain (local) branches named things like "eligible" and
"scratch" (perhaps such a pair per logical change you're working on).
You can then feel free to commit regardless of quality to scratch,
knowing that you would never push such a branch. That frees your
attention to switch branches. When you come back, you can rebase/amend
the scratch commit(s) as needed, then put them onto eligible. It's a
separate question of when "eligible" is complete enough to be worth
pushing to a public location.
The change (for any given piece of work) from scratch to eligible is
then a question of quality, whereas from eligible to Savannah is a
question of completeness. It's all reasonably self-explanatory once you
choose your names.
Davis
--
This product is sold by volume, not by mass. If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], (continued)
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], Eli Zaretskii, 2015/10/30
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], Paul Eggert, 2015/10/30
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], joakim, 2015/10/30
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], Yuri Khan, 2015/10/30
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], Juanma Barranquero, 2015/10/30
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], David Kastrup, 2015/10/30
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], Juanma Barranquero, 2015/10/30
- Re: On the popularity of git [Was: Git question: when using branches, how does git treat working files when changing branches?], David Kastrup, 2015/10/30
- Re: Git question: when using branches, how does git treat working files when changing branches?, Eli Zaretskii, 2015/10/29
- Re: Git question: when using branches, how does git treat working files when changing branches?, Eli Zaretskii, 2015/10/29
- Re: Git question: when using branches, how does git treat working files when changing branches?,
Davis Herring <=
Re: Git question: when using branches, how does git treat working files when changing branches?, David Kastrup, 2015/10/28