# RE: git pull on Linux/ACPI release tree

4 messages from 2006-01-09 to 2006-01-09. Participants: Brown, Len, Martin Langhoff, Linus Torvalds, Junio C Hamano.
Thread: https://gitlist.dev/t/3013

## Brown, Len, 2006-01-09 05:53

Subject: RE: git pull on Linux/ACPI release tree
Message-ID: <F7DC2337C7631D4386A2DF6E8FB22B3005A136DD@hdsmsx401.amr.corp.intel.com>
URL: https://gitlist.dev/e/F7DC2337C7631D4386A2DF6E8FB22B3005A136DD%40hdsmsx401.amr.corp.intel.com

```

>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, 2006-01-09 06:08

Subject: Re: git pull on Linux/ACPI release tree
Message-ID: <46a038f90601082208i95cd19fmda542da0da8cc9ef@mail.gmail.com>
URL: https://gitlist.dev/e/46a038f90601082208i95cd19fmda542da0da8cc9ef%40mail.gmail.com
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A136DD@hdsmsx401.amr.corp.intel.com>

```
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, 2006-01-09 06:13

Subject: Re: git pull on Linux/ACPI release tree
Message-ID: <Pine.LNX.4.64.0601082212420.3169@g5.osdl.org>
URL: https://gitlist.dev/e/Pine.LNX.4.64.0601082212420.3169%40g5.osdl.org
In-Reply-To: <46a038f90601082208i95cd19fmda542da0da8cc9ef@mail.gmail.com>

```


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, 2006-01-09 06:46

Subject: Re: git pull on Linux/ACPI release tree
Message-ID: <7vlkxpucep.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vlkxpucep.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <Pine.LNX.4.64.0601082212420.3169@g5.osdl.org>

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

```