[Qemu-devel] updating git tree

[Qemu-devel] updating git tree

[C.W. Betts]

I'm feeling lazy and I don't want to look at all the e-mails.  How do  
you update your git tree?

Re: [Qemu-devel] updating git tree

[Laurent Desnogues]

On Tue, Apr 28, 2009 at 8:50 AM, C.W. Betts <computers57@hotmail.com> wrote:
> I'm feeling lazy and I don't want to look at all the e-mails.  How do you
> update your git tree?

Once you've cloned it (aka checkout), you update your tree using git pull (aka
update).


Laurent

Re: [Qemu-devel] updating git tree

[Bartlomiej Celary]

Something really easy to follow is at:
http://www.kernel.org/pub/software/scm/git/docs/everyday.html#Individual%20Developer%20(Participant)

(see examples)

Regards,
Bartek Celary

2009/4/28 Laurent Desnogues <laurent.desnogues@gmail.com>:
> On Tue, Apr 28, 2009 at 8:50 AM, C.W. Betts <computers57@hotmail.com> wrote:
>> I'm feeling lazy and I don't want to look at all the e-mails.  How do you
>> update your git tree?
>
> Once you've cloned it (aka checkout), you update your tree using git pull (aka
> update).
>
>
> Laurent
>
>
>

Re: [Qemu-devel] updating git tree

[Christoph Egger]

On Tuesday 28 April 2009 08:54:56 Laurent Desnogues wrote:
> On Tue, Apr 28, 2009 at 8:50 AM, C.W. Betts <computers57@hotmail.com> wrote:
> > I'm feeling lazy and I don't want to look at all the e-mails.  How do you
> > update your git tree?
>
> Once you've cloned it (aka checkout), you update your tree using git pull
> (aka update).

Unlike 'svn update', a 'git pull' doesn't automatically merge local changes.
git fails instead. git is missing this 'automatic merge on pull' feature.
If you have local changes, you must do

git stash ; git pull ; git stash pop

Christoph

P.S.: With mercurial you do 'hg pull -u' and local changes are automatically
merged.


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [Qemu-devel] updating git tree

[Kevin Wolf]

Christoph Egger schrieb:
> On Tuesday 28 April 2009 08:54:56 Laurent Desnogues wrote:
>> On Tue, Apr 28, 2009 at 8:50 AM, C.W. Betts <computers57@hotmail.com> wrote:
>>> I'm feeling lazy and I don't want to look at all the e-mails.  How do you
>>> update your git tree?
>> Once you've cloned it (aka checkout), you update your tree using git pull
>> (aka update).
> 
> Unlike 'svn update', a 'git pull' doesn't automatically merge local changes.
> git fails instead. git is missing this 'automatic merge on pull' feature.
> If you have local changes, you must do

Why would you have local (and even more, not committed) changes in the 
master branch? I always work in branches, commit frequently and rebase 
then on the master branch with a clean tree.

Kevin

[Qemu-devel] Re: updating git tree

[Jan Kiszka]

Christoph Egger wrote:
> On Tuesday 28 April 2009 08:54:56 Laurent Desnogues wrote:
>> On Tue, Apr 28, 2009 at 8:50 AM, C.W. Betts <computers57@hotmail.com> wrote:
>>> I'm feeling lazy and I don't want to look at all the e-mails.  How do you
>>> update your git tree?
>> Once you've cloned it (aka checkout), you update your tree using git pull
>> (aka update).
> 
> Unlike 'svn update', a 'git pull' doesn't automatically merge local changes.
> git fails instead. git is missing this 'automatic merge on pull' feature.
> If you have local changes, you must do
> 
> git stash ; git pull ; git stash pop
> 
> Christoph
> 
> P.S.: With mercurial you do 'hg pull -u' and local changes are automatically
> merged.

If you have non-trivial changes pending, probably in multiple commits, I
can only recommend using stgit (or guilt) to compensate the missing
patch queue feature of git. It allows you to easily navigate back and
forth in your patch queues before finally posting them.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: updating git tree

[Laurent Desnogues]

Didn't Anthony say there would be a document explaining git workflow
for QEMU?  I think it's really needed for us git beginners.


Laurent

Re: [Qemu-devel] Re: updating git tree

[Kevin Wolf]

Jan Kiszka schrieb:
> Christoph Egger wrote:
>> On Tuesday 28 April 2009 08:54:56 Laurent Desnogues wrote:
>>> On Tue, Apr 28, 2009 at 8:50 AM, C.W. Betts <computers57@hotmail.com> wrote:
>>>> I'm feeling lazy and I don't want to look at all the e-mails.  How do you
>>>> update your git tree?
>>> Once you've cloned it (aka checkout), you update your tree using git pull
>>> (aka update).
>> Unlike 'svn update', a 'git pull' doesn't automatically merge local changes.
>> git fails instead. git is missing this 'automatic merge on pull' feature.
>> If you have local changes, you must do
>>
>> git stash ; git pull ; git stash pop
>>
>> Christoph
>>
>> P.S.: With mercurial you do 'hg pull -u' and local changes are automatically
>> merged.
> 
> If you have non-trivial changes pending, probably in multiple commits, I
> can only recommend using stgit (or guilt) to compensate the missing
> patch queue feature of git. It allows you to easily navigate back and
> forth in your patch queues before finally posting them.

I haven't used these yet. Is there a real benefit compared to using a
normal git branch and rebase -i? Maybe I should try them if so.

Kevin

Re: [Qemu-devel] Re: updating git tree

[Jan Kiszka]

Kevin Wolf wrote:
> Jan Kiszka schrieb:
>> Christoph Egger wrote:
>>> On Tuesday 28 April 2009 08:54:56 Laurent Desnogues wrote:
>>>> On Tue, Apr 28, 2009 at 8:50 AM, C.W. Betts <computers57@hotmail.com> wrote:
>>>>> I'm feeling lazy and I don't want to look at all the e-mails.  How do you
>>>>> update your git tree?
>>>> Once you've cloned it (aka checkout), you update your tree using git pull
>>>> (aka update).
>>> Unlike 'svn update', a 'git pull' doesn't automatically merge local changes.
>>> git fails instead. git is missing this 'automatic merge on pull' feature.
>>> If you have local changes, you must do
>>>
>>> git stash ; git pull ; git stash pop
>>>
>>> Christoph
>>>
>>> P.S.: With mercurial you do 'hg pull -u' and local changes are automatically
>>> merged.
>> If you have non-trivial changes pending, probably in multiple commits, I
>> can only recommend using stgit (or guilt) to compensate the missing
>> patch queue feature of git. It allows you to easily navigate back and
>> forth in your patch queues before finally posting them.
> 
> I haven't used these yet. Is there a real benefit compared to using a
> normal git branch and rebase -i? Maybe I should try them if so.

I'm not only talking about rebasing, also about working within your
patch queue, editing patches in their middle, splitting it up,
reordering it etc. There are surely ways to do this with native git
(stgit is just a front-end and uses normal git), but that's not done
with two or three git commands.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: updating git tree

[Kevin Wolf]

Jan Kiszka schrieb:
> Kevin Wolf wrote:
>> Jan Kiszka schrieb:
>>> If you have non-trivial changes pending, probably in multiple commits, I
>>> can only recommend using stgit (or guilt) to compensate the missing
>>> patch queue feature of git. It allows you to easily navigate back and
>>> forth in your patch queues before finally posting them.
>> I haven't used these yet. Is there a real benefit compared to using a
>> normal git branch and rebase -i? Maybe I should try them if so.
> 
> I'm not only talking about rebasing, also about working within your
> patch queue, editing patches in their middle, splitting it up,
> reordering it etc. There are surely ways to do this with native git
> (stgit is just a front-end and uses normal git), but that's not done
> with two or three git commands.

This is why I said rebase -i and not only rebase. In case you don't know
this yet: It presents you a list of all commits you did since the point
you're rebasing on. You can then drop, merge, edit (which includes
splitting, see the man page of git-rebase) and change the order of them.

Kevin

Re: [Qemu-devel] Re: updating git tree

[Jan Kiszka]

Kevin Wolf wrote:
> Jan Kiszka schrieb:
>> Kevin Wolf wrote:
>>> Jan Kiszka schrieb:
>>>> If you have non-trivial changes pending, probably in multiple commits, I
>>>> can only recommend using stgit (or guilt) to compensate the missing
>>>> patch queue feature of git. It allows you to easily navigate back and
>>>> forth in your patch queues before finally posting them.
>>> I haven't used these yet. Is there a real benefit compared to using a
>>> normal git branch and rebase -i? Maybe I should try them if so.
>> I'm not only talking about rebasing, also about working within your
>> patch queue, editing patches in their middle, splitting it up,
>> reordering it etc. There are surely ways to do this with native git
>> (stgit is just a front-end and uses normal git), but that's not done
>> with two or three git commands.
> 
> This is why I said rebase -i and not only rebase. In case you don't know
> this yet: It presents you a list of all commits you did since the point
> you're rebasing on. You can then drop, merge, edit (which includes
> splitting, see the man page of git-rebase) and change the order of them.

It still lacks the flexibility and consistency of stgit-managed series
as it is designed around the original "rebase" step. With stgit, you are
permanently in "rebase -i" mode, you can go back and forth _while_
editing. You can switch branches without leaving the rebase mode. You
can also hide patches temporarily (how do you do this with rebase -i?).

However, in the end it is a question how you set up your personal
workflow. There are n ways to skin a cat.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: updating git tree

[Kevin Wolf]

Jan Kiszka schrieb:
> Kevin Wolf wrote:
>> Jan Kiszka schrieb:
>>> Kevin Wolf wrote:
>>>> Jan Kiszka schrieb:
>>>>> If you have non-trivial changes pending, probably in multiple commits, I
>>>>> can only recommend using stgit (or guilt) to compensate the missing
>>>>> patch queue feature of git. It allows you to easily navigate back and
>>>>> forth in your patch queues before finally posting them.
>>>> I haven't used these yet. Is there a real benefit compared to using a
>>>> normal git branch and rebase -i? Maybe I should try them if so.
>>> I'm not only talking about rebasing, also about working within your
>>> patch queue, editing patches in their middle, splitting it up,
>>> reordering it etc. There are surely ways to do this with native git
>>> (stgit is just a front-end and uses normal git), but that's not done
>>> with two or three git commands.
>> This is why I said rebase -i and not only rebase. In case you don't know
>> this yet: It presents you a list of all commits you did since the point
>> you're rebasing on. You can then drop, merge, edit (which includes
>> splitting, see the man page of git-rebase) and change the order of them.
> 
> It still lacks the flexibility and consistency of stgit-managed series
> as it is designed around the original "rebase" step. With stgit, you are
> permanently in "rebase -i" mode, you can go back and forth _while_
> editing. You can switch branches without leaving the rebase mode. You
> can also hide patches temporarily (how do you do this with rebase -i?).

Thanks, this is more or less what I wanted to know.

(And I don't think I had to hide a patch yet, but I would either create
another branch with the patch dropped or revert the patch and drop the
revert commit later.)

> However, in the end it is a question how you set up your personal
> workflow. There are n ways to skin a cat.

Sure. But as long as I only know m < n ways, there is always a chance to
miss the better workflow. ;-)

Kevin

Re: [Qemu-devel] Re: updating git tree

[Jan Kiszka]

Kevin Wolf wrote:
> Jan Kiszka schrieb:
>> Kevin Wolf wrote:
>>> Jan Kiszka schrieb:
>>>> Kevin Wolf wrote:
>>>>> Jan Kiszka schrieb:
>>>>>> If you have non-trivial changes pending, probably in multiple commits, I
>>>>>> can only recommend using stgit (or guilt) to compensate the missing
>>>>>> patch queue feature of git. It allows you to easily navigate back and
>>>>>> forth in your patch queues before finally posting them.
>>>>> I haven't used these yet. Is there a real benefit compared to using a
>>>>> normal git branch and rebase -i? Maybe I should try them if so.
>>>> I'm not only talking about rebasing, also about working within your
>>>> patch queue, editing patches in their middle, splitting it up,
>>>> reordering it etc. There are surely ways to do this with native git
>>>> (stgit is just a front-end and uses normal git), but that's not done
>>>> with two or three git commands.
>>> This is why I said rebase -i and not only rebase. In case you don't know
>>> this yet: It presents you a list of all commits you did since the point
>>> you're rebasing on. You can then drop, merge, edit (which includes
>>> splitting, see the man page of git-rebase) and change the order of them.
>> It still lacks the flexibility and consistency of stgit-managed series
>> as it is designed around the original "rebase" step. With stgit, you are
>> permanently in "rebase -i" mode, you can go back and forth _while_
>> editing. You can switch branches without leaving the rebase mode. You
>> can also hide patches temporarily (how do you do this with rebase -i?).
> 
> Thanks, this is more or less what I wanted to know.
> 
> (And I don't think I had to hide a patch yet, but I would either create
> another branch with the patch dropped or revert the patch and drop the
> revert commit later.)
> 
>> However, in the end it is a question how you set up your personal
>> workflow. There are n ways to skin a cat.
> 
> Sure. But as long as I only know m < n ways, there is always a chance to
> miss the better workflow. ;-)
> 

Yeah, true.

For that and some other reasons it would be great if git itself could
gain fully flexible queue management. stgit is only a workaround that
has some downsides, too (same for guilt). Once I'll find its core
features natively, I'm going to switch over to have only a single UI.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: updating git tree

[François Revol]

> >>>> If you have non-trivial changes pending, probably in multiple
> > > > > commits, I
> >>>> can only recommend using stgit (or guilt) to compensate the
> > > > > missing
> >>>> patch queue feature of git. It allows you to easily navigate
> > > > > back and
> >>>> forth in your patch queues before finally posting them.
> >>> I haven't used these yet. Is there a real benefit compared to
> > > > using a
> >>> normal git branch and rebase -i? Maybe I should try them if so.
> >> I'm not only talking about rebasing, also about working within
> > > your
> >> patch queue, editing patches in their middle, splitting it up,
> >> reordering it etc. There are surely ways to do this with native
> > > git
> >> (stgit is just a front-end and uses normal git), but that's not
> > > done
> >> with two or three git commands.
> >
> > This is why I said rebase -i and not only rebase. In case you don't
> > know
> > this yet: It presents you a list of all commits you did since the
> > point
> > you're rebasing on. You can then drop, merge, edit (which includes
> > splitting, see the man page of git-rebase) and change the order of
> > them.
>
> It still lacks the flexibility and consistency of stgit-managed
> series
> as it is designed around the original "rebase" step. With stgit, you
> are
> permanently in "rebase -i" mode, you can go back and forth _while_
> editing. You can switch branches without leaving the rebase mode. You
> can also hide patches temporarily (how do you do this with rebase -
> i?).
>
> However, in the end it is a question how you set up your personal
> workflow. There are n ways to skin a cat.

In the end it's a question of whether you have the time to read the doc
and learn a new SCM or not.

ATM... I do not.

François.

Re: [Qemu-devel] Re: updating git tree

[Gerd Hoffmann]

On 04/28/09 12:04, Kevin Wolf wrote:
> Jan Kiszka schrieb:
>> If you have non-trivial changes pending, probably in multiple commits, I
>> can only recommend using stgit (or guilt) to compensate the missing
>> patch queue feature of git. It allows you to easily navigate back and
>> forth in your patch queues before finally posting them.
>
> I haven't used these yet. Is there a real benefit compared to using a
> normal git branch and rebase -i?

No.  Except that if you are used to use quilt, you can maintain your 
workflow.

cheers,
   Gerd

Re: [Qemu-devel] updating git tree

[François Revol]

> On Tuesday 28 April 2009 08:54:56 Laurent Desnogues wrote:
> > On Tue, Apr 28, 2009 at 8:50 AM, C.W. Betts <
> > computers57@hotmail.com> wrote:
> > > I'm feeling lazy and I don't want to look at all the e-mails.
> > >  How do you
> > > update your git tree?
> >
> > Once you've cloned it (aka checkout), you update your tree using
> > git pull
> > (aka update).
>
> Unlike 'svn update', a 'git pull' doesn't automatically merge local
> changes.
> git fails instead. git is missing this 'automatic merge on pull'
> feature.
> If you have local changes, you must do
>
> git stash ; git pull ; git stash pop
>

git: 'stash' is not a git-command
...
is this deprecated or just in another package ?

François.

Re: [Qemu-devel] updating git tree

[Laurent Desnogues]

On Tue, Apr 28, 2009 at 1:11 PM, François Revol <revol@free.fr> wrote:
[...]
>
> git: 'stash' is not a git-command
> ...
> is this deprecated or just in another package ?

It was added in git v1.5.3.


Laurent

Re: [Qemu-devel] updating git tree

[François Revol]

> On Tue, Apr 28, 2009 at 1:11 PM, François Revol <revol@free.fr>
> wrote:
> [...]
> >
> > git: 'stash' is not a git-command
> > ...
> > is this deprecated or just in another package ?
>
> It was added in git v1.5.3.

Ah, of course, and I don't have the disk space to upgrade from etch to
lenny...
fun.

I think I'll just send the diffs from the last svn and be done with it.

François.

Re: [Qemu-devel] updating git tree

[Laurent Vivier]

Le mardi 28 avril 2009 à 14:57 +0200, François Revol a écrit :
> > On Tue, Apr 28, 2009 at 1:11 PM, François Revol <revol@free.fr> 
> > wrote:
> > [...]
> > >
> > > git: 'stash' is not a git-command
> > > ...
> > > is this deprecated or just in another package ?
> > 
> > It was added in git v1.5.3.
> 
> Ah, of course, and I don't have the disk space to upgrade from etch to 
> lenny...
> fun.
> 
> I think I'll just send the diffs from the last svn and be done with it.

you can use:

git diff > tmp.patch
patch -R -p1 < tmp.patch
git pull
patch -p1 < tmp.patch

Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] updating git tree

[François Revol]

> > Ah, of course, and I don't have the disk space to upgrade from etch
> > to
> > lenny...
> > fun.
> >
> > I think I'll just send the diffs from the last svn and be done with
> > it.
>
> you can use:
>
> git diff > tmp.patch
> patch -R -p1 < tmp.patch
> git pull
> patch -p1 < tmp.patch

Ok this seems to work at least for now, I've put it in a script like

#!/bin/sh
git diff > tmp.patch && patch -R -p1 < tmp.patch && git pull && patch -
p1 < tmp.patch && rm tmp.patch

Seems there is a git-revert, not sure how to use it anyway...
Oh well...

Thanks.

François.
todo += "learn git";
freetime -= "many days";

Re: [Qemu-devel] updating git tree

[Kevin Wolf]

François Revol schrieb:
>>> Ah, of course, and I don't have the disk space to upgrade from etch 
>>> to 
>>> lenny...
>>> fun.
>>>
>>> I think I'll just send the diffs from the last svn and be done with 
>>> it.
>> you can use:
>>
>> git diff > tmp.patch
>> patch -R -p1 < tmp.patch
>> git pull
>> patch -p1 < tmp.patch
> 
> Ok this seems to work at least for now, I've put it in a script like
> 
> #!/bin/sh
> git diff > tmp.patch && patch -R -p1 < tmp.patch && git pull && patch -
> p1 < tmp.patch && rm tmp.patch
> 
> Seems there is a git-revert, not sure how to use it anyway...
> Oh well...

git revert is for reverting commits. You can use git reset --hard
instead of the patch -R though.

Kevin

Re: [Qemu-devel] updating git tree

[Laurent Vivier]

Le mardi 28 avril 2009 à 15:58 +0200, Kevin Wolf a écrit :
> François Revol schrieb:
> >>> Ah, of course, and I don't have the disk space to upgrade from etch 
> >>> to 
> >>> lenny...
> >>> fun.
> >>>
> >>> I think I'll just send the diffs from the last svn and be done with 
> >>> it.
> >> you can use:
> >>
> >> git diff > tmp.patch
> >> patch -R -p1 < tmp.patch
> >> git pull
> >> patch -p1 < tmp.patch
> > 
> > Ok this seems to work at least for now, I've put it in a script like
> > 
> > #!/bin/sh
> > git diff > tmp.patch && patch -R -p1 < tmp.patch && git pull && patch -
> > p1 < tmp.patch && rm tmp.patch
> > 
> > Seems there is a git-revert, not sure how to use it anyway...
> > Oh well...
> 
> git revert is for reverting commits. You can use git reset --hard
> instead of the patch -R though.

No, you can't:

"git diff" will create patch for only already existing files in the git
repository, so "patch -R" will not remove new files whereas "git reset
--hard" will remove them.

Regards,
Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] updating git tree

[Kevin Wolf]

Laurent Vivier schrieb:
> Le mardi 28 avril 2009 à 15:58 +0200, Kevin Wolf a écrit :
>> François Revol schrieb:
>>>>> Ah, of course, and I don't have the disk space to upgrade from etch 
>>>>> to 
>>>>> lenny...
>>>>> fun.
>>>>>
>>>>> I think I'll just send the diffs from the last svn and be done with 
>>>>> it.
>>>> you can use:
>>>>
>>>> git diff > tmp.patch
>>>> patch -R -p1 < tmp.patch
>>>> git pull
>>>> patch -p1 < tmp.patch
>>> Ok this seems to work at least for now, I've put it in a script like
>>>
>>> #!/bin/sh
>>> git diff > tmp.patch && patch -R -p1 < tmp.patch && git pull && patch -
>>> p1 < tmp.patch && rm tmp.patch
>>>
>>> Seems there is a git-revert, not sure how to use it anyway...
>>> Oh well...
>> git revert is for reverting commits. You can use git reset --hard
>> instead of the patch -R though.
> 
> No, you can't:
> 
> "git diff" will create patch for only already existing files in the git
> repository, so "patch -R" will not remove new files whereas "git reset
> --hard" will remove them.

Oops, right, this doesn't work for staged changes (which is the case for
new files). But in that case, with patch -R the pull won't work because
you still have a modified tree, right? So git diff HEAD should do the
trick by including everything in the patch.

Kevin

Re: [Qemu-devel] updating git tree

[Laurent Vivier]

Le mardi 28 avril 2009 à 17:22 +0200, Kevin Wolf a écrit :
> Laurent Vivier schrieb:
> > Le mardi 28 avril 2009 à 15:58 +0200, Kevin Wolf a écrit :
> >> François Revol schrieb:
> >>>>> Ah, of course, and I don't have the disk space to upgrade from etch 
> >>>>> to 
> >>>>> lenny...
> >>>>> fun.
> >>>>>
> >>>>> I think I'll just send the diffs from the last svn and be done with 
> >>>>> it.
> >>>> you can use:
> >>>>
> >>>> git diff > tmp.patch
> >>>> patch -R -p1 < tmp.patch
> >>>> git pull
> >>>> patch -p1 < tmp.patch
> >>> Ok this seems to work at least for now, I've put it in a script like
> >>>
> >>> #!/bin/sh
> >>> git diff > tmp.patch && patch -R -p1 < tmp.patch && git pull && patch -
> >>> p1 < tmp.patch && rm tmp.patch
> >>>
> >>> Seems there is a git-revert, not sure how to use it anyway...
> >>> Oh well...
> >> git revert is for reverting commits. You can use git reset --hard
> >> instead of the patch -R though.
> > 
> > No, you can't:
> > 
> > "git diff" will create patch for only already existing files in the git
> > repository, so "patch -R" will not remove new files whereas "git reset
> > --hard" will remove them.
> 
> Oops, right, this doesn't work for staged changes (which is the case for
> new files). But in that case, with patch -R the pull won't work because
> you still have a modified tree, right? So git diff HEAD should do the
> trick by including everything in the patch.

"git pull" will work if the local new file is not created by the pull.
BTW, "git reset --hard" is a very dangerous command...

Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] updating git tree

[Andreas Färber]

Am 28.04.2009 um 15:10 schrieb Laurent Vivier:

> Le mardi 28 avril 2009 à 14:57 +0200, François Revol a écrit :
>>> On Tue, Apr 28, 2009 at 1:11 PM, François Revol <revol@free.fr>
>>> wrote:
>>> [...]
>>>>
>>>> git: 'stash' is not a git-command
>>>> ...
>>>> is this deprecated or just in another package ?
>>>
>>> It was added in git v1.5.3.
>>
>> Ah, of course, and I don't have the disk space to upgrade from etch  
>> to
>> lenny...
>> fun.
>>
>> I think I'll just send the diffs from the last svn and be done with  
>> it.
>
> you can use:
>
> git diff > tmp.patch
> patch -R -p1 < tmp.patch
> git pull
> patch -p1 < tmp.patch

Or to stick with a `git` workflow, you can do:

git commit -a -m "Description of local change"
git pull

Andreas

Re: [Qemu-devel] updating git tree

[François Revol]

> > you can use:
> >
> > git diff > tmp.patch
> > patch -R -p1 < tmp.patch
> > git pull
> > patch -p1 < tmp.patch
>
> Or to stick with a `git` workflow, you can do:
>
> git commit -a -m "Description of local change"
> git pull

So, was it too hard to tell it in the first place ? ;)

Though it doesn't like me...
I have a file to remove, one to add, and I don't want to commit all the
changes at once...

I tried git commit -i (it wanted it) -m "Merge usb-wacom into usb-hid"
hw/usb-hid.c Makefile hw/usb-wacom.c

but it didn't like usb-wacom.c being already gone by git rm ...
+ this stupid thing commited the popenaudio.c I wanted to leave for
another commit despite not using -a...

Plus it used the local hostname to make my email in the commit, and I
couldn't find git-config as I saw it somewhere to change it...

This is beyond logic.
I thought it was supposed to be simpler but I'll have to git clone
again, apply each diff and commit them separately... :(

François.

Re: [Qemu-devel] updating git tree

[Andreas Färber]

Am 28.04.2009 um 21:25 schrieb François Revol:

>>> you can use:
>>>
>>> git diff > tmp.patch
>>> patch -R -p1 < tmp.patch
>>> git pull
>>> patch -p1 < tmp.patch
>>
>> Or to stick with a `git` workflow, you can do:
>>
>> git commit -a -m "Description of local change"
>> git pull
>
> So, was it too hard to tell it in the first place ? ;)
>
> Though it doesn't like me...
> I have a file to remove, one to add, and I don't want to commit all  
> the
> changes at once...
>
> I tried git commit -i (it wanted it) -m "Merge usb-wacom into usb-hid"
> hw/usb-hid.c Makefile hw/usb-wacom.c
>
> but it didn't like usb-wacom.c being already gone by git rm ...
> + this stupid thing commited the popenaudio.c I wanted to leave for
> another commit despite not using -a...
>
> Plus it used the local hostname to make my email in the commit, and I
> couldn't find git-config as I saw it somewhere to change it...
>
> This is beyond logic.
> I thought it was supposed to be simpler but I'll have to git clone
> again, apply each diff and commit them separately... :(

To commit individual files, use `git add file1.c`, then `git commit`  
without -a.
You can check `git status` for what'll get committed.

While individual commands are referred to as git-svn, for instance,  
you need to call them without dash since v1.6, e.g., `git svn`.
So `git config --global user.email revol@free.fr` should do the trick  
iirc. But does it matter locally? ;)

No need to clone again. To remove the last commit, simply do `git  
reset --hard HEAD^` (one accent circonflexe per commit backwards from  
HEAD).

Andreas

Re: [Qemu-devel] updating git tree

[François Revol]

>
> To commit individual files, use `git add file1.c`, then `git commit`
> without -a.
> You can check `git status` for what'll get committed.

That I guessed, but there is no way to forbid commiting deleted files
at once...

> While individual commands are referred to as git-svn, for instance,
> you need to call them without dash since v1.6, e.g., `git svn`.
> So `git config --global user.email revol@free.fr` should do the trick
> iirc. But does it matter locally? ;)

Yes I tried this too.
Again, git is too old here and ENOSPC to distupgrade yet.

Found out in man pages one can either use ~/.git/config with .ini like
sections:
[user]
	name = "François Revol"
	email = "revol@free.fr"

or
export GIT_AUTHOR_NAME="François Revol"
export GIT_AUTHOR_EMAIL="revol@free.fr"
export GIT_COMMITTER_NAME="François Revol"
export GIT_COMMITTER_EMAIL="revol@free.fr"
which I've done in the project-local .profile.


François.

Re: [Qemu-devel] updating git tree

[François Revol]

> >
> > To commit individual files, use `git add file1.c`, then `git
> > commit`
> > without -a.
> > You can check `git status` for what'll get committed.
>
> That I guessed, but there is no way to forbid commiting deleted files
> at once...
>

So here is what I've did, FWIW:

svn diff > svn-popenaudio.diff
svn diff > svn-hid.diff
# vi both to only keep related changes
cd ..

git clone ...

git apply -p0 < ../svn-hid.diff
git rm hw/usb-wacom.c
git commit -a -m "Merge usb-wacom.c into usb-hid.c"
# argh, git status sayw hw/usb-wacom.c is still here...
rm hw/usb-wacom.c

# generate a diff...
git-format-patch -s origin
# of course it outputs a stupid mbox format which isn't used everywhere
# so I must strip the headers if I just need the real patch
(overengineering)
for f in 0???-*; do sed '1,/^$/d' -i "$f"; done

git apply -p0 < ../svn-popenaudio.diff
# now I should probably finish it first as I don't know how to generate
a single merged patch from multiple commits...
#git add audio/popenaudio.c
#git commit -a -m "Start of popen(3) audio output"

François.

Re: [Qemu-devel] updating git tree

[Markus Armbruster]

"François Revol" <revol@free.fr> writes:

>> > 
>> > To commit individual files, use `git add file1.c`, then `git 
>> > commit`  
>> > without -a.
>> > You can check `git status` for what'll get committed.
>> 
>> That I guessed, but there is no way to forbid commiting deleted files 
>> at once...

There is.

git-commit by default commits exactly what you staged in the index.  If
you staged a delete, it'll commit a delete.  If you don't want that,
unstage it, say with git-add or git-reset.

git-commit can also bypass the index.  Just list the files you want to
commit.  If a listed file no longer exists, the commit will remove it.

> So here is what I've did, FWIW:
>
> svn diff > svn-popenaudio.diff
> svn diff > svn-hid.diff
> # vi both to only keep related changes
> cd ..
>
> git clone ...
>
> git apply -p0 < ../svn-hid.diff
> git rm hw/usb-wacom.c
> git commit -a -m "Merge usb-wacom.c into usb-hid.c"
> # argh, git status sayw hw/usb-wacom.c is still here... 
> rm hw/usb-wacom.c
>
> # generate a diff...
> git-format-patch -s origin
> # of course it outputs a stupid mbox format which isn't used everywhere
> # so I must strip the headers if I just need the real patch 
> (overengineering)

If you want a diff, use git-diff.

If you want e-mail ready for sending, use git-format-patch.

> for f in 0???-*; do sed '1,/^$/d' -i "$f"; done
>
> git apply -p0 < ../svn-popenaudio.diff
> # now I should probably finish it first as I don't know how to generate 
> a single merged patch from multiple commits...
> #git add audio/popenaudio.c
> #git commit -a -m "Start of popen(3) audio output"
>
> François.

Me thinks you are still fighting the tool instead of working with it.
No happiness found down that way.

Re: [Qemu-devel] updating git tree

[François Revol]

<rant cause="I'm right but you might not have time to read it">

> >> That I guessed, but there is no way to forbid commiting deleted
> > > files
> >> at once...
>
> There is.
>
> git-commit by default commits exactly what you staged in the index.
> If
> you staged a delete, it'll commit a delete.  If you don't want that,
> unstage it, say with git-add or git-reset.
>
> git-commit can also bypass the index.  Just list the files you want
> to
> commit.  If a listed file no longer exists, the commit will remove
> it.

This sounds confuse...
anyway.

> > (overengineering)
>
> If you want a diff, use git-diff.
>
> If you want e-mail ready for sending, use git-format-patch.

I want a patch ready to submit, that is, a diff with the Signed-off-by
tag as it is supposed to be able to do this, and the commit summary as
it knows about it.

There is no reason it would make me a mail in any format that I don't
use.
mbox is not standard, despite it storing messages themselves in RFC
format.

<obvious>
Besides the command is named git format-*patch* *not* format-mail!
</obvious>

> Me thinks you are still fighting the tool instead of working with it.
> No happiness found down that way.

It's the tool that is fighting me instead of doing what I want it to
do.
It tries to impose a format on me that I don't want.
There is no reason I want to setup a mail account on this box while I
have all my mail on another box on another OS in another format (almost
maildir just better). And I don't like having send-mails hiding
elsewhere.

Why does it think I want to let it send mails for me ? I don't like
apps that does things behind my back, that sounds so Windows-ish. :^\
I thought UNIX philosophy was all about interoperability...

</rant>

Let's see if it still works today...

No commit since fc1c67bc2a43a53f7315b602e0c67f9604835fe1 ?
Hmm oh, no way to do a "git log" on a git: url without a clone ?

Btw, front page: "The a QEMU repository" typo. It could reuse a link
too...
http://savannah.nongnu.org/git/?group=qemu ?

François.

Re: [Qemu-devel] updating git tree

[Markus Armbruster]

"François Revol" <revol@free.fr> writes:

> <rant cause="I'm right but you might not have time to read it">
>
>> >> That I guessed, but there is no way to forbid commiting deleted 
>> > > files 
>> >> at once...
>> 
>> There is.
>> 
>> git-commit by default commits exactly what you staged in the index.  
>> If
>> you staged a delete, it'll commit a delete.  If you don't want that,
>> unstage it, say with git-add or git-reset.
>> 
>> git-commit can also bypass the index.  Just list the files you want 
>> to
>> commit.  If a listed file no longer exists, the commit will remove 
>> it.
>
> This sounds confuse...
> anyway.

The index can be confusing for beginners.  Just think about it as your
commit staging area.  Having a staging area lets me construct what I
want to commit incrementally.  I find that especially useful when my
working tree is in a messy state.

Try git-add -p some time, and you'll understand.

>> > (overengineering)
>> 
>> If you want a diff, use git-diff.
>> 
>> If you want e-mail ready for sending, use git-format-patch.
>
> I want a patch ready to submit, that is, a diff with the Signed-off-by 
> tag as it is supposed to be able to do this, and the commit summary as 
> it knows about it.
>
> There is no reason it would make me a mail in any format that I don't 
> use.
> mbox is not standard, despite it storing messages themselves in RFC 
> format.

I'm not sure I understand what you're talking about.

git-format-patch puts each commit in a separate file.  Mbox comes into
play only if you use --stdout.

> <obvious>
> Besides the command is named git format-*patch* *not* format-mail!
> </obvious>

>From its man page:

NAME
       git-format-patch - Prepare patches for e-mail submission

>> Me thinks you are still fighting the tool instead of working with it.
>> No happiness found down that way.
>
> It's the tool that is fighting me instead of doing what I want it to 
> do.
> It tries to impose a format on me that I don't want.
> There is no reason I want to setup a mail account on this box while I 
> have all my mail on another box on another OS in another format (almost 
> maildir just better). And I don't like having send-mails hiding 
> elsewhere.

Maybe you're looking for git-show.

> Why does it think I want to let it send mails for me ? I don't like 
> apps that does things behind my back, that sounds so Windows-ish. :^\
> I thought UNIX philosophy was all about interoperability...
>
> </rant>

I trust venting your frustration is good for you, but I doubt it's good
for getting help :)

> Let's see if it still works today...
>
> No commit since fc1c67bc2a43a53f7315b602e0c67f9604835fe1 ?
> Hmm oh, no way to do a "git log" on a git: url without a clone ?

Sorry, I don't understand what you're trying to do.

> Btw, front page: "The a QEMU repository" typo. It could reuse a link 
> too...
> http://savannah.nongnu.org/git/?group=qemu ?
>
> François.

Re: [Qemu-devel] updating git tree

[François Revol]

> > This sounds confuse...
> > anyway.
>
> The index can be confusing for beginners.  Just think about it as
> your
> commit staging area.  Having a staging area lets me construct what I
> want to commit incrementally.  I find that especially useful when my
> working tree is in a messy state.

Sure, likely works much better than grepping svn stat to split stuff,
or
echo "svn ci foo bar/plop -m 'some commit'" >> pending.txt

once you spent the time you didn't have to learn it of course.

> Try git-add -p some time, and you'll understand.

Hmm not documented here, git too old again I guess.

> > There is no reason it would make me a mail in any format that I
> > don't
> > use.
> > mbox is not standard, despite it storing messages themselves in RFC
> > format.
>
> I'm not sure I understand what you're talking about.
>
> git-format-patch puts each commit in a separate file.  Mbox comes
> into
> play only if you use --stdout.

Still it outputs a single mbox mail, not a patch...

> NAME
>        git-format-patch - Prepare patches for e-mail submission

which is different to me than "prepare patch as e-mail for submission"

> > It tries to impose a format on me that I don't want.
> > There is no reason I want to setup a mail account on this box while
> > I
> > have all my mail on another box on another OS in another format
> > (almost
> > maildir just better). And I don't like having send-mails hiding
> > elsewhere.
>
> Maybe you're looking for git-show.

git-show doesn't seem to know about Signed-off-by, so it must still be
done by hand anyway...

Anyway, sed magic works for me.

> I trust venting your frustration is good for you, but I doubt it's
> good
> for getting help :)

Well I'm thankful to you and some other who do try to help, but the
first mails after the announce were more like "oh we switched to git
and don't care if you don't know it and actually laugh at you, everyone
knows git, git is nice, git is all logical, it's you who is weird", at
least that's how I felt it.

> > No commit since fc1c67bc2a43a53f7315b602e0c67f9604835fe1 ?
> > Hmm oh, no way to do a "git log" on a git: url without a clone ?
>
> Sorry, I don't understand what you're trying to do.

Something like
svn log svn://svn.berlios.de/haiku/haiku/trunk -v | more
svn diff svn://svn.berlios.de/haiku/haiku/trunk -r30330:30331 | more

which doesn't require a checkout or a web browser; oh well, nevermind.

François.

Re: [Qemu-devel] updating git tree

[Markus Armbruster]

"François Revol" <revol@free.fr> writes:

[...]
> Again, git is too old here and ENOSPC to distupgrade yet.
[...]

Why not compile git from source and put it in /usr/local?  I'd expect
that to save you plenty of pain.

If you must have it as a .deb, you can try building one from a newer
distro version's deb-src.