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

Re: Workflow question

From
RBRuss Brown <pickscrape@gmail.com>
Date
Sep 26, 2007, 00:01 UTC
Message-ID
<46F9A13E.4000608@gmail.com>
In-Reply-To
<7vabra5tah.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 12 quoted lines
> Russ Brown <pickscrape@gmail.com> writes:
> 
>> I keep reading things similar to this and bit by bit I'm starting to get
>> it. :) I suppose this is one case in which it's definitely a
>> disadvantage to have a good understanding of svn before coming to git...
>>
>> <yoda>You must unlearn what you have learned</yoda>
> 
> You do not have to unlearn; if Jeff truly unlearned he wouldn't
> have spotted you were trapped in SVN mentality.  You just need
> to learn there could be other ways ;-).
> 

I suppose what I really mean is you need to stop assuming what you've already learned. :)

Show 17 quoted lines
>> If you delete a branch that has commits on it that aren't referenced by
>> any other branches, will those commits be removed by something like git
>> pack or git gc?
> 
> Yes, eventually.
> 
>> I suppose what has me the most confused is how a developer works with a
>> remote branch: I've come to understand that a developer should never
>> check out and work on a remote branch, and always create a local one and
>> work on that. If he does that using the above hierarchy, there then
>> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
>> is possible for a developer to work directory on a remote branch?
> 
> The statement in the last sentence does not make any sense.
> Remote is called remote because it is remote and supposed to be
> out of reach ;-)
> 

Ah. I think I was a little confused by the fact that git does let you checkout remote branches, through I see that it does warn you about it when you do it.

Show 8 quoted lines
> More seriously, remotes are used as reference points so if you
> "work directly on them", you cannot use them as reference points
> any more; you defeat the sole purpose of existence of remotes.
> 
> You can work _without_ using remote tracking branches, but that
> is mostly for merge based workflow.  It appears that you are
> leaning towards rebase-heavy workflow, so I do not think it is
> applicable to your project.

Right, I think we're going to be aiming for that, though as I say I'm going to be experimenting a bit to see how things work when using both approaches.

Thanks.
-- 
Russ
Previous: Junio C HamanoNext: Jeff King
Message 11 of 17 in “Workflow question”
  1. Russ BrownSep 25, 2007
  2. Andreas EricssonSep 25, 2007
  3. Jeff KingSep 25, 2007
  4. Wincent ColaiutaSep 25, 2007
  5. Jeff KingSep 25, 2007
  6. Wincent ColaiutaSep 25, 2007
  7. Russ BrownSep 25, 2007
  8. Jeff KingSep 25, 2007
  9. Russ BrownSep 25, 2007
  10. Junio C HamanoSep 25, 2007
  11. Russ BrownSep 26, 2007
  12. Jeff KingSep 26, 2007
  13. Karl HasselströmSep 26, 2007
  14. Russ BrownSep 26, 2007
  15. Junio C HamanoSep 26, 2007
  16. Jeff KingSep 26, 2007
  17. Andreas EricssonSep 25, 2007

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.