git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: question concerning branches

From
Jakub Narebski <jnareb@gmail.com>
Date
Aug 20, 2009, 14:59 UTC
Message-ID
<m3y6pemsyl.fsf@localhost.localdomain>
In-Reply-To
<4A8D53F3.3050500@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Ingo Brueckl schrieb:
> > In a branch, I learned, I have to commit or stash before I return to master
> > for push/pull to follow the project. If I forget, I'm screwed, because files
> > have changed due to the rewrite (in that branch), I won't get a warning until
> > my first commit (in that branch) and commits (in master) will conflict.

Errr... if having unknown files in status info when comitting doesn't clue you in that you have spurious uncomitted changes,

  # On branch master
  # Changes to be committed:
  #   (use "git reset HEAD <file>..." to unstage)
  #
  #       modified:   somefile
and neither commit diff summary
   n files changed, kk insertions(+), ll deletions(-)
doesn't clue you in, then you have more serous problems!

Second, you can use git-aware prompt to tell you if you have uncomitted changes, so you will know when switching branches that you have some changes that don't belong to branch you switch from.

Show 14 quoted lines
> 
> You are obviously of a CVS or SVN mindset, where making a commit is such
> an important operation that you don't dare to make it until your work is
> *completed*.
> 
> With a git mindset, it won't happen that you "forget" whether you have
> anything uncommitted; you simply never have because committing half-baked
> stuff is the rule, not the exception. That is, before you get a cup of
> coffee, you commit; before you answer a phone call, you commit; before you
> turn your attention away, you commit. (That may be exaggerated, perhaps it
> even isn't, but you get the point.)
> 
> When you have completed your work, you go back to make your commit history
> look nice, comprehensible, and bisectable.

...with "git rebase --interactive" or patch management interface (StGit, Guilt), or topic branch management interface (TopGit).

Show 5 quoted lines
> 
> And only then comes the heavy operation: You publish your work for
> consumption by interested parties. This may be even only you yourself:
> "Consumption" would be to merge the work into your release branch. This is
> the right time to care about upstream again.
-- 
Jakub Narebski
Poland
ShadeHawk on #git
Previous: Johannes SixtNext: Junio C Hamano
Message 18 of 21 in “question concerning branches”
  1. Ingo BruecklAug 19, 2009
  2. Bruce StephensAug 19, 2009
  3. Avery PennarunAug 19, 2009
  4. Ingo BruecklAug 19, 2009
  5. Jakub NarebskiAug 19, 2009
  6. Ingo BruecklAug 19, 2009
  7. Avery PennarunAug 19, 2009
  8. Matthieu MoyAug 20, 2009
  9. Jacob HelwigAug 19, 2009
  10. Jakub NarebskiAug 19, 2009
  11. Theodore TsoAug 19, 2009
  12. Jakub NarebskiAug 19, 2009
  13. Theodore TsoAug 20, 2009
  14. Linus TorvaldsAug 19, 2009
  15. Randal L. SchwartzAug 20, 2009
  16. Ingo BruecklAug 20, 2009
  17. Johannes SixtAug 20, 2009
  18. Jakub NarebskiAug 20, 2009
  19. Junio C HamanoAug 19, 2009
  20. Ingo BruecklAug 19, 2009
  21. Andreas EricssonAug 20, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.