[aur-dev] Git workflow

Denis Kobozev

23 Jun 2010 23 Jun '10

8:19 p.m.

Is there a suggested workflow for working with AUR git repo? Suppose I do the following: $ git clone git://projects.archlinux.org/aur.git # code/test feature A $ git commit -a # commit feature A to my local branch $ git format-patch origin # create a patch with feature A # send patch with feature A to origin, patch applied to origin with git am Now branches look like this: ---o---o---A' origin/master \ \---A local/master I do a `git pull` from my local branch and get: ---o---o---A'--- origin/master \ \ \---A---M local/master I then work on feature B and commit it to my local branch: ---o---o---A'--- origin/master \ \ \---A---M---o---B local/master Then I do `git format-patch origin` and get two patches, both for A and B, even though A is already in origin as A'. Is there a better way to do this? Best, Denis.

Show replies by date

Aaron Griffin

23 Jun 23 Jun

8:42 p.m.

On Wed, Jun 23, 2010 at 3:19 PM, Denis Kobozev wrote:

...

Is there a suggested workflow for working with AUR git repo? Suppose I do the following:

$ git clone git://projects.archlinux.org/aur.git # code/test feature A $ git commit -a # commit feature A to my local branch $ git format-patch origin # create a patch with feature A # send patch with feature A to origin, patch applied to origin with git am

Now branches look like this:

---o---o---A' origin/master \ \---A local/master

I do a `git pull` from my local branch and get:

---o---o---A'--- origin/master \ \ \---A---M local/master

I then work on feature B and commit it to my local branch:

---o---o---A'--- origin/master \ \ \---A---M---o---B local/master

Then I do `git format-patch origin` and get two patches, both for A and B, even though A is already in origin as A'.

Is there a better way to do this?

If you're not in control of a branch, it is best not to work on that branch. I generally keep all my work in a separate branch, so that master can be clean and I can rebase as needed. That said, you can also do a "git pull --rebase" as needed, though you will have to address any conflicts

Denis Kobozev

24 Jun 24 Jun

1:32 a.m.

On Wed, Jun 23, 2010 at 4:42 PM, Aaron Griffin wrote:

...

If you're not in control of a branch, it is best not to work on that branch. I generally keep all my work in a separate branch, so that master can be clean and I can rebase as needed.

It's somewhat surprising that the Git documentation and other online info I found rarely describes what happens after you do `git format-patch origin`. Perhaps I've been thinking about this for too long. Suppose I do this: $ git clone git://projects.archlinux.org/aur.git $ git checkout -b feature_a # code, test... $ git commit -a $ git checkout master $ git pull origin $ git checkout feature_a $ git rebase master $ git format-patch master $ git send-email --to "aur-dev@archlinux.org" *.patch Then after a while I'd like to see if feature A has been accepted. I do: $ git checkout master $ git pull $ git log It looks like it has been accepted. Can I be sure it has been accepted in its entirety and that I can delete my feature_a branch? I could've sent a series of patches and some of them have been rejected. Best, Denis.

Dan McGee

1:38 a.m.

On Wednesday, June 23, 2010, Denis Kobozev wrote:

...

On Wed, Jun 23, 2010 at 4:42 PM, Aaron Griffin wrote:

...
If you're not in control of a branch, it is best not to work on that branch. I generally keep all my work in a separate branch, so that master can be clean and I can rebase as needed.

It's somewhat surprising that the Git documentation and other online info I found rarely describes what happens after you do `git format-patch origin`. Perhaps I've been thinking about this for too long. Suppose I do this:

$ git clone git://projects.archlinux.org/aur.git $ git checkout -b feature_a # code, test... $ git commit -a

$ git checkout master $ git pull origin $ git checkout feature_a $ git rebase master $ git format-patch master $ git send-email --to "aur-dev@archlinux.org" *.patch

Then after a while I'd like to see if feature A has been accepted. I do:

$ git checkout master $ git pull $ git log

It looks like it has been accepted. Can I be sure it has been accepted in its entirety and that I can delete my feature_a branch? I could've sent a series of patches and some of them have been rejected.

man git-cherry

Denis Kobozev

2:42 a.m.

On Wed, Jun 23, 2010 at 9:38 PM, Dan McGee wrote:

...

On Wednesday, June 23, 2010, Denis Kobozev wrote:

...
It looks like it has been accepted. Can I be sure it has been accepted in its entirety and that I can delete my feature_a branch? I could've sent a series of patches and some of them have been rejected.

man git-cherry

Wow. Thanks, Dan. `git cherry` is mentioned neither in the official Git tutorial nor in Everyday Git in 20 commands nor in Git User's Manual. And thanks Aaron and Lui for helping me get a better grasp on working with branches. Best, Denis.

Loui Chang

23 Jun 23 Jun

9:11 p.m.

On Wed 23 Jun 2010 16:19 -0400, Denis Kobozev wrote:

...

Is there a suggested workflow for working with AUR git repo? Suppose I do the following:

$ git clone git://projects.archlinux.org/aur.git # code/test feature A $ git commit -a # commit feature A to my local branch $ git format-patch origin # create a patch with feature A # send patch with feature A to origin, patch applied to origin with git am

Now branches look like this:

---o---o---A' origin/master \ \---A local/master

I do a `git pull` from my local branch and get:

---o---o---A'--- origin/master \ \ \---A---M local/master

I then work on feature B and commit it to my local branch:

---o---o---A'--- origin/master \ \ \---A---M---o---B local/master

Then I do `git format-patch origin` and get two patches, both for A and B, even though A is already in origin as A'.

Is there a better way to do this?

You can rebase, but that is not recommended if you are sharing your branches with others via http, or other transfer protocol. It's fine if you're only sending patches via email.

5068

Age (days ago)

5069

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

Aaron Griffin
Dan McGee
Denis Kobozev
Loui Chang