[Buildroot] OT: git workflow question

[Buildroot] OT: git workflow question

[Grant Edwards]

I don't seem to "get" git when it comes to working with
buildroot.

 1) I cloned the repository about two weeks ago

 2) I made a bunch of small edits to docs/buildroot.html and
    commited them locally.

 3) I submitted the changes using git format-patch

 4) The patches were merged to the "master" repository

 5) Then when I did a "git pull" to update my repository, it
    failed because of conflicts in docs/buildroot.html

Since I had only changed the one file (and those changes had
been merged into the master repository) I didn't bother trying
to resolve the conflict -- I just blew away my repository and
did a 'clone'.

Here's my question: why was there a conflict?

Is this how git is supposed to work?

-- 
Grant Edwards                   grante             Yow! I'm ZIPPY the PINHEAD
                                  at               and I'm totally committed
                               visi.com            to the festive mode.

[Buildroot] OT: git workflow question

[Thomas Petazzoni]

Le Wed, 16 Dec 2009 16:53:24 +0000 (UTC),
Grant Edwards <grant.b.edwards@gmail.com> a ?crit :

> Since I had only changed the one file (and those changes had
> been merged into the master repository) I didn't bother trying
> to resolve the conflict -- I just blew away my repository and
> did a 'clone'.
> 
> Here's my question: why was there a conflict?

Not sure why, Peter will probably give an explanation.

> Is this how git is supposed to work?

No. You should have made your changes in a separate branch instead of a
master branch. Then, you submit your patches. When they are merged, you
do "git pull" in your master branch. And then "git branch -d
yourbranch". If everything has been merged, "git branch -d" will
succeed, otherwise it will fail (and you can use "git branch -D" to
remove a branch that hasn't been merged).

This is at least how I'm contributing to Buildroot. Not necessarly the
cleanest way, I'm no git expert.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] OT: git workflow question

[Chris Packham]

On Wed, Dec 16, 2009 at 11:53 AM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
>
> Here's my question: why was there a conflict?
>
> Is this how git is supposed to work?

Chances are you changes got massaged on the way in, either
intentionally or by some script/git configuration (whitespace.strip
catches me out a lot). Some maintainers I've seen on other projects
insist that patches are perfect before they apply them. From what I've
seen Peter is a bit more pragmatic and is happy to make small
changes/amendments to patches as they get applied.

When you pull from the upstream buildroot git sees both sets of
changes and flags them as a conflict.

The best advice would be to work on local branches for logical sets of
changes (in my case I've just got one branch because I'm only
tinkering with buildroot). You can then rebase (git rebase
origin/master <branch> or git pull --rebase) these branches or blow
them away when you're done (git branch -d <branch>). Git also has a
merge helper (git mergetool) which can be configured with a graphical
diff tool like kdiff3 to make resolving merges easier.

[Buildroot] OT: git workflow question

[Markus Heidelberg]

Grant Edwards, 2009-12-16:
> I don't seem to "get" git when it comes to working with
> buildroot.
> 
>  1) I cloned the repository about two weeks ago
> 
>  2) I made a bunch of small edits to docs/buildroot.html and
>     commited them locally.
> 
>  3) I submitted the changes using git format-patch
> 
>  4) The patches were merged to the "master" repository
> 
>  5) Then when I did a "git pull" to update my repository, it
>     failed because of conflicts in docs/buildroot.html

If you don't have problems with rewritten history, then "git rebase"
may suit your needs better. Can also be used with "git pull --rebase".

> Since I had only changed the one file (and those changes had
> been merged into the master repository) I didn't bother trying
> to resolve the conflict -- I just blew away my repository and
> did a 'clone'.

You should never need to do a fresh clone. Read about "git reset --hard"
for escaping from a mess.

> Here's my question: why was there a conflict?

I'm aware of 2 possible reasons:
Either Peter has fixed something in your patch before he committed it or
commit 16c1549fd22af9a5fedd98d173a4c229b909af4c, which touched the same
file afterwards, caused the conflict.

Markus

[Buildroot] OT: git workflow question

[Grant Edwards]

On 2009-12-16, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> Grant Edwards, 2009-12-16:

>> Here's my question: why was there a conflict?
>
> I'm aware of 2 possible reasons: Either Peter has fixed
> something in your patch before he committed it

That is what happened.  He combined two patches into a single
commit (he may have fixed other things as well).

-- 
Grant Edwards                   grante             Yow! What GOOD is a
                                  at               CARDBOARD suitcase ANYWAY?
                               visi.com            

[Buildroot] OT: git workflow question

[Grant Edwards]

On 2009-12-16, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Le Wed, 16 Dec 2009 16:53:24 +0000 (UTC),
> Grant Edwards <grant.b.edwards@gmail.com> a ??crit :
>
>> Since I had only changed the one file (and those changes had
>> been merged into the master repository) I didn't bother trying
>> to resolve the conflict -- I just blew away my repository and
>> did a 'clone'.
>> 
>> Here's my question: why was there a conflict?
>
> Not sure why, Peter will probably give an explanation.

That question has been answered.

>> Is this how git is supposed to work?
>
> No. You should have made your changes in a separate branch
> instead of a master branch.

Thanks.  That's the clue I was missing.  The tutorials I had
read on git didn't say that -- they showed all work being done
in the master branch.

> Then, you submit your patches. When they are merged, you do
> "git pull" in your master branch. And then "git branch -d
> yourbranch". If everything has been merged, "git branch -d"
> will succeed, otherwise it will fail (and you can use "git
> branch -D" to remove a branch that hasn't been merged).
>
> This is at least how I'm contributing to Buildroot. Not
> necessarly the cleanest way, I'm no git expert.

I certainly sounds like a better approach that what I was doing.

-- 
Grant Edwards                   grante             Yow! !  Now I understand
                                  at               advanced MICROBIOLOGY and
                               visi.com            th' new TAX REFORM laws!!

[Buildroot] OT: git workflow question

[Markus Heidelberg]

Thomas Petazzoni, 2009-12-16:
> > Is this how git is supposed to work?
> 
> No. You should have made your changes in a separate branch instead of a
> master branch.

I don't think this is always necessary. Depending on the amount of
changes he is working on, working on one branch and rebasing against
origin is sufficient and may be the better approach.

> Then, you submit your patches. When they are merged, you
> do "git pull" in your master branch. And then "git branch -d
> yourbranch". If everything has been merged, "git branch -d" will
> succeed,

No, it will never succeed for him, because Peter applies his patches. It
works for you, because Peter doesn't apply patches from you, but merges
your branches. So the commit SHA1 stays the same in your case.

Markus

[Buildroot] OT: git workflow question

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

Hi,

 >> No. You should have made your changes in a separate branch
 >> instead of a master branch.

 Grant> Thanks.  That's the clue I was missing.  The tutorials I had
 Grant> read on git didn't say that -- they showed all work being done
 Grant> in the master branch.

That can work for quick edits, but then you need to remove the commit
before pulling updates in (git reset --hard origin/master).
I would recommend just creating a branch instead though as it's so
easy/fast to do in git (and it allows you to use git-rebase).

 >> This is at least how I'm contributing to Buildroot. Not
 >> necessarly the cleanest way, I'm no git expert.

 Grant> I certainly sounds like a better approach that what I was doing.

And it's what I would consider the "normal" way of working (it's atleast
how I do it when I contribute something to a project using git).

-- 
Bye, Peter Korsgaard

[Buildroot] OT: git workflow question

[Julien Boibessot]

Hello,

Thomas Petazzoni a ?crit :
>
> No. You should have made your changes in a separate branch instead of a
> master branch. Then, you submit your patches. When they are merged, you
> do "git pull" in your master branch. And then "git branch -d
> yourbranch". If everything has been merged, "git branch -d" will
> succeed, otherwise it will fail (and you can use "git branch -D" to
> remove a branch that hasn't been merged).
>
> This is at least how I'm contributing to Buildroot. Not necessarly the
> cleanest way, I'm no git expert.
>   
Could someone update the Buildroot documentation to explain the workflow
for contributing efficiently to the project ?
I'm a newbie with git and it takes me significant time when I want to
share my work with you.
So I'm pretty sure top contributors have tips to not gather and send
patches manually ;-)

Regards,
Julien

[Buildroot] OT: git workflow question

[Vellemans, Noel]

On 16 Dec, 2009 Thomas has written 
>
>> Is this how git is supposed to work?

>No. You should have made your changes in a separate branch instead of a
>master branch. Then, you submit your patches. When they are merged, you
>do "git pull" in your master branch. And then "git branch -d
>yourbranch". If everything has been merged, "git branch -d" will
>succeed, otherwise it will fail (and you can use "git branch -D" to
>remove a branch that hasn't been merged).
>
>This is at least how I'm contributing to Buildroot. Not necessarly the
>cleanest way, I'm no git expert.


Thomas, this is a problem most of the 'NEW' users are facing.

What is the correct way (or supposed correct way) of working with the
buildroot-git, it's quit hard to get the 'picture' of you are not a git
expert.

Is there a known document (or url) that you can recommend, not that we
all need/want te be git experts, but a guide that helps us in getting
some basic git workflow would be nice.


Regards Noel.

[Buildroot] OT: git workflow question

[Lionel Landwerlin]

I do use the same method than Thomas.
I maintain a local git branch with my patches. Before submitting them
to the list I made this :

#  Grab the local branch which tracks the official buildroot dev branch
git checkout master
# Pull from the buildroot repository to get an up to date image
git pull origin/master
# Rebase my branch on top of up to date buildroot dev branch
git rebase --onto master my_dev_branch_start my_dev_branch

Usually I dont get too much merges, but it depends how many people are
working on the same
packages than me...
The goal is to make the work of the maintainer easier. So your patches
get integrated faster,
and you remain happy :)

Then I submit my patches using :

git send-email master..my_dev_branch

In the pratice it's a little bit more complicated, because you dont
always want to send all your patches,
some of them are not yet ready, etc...

Regards,

--
Lionel Landwerlin

On Fri, Dec 18, 2009 at 9:08 AM, Vellemans, Noel
<Noel.Vellemans@visionbms.com> wrote:
> On 16 Dec, 2009 Thomas has written
>>
>>> Is this how git is supposed to work?
>
>>No. You should have made your changes in a separate branch instead of a
>>master branch. Then, you submit your patches. When they are merged, you
>>do "git pull" in your master branch. And then "git branch -d
>>yourbranch". If everything has been merged, "git branch -d" will
>>succeed, otherwise it will fail (and you can use "git branch -D" to
>>remove a branch that hasn't been merged).
>>
>>This is at least how I'm contributing to Buildroot. Not necessarly the
>>cleanest way, I'm no git expert.
>
>
> Thomas, this is a problem most of the 'NEW' users are facing.
>
> What is the correct way (or supposed correct way) of working with the
> buildroot-git, it's quit hard to get the 'picture' of you are not a git
> expert.
>
> Is there a known document (or url) that you can recommend, not that we
> all need/want te be git experts, but a guide that helps us in getting
> some basic git workflow would be nice.
>
>
> Regards Noel.
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>

[Buildroot] OT: git workflow question

[Chris Packham]

On Fri, Dec 18, 2009 at 3:08 AM, Vellemans, Noel
<Noel.Vellemans@visionbms.com> wrote:

> Is there a known document (or url) that you can recommend, not that we
> all need/want te be git experts, but a guide that helps us in getting
> some basic git workflow would be nice.

Um not sure if you wanted generic git stuff but I found the git
community book [1] pretty good. Its free to download or the online
version includes some screencasts (although my company's firewall
blocks any flash videos so I've not been able to view them).

Everyday Git [2] is fairly short and sweet and give a good picture of
how individuals can interact with a integrator/maintainer. There is
also a git tutorial [3] and plenty of other resources on the git
website [4].

---

[1] http://book.git-scm.com/
[2] http://www.kernel.org/pub/software/scm/git/docs/everyday.html
[3] http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
[4] http://git-scm.com/