threads / discuss / 3013

RE: git pull on Linux/ACPI release tree

Subject: RE: git pull on Linux/ACPI release tree

## tl;dr

4 messages between Jan 9, 2006 and Jan 9, 2006.

replies: 3people: 4as markdown or json

Brown, Len· Jan 9, 2006, 05:53 UTC · lore
Show 24 quoted lines
>On 1/9/06, Brown, Len <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> Perhaps the tools should try to support what "a lot of people"
>> expect, rather than making "a lot of people" do extra work
>> because of the tools?
>
>I think it does. All the tricky stuff that David and Junio have been
>discussing is actually done very transparently by
>
>    git-rebase <upstream>
>
>Now, git-rebase uses git-format-patch <options> | git-am <options> so
>it sometimes has problems merging. In that case, you can choose to
>either resolve the problem (see the doco for how to signal to git-am
>that you've resolved a conflict) or to cancel the rebase. If you
>choose to cancel the rebase, do
>
>   cp .git/refs/heads/{<headname>,<headnamebadrebase>}
>   cat .git/HEAD_ORIG > .git/refs/heads/<headname>
>   git-reset --hard
>   rm -fr .dotest
>
>and you'll be back to where you started. Perhaps this could be rolled
>into something like git-rebase --cancel to make it easier, but that's
>about it. The toolchain definitely supports it.

This is completely insane. Do you have any idea what "sometimes has problems merging" means in practice? It means the tools are really nifty in the trivial case but worse than worthless when you need them the most.

-Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Langhoff· Jan 9, 2006, 06:08 UTC · re: Brown, Len · lore

Re: git pull on Linux/ACPI release tree

On 1/9/06, Brown, Len <len.brown@intel.com> wrote:
> This is completely insane.
> Do you have any idea what "sometimes has problems merging" means
> in practice?  It means the tools are really nifty in the trivial
> case but worse than worthless when you need them the most.
Len,

all I meant was that you will sometimes see conflicts. And in that case, you are far better off cancelling the rebase and doing a merge, where you will have to resolve the conflicts by hand.

git-rebase is for when the potential merge is clearly trivial. In any other case, you do want a proper merge. But in any case, it is easy to do

    git-fetch <upstream> && git-rebase <upstream>
and if it does anything but a very trivial merge, backtrack and do a merge.
In any case, if I have any suspicion that the merge may not be trivial, I do
   git-fetch <upstream> && gitk --since=" 1 month ago" upstream master

before deciding on a course of action. Of course, you can merge all the time. It's whether people care about a readable/useful history afterwards.

cheers,
martin
Linus Torvalds· Jan 9, 2006, 06:13 UTC · re: Martin Langhoff · lore

Re: git pull on Linux/ACPI release tree

On Mon, 9 Jan 2006, Martin Langhoff wrote:
> 
> and if it does anything but a very trivial merge, backtrack and do a merge.

To be fair, backtracking a "git-rebase" isn't obvious. One of the downsides of rebasing.

		Linus
Junio C Hamano· Jan 9, 2006, 06:46 UTC · re: Linus Torvalds · lore

Re: git pull on Linux/ACPI release tree

Linus Torvalds <torvalds@osdl.org> writes:
> To be fair, backtracking a "git-rebase" isn't obvious. One of the 
> downsides of rebasing.
I thought "git reset --hard ORIG_HEAD" as usual would do.

← back to recent threads