All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russ Brown <pickscrape@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Workflow question
Date: Tue, 25 Sep 2007 19:01:02 -0500	[thread overview]
Message-ID: <46F9A13E.4000608@gmail.com> (raw)
In-Reply-To: <7vabra5tah.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:
> 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. :)

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

> 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

  reply	other threads:[~2007-09-26  0:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-25 16:43 Workflow question Russ Brown
2007-09-25 19:09 ` Andreas Ericsson
2007-09-25 19:34   ` Jeff King
2007-09-25 19:50     ` Wincent Colaiuta
2007-09-25 20:20       ` Jeff King
2007-09-25 20:37         ` Wincent Colaiuta
2007-09-25 19:42   ` Russ Brown
2007-09-25 20:17     ` Jeff King
2007-09-25 20:56       ` Russ Brown
2007-09-25 21:28         ` Junio C Hamano
2007-09-26  0:01           ` Russ Brown [this message]
2007-09-26  0:47         ` Jeff King
2007-09-26  1:51           ` Karl Hasselström
2007-09-26  2:55           ` Russ Brown
2007-09-26  5:29             ` Junio C Hamano
2007-09-26 12:42             ` Jeff King
2007-09-25 22:38     ` Andreas Ericsson
  -- strict thread matches above, loose matches on Subject: below --
2007-07-24 13:53 workflow question Patrick Doyle
2007-07-24 15:37 ` Alex Riesen
2007-07-24 16:30   ` Patrick Doyle
2007-07-24 16:35     ` Julian Phillips
2007-07-24 20:54       ` Alex Riesen
2007-07-24 20:57     ` Alex Riesen
2007-07-24 21:00       ` J. Bruce Fields
2007-07-24 21:38         ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46F9A13E.4000608@gmail.com \
    --to=pickscrape@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.