nicer frontend to get rebased tree?

nicer frontend to get rebased tree?

[Andi Kleen]

A common use case for git here is to just use it as a code 
downloader without actually changing anything in the main branch.

Especially in Linux kernel land there seem to be quite a few tree
which are frequently rebased, which means that the usual "git pull -u"
usually leads to conflicts even when one hasn't changed anything
at all and just wants the latest state of that tree.

I found this initially quite frustrating ("$@#!-git cannot 
even download new trees"), until I managed to
script the necessary magic incarnations after some
documentation study (which are quite a handfull to type manually). 

But I presume that's a reasonable common usage. Would it 
make sense to have some standard git sub command that does that? 
("get latest state of remote branch, doing what it takes to get it")
Or is there already one that I missed?

Thanks,
-Andi

-- 
ak@linux.intel.com

Re: nicer frontend to get rebased tree?

[Linus Torvalds]

On Fri, 22 Aug 2008, Andi Kleen wrote:
> 
> Especially in Linux kernel land there seem to be quite a few tree
> which are frequently rebased, which means that the usual "git pull -u"
> usually leads to conflicts even when one hasn't changed anything
> at all and just wants the latest state of that tree.

What drugs are you on?

"git pull" is not "download". It's "download and merge".

If you just want download, use "git fetch". You should never _ever_ use 
"git pull -u", and the docs even tell you so.

And if you _really_ haven't changed anything, then "git pull" will never 
_ever_ generate a conflict, not with -u, not without, not _ever_. 

So you are really majorly confused about something here.

			Linus

Re: nicer frontend to get rebased tree?

[Avery Pennarun]

On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen <andi@firstfloor.org> wrote:
> But I presume that's a reasonable common usage. Would it
> make sense to have some standard git sub command that does that?
> ("get latest state of remote branch, doing what it takes to get it")
> Or is there already one that I missed?

Isn't that just

    git fetch somewhere branchname
    git reset --hard FETCH_HEAD

?

Have fun,

Avery

Re: nicer frontend to get rebased tree?

[Andi Kleen]

On Fri, Aug 22, 2008 at 10:55:35AM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 22 Aug 2008, Andi Kleen wrote:
> > 
> > Especially in Linux kernel land there seem to be quite a few tree
> > which are frequently rebased, which means that the usual "git pull -u"
> > usually leads to conflicts even when one hasn't changed anything
> > at all and just wants the latest state of that tree.
> 
> What drugs are you on?
> 
> "git pull" is not "download". It's "download and merge".

Well it's in pretty much every tutorial.  And none of them
said "you have to figure out first if the person maintaining
the tree ever uses git rebase or not".

I also don't know of any good way to detect this. One has
to just guess and try and error.

> 
> If you just want download, use "git fetch". You should never _ever_ use 
> "git pull -u", and the docs even tell you so.

Well git fetch does nothing by itself.

Yes I know it can be done (which I figured out after a extended
oddysee through git's great documentation), but it's quite complicated 
and definitely nowhere near intuitive.

> And if you _really_ haven't changed anything, then "git pull" will never 
> _ever_ generate a conflict, not with -u, not without, not _ever_. 

Sorry that's what I though initially too. But that's wrong.  Just clone
e.g. linux-next and then try to update it with pull a day later.  

rebase messed this all up majorly.  And people use that unfortunately.

In fact most kernel trees except yours seem to do rebase sooner 
or later. 

-Andi

Re: nicer frontend to get rebased tree?

[Andi Kleen]

On Fri, Aug 22, 2008 at 01:56:39PM -0400, Avery Pennarun wrote:
> On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > But I presume that's a reasonable common usage. Would it
> > make sense to have some standard git sub command that does that?
> > ("get latest state of remote branch, doing what it takes to get it")
> > Or is there already one that I missed?
> 
> Isn't that just
> 
>     git fetch somewhere branchname
>     git reset --hard FETCH_HEAD
> 
> ?

My script right now does.

git fetch origin
git fetch --tags origin
git remote update
git checkout master
git reset --hard origin/master

Sure I can continue using the script (until some change breaks it %),
but I was just asking if that was a common enough operation to deserve
some better support in standard git. It personally (as a relatively
inexperienced git user) took me some time to come up with
this script and I found the original behaviour of git pull on rebased
trees double-plus unintuitive.

Just an idea for improvement.

-Andi

-- 
ak@linux.intel.com

Re: nicer frontend to get rebased tree?

[Paolo Ciarrocchi]

On 8/22/08, Andi Kleen <andi@firstfloor.org> wrote:
> On Fri, Aug 22, 2008 at 01:56:39PM -0400, Avery Pennarun wrote:
>> On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> > But I presume that's a reasonable common usage. Would it
>> > make sense to have some standard git sub command that does that?
>> > ("get latest state of remote branch, doing what it takes to get it")
>> > Or is there already one that I missed?
>>
>> Isn't that just
>>
>>     git fetch somewhere branchname
>>     git reset --hard FETCH_HEAD
>>
>> ?
>
> My script right now does.
>
> git fetch origin
> git fetch --tags origin
> git remote update
> git checkout master
> git reset --hard origin/master
>


why the two fetch?
isn't git remote update sufficient?

ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Re: nicer frontend to get rebased tree?

[Jakub Narebski]

Andi Kleen <andi@firstfloor.org> writes:

> On Fri, Aug 22, 2008 at 01:56:39PM -0400, Avery Pennarun wrote:
> > On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen <andi@firstfloor.org> wrote:

> > > But I presume that's a reasonable common usage. Would it
> > > make sense to have some standard git sub command that does that?
> > > ("get latest state of remote branch, doing what it takes to get it")
> > > Or is there already one that I missed?
> > 
> > Isn't that just
> > 
> >     git fetch somewhere branchname
> >     git reset --hard FETCH_HEAD
> > 
> > ?
> 
> My script right now does.
> 
> git fetch origin
> git fetch --tags origin
> git remote update
> git checkout master
> git reset --hard origin/master
> 
> Sure I can continue using the script (until some change breaks it %),
> but I was just asking if that was a common enough operation to deserve
> some better support in standard git. It personally (as a relatively
> inexperienced git user) took me some time to come up with
> this script and I found the original behaviour of git pull on rebased
> trees double-plus unintuitive.
> 
> Just an idea for improvement.

With new enough git it should be enough to do

  $ git fetch origin
  $ git checkout origin/master      # detaches HEAD

OR

  $ git remote update
  $ git reset --hard origin/master  # when on master

BTW. it is stated countless time in documentation that published
history should be not rebased, barring some extenuating circumstances
(liku Junio's 'pu' (proposed updates) branch in git repository).
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: nicer frontend to get rebased tree?

[Linus Torvalds]

On Fri, 22 Aug 2008, Andi Kleen wrote:
> 
> Well git fetch does nothing by itself.

Git fetch does exactly what it should do by itself. 

If you think it does "nothing", you're really confused.

It updates the "remote" branches - the ones you are downlaoding.

> Sorry that's what I though initially too. But that's wrong.  Just clone
> e.g. linux-next and then try to update it with pull a day later.  

You SHOULD NOT DO THAT!

linux-next is not a tree that you can track. It's a tree that you can 
fetch _once_ and then throw away.

So what you can do is to "fetch" linux-next, and test it. But you MUST 
NEVER EVER use it for anything else. You can't do development on it, you 
cannot rebase onto it, you can't do _anything_ with it.

So what you can do is to "git fetch" it (to download it), and then "git 
checkout" to create a temporary checkout. That's pretty much all you can 
do with linux-next.

> rebase messed this all up majorly.  And people use that unfortunately.

Exactly. Don't rebase. And don't base your development on somebody who 
does.

And "linux-next" is literally just a temporary tree that is a merge of a 
lot of random trees. It has no future.

Remember how I told you that you should never rebase?

			Linus

Re: nicer frontend to get rebased tree?

[Mikael Magnusson]

2008/8/22 Andi Kleen <andi@firstfloor.org>:
>
> A common use case for git here is to just use it as a code
> downloader without actually changing anything in the main branch.
>
> Especially in Linux kernel land there seem to be quite a few tree
> which are frequently rebased, which means that the usual "git pull -u"
> usually leads to conflicts even when one hasn't changed anything
> at all and just wants the latest state of that tree.
>
> I found this initially quite frustrating ("$@#!-git cannot
> even download new trees"), until I managed to
> script the necessary magic incarnations after some
> documentation study (which are quite a handfull to type manually).
>
> But I presume that's a reasonable common usage. Would it
> make sense to have some standard git sub command that does that?
> ("get latest state of remote branch, doing what it takes to get it")
> Or is there already one that I missed?

I'm pretty sure "git pull --rebase" will handle this case. You can set up
a config variable (per branch if you want) to make it the default so you
can just "git pull" again.

-- 
Mikael Magnusson

Re: nicer frontend to get rebased tree?

[Paolo Ciarrocchi]

On Fri, Aug 22, 2008 at 9:36 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 22 Aug 2008, Andi Kleen wrote:
>>
>> Well git fetch does nothing by itself.
>
> Git fetch does exactly what it should do by itself.
>
> If you think it does "nothing", you're really confused.
>
> It updates the "remote" branches - the ones you are downlaoding.
>
>> Sorry that's what I though initially too. But that's wrong.  Just clone
>> e.g. linux-next and then try to update it with pull a day later.
>
> You SHOULD NOT DO THAT!
>
> linux-next is not a tree that you can track. It's a tree that you can
> fetch _once_ and then throw away.
>
> So what you can do is to "fetch" linux-next, and test it. But you MUST
> NEVER EVER use it for anything else. You can't do development on it, you
> cannot rebase onto it, you can't do _anything_ with it.
>
> So what you can do is to "git fetch" it (to download it), and then "git
> checkout" to create a temporary checkout. That's pretty much all you can
> do with linux-next.

Linus,
sorry for the double posting.

I agree, but I would like to point out a typical use case:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git remote add tip
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
git remote update (to fetch both the trees, now i can "track" your
branch with a simple merge which will results in a fast forward)
git checkout -b tip-latest tip/master

since tip/master is often rebased (as pu or linux-next) what I do is
the following:
git branch -D tip-latest
git checkout -b tip-latest tip/master

but I guess lot of people would expect to "throw away" and "checkout
again" with a single git command.

Does it make sense?

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Re: nicer frontend to get rebased tree?

[Linus Torvalds]

On Fri, 22 Aug 2008, Linus Torvalds wrote:
> 
> So what you can do is to "git fetch" it (to download it), and then "git 
> checkout" to create a temporary checkout. That's pretty much all you can 
> do with linux-next.

.. oh, and you can also do a throw-away branch and test what a merge would 
look like when merged into linux-next. 

Basically there's a few sane sequences you can do with linux-next:

 - They all basically start with "fetch and test":

	# This obviously assumes you have set up 'linux-next' as a branch
	# earlier by either editing .git/config or using 'git remote add'
	# or something

	git fetch linux-next

	git checkout linux-next/master
	.. this will create a _temporary_ branch ("detatched head") ..
	.. you can now compile, install, boot this state ..

   repeat as necessary, but never actually do anything else with that 
   detached branch (do a "git checkout master" to get back to a sane 
   state)

and after that you can do some things:

 - You can do throw-away work on that temporary branch: you can fix up 
   crap when it doesn't compile etc, but you should always remember that 
   it's purely throw-away, beacuse all of linux-next is throw-away, and 
   gets re-created from scratch each time.

   In particular, one useful "throw-away" thing to do is to test what 
   would happen if all the crud on linux-next is merged with whatever you 
   have done youself. So assuming you're still on that throw-away branch 
   (aka "detached head": "git branch" will say "* (no branch)" is your 
   current branch), you can do things like

	git merge master

   to merge in your own work on top of linux-next, but as a total 
   throw-away (which is what you want: you can never use the state for 
   anything else anyway, and you do _not_ want to pollute your real work 
   in "master" by merging in the throw-away linux-next into that!)

but what you should _never_ do is to forget that you're on the throw-away 
branch, and do any real development.

			Linus

Re: nicer frontend to get rebased tree?

[Linus Torvalds]

On Fri, 22 Aug 2008, Paolo Ciarrocchi wrote:
> 
> since tip/master is often rebased (as pu or linux-next) what I do is
> the following:
> git branch -D tip-latest
> git checkout -b tip-latest tip/master
> 
> but I guess lot of people would expect to "throw away" and "checkout
> again" with a single git command.

I would literally suggest not using a branch at all. Yes, it works, but 
this is the perfect usage case for "no branch" aka "detached head" usage, 
because "git status" will nicely tell you "Not currently on any branch" 
and "git branch" will point it out too.

So instead of using a real branch "tip-latest", just do

	git checkout tip/master

to not create a branch at all, since all you will eventually have to do is 
to delete it anyway, and saving the state for later would be actively 
wrong.

The "git checkout" will also have a nice message like

	Note: moving to "tip/master" which isn't a local branch

and about how you _can_ save the state later if you want to (even if you 
don't), which may look a bit scary, but once you get used to it it's 
actually not scary at all, but just reminds you that you did the right 
thing.

		Linus

Re: nicer frontend to get rebased tree?

[Björn Steinbrink]

On 2008.08.22 22:11:42 +0200, Paolo Ciarrocchi wrote:
> since tip/master is often rebased (as pu or linux-next) what I do is
> the following:
> git branch -D tip-latest
> git checkout -b tip-latest tip/master
> 
> but I guess lot of people would expect to "throw away" and "checkout
> again" with a single git command.

git reset --hard tip/master

or just don't create a local branch at all and do testing on a detached
HEAD, ie. just:
git checkout tip/master

That works after each fetch.

Björn

Re: nicer frontend to get rebased tree?

[Paolo Ciarrocchi]

On 8/22/08, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.08.22 22:11:42 +0200, Paolo Ciarrocchi wrote:
>> since tip/master is often rebased (as pu or linux-next) what I do is
>> the following:
>> git branch -D tip-latest
>> git checkout -b tip-latest tip/master
>>
>> but I guess lot of people would expect to "throw away" and "checkout
>> again" with a single git command.
>
> git reset --hard tip/master

good point.

> or just don't create a local branch at all and do testing on a detached
> HEAD, ie. just:
> git checkout tip/master
>
> That works after each fetch.

yes, that's the same suggestion that i got from linus.
Thanks Bjorn, Linus.

these hints should probably get some visibility in lkml as well.

ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Re: nicer frontend to get rebased tree?

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Fri, 22 Aug 2008, Andi Kleen wrote:
>> 
>> Well git fetch does nothing by itself.
>
> Git fetch does exactly what it should do by itself. 
>
> If you think it does "nothing", you're really confused.
>
> It updates the "remote" branches - the ones you are downlaoding.
>
>> Sorry that's what I though initially too. But that's wrong.  Just clone
>> e.g. linux-next and then try to update it with pull a day later.  
>
> You SHOULD NOT DO THAT!
>
> linux-next is not a tree that you can track. It's a tree that you can 
> fetch _once_ and then throw away.
>
> So what you can do is to "fetch" linux-next, and test it. But you MUST 
> NEVER EVER use it for anything else. You can't do development on it, you 
> cannot rebase onto it, you can't do _anything_ with it.

Except perhaps if you are maintaining your own set of patches on top of
"last official release from Linus", you can test merge your changes into
the tip of linux-next of the day and make sure you are in good shape.

Of course you need to discard the test merge after doing so. 

An obvious question I can foresee is "What if I had conflicts in the test
merge, and have to resolve it to see if my changes still work?  I'd
want to rebase so that I do not have to resolve the conflict again when
linux-next matures and gets into Linus's tree.  Now you tell me not to
rebase onto it.  What should I do?"

My tentative answer is "don't worry, rerere will help you next time", but
there may be better options.

Re: nicer frontend to get rebased tree?

[Andi Kleen]

> Exactly. Don't rebase. And don't base your development on somebody who 
> does.

That's pretty much impossible in the current state of Linux development
as far as I know.

> Remember how I told you that you should never rebase?

I suspect your recommendation does not match real world git use.

-Andi

Re: nicer frontend to get rebased tree?

[Andi Kleen]

>   $ git remote update
>   $ git reset --hard origin/master  # when on master
> 
> BTW. it is stated countless time in documentation that published
> history should be not rebased, barring some extenuating circumstances

Yes and people countless times ignore that recommendation and do 
it anyways (for good reasons).  And then other users 
have to deal with these rebased trees somehow.

Anyways it is all solvable but right now ill supported
in standard commands and the documentation does not really
cover it. I was just asking (mostly for others to avoid
going through the same pain as me) for that to be improved
so that git becomes easier to use.

Sadly you guys don't even seem to want to recognize there
is a problem :-( 

-Andi

Re: nicer frontend to get rebased tree?

[Paolo Ciarrocchi]

Andi Kleen <andi <at> firstfloor.org> writes:

> 
> >   $ git remote update
> >   $ git reset --hard origin/master  # when on master
> > 
> > BTW. it is stated countless time in documentation that published
> > history should be not rebased, barring some extenuating circumstances
> 
> Yes and people countless times ignore that recommendation and do 
> it anyways (for good reasons).  And then other users 
> have to deal with these rebased trees somehow.
> 
> Anyways it is all solvable but right now ill supported
> in standard commands and the documentation does not really
> cover it. I was just asking (mostly for others to avoid
> going through the same pain as me) for that to be improved
> so that git becomes easier to use.
> 
> Sadly you guys don't even seem to want to recognize there
> is a problem  

Why are you saying so?

You now understand that your script:
git fetch origin
git fetch --tags origin
git remote update
git checkout master
git reset --hard origin/master

it's far from being perfect, right?

git remote update is going to update all the remotes so you don't need the two
git fetch command.

Furthermore, I just tried what was suggested in this thread:
paolo@paolo-desktop:~/linux.trees.git$ git pull --rebase
remote: Counting objects: 7867, done.
remote: Compressing objects: 100% (1868/1868), done.
remote: Total 5125 (delta 4373), reused 3839 (delta 3246)
Receiving objects: 100% (5125/5125), 870.73 KiB | 187 KiB/s, done.
Resolving deltas: 100% (4373/4373), completed with 942 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
 + dff643a...f8fcb0d auto-core-next -> tip/auto-core-next  (forced update)
   b635ace..6a55617  auto-core-next-base -> tip/auto-core-next-base
   b635ace..6a55617  auto-cpus4096-next -> tip/auto-cpus4096-next
   b635ace..6a55617  auto-cpus4096-next-base -> tip/auto-cpus4096-next-base
 + 1f1fccc...696f6d1 auto-fastboot-next -> tip/auto-fastboot-next  (forced update)
   b635ace..6a55617  auto-fastboot-next-base -> tip/auto-fastboot-next-base
 + cdca408...06d0224 auto-ftrace-next -> tip/auto-ftrace-next  (forced update)
   b635ace..6a55617  auto-ftrace-next-base -> tip/auto-ftrace-next-base
   b635ace..6a55617  auto-generic-ipi-next -> tip/auto-generic-ipi-next
[...]

A nice single command that seems to achive your needs.


Ciao,
             Paolo

Re: nicer frontend to get rebased tree?

[Jakub Narebski]

Andi Kleen wrote:
> Jakub Narębski wrote:
> > 
> > BTW. it is stated countless time in documentation that published
> > history should be not rebased, barring some extenuating
> > circumstances 
> 
> Yes and people countless times ignore that recommendation and do 
> it anyways (for good reasons).  And then other users 
> have to deal with these rebased trees somehow.

If you are thinking about 'linux-next', it is exception rather than
the rule.

Besides, Git is feature rich and allows many different workflows, so
you should _always_ read the Development/Contributing document for
specific project, if it exists.  (See also explanation below on 
different workflows). 

> Anyways it is all solvable but right now ill supported
> in standard commands and the documentation does not really
> cover it. I was just asking (mostly for others to avoid
> going through the same pain as me) for that to be improved
> so that git becomes easier to use.
> 
> Sadly you guys don't even seem to want to recognize there
> is a problem :-( 

First, there isn't just _one_ way to deal with non fast-forward 
(rebased) branch; there are many possible workflow wrt rebasing.

There can be something like 'pu' (proposed updates) branch in git 
repository, which is basically read-only, rebuild from scratch merging 
branch gathering topic branches which are not ready yet for 'next'
(for development branch), like work in progress and the like.  It is 
here to be able to view/examine those topic branches, without crowding 
public branch namespace.  In short: it is only to view.
Workflow:
  $ git fetch origin   OR   git remote update

Then there is something like 'linux-next' tree, which is also rebuild 
from scratch, and as far as I understand serves as gathering point for 
different patches being prepared to enter Linux, and to resolve 
conflicts early.  It is, if I understand correctly, to check if it 
compiles and doesn't have bugs, and to test merging your work; _not_
to base your own work on.
Workflow:
  $ git fetch origin   OR   git remote update
  $ git checkout origin/master  # detaches HEAD / not on any branch

Finally (or not: perhaps there are yet different workflows involving
history rewriting) there are projects which use rebase based workflow.
The information about it should be on project homepage (or wiki).
Workflow:
  $ git pull --rebase  # or configure it: branch.autosetuprebase etc.


Second, this is open source. If you feel that documentation needs 
improvement, now that you have all this information, you can simply 
send patch either to manpages, or to Git User's Manual.  Trolling won't 
work ;-P
-- 
Jakub Narebski
Poland

Re: nicer frontend to get rebased tree?

[Paolo Bonzini]

Andi Kleen wrote:
>> Exactly. Don't rebase. And don't base your development on somebody who 
>> does.
> 
> That's pretty much impossible in the current state of Linux development
> as far as I know.
> 
>> Remember how I told you that you should never rebase?
> 
> I suspect your recommendation does not match real world git use.

I think if you have to rebase often, you're actually better off using
stgit (patch queues is what the mercurial folks use instead of
often-rebased local branches).

Disclaimer: I am not an stgit user myself.

Paolo

Re: nicer frontend to get rebased tree?

[Linus Torvalds]

On Sat, 23 Aug 2008, Andi Kleen wrote:
>
> > Exactly. Don't rebase. And don't base your development on somebody who 
> > does.
> 
> That's pretty much impossible in the current state of Linux development
> as far as I know.

Note that the "don't rebase" (as usual) only concerns your published tree. 
You can certainly rebase non-published stuff.

As to the "don't base your development on somebody who does" - base your 
development either on my tree (I don't rebase) or talk to the d*ck-head 
that you _want_ to work with, but who rebases.

> > Remember how I told you that you should never rebase?
> 
> I suspect your recommendation does not match real world git use.

A lot of the trees don't rebase. The rest of the trees may not realize 
that somebody wants to work on top of them.

And linux-next has _never_ been appropriate as a development base for 
other reasons, so forget about linux-next. It's to find merge conflicts 
and possibly boot/test failures of the trees it contains, not for anything 
else.

			Linus

Re: nicer frontend to get rebased tree?

[Andi Kleen]

On Sat, Aug 23, 2008 at 11:24:52AM +0200, Paolo Bonzini wrote:
> Andi Kleen wrote:
> >> Exactly. Don't rebase. And don't base your development on somebody who 
> >> does.
> > 
> > That's pretty much impossible in the current state of Linux development
> > as far as I know.
> > 
> >> Remember how I told you that you should never rebase?
> > 
> > I suspect your recommendation does not match real world git use.
> 
> I think if you have to rebase often, you're actually better off using

[ ] You read my original email.

The issue is not that I'm rebasing [1], but that other people I'm updating
trees from are rebasing all the time. And Linus and the others can
say "don't rebase" all the time -- that doesn't change the fact thato
others are rebasing anyways. And git's support for dealing with that seems
to be quite poor.

-Andi

[1] Ok I do it occasionally, but that's not the problem here, and
I don't have a real user base for my trees and the branches I'm 
doing that on.

Re: nicer frontend to get rebased tree?

[Andi Kleen]

> Note that the "don't rebase" (as usual) only concerns your published tree. 
> You can certainly rebase non-published stuff.
> 
> As to the "don't base your development on somebody who does" - base your 

That's not practical for me. Maybe it's for you, but it doesn't really
work if you're sufficiently down the food tree. You just have to work
with what other maintainers have and you can't really yell at them
when they do something inconvenient like you do all the time, because
they just ignore you then.

> development either on my tree (I don't rebase) or talk to the d*ck-head 
> that you _want_ to work with, but who rebases.
> 
> > > Remember how I told you that you should never rebase?
> > 
> > I suspect your recommendation does not match real world git use.
> 
> A lot of the trees don't rebase. The rest of the trees may not realize 

That's not my experience, sorry (even on other other trees than linux-next,
linux-next was just an example).  e.g. the original ACPI tree did it,
the x86 tree jungle does it, most of the other architecture trees do it,
the networking tree does it. etc.etc.

Then for linux-next it's reasonable to say that one shouldn't 
do development on top of it, but still if there is supposed
to be a tester base for it it requires at least reasonable
support in git for regular read-only download and right now that
support is at best obscure and unobvious (to avoid stronger words)

> And linux-next has _never_ been appropriate as a development base for 
> other reasons, so forget about linux-next. It's to find merge conflicts 
> and possibly boot/test failures of the trees it contains, not for anything 
> else.

Well it sounds like most people except you get it "wrong". Or maybe
it's more that your intended usage model just does not match what
people really do.

-Andi 

Re: nicer frontend to get rebased tree?

[Andi Kleen]

> If you are thinking about 'linux-next', it is exception rather than
> the rule.

No you're wrong. The majority of Linux trees I have to deal with 
do it now and then. And I must say I also understand why 
they want it -- they want a clean history on top of Linus' tree.
Otherwise there is no chance to find the own changes again
after a few thousands other merges.

> First, there isn't just _one_ way to deal with non fast-forward 
> (rebased) branch; there are many possible workflow wrt rebasing.

I don't doubt there are a million ways to do it somehow in
all kinds of convoluted ways. And that's exactly the problem.

The only thing I asked for was that were as a simple standard way that
is actually documented in the main documentation and the tutorials
and doesn't require lots of strange commands.

Not more not less. Right now that's not there as I know
from my own experience.

Maybe for you people who spend days thinking about git and
hacking it these ways are all obvious, but for someone like
me who just wants to use the tool it's definitely not easy
to do currently.

Anyways I'll shut up on this now because it sounds like
you people are not interested in improving the tool for 
non power users. 

-Andi

Re: nicer frontend to get rebased tree?

[Linus Torvalds]

On Sat, 23 Aug 2008, Andi Kleen wrote:
> > 
> > A lot of the trees don't rebase. The rest of the trees may not realize 
> 
> That's not my experience, sorry (even on other other trees than linux-next,
> linux-next was just an example).  e.g. the original ACPI tree did it,
> the x86 tree jungle does it, most of the other architecture trees do it,
> the networking tree does it. etc.etc.

So _complain_ to those people. Tell them that they are making your life 
harder. Let them know.

I sure as hell let people know when they are making _my_ life harder. It 
has helped. The networking tree stopped rebasing, and the x86 tree doesn't 
do it for the topic branches (although I think it re-creates the "common" 
branches all the time, kind of like linux-next).

That said, why the hell do you even care? You shouldn't base your work on 
other trees anyway. You should base your work on something as stable as 
possible. IOW, not necessariyl even my "tree-of-the-day", but actually try 
to do as much development based on real releases as possible.

Yeah, sometimes you need to synchronize with other people, but that really 
should be avoided. Not because git doesn't do it well, but because any 
time you have multiple people working in the same area, there is something 
generally WRONG. It's indicative that there is a lack of modularity when 
people step on each others toes too much.

> Then for linux-next it's reasonable to say that one shouldn't 
> do development on top of it, but still if there is supposed
> to be a tester base for it it requires at least reasonable
> support in git for regular read-only download and right now that
> support is at best obscure and unobvious (to avoid stronger words)

Umm. How obscure was it really to do

	git fetch
	git checkout

Hmm?

		Linus

Re: nicer frontend to get rebased tree?

[Björn Steinbrink]

On 2008.08.23 18:45:46 +0200, Andi Kleen wrote:
> Then for linux-next it's reasonable to say that one shouldn't 
> do development on top of it, but still if there is supposed
> to be a tester base for it it requires at least reasonable
> support in git for regular read-only download and right now that
> support is at best obscure and unobvious (to avoid stronger words)

So, how would you make it less obscure and unobvious then the current
method? The current method would be:

git fetch linux-next
git checkout linux-next/whatever

Which seems neither obscure nor unobvious to me...

Björn

Re: nicer frontend to get rebased tree?

[Linus Torvalds]

On Sat, 23 Aug 2008, Björn Steinbrink wrote:
> 
> So, how would you make it less obscure and unobvious then the current
> method? The current method would be:
> 
> git fetch linux-next
> git checkout linux-next/whatever
> 
> Which seems neither obscure nor unobvious to me...

One thing that I admit we haven't done is _document_ this in some obvious 
place.

When you know git, it's really fairly obvious and straightforward. But for 
somebody who doesn't, then _all_ the documentation is really about 
well-maintained trees that don't rebase. We very much discourage rebasing, 
and none of the docs even really talk about how to handle it.

The linux-next tree in general is I think not as useful as people think it 
could be. _I_ think it's been sold as something much bigger and more 
useful than "it's a tree where you see conflicts early, but you can't 
actually really _use_ it for anything".

So part of it is not even necessarily about _git_ documentation, but about 
the documentation for some of the trees that use git, but that aren't 
really meant for others to then use. 

		Linus

Re: nicer frontend to get rebased tree?

[Björn Steinbrink]

On 2008.08.23 11:56:27 -0700, Linus Torvalds wrote:
> On Sat, 23 Aug 2008, Björn Steinbrink wrote:
> > So, how would you make it less obscure and unobvious then the current
> > method? The current method would be:
> > 
> > git fetch linux-next
> > git checkout linux-next/whatever
> > 
> > Which seems neither obscure nor unobvious to me...
> 
> One thing that I admit we haven't done is _document_ this in some
> obvious place.

One thing I experienced in #git is that people seem to have problems
understanding remote tracking branches like linux-next/whatever in the
above example. Quite often, there have been requests like:

 How can I pull into all of my branches at once?

And after some back and forth about pull being fetch+merge and that you
can only merge into your current branch etc. it usually turns out that
those folks just have a local branch for each remote tracking branch,
even if all they want is just the state of the remote tracking branch
anyway.

So they end up doing stuff like:

git checkout foo
git pull
git checkout my_work_on_top_of_foo
git rebase foo

Where "foo" is always just fast-forwarded to origin/foo.

So I think a major part of the problem is that remote tracking branches
are not understood or at least not valued enough. Unfortunately, I have
no real idea how we could improve that.

Once on #git, I explained how branches (ie. the refs in refs/heads) are
special and that HEAD becomes a symbolic ref when you check them out,
while it becomes a plain reference to a commit when you check out
something else (tag, remote tracking branch, commit, whatever). And that
operations like commit dereference HEAD until they find a non-symbolic
ref and update _that_ ref. I think that explanation worked quite well
for the person I was talking to and made him realize that you only need
branches when you really want create your own commits. But OTOH, telling
people that local branches are the actual special case might as well
confuse the hell out of them (me thinks). And besides that, I'm no good
at writing "static" documentation anyway.

Björn

Re: nicer frontend to get rebased tree?

[Paolo Ciarrocchi]

On 8/23/08, Andi Kleen <andi@firstfloor.org> wrote:
[...]
> Not more not less. Right now that's not there as I know
> from my own experience.
>
> Maybe for you people who spend days thinking about git and
> hacking it these ways are all obvious, but for someone like
> me who just wants to use the tool it's definitely not easy
> to do currently.
>
> Anyways I'll shut up on this now because it sounds like
> you people are not interested in improving the tool for
> non power users.


that's unfair Andi.
you got nice and detailed answers,  for example you can track a
rebased tree in your working directory using git pull --rebase.
What's wrong with that?

ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Documentating branches (was: nicer frontend to get rebased tree?)

[Marius Vollmer]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> So part of it is not even necessarily about _git_ documentation, but about 
> the documentation for some of the trees that use git, but that aren't 
> really meant for others to then use. 

Incidentally, can Git attach random blurbs to branches?

I know that gitweb uses ".git/description" to describe the whole
repository.  Is there a way I can add descriptions for individual
branches?

Junio periodically posts "A note from the maintainer" that explains how
the Git repository is structured and what each of the branches is for.
It would good if this information could be found in a standard location
in the repository itself.

Putting a README or HACKING (or MaintNote) file in the project sources
itself doesn't seem right, since the sources can be offered from many
repositories, each with their own way of doing things.

One could extend the .git/description convention to
.git/descriptions/refs/heads/master, say, and gitweb would put that next
to the link for master.

But what about putting this information into proper objects, so that we
have the goodness of git to handle it.  There could be a head called
"README", and gitweb (and everybody else) could look there for blurbs.

A simple convention should suffice, and maybe there is already one that
I just don't know about.  No changes to Git are needed.  But
implementing it in gitweb would both be useful and would help people
finding them.

Re: nicer frontend to get rebased tree?

[Linus Torvalds]

On Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:
>
> you got nice and detailed answers,  for example you can track a
> rebased tree in your working directory using git pull --rebase.
> What's wrong with that?

No, you really really cannot do that.

If the _tree_ you are tracking is itself rebasing (not just your own 
tree), then you cannot and absolutely SHOULD NOT use rebase (not directly, 
and not with "git pull --rebase".

Why?

Let's look at what happens. Let's say that your history looks like

	... -> A -> B -> C -> a -> b -> c

where the upper-case letters are from the tree you track, and the 
lower-case letters are the commits you added yourself.

Now, let's say that the tree you track gets rebased, and in the process 
'B' is removed (because it turns out it was buggy), and A and C get 
modified. What happens?

You now have

	... -> A -> B -> C -> a -> b -> c     <- your branch
	  \
	    other stuff -> A' -> C'     <- newly rebased branch

(where "other stuff" is whatever the remote branch was rebased on top 
of) and when you now try to rebase your stuff on top of the newly rebased 
branch, you are going to end up trying to rebase all the _old_ commits 
that weren't even yours (ie it's going to try to rebase A, B and C too!)

And that's not what you want! It will potentially not only generate lots 
of conflicts (because A' and A aren't the same, and C' and C aren't the 
same), and it will actually re-insert B - which was buggy - before it 
finally gets to the commits _you_ actually did (a, b and c).

So no, you canno even sanely rebase on top of another persons rebased 
tree, because the _other_ person threw away his history, and since you 
remember their _old_ history, it's basically now you who are in charge of 
it.

What you can do is to basically do

	git fetch nasty-tree
	git rebase C.. --onto nasty-tree

ie you can explicitly _tell_ rebase which commits you want to rebase. 
Obviously, "git rebase --interactive" can help you do this (ie you can get 
the whole list and edit out all the crud that you know isn't yours).

But this is why working on top of somebody elses tree that gets rebased is 
so hard. You lose all the history, because the other person basically 
threw it away and started over.

Don't get me wrong - it's _possible_ to do. See above about how you can 
pick-and-choose the parts you decide you want to keep (your "own" stuff). 

In fact, we could even do a form of "rebase" that only picks commits that 
you committed yourself, and call it "git rebase --my-commits nasty-tree", 
and that would often do the right thing (assuming the source tree only 
ever rebases its own commits, of course! If it rebases other peoples 
commits, it's so terminally broken that you should just refuse to work 
with that tree, and shoot the maintainer)

So we could do more helper functions for this, but the fact is, it's a 
really broken model. The real fix is to teach people not to rebase.

			Linus

Re: nicer frontend to get rebased tree?

[Paolo Ciarrocchi]

On 8/23/08, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:
>>
>> you got nice and detailed answers,  for example you can track a
>> rebased tree in your working directory using git pull --rebase.
>> What's wrong with that?
>
> No, you really really cannot do that.
>
> If the _tree_ you are tracking is itself rebasing (not just your own
> tree), then you cannot and absolutely SHOULD NOT use rebase (not directly,
> and not with "git pull --rebase".
>
> Why?
>
> Let's look at what happens. Let's say that your history looks like
>
> 	... -> A -> B -> C -> a -> b -> c
>
> where the upper-case letters are from the tree you track, and the
> lower-case letters are the commits you added yourself.
>
[skipping a nice explanation, thanks]

you are right. But i thougth Andi was looking for simply having a
working tree in sync with a remote tree that is often rebased. That's
what his script is doing.
if the user is not adding any commit, isn't git pull --rebase the same
of git fetch (or git remote update) +git checkout ?

ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Re: nicer frontend to get rebased tree?

[Björn Steinbrink]

On 2008.08.23 14:52:37 -0700, Linus Torvalds wrote:
> On Sat, 23 Aug 2008, Paolo Ciarrocchi wrote:
> >
> > you got nice and detailed answers,  for example you can track a
> > rebased tree in your working directory using git pull --rebase.
> > What's wrong with that?
> 
> No, you really really cannot do that.
> 
> If the _tree_ you are tracking is itself rebasing (not just your own 
> tree), then you cannot and absolutely SHOULD NOT use rebase (not directly, 
> and not with "git pull --rebase".
> 
> Why?
> 
> Let's look at what happens. Let's say that your history looks like
> 
> 	... -> A -> B -> C -> a -> b -> c
> 
> where the upper-case letters are from the tree you track, and the 
> lower-case letters are the commits you added yourself.
> 
> Now, let's say that the tree you track gets rebased, and in the process 
> 'B' is removed (because it turns out it was buggy), and A and C get 
> modified. What happens?
> 
> You now have
> 
> 	... -> A -> B -> C -> a -> b -> c     <- your branch
> 	  \
> 	    other stuff -> A' -> C'     <- newly rebased branch
> 
> (where "other stuff" is whatever the remote branch was rebased on top 
> of) and when you now try to rebase your stuff on top of the newly rebased 
> branch, you are going to end up trying to rebase all the _old_ commits 
> that weren't even yours (ie it's going to try to rebase A, B and C too!)

But before the fetch step, you have remote/branch point to your old
upstream. If "pull --rebase" remembers that and uses:

git rebase --onto remote/branch $old_upstream

That should work. And in fact, it actually seems to do that.

	exec git-rebase $strategy_args --onto $merge_head \
	${oldremoteref:-$merge_head}

With $oldremoteref being the remote tracking branch before the rebase.

That said, it seems very fragile. One "git fetch" and your upstream is
lost and the next "pull --rebase" will fail.

So a somewhat less fragile way to do it would be:

git checkout -b foo origin/foo
git branch foo-upstream
....
git fetch origin
git rebase --onto origin/foo foo-upstream
git branch -f foo-upstream origin/foo

So that you always have the current upstream for your branch available
and can thus do a correct rebase. That at least doesn't break on its
own, but still does when you forget to adjust your upstream reference.

I don't actually like the idea, but maybe a refs/upstreams namespace
could be used by some script to keep track of the current upstreams of
local branches and to help with such a workflow, if one really badly
wants to do that... *hides*

Björn

Re: Documentating branches (was: nicer frontend to get rebased tree?)

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On Sun, Aug 24, 2008 at 12:38:33AM +0300, Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
> Junio periodically posts "A note from the maintainer" that explains how
> the Git repository is structured and what each of the branches is for.
> It would good if this information could be found in a standard location
> in the repository itself.

See MaintNotes in the 'todo' branch.

See also Junio's post in this thread:

http://thread.gmane.org/gmane.comp.version-control.git/79608/focus=79621

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Documentating branches

[Marius Vollmer]

("Documentating", wow...  Sorry for that.)

Re: Documenting branches

[Marius Vollmer]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Sun, Aug 24, 2008 at 12:38:33AM +0300, Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
>> Junio periodically posts "A note from the maintainer" that explains how
>> the Git repository is structured and what each of the branches is for.
>> It would good if this information could be found in a standard location
>> in the repository itself.
>
> See MaintNotes in the 'todo' branch.

Yes, I found them there, but I wouldn't call this a good example that
other people should imitate.  "MaintNotes in the todo branch" seems more
born out of accident than by design.  "NOTES in the README branch"
already sounds much better.

> See also Junio's post in this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/79608/focus=79621

Thanks, I will read the whole thread.

Re: nicer frontend to get rebased tree?

[Jakub Narebski]

Andi Kleen wrote:
> Jakub Narebski wrote:

[By the way, could you try to keep attributions? It helps when writing
 responses to know who wrote which part. TIA]

> > If you are thinking about 'linux-next', it is exception rather than
> > the rule.
> 
> No you're wrong. The majority of Linux trees I have to deal with 
> do it now and then. And I must say I also understand why 
> they want it -- they want a clean history on top of Linus' tree.
> Otherwise there is no chance to find the own changes again
> after a few thousands other merges.

Numbers? I still think that in most cases projects shouldn't rebase
published history; and if they are, they should be educated (as Linus
wrote elsewhere in the thread).
 
> > First, there isn't just _one_ way to deal with non fast-forward 
> > (rebased) branch; there are many possible workflow wrt rebasing.
> 
> I don't doubt there are a million ways to do it somehow in
> all kinds of convoluted ways. And that's exactly the problem.

_Workflows_. Not the way to deal with non fast-forward branches, not
the sequence of commands used, but the workflow, how branches are meant
to be used.

And that's three workflows which use rebase on published branches, not
million.  Perhaps they are a few more that I didn't thought about, but
I don't think that it would be _much_ more.

> The only thing I asked for was that were as a simple standard way that
> is actually documented in the main documentation and the tutorials
> and doesn't require lots of strange commands.
> 
> Not more not less. Right now that's not there as I know
> from my own experience.
> 
> Maybe for you people who spend days thinking about git and
> hacking it these ways are all obvious, but for someone like
> me who just wants to use the tool it's definitely not easy
> to do currently.

There is "simple standard way", although it might be not obvious to
somebody who is only beginner git user.  And the problem is that
for "us people" it is _obvious_, so it is not documented.  Documentation
is usually best done, or at least best started by people who have
freshness enough to know what beginners might stumble on, what people
new to git might have problems with, while having enough information
to actually write good, correct, exhaustive documentation.

And the simple standard way is fetch+checkout (detaching checkout),
at least for linux-next repository/project workflow.

> Anyways I'll shut up on this now because it sounds like
> you people are not interested in improving the tool for 
> non power users. 

Why don't you send patch improving documentation (or command messages)
then, eh?

-- 
Jakub Narebski
Poland

Re: nicer frontend to get rebased tree?

[Paolo Bonzini]

Andi Kleen wrote:
> On Sat, Aug 23, 2008 at 11:24:52AM +0200, Paolo Bonzini wrote:
>> Andi Kleen wrote:
>>>> Exactly. Don't rebase. And don't base your development on somebody who 
>>>> does.
>>> That's pretty much impossible in the current state of Linux development
>>> as far as I know.
>>>
>>>> Remember how I told you that you should never rebase?
>>> I suspect your recommendation does not match real world git use.
>> I think if you have to rebase often, you're actually better off using
> 
> [ ] You read my original email.
> 
> The issue is not that I'm rebasing [1],

Yes sorry, I meant: if you have to rebase your branches on top of
branches that also rebase, you're actually better off using stgit.

Paolo

Re: nicer frontend to get rebased tree?

[Theodore Tso]

On Sat, Aug 23, 2008 at 06:53:50PM +0200, Andi Kleen wrote:
> > If you are thinking about 'linux-next', it is exception rather than
> > the rule.
> 
> No you're wrong. The majority of Linux trees I have to deal with 
> do it now and then. And I must say I also understand why 
> they want it -- they want a clean history on top of Linus' tree.
> Otherwise there is no chance to find the own changes again
> after a few thousands other merges.

What I don't understand is in what context do you need to deal with
"the majority of Linux trees"?  Sure, the ext4 tree gets rebased all
the time.  But that's because it's a "leaf" tree; it means that people
can't base development trees off of the ext4 tree as a result.  But
then again, that's not what the ext4 git tree is intended for!  It's
like in Java when you declare a class with the 'final' keyword; such
classes can't be subclassed.

The main use of the ext4 git tree is to allow people to more easily
pull changes into their own trees, either for building their own
integration trees, or their own personal private trees.  It's simply a
much more efficient way of applying a large number of patch queues.
So for example, when I build my personal kernel that I use on my
laptops, servers, et. al, I start with ext4 and pull in various
"fixes" branches that I've needed over time to build a useful, stable
kernel.   So I have a personal merge script which does:

git branch -f master linus/master
git checkout master
git merge tp_smapi-0.37
git merge remotes/libata-dev/upstream-fixes
git merge remotes/ibm-acpi/for-upstream/acpi-release
git merge misc-fixes
git merge ext4dev

... and the result is an integration tree that always treet as
throwaway, because I've merged in trees which are indeed throwaway.
If I *do* any development work on this tree, say I cheat and fix some
ext4 bugs on this tree instead of the ext4 branch, I always will go
back to the ext4 branch, and use "git cherry-pick" to move those
changes back to the ext4 tree.

> > First, there isn't just _one_ way to deal with non fast-forward 
> > (rebased) branch; there are many possible workflow wrt rebasing.
> 
> I don't doubt there are a million ways to do it somehow in
> all kinds of convoluted ways. And that's exactly the problem.

There are, but the simpliest way to win (as the movie "Wargames" put
it), is not to play.  Just don't put commits on top of a non-terminal
trees; just use them to pull to create throw-away trees for
building/testing, for integration testing or to build your own
personal kernels.  The only time when you really need to build on top
of others' trees is if you have changes that depend on patches in
another tree, which in practice should happen rarely; and if it does,
you can ask the other maintainer to push the changes to Linus first.

In that case, what you can do is put a placeholder patch in your tree,
with a note in the commit log that this is a placeholder is pending
someone else pushing the equivalent patch to Linus, and once they push
it to Linus, when you do a rebase it will disappear.  In practice,
this happens so rarely that doing this manually with manual
coordination between maintainers about who pushes a patch to Linus
really isn't that big of a deal.

						- Ted

A proposed solution (Was: nicer frontend to get rebased tree?)

[Theodore Tso]

Maybe what we need is a way in git to advertise that a particular
branch, when pulled into another repository, shouldn't be used as a
base for someone else to do development.  The only question is what
can we do other than give a warning if someone tries to create a local
branch which tracks such a branch.  One thought is to have a git
config option which will forbid creating local branches that track an
"rebase-unstable" branch, on the theory that the best thing to do with
such workloads is to either use them as sources for "git merge" or a
git checkout creating a detached HEAD. 

Once you've merged a rebase-unstable remote branch into a local
branch, the resulting local branch could be treated "contaminated"
such that if the user tries to do any commits on such a local branch,
git issues a warning that you are committing changes onto a branch
which should be considered throwaway.

I guess the real question is whether we should be encoding quite this
much policy into git.  I think it would help make it easier to
advertise what is considered the preferred workflow, and if it can all
be turned off with a git-config option, people who don't want it can
always turn it off.

What do folks think?

						- Ted

Re: nicer frontend to get rebased tree?

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Let's look at what happens. Let's say that your history looks like
>
> 	... -> A -> B -> C -> a -> b -> c
>
> where the upper-case letters are from the tree you track, and the 
> lower-case letters are the commits you added yourself.
>
> Now, let's say that the tree you track gets rebased, and in the process 
> 'B' is removed (because it turns out it was buggy), and A and C get 
> modified. What happens?
>
> You now have
>
> 	... -> A -> B -> C -> a -> b -> c     <- your branch
> 	  \
> 	    other stuff -> A' -> C'     <- newly rebased branch
>
> (where "other stuff" is whatever the remote branch was rebased on top 
> of) and when you now try to rebase your stuff on top of the newly rebased 
> branch, you are going to end up trying to rebase all the _old_ commits 
> that weren't even yours (ie it's going to try to rebase A, B and C too!)
> ...
> What you can do is to basically do
>
> 	git fetch nasty-tree
> 	git rebase C.. --onto nasty-tree
>
> ie you can explicitly _tell_ rebase which commits you want to rebase. 

Which if I am reading git-rebase.sh right (mind you, this is not my code,
so I may well be mistaken), that is what "pull --rebase" attempts to do
with the "oldremoteref" variable.

Re: nicer frontend to get rebased tree?

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 23 Aug 2008, Andi Kleen wrote:
> > > 
> > > A lot of the trees don't rebase. The rest of the trees may not realize 
> > 
> > That's not my experience, sorry (even on other other trees than linux-next,
> > linux-next was just an example).  e.g. the original ACPI tree did it,
> > the x86 tree jungle does it, most of the other architecture trees do it,

[ thanks for the lovely charecterisation of -tip, it's appreciated.
  </sarcasm> ]

> > the networking tree does it. etc.etc.
> 
> So _complain_ to those people. Tell them that they are making your 
> life harder. Let them know.
> 
> I sure as hell let people know when they are making _my_ life harder. 
> It has helped. The networking tree stopped rebasing, and the x86 tree 
> doesn't do it for the topic branches (although I think it re-creates 
> the "common" branches all the time, kind of like linux-next).

Correct - we keep all topic branches append-only. (We rebase a topic 
only in exceptional cases: if there's a complete restart from scratch, 
when the history is so messy or uninteresting that no-one would care 
about it.)

And we do more than that: even tip/master is becoming more and more 
append-only. We are set up in a way that makes rebasing of a topic 
branch painful for _us_ integrators already. That is because tip/master 
is a "consumer" of all the topic trees, in form of 'delta-integration', 
which just merges all updated topic branches ontop of tip/master.

If a topic tree is rebased, we feel the pain in tip/master: no easy 
delta-integration run is possible anymore, we get a ton of conflicts due 
to the changed sha1's and due to the slightly changed content and the 
whole topic tree has to be undone and re-merged. It's also harder to 
track changes and it's harder to trust the quality of a stream of 
changes if they get rebased - etc.

Alas, we dont rebase when we can avoid it.

We periodically 'reintegrate' the whole thing to create the linux-next 
output branches and to get rid of the uninteresting hundreds of 
criss-cross merges, but that's on a relatively slow scale of 1-2 weeks.

( which is still too frequent for this to be truly append-only, but
  dependable enough for short-term development and obviously good for
  testing and regression-bisection activities. )

When people ask me "what should I use for development, tip/master?", i 
suggest them to use -git or a specific topic branch they are interested 
in. (and each topic branch is based on upstream -git as well.)

Sometimes if they are working in an area where there's known overlap 
with multiple topics, people will send patches/pull-requests against 
tip/master. In that case we maintainers sort those out and 'spread' them 
into individual topic branches - i.e. turn them into an append-only flow 
of changes.

But arch/x86 development is also a bit special: in the past year it has 
gathered almost as many developers and per kernel cycle commits as the 
networking tree, but compressed into a highly critical and hard to 
debug/test ~190 KLOC codebase.

The networking tree is an order of magnitude larger at 1.5 MLOC, which 
makes it statistically a lot less likely that commits would overlap in 
it - and makes it far more feasible to handle conflicts in the simplest 
and most robust way: by doing hierarchical maintenance with strict 
boundaries and thus _avoiding_ conflicts.

Hence we've set up the x86 tree as this 'forest of 160+ trees' which 
topic trees iteract with each other intelligently and which get 
integrated into a single "kitchen sink" test branch, tip/master.

	Ingo