Stupid GIT question...

Stupid GIT question...

[Valdis.Kletnieks]

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

I have a GIT tree (iwlwifi, but the problem is my idiocy, not the tree ;).

What's the command to get a diff of "what I would merge if I said 'git pull'?"
(similar to what 'cvs diff' does - AFAICT, 'git diff HEAD .' diffs my *current*
pull of the tree against itself and does nothing...


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

Re: Stupid GIT question...

[Andreas Schwab]

Valdis.Kletnieks@vt.edu writes:

> What's the command to get a diff of "what I would merge if I said 'git pull'?"

$ git fetch
$ git diff master origin

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

stupid git question

[Bob Tracy]

Subject says a mouthful, but I digress...

Pointed "git" at Linus' github.com repository to pull the "-rc6"
changes (git pull <repo_url>).  Seems to have worked, except I received
no updated tags: the latest tag in my local repo copy is "v3.1-rc4".

Is this an expected consequence of doing the initial clone operation
from one repo, and then pulling updates from another that, in theory, is
identical to the first?  If so, is there an officially sanctioned method
of switching repositories that doesn't require blowing away the local
copy and doing another "git clone"?

Thanks.

--Bob

Re: stupid git question

[Josh Boyer]

On Wed, Sep 14, 2011 at 4:19 PM, Bob Tracy <rct@gherkin.frus.com> wrote:
> Subject says a mouthful, but I digress...
>
> Pointed "git" at Linus' github.com repository to pull the "-rc6"
> changes (git pull <repo_url>).  Seems to have worked, except I received
> no updated tags: the latest tag in my local repo copy is "v3.1-rc4".
>
> Is this an expected consequence of doing the initial clone operation
> from one repo, and then pulling updates from another that, in theory, is
> identical to the first?  If so, is there an officially sanctioned method
> of switching repositories that doesn't require blowing away the local
> copy and doing another "git clone"?

Do a git fetch --tags <repo url> and you'll get the tags too.

josh

Re: stupid git question

[Bob Tracy]

On Wed, Sep 14, 2011 at 04:22:05PM -0400, Josh Boyer wrote:
> On Wed, Sep 14, 2011 at 4:19 PM, Bob Tracy <rct@gherkin.frus.com> wrote:
> > Pointed "git" at Linus' github.com repository to pull the "-rc6"
> > changes (git pull <repo_url>).  Seems to have worked, except I received
> > no updated tags: the latest tag in my local repo copy is "v3.1-rc4".
> 
> Do a git fetch --tags <repo url> and you'll get the tags too.

Perfect!  Exactly what I needed: thanks!

--Bob

Re: stupid git question

[Markus Trippelsdorf]

On 2011.09.14 at 15:19 -0500, Bob Tracy wrote:
> Subject says a mouthful, but I digress...
> 
> Pointed "git" at Linus' github.com repository to pull the "-rc6"
> changes (git pull <repo_url>).  Seems to have worked, except I received
> no updated tags: the latest tag in my local repo copy is "v3.1-rc4".
> 
> Is this an expected consequence of doing the initial clone operation
> from one repo, and then pulling updates from another that, in theory, is
> identical to the first?  If so, is there an officially sanctioned method
> of switching repositories that doesn't require blowing away the local
> copy and doing another "git clone"?

git fetch --tags https://github.com/torvalds/linux.git

is what you need.

-- 
Markus

Stupid git question...

[Valdis Kletnieks]

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

OK.. Here's the situation - I've got several sets of patches I'll probably
be cooking over the holidays, and I'm planning to base on linux-next (though
any other moving-target base has the same issues).

What I *want* to accomplish:

At any given point, linux-next may or may not have breakages that cause
me grief (anything from compile issues to can't-boot-to-multiuser crashes).
What's the *clean* way to accomplish the following:

<assume I have a current linux-next/master copied to my box>

git branch --track linux-next/master local-fixes

git branch --track local-fixes project-1
git branch --track local-fixes project-2
git branch --track local-fixes project-3

Basically, have some way to keep track of the small integer number of
local things that I don't want escaping if I do a 'git format-patch project-2'
or other similar thing, and so I only have to deal with doing the local
fix once.  Just dropping commits on top of linux-next doesn't seem right, as
it could get ugly the next 'git remote update'.

What are maintainers doing to deal with similar issues, where you need to
make sure that your test builds in fact contain unrelated commits needed for
the build to be testable?

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

Re: Stupid git question...

[Jeff Kirsher]

On Fri, Dec 11, 2015 at 5:27 PM, Valdis Kletnieks
<Valdis.Kletnieks@vt.edu> wrote:
> OK.. Here's the situation - I've got several sets of patches I'll probably
> be cooking over the holidays, and I'm planning to base on linux-next (though
> any other moving-target base has the same issues).
>
> What I *want* to accomplish:
>
> At any given point, linux-next may or may not have breakages that cause
> me grief (anything from compile issues to can't-boot-to-multiuser crashes).
> What's the *clean* way to accomplish the following:
>
> <assume I have a current linux-next/master copied to my box>
>
> git branch --track linux-next/master local-fixes
>
> git branch --track local-fixes project-1
> git branch --track local-fixes project-2
> git branch --track local-fixes project-3
>
> Basically, have some way to keep track of the small integer number of
> local things that I don't want escaping if I do a 'git format-patch project-2'
> or other similar thing, and so I only have to deal with doing the local
> fix once.  Just dropping commits on top of linux-next doesn't seem right, as
> it could get ugly the next 'git remote update'.
>
> What are maintainers doing to deal with similar issues, where you need to
> make sure that your test builds in fact contain unrelated commits needed for
> the build to be testable?

Look at stacked git (stgit), it can resolve a number of the issues you
seem to be running into.  It makes it easy to modify patches in a
series and you can easily update your tree.

-- 
Cheers,
Jeff