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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
