[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Version mismatch when building trunk
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2009-10-17 1:32:36
Message-ID: hbb6rk$92i$1 () ger ! gmane ! org
[Download RAW message or body]

Andreas Pakulat wrote:
> On 16.10.09 16:24:35, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> Well, git-challenged can be easily cured. In fact for keeping track of
>>> kde-qt you need exactly two very easy to learn commands: git branch and
>>> git pull. The first one to select the right branch and the latter to
>>> keep that branch up-to-date.
>> I think you mean 'git checkout'; 'git branch' *creates* branches, it
>> does not switch between branches.
> 
> Sorry, of course.

No worries, just so we're not confusing the people not familiar with git 
;-).

>> ...and that's still more than we needed with svn.
> 
> actually no, the checkout has been done with svn too. What you didn't do
> with svn is cloning the repository.

I was referring to having to periodically switch branches. (Er... 
technically I think you are forgetting a 'git clone'? svn was two 
commands, 'co' and 'up'; with git you need clone, pull and occasionally 
checkout to change branches. Or maybe one of those can also do a clone 
when no repo exists yet, but...)

>> My update script doesn't like git repos without a 'master' branch,
>> so I set up one (locally). Now, is there a way to say that this
>> should track some "latest" branch upstream
> 
> No, because there's no such thing right now in the kde-qt repo. HEAD
> points to the latest stable release. As Thiago said that could be
> created however.

...and he and I also had a long discussion on why a "polluted" branch is 
less than desirable. For now I don't find it as needed, but that's 
because the pain of switching is some time behind me. Now, if you ask me 
again next time there is a switch, I might feel otherwise.

As per my other mail I'd prefer some sort of "meta branch" (what it 
sounds like "HEAD" is, actually), so that when "latest" gets switched, 
'git pull --rebase' will rebase remote..HEAD from where it was to the 
new branch (if that isn't empty; obviously if it is empty, it just 
switches branches).

>> so that 'git pull --rebase' will rebase master less its old upstream
> 
> You don't need the --rebase there usually.

If I wanted merges instead of rebases, that's true. But I want rebases 
:-). Anyway, you are right that to --rebase or not isn't really 
important, it's setting up the merge target for 'pull' that matters.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
In the GNU/Linux world there are two major text editing programs: the 
minimalist vi and the maximalist emacs. I use emacs, which might be 
thought of as a thermonuclear word processor. -- Neal Stephenson (from 
"In the Beginning was the Command Line")

[prev in list] [next in list] [prev in thread] [next in thread]